Are REST Alternatives Needed?
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."
- 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?
Article feed-back, real REST limits, HTTP/2.0
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: 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.
Mike Amundsen May 29, 2015
Ben Linders May 28, 2015