Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News What Are The Drawbacks Of REST?

What Are The Drawbacks Of REST?

This item in japanese

Lire ce contenu en français


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:

  1.  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)."
  2. "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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • HTTP is NOT a transport Protocol

    by Noel Hebert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I stopped reading when Ganesh called HTTP a transport protocol. It
    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

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    From first hand experience, the biggest issue I see with REST is maintenance and documentation. Look at the various OAuth implementations in the wild. Most of them have really poor documentation and often it's totally out of date. Most don't even describe the underlying modeled used by the REST service, so often you have to just make a call and reverse engineer the damn thing. Sure, many think REST is suppose to be schemaless, but that's no excuse for incomplete and wrong documentation.

    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

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Another big drawback is that REST offers a small (not even good enough) query language which drives developers to design CRUD APIs when they are lazy (why add an operation or a resource when you can add a property to an existing resource). When they are less lazy it drives them towards building resource-oriented APIs (customer, employee, order, ...). Of course ... that's the point, but in reality, this is still the wrong interaction model.

    Why? We always access information in context. Compare these two API calls:
    GET /v1/customers/1234
    GET /v2/orderservice/customers/1234

    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

    by Florin Neamtu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Totally agree with Jean-Jacques, fortunately there are still common sense people on this planet! We'll see REST systems in couple of years, when maintenance and expandability will come into play. Most systems following REST principles are green field development. Very little care towards maintainability or service reuse and governance.

  • The confusion on REST

    by Rickard Öberg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    While reading this keep in mind that the majority of REST libraries and applications today aren't really REST, following the constraints that Roy described in his original paper. Also keep in mind that the whole use case orientation that it would naturally promote if followed is entirely missing, as JJD pointed out in his comment. If REST APIs are designed from a use case point of view, following all constraints (including HATEOAS), then the situation is far far different. It's just that noone is doing that, and still call it REST. It should instead be called "CRUD using JSON+HTTP", which in my experience is stupid for most applications. But that's what the real problem is, developers not realizing this difference and how it impacts the results.

  • Re: The confusion on REST

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    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.
    GET /v1/customers/1234
    GET /v2/orderservice/customers/1234

    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

    by Ryan McDonough,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you were building a hypermedia-based API, you wouldn't bake context into the URI. URIs are opaque identifiers and clients shouldn't be forced to infer meaning or context from the URL. Your example assumes that a URI structure has some type of meaning. If you were using hypermedia properly, context would baked into another resource that informs the user of the context, rather than relying on what's in the URL.

  • Re: The confusion on REST

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    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.


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p