A number of these points are not really a criticism of RESTful principles per se, but rather of typical REST over HTTP approaches.<p><i>1) Asynchronous APIs</i><p>There's nothing about REST that says that operations must be performed synchronously. If a client updates a resource via a PATCH method and other services are notified of the update via a web hook or a message bus (possibly including the PATCH or the full resource), the system is still following a RESTful design.<p><i>2) Orchestration / Experience APIs</i><p>A RESTful API does not need to require a separate GET for every individual resource. There's nothing wrong with implementing bulk queries that return variable projections of the server state tuned to the need of particular use cases.<p>Bulk modifications are trickier, especially when atomicity comes into play. But if atomicity is not a concern, then this is more of a transport problem, not a semantic one.<p><i>4) Binary protocols</i><p>Plenty of RESTful APIs (e.g., Twitter[1]) provide data in a number of payload formats. Choice of wire format is unrelated to whether or not the semantics of the API are RESTful.<p>[1] <a href="https://dev.twitter.com/docs/things-every-developer-should-know" rel="nofollow">https://dev.twitter.com/docs/things-every-developer-should-k...</a>
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.<p>Better title: "Is using REST for everything a bad idea perhaps?" Turns out that yes, yes it is.
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; #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.<p>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.
Interesting that REST and JavaScript ended up in the same graph.<p>So I reckon the REST is dominating the field, SOAP is on the way out and JavaScript is the little upstart that could?<p>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 them over those that are not.<p>I keep trying to read the article and I have huge problems. I recognize the words, but I have no idea what the author is trying to say.
A link bait title with a graph that portrays REST growing faster than all other alternatives.<p><a href="http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines" rel="nofollow">http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines</a>
If he's making the claim that "there are a number of initiatives, technologies and discussions that are starting to nibble at the crust of the de-facto standard that REST has become.", then surely he would have evidence of this claim?<p>To start with:<p>1. Label your axis, that graph doesn't say anything.<p>2. Maybe we should be looking at percentage change in the graph rather than whatever is being graphed here.
the 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.<p>deep ops on multiple objects complicate things even further.<p>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.
Async is an important category that deserves better coverage. Fundamentally, REST and the alternatives (SOAP, etc.) are all RPC protocols. They may make use of the RPC nature of HTTP or maybe like XML-RPC they shove another RPC layer on top. A remote procedure call sounds like the simplest component of a remote api, but it is not. In RPC you make a request and wait for a reply.<p>But with async, you send a message and that is it. This can be implemented on top of HTTP RPC such as with Websockets, but the HTTP layer is unnecessary. Messaging using the AMQP protocol is a nice alternative. You can open a socket and hold it open for sending and receiving messages. When you send a message, it can be received by an MQ broker like RabbitMQ for guaranteed delivery to whatever internal service(s) need to process it. And when some kind of result needs to be sent back to the message originator, the socket is open and ready to receive it. For those things where the app needs RPC, it is simple to send a message and wait for a reply message. But when all you need is a notification going out, or coming in, that works too.<p>While MQTT and ZeroMQ and others could be used, it would be nicer if the Internet standardized on AMQP at a known port (just like HTTP) and even included the use of an MQ broker with all the optional services (topic queues, persistence, guaranteed delivery) that can be provided.
All these are limited when you take a step back.<p>The concept of poking about with HTTP to try and treat it vaguely like a TCP style transport protocol is rather silly.<p>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."<p>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.<p>yes its a bit harder, but you know, its smaller, better, more efficient.
This article just demonstrates the author's total lack of understanding of REST.<p>Let's start with asynchronous API. You can easily POST a request, get a new URL back, the just poll it until you get a result (returning 202 in the meantime). The simplest article explaining it can be found here:<p><a href="http://www.infoq.com/articles/webber-rest-workflow" rel="nofollow">http://www.infoq.com/articles/webber-rest-workflow</a><p>It's not even that hard - almost every website that generates non-trivial reports does it somewhere. REST hides all the implementation details behind simple resources (URLs in the HTTP world).<p>Orchestation: Go look up SPARQL. Yes, the language itself isn't pretty, but it's proof that you can orchestrate some pretty complex reports if you like. As pcl notes, you can do it with simpler URLs too. It's all down to the web service.<p>For SDKs... they tend to be reserved for the nastier APIs (usually involving XML).<p>Binary protocols? Seriously? There are entire theses dedicated to the fact that HTTP was designed to deal with this stuff. Go read the documentation on HTTP Accept headers.<p>I'm not surprised there are badly designed HTTP interfaces out there; but criticising the architectural style itself based on your own lack of knowledge helps nobody.
I'm having trouble understanding the continual claiming that REST is not asynchronous - which I guess means that REST is synchronous. Saying it once would be a typo, but several times and I start to feel there is a distinct difference of opinion between myself and the author as to what constitutes a Restful architecture.
I like to start with REST, I feel it's a great canvas, and a great way to think about what I am delivering. And if I can get the design to work within it's confines, then that's what I'll go with. It almost never ends up fully RESTful, and that's usually because the complexity required in the code would impact the maintainability. And to me maintainability is usually more important.
I love that REST is popular and SOAP is not (bad memories of SOAP). These days web sockets make streams and the unix process model of command parameters, environment, input and output possible.<p>A good module that uses this philosophy is:<p><a href="https://github.com/substack/shoe" rel="nofollow">https://github.com/substack/shoe</a><p>As with everything - pick the right tool for the job. It helps to have more rather than less tools.
Its an OK article but I was really expecting to see some alternatives. I'm truly interested in something that compete with REST but was left wanting by the article.
Somewhat related question I've been meaning to ask. Why isn't xmlrpc more popular? At least in python it's incredibly easy to set up and to consume.
RESTful services still work in those situations where they are correctly applied. Maybe what has happened is some of the less mature and more shrill developers have stepped back from their war on any Web service that doesn't fit their dogmatic rest-tard view of the world. There are plenty of valid XML-RPC based services that continue to run well despite the whining that someone somewhere did not yet have a ruby gem to connect their ruby on fails site to it and that it was simply unacceptable - and so complain on twatter they must!<p>So in short - no, REST works, use it in the right places, and remember kids - not every Web service or endpoint has to expose a REST based interface.