Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Are REST Alternatives Needed?

Are REST Alternatives Needed?

Leia em Português

This item in japanese

Lire ce contenu en français


Ole Lensmar, the creator of SoapUI, recently asked whether REST is "losing it's flair" and if there's a need for alternatives? As he says:

The adoption of REST as the predominant method to build public APIs has over-shadowed any other API technology or approach in recent years. Although several alternatives (mainly SOAP) are still (very) prevalent in the enterprise, the early adopters of the API movement have taken a definitive stance against them and opted for REST as their approach and JSON as their preferred message format.

He discusses why he believes REST has become more successful than other approaches such as SOAP and XML-RPC. However, Ole thinks that there are a number of areas where REST does not work well and where alternative approaches are needed. These include:

  • Asynchronous APIs: "The need for pushing out data asynchronously instead of the traditional request/response doesn’t always fit well with a RESTful design. Furthermore, the underlying technologies (WebSockets, MQTT, AMQP, Stomp, pubsubhubbub/WebHooks – to name a few) are often very different from HTTP and therefore often don’t align well with REST principles either."
  • Orchestration APIs: "The resource granularity given by traditional REST APIs isn’t always an advantage; pulling required resources into a mobile dashboard or complex single-page web application can require many API requests – which adds overhead to both the client logic, bandwidth and server processing."
  • SDKs vs APIs: "Most API consumers are ultimately consuming these from some high-level language; javascript, python, ruby, java, etc. which has lead to many API providers including prebuilt client libraries for these languages (Google, Facebook, etc.). Since the languages themselves are often more RPC oriented, so is the code-level API exposed by the SDK – paving way for the backend API to work in a similar fashion, perhaps by using more optimized binary protocols (see below) or a more RPC-like usage of HTTP resources (for example with JSON-RPC)."
  • Binary protocols: "[...] for optimized message transfer for example required in IoT devices or SDKs, several binary protocols are getting more attention and usage" such as Apache Thrift, Google Protocol Buffers, Apache Avro. "[It is worth noting] that several of the asynchronous API technologies mentioned above use a binary format – related to the bandwidth and processing restrictions imposed by their harboring devices or services."

Ole uses the example of Evernote who used Thrift as their underlying protocol because of real-time requirements, (which presumably is something Ole believes is beyond the abilities of REST as well). As he says, referring to a separate article by Daniel Jacobson on Evernote's RESTless design:

[...] REST API is perhaps good when you are targeting a large number of unknown developers – but when your API targets very specific users, markets, industries or technologies, the need to choose a more specific solution is not unreasonable – it might even result in advantages over your competitors in terms of performance, easy-of-use or security.

Ole concludes by admitting that one-size typically does not fit all, especially where API design is concerned. "Fortunately for us passionate technologists, building and learning new stuff and putting it to use in the best possible way for all stakeholders is what makes our world tick (or at least mine). So, I’m not opposed to this diversity, I welcome it."

However, whilst some people agree with Ole in his comments, many others disagree. For instance John Sheehan says:

I don’t think Evernote abandoned REST, they never used it from the beginning and had a reasonable justification for doing so. Also, webhooks can be very ‘REST’-y (at least in the popular understanding of the term). The caveats you list in the Asynchronous section do not apply for the most common implementations.

And Darrel Miller tries to differentiate between REST and "pop REST" (his term):

From what I can tell from Daniel Jacobson’s description of an orchestration layer, it maps very closely to the way I have been building RESTful (and hypermedia driven) APIs for a number of years. Just because people are starting to see through the hype of “pop REST” doesn’t mean that anything has changed about the properties of Fielding’s REST.

In fact many of the commenters believe that Ole has not differentiated between truly RESTful principles and implementations that say they are RESTful but are not. What do you think? Is REST really applicable in all of the areas Ole has outlined? If not, what alternatives would you recommend?

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

  • Article feed-back, real REST limits, HTTP/2.0

    by Jerome Louvel,

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

    Great article Mark. IMO, most of the issues described are not intrinsic to REST, more about HTTP/1.1 or the way it is used.

    1) Asynchronous APIs: not a fundamental issue as illustrated by W3C HTML 5 server-sent events and HTTP/2.0 server push capabilities

    2) Orchestration APIs: not an issue at all, it is perfectly possible (and desirable) to have several APIs for each user case/channel/device to ensure aggregate/customized HTTP calls are available to each type of client.

    3) SDKs vs APIs: this is where we need to have a separate architecture style from formal REST (hypermedia driven). See my initiative for a "Web API" style:

    Based on the availability of web API/HTTP contracts, tooling can easily be built such as high level client SDKs. Still, the network HTTP API is staying the lingua franca and not a given/compatible software stack (like in SOAP world).

    4) Binary protocols: again being solved by HTTP/2.0 as already technically proven by SPDY.

    Best regards,
    Jerome Louvel

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

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