21–30 of 82 posts
Earlier quoted context omitted.
In context, the graph is intended to show the dominance of REST over time and not how it's losing out to any of the other items.
What the fuck is JavaScript thing doing in there then?
A good module that uses this philosophy is:
https://github.com/substack/shoe
As with everything - pick the right tool for the job. It helps to have more rather than less tools.
Earlier quoted context omitted.
What the fuck is JavaScript thing doing in there then?
I was puzzled briefly as to what JavaScript was doing there but thinking about it I've been doing some stuff with google maps and the API for that is mostly done with JavaScript objects.
REST is not losing its flair, this article's four points focus on things that have mostly nothing to do with the huge bread and butter of web services, which is getting businesses to talk to each other and share data between entirely unrelated applications. #1 does not apply because these are simple data sharing services and async has nothing to do with it; #2 does not apply because these services are not internal; #…
Interesting that REST and JavaScript ended up in the same graph. So I reckon the REST is dominating the field, SOAP is on the way out and JavaScript is the little upstart that could? I don't think the person writing this article has any grasp on what REST actually is. If they knew they wouldn't be comparing it to the "Asynchronous APIs". I use asynchronous API's everyday. And some of them are RESTful and I prefer the…
1. REST is not inherently uni-directional. This is especially going to be the case in the internet of things, where you're just as likely to have servers on both ends. 2. You can do server->client push with Server-Sent Events.
Answer: This isn't even applicable. REST is still a good tool that applies to many jobs, use it where it makes sense, don't use it where it doesn't. Better title: "Is using REST for everything a bad idea perhaps?" Turns out that yes, yes it is.
For the vast majority of these uses, "REST" is a worthless and meaningless buzzword, so that's not a better title as the rise and fall of "REST" has nothing to do with it.
REST is not losing its flair, this article's four points focus on things that have mostly nothing to do with the huge bread and butter of web services, which is getting businesses to talk to each other and share data between entirely unrelated applications. #1 does not apply because these are simple data sharing services and async has nothing to do with it; #2 does not apply because these services are not internal; #…
Yeah. I've found a weird dichotomy in the general push to use "REST" for web APIs, but then certain aspects (true statelessness, for instance) are met with blank stares.