What Are The Drawbacks Of REST?

Several years ago Ganesh Prasad asked Is The Internet More Fundamental Than REST? Over the intervening years he's continued to raised discussion around REST, SOA and more recently Cloud, favouring REST guiding principles. However, recently someone posting on the LinkedIn REST Architects group asked the question "What Are The Drawbacks Of REST?" Ganesh wrote a response, which he repeated in his blog:

I wouldn't say REST has "drawbacks" as such. It does what it says on the tin, and does that very well. But remember that the only implementation of the REST architecture uses the HTTP protocol. We can surely think of a future RESTian implementation that uses another transport protocol, and that is where some improvements could be made.

He then goes on to talk about four areas for possible improvement and it is worth noting that as with many people, Ganesh equates REST to REST/HTTP, i.e., REST over HTTP:

1. "HTTP is a synchronous, request/response protocol. This means the protocol does not inherently support server-initiated notifications (peer-to-peer), which are often required. That's why callbacks in RESTian applications require the use of application-level design patterns like Webhooks. Now that we have a bidirectional transport protocol in the form of WebSockets, perhaps the industry should be looking at layering a new application protocol on top of it that follows RESTian principles." This is interesting, given that over the past year or so we have seen others discussed whether WebSockets and REST are even compatible.
2. Ganesh believes that there is at least something that REST community could learn from the Web Services stack: "These are all end-to-end protocols layered on top of the core SOAP+WS-Addressing "messaging" capability." Others have suggested similar in the past. Ganesh then goes on to discuss an analogy between the way Web Services uses WS-Addressing, WS-ReliableMessaging, WS-SecureConversation and WS-Policy and the internet equivalents including TCP, IP and IPSec. Ganesh suggests that REST's application idempotence may be better for reliability (though does not define better in any context), and perhaps there are alternatives to transactions for REST, but he is left with:

But what remains is security. WS-SecureConversation with WS-Security is routable, unlike SSL/TLS, which is the only security mechanism in REST. With WS-Sec*, messages can also be partially encrypted, leaving some content in the clear to aid in content-based routing or switching. This is something REST does not have an elegant equivalent for. SSL is point-to-point, cannot be inspected by proxies and violates RESTian principles. It is just tolerated.

This is interesting because others, such as Resteasy's Bill Burke, have suggested that REST needs a better approach to security. But Ganesh goes on to address REST and QoS in general:

The reason behind REST's inability to support such QoS in general is that all of these require *conversation state* to be maintained. Statefulness has known drawbacks (i.e., impacts to scalability and failure recovery), but with the advent of NoSQL datastores like Redis that claim constant-time, i.e., O(1), performance, it may be possible to delegate conversation state from memory to this datastore and thereby support shared sessions for multiple nodes for the purposes of QoS alone.

But returning to the last two points Ganesh has:

3.  He believes that HTTP has too few verbs, particularly if you want to do peer-to-peer interactions and has a few suggestions: "INCLUDE (add to a resource collection and return a server-determined URI), PLACE (add to a resource collection with client-specified URI), REPLACE (in toto), FORCE (PLACE or REPLACE), AMEND (partial update, a container verb specifying one or more other verbs to specify operations on a resource subset), MERGE (populate parts of the resource with the supplied representation), RETIRE (a better word than DELETE) and SOLICIT (a GET replacement that is also a container verb, to tell the responding peer what to do to the initiator's own resource(s), because this is a peer-to-peer world now)."
4. "HTTP combines application-level and transport-level status codes (e.g., 304 Not Modified and 400 Bad Request vs 407 Proxy Authentication Required and 502 Bad Gateway). The next implementation of REST on another transport should design for a cleaner separation between the application protocol and the transport protocol. HTTP does double-duty and the results are often a trifle inelegant."

Looking at the initial draft of HTTP 2.0, it is unlikely to address all of Ganesh's suggestions. However, it seems that Ganesh himself has been working for the past 5 years on a proposed specification:

I'm in the process of writing an Internet Draft for a new application protocol that can be bound to any transport (Pub/Sub, Asynchronous Point-to-Point or Synchronous Request/Response). The protocol is part of a new distributed computing architecture that I call ROMA (Resource/Representation-Oriented Messaging Architecture) and covers not just the data model and message API but also higher levels (QoS, description and process coordination).

Once this is published, it will be interesting to see how it addresses these perceived problems and whether it receives a positive reception from the REST community.