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:
- "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.
- 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.
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:
- 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)."
- "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.
HTTP is NOT a transport Protocol
is application transfer protocol. TCP/IP is the transport! If he wants to
see another RESTful implementation, look no farther then NetKernel.
Documentation and maintenance
To be fair, that's not a problem specific to REST and plagues software development in general. One reason I like SOAP WS over REST is the schema and operations are all defined. I don't have to spend time reverse engineering the API because some developer was too lazy to write it. Most mature SOAP stacks auto generate the WSDL, so even if a lazy developer wrote the service, the tooling will at minimum generate the WSDL.
Rest has it's place, but it's not better. It's different. Sometimes it's appropriate and other times it's not.
CRUD, Resource Orientation, Service Orientation
Why? We always access information in context. Compare these two API calls:
The first API call is a call without context. The second allows you to access customer information in the context of the order service, which is different from the payment service or the support service. Why would you couple the "customer" resource to all possible contexts in which customer data can be accessed? how about employee data (contexts: contacts, payroll, benefits...).
REST works in the small, when CRUD is ok or when the number of contexts is very small. It works great for a Web Page, sorry resource, a Web Resource, for instance which has exactly a CRUD lifecycle. Actually, even there it is not great because you can't create "expiration" policies, a major oversight in the lifecycle of a Web resource.
In the enterprise REST does not work because it creates a massive "knot" around each resource and couples all contexts in an infortunate contextless resource oriented model.
Worse, if you use REST poorly, you even face the coupling between the "access" to a resource and its "identity". As you can notice in the two calls above I cannot reuse /v1/customers/1234 as an identity once I found the customer I was looking for, I have to parse the path to extract the identity to make the second call. That's a major issue for Hypermedia, because contexts are there, whether you like it or not.
REST is dead, the pundits who drove us there are no longer talking about it. Subbu has moved on. Stefan is back at the UI level, where REST belongs, Jim Webber works on a graph database, Mike Amundsen has been cornered to make hypermedia work. It won't work, Hypermedia is the UDDI of REST, nice idea on paper, totally impractical, in practice. "Shared Understanding" has been studied for 30 years at least and it never comes cheap or easy.
Time to unREST. Let's be honest as an industry and let's not waste any more time on these silly questions, just use CRUD where it makes sense (very rarely), Resources when you have one context or two and Services/APIs everywhere else. If you want to use HTTP/Swagger, SOAP/WSDL, XML or JSON, that's your choice. Personally, I don't care, I am a metaprogrammer.
Re: CRUD, Resource Orientation, Service Orientation
The confusion on REST
Re: The confusion on REST
I find it a bit "easy" for a RESTafarian to brush off resource-orientation and "pivot" back to service orientation 7 years after Tim Bray threw the REST wrench into SOA.
I would encourage you to look carefully at the claim you make that HATEOAS is compatible with a context-based approach, because it is not...
There is a very simple reason for that, in the example I provided above, I paid special attention to include the version of the API calls that I am making.
In a "use case" driven world, I would search for a customer, find its id and then query its orders. I could easily see how an "app" could be build to do just that. The problem though is that the client, and only the client, decides which context is next, and which version of that context to use: v1 of search to find a customer and v2 of order service to find the purchase history of that customer.
Hypermedia cannot be composed across context boundaries. You need a coordinator for that. The coordinator could of course produce a clean piece of Hypermedia, but, it does not change the fact that you need a coordinator separate from the APIs themselves. It would actually be a terrible coupling for the "search" service to have to know every possible context you can access customer information from.
Imagine, say Amazon, somebody references a book with a link, but customers who read that post need to enter the amazon store in which they can buy the book. The book may not even be sold in their country. You need to decouple the "identity" from contextual access to the resource. D
oes it really make sense to create a "knot" of all possible contexts (using HATEOS) in which that particular resource is used? No. A big NO. When you can, in the small, it is true that it beautiful, almost magic, but in the large, you simply cannot.
So, no, REST does not work, including HATEOAS, in a contextful world. Some people can create funny presentations, write simplistic articles, or vice versa but in the end, we are back where we started: you access data in a context (not through a mythical business object or resource) and contexts can't be composed easily, one of the key aspects of composing contexts is a uniform identity mechanism, which REST does not provide because it couples access with identity.
Re: The confusion on REST
Re: The confusion on REST
Could you please explain how you would decouple (contextual) access from identity using hypermedia and context resources? You can use the example I provided above: "Imagine, when someone references a book in a post with a link, but customers who read that post need to enter, say, the amazon store in which they can buy the book. The book may not even be sold in their country". I am sure it can be done, but I'd like to compare a "standard" approach with a REST approach. Bonus points if you can also show how API versioning works on top of the contextual access.
Ralph Winzinger Nov 25, 2014
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014