This guest post comes from Ole Lensmar, the creator of SoapUI and Chief Architect at SmartBear Software. Follow him at @olensmar
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. All this for good reasons:
Undoubtedly REST is still the poster child of the API movement, but there are a number of initiatives, technologies and discussions that are starting to nibble at the crust of the de-facto standard that REST has become. To name a few:
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.
The need for asynchronicity is especially prevalent within the Internet of Things; connected devices need to publish status-updates, sensory data, etc. to other applications that are listening – instead of those applications having to poll them continuously, which would impose unnecessary bandwidth and processing requirements on the devices themselves (which are often extremely restricted).
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. Orchestrating internal APIs at the server and publishing very usage-specific “experience APIs” can therefore make a huge difference in performance and simplicity for client developers. These APIs don’t have any desire to follow RESTful principles – they are all about optimizing both the end user and developer experience – Netflix was one of the first to publicly tout this approach – and others have followed (see this post from TheNextWeb.com).
This one ultimately ties in with several of the above; for optimized message transfer for example required in IoT devices or SDKs, several binary protocols are getting more attention and usage:
a. Apache Thrift was originally created by Facebook but is now being developed under the Apache organization and used by for example last.fm and Cloudera.
b. Google Protocol Buffers is used by all Google APIs internally.
c. Apache Avro is the primary internal protocol used by Hadoop.
Common for these is the need for an interface definition in a protocol-specific format, which is then processed by included tools to generate code for supported languages. All have support for most popular languages today – the difference between them lies in the details and naturally needs to be matched against ones specific needs.
Also worth noting is 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.
One example of a company that has abandoned a traditional RESTful approach is Evernote; they provide their 3rd party developers with an SDK using Apache Thrift as the underlying protocol – mainly to optimize their real-time synchronization requirements – something that I’m sure many other real-time application providers will follow with interest as they decide which technologies to use for their APIs (check out this recent PW article).
Underlying a transition to any of the above is perhaps also the maturing of the API market itself; like Daniel Jacobson noted in his post referred to above, a granular 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.
Obviously there is no one-size-fits-all solution for building APIs – and as the world of APIs grows it is only natural for its adopters to look elsewhere when one technology or another doesn’t fit their or their customers needs. 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.