A link bait title with a graph that portrays REST growing faster than all other alternatives.
REST API Alternatives
11–20 of 82 posts
Re: REST API Alternatives
#12REST 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; #3 does not apply because the other business you're talking to, RPC what? SDK-what? can I just send you my customer data in an XML file? #4 does not apply because see #3.
Then again, most "REST" as practiced for intra-business data is not really "REST" as far as purists would be concerned; while we at least do things like use HTTP error codes instead of an HTML page with "error" on it under a 200, I'd be laughed out of the conference room if I suggested our clients use a PUT instead of a POST. But who cares, as long as it's not SOAP.
Re: REST API Alternatives
#13All these are limited when you take a step back.
The concept of poking about with HTTP to try and treat it vaguely like a TCP style transport protocol is rather silly.
If you think about how "wordy" HTTP is, along with the standard RESTful verbs, you'll start to think "hmmm, perhaps this isn't the best way."
Websockets and if you must a bit of JSON (binary if done properly is lower latency and much more efficient) should be the way forward.
yes its a bit harder, but you know, its smaller, better, more efficient.
Re: REST API Alternatives
#14The next big thing: noREST.
Re: REST API Alternatives
#15The next big thing: noREST.
[deleted]
Re: REST API Alternatives
#16its never been REST vs asynchronous Apis. You will probably use both in the same project for different usecases
Re: REST API Alternatives
#17the place where REST over HTTP fails badly IMO is batch operations and deep operations. when creating multiple entities at once, you cannot get back multiple location headers. and even if you could get back several headers, you have to re-request each of them via http to get their contents. it obligates you to be needlessly chatty.
deep ops on multiple objects complicate things even further.
i feel like once you get outside the realm of basic document storage (which is what HTTP was designed for), REST via HTTP headers completely breaks down into custom hackery for which there are no standards.
Re: REST API Alternatives
#18Utter linkbait.
Re: REST API Alternatives
#19I'm still a huge fan I do apply the resource think to most stuff I build.
Re: REST API Alternatives
#20The next big thing: noREST.
My money is on RESTless, which in the form of RESTless web syndrome can cause sleepless nights.