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?

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: github.com/restlet/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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.