In recent times, legions of API developers have adopted REST over any other technology approach to create public APIs
REST or Representational State Transfer emphasizes, that interactions between clients and services is enhanced by having a limited number of operations (verbs). Flexibility is provided by assigning resources (nouns) their own unique universal resource indicators (URIs). Because each verb has a specific meaning (GET, POST, PUT and DELETE), REST avoids ambiguity.
It is an “architectural style” that basically exploits the existing technology and protocols of the Web, including HTTP (Hypertext Transfer Protocol) and XML and is simpler to use than the well-known SOAP (Simple Object Access Protocol) approach, which requires writing or using a provided server program (to serve data) and a client program (to request data).
But why REST ?
Let’s dissect it a bit:
- SOAP/WSDL is overly complex in most cases and difficult to consume from thin clients.
- The REST architectural style fits well with HTTP and the scalability, caching and distribution best practices prevalent in large-scale web and mobile applications.
- The common use of JSON within REST APIs makes them extremely easy to consume from scripting-based platforms (web/Ajax, node.js, grails, etc.)
But often within the strengths of a particular system/ program lie the chinks which force us to look for alternatives, especially in this age where innovation is driving more and more user centric experiences and solutions.
Asynchronous APIs:
In our world, connected devices constantly publish sensory data (eg status updates) to other applications that are listening- but this imposes unnecessary bandwidth and processing requirements on the device itself. To explain with a simpler example, think how your smartphone battery drains when your push notifications are on and why mobile devices are striving harder to improve mobile chip performances, (eg the iPhones A6 Chip) thereby driving costs higher.
With asynchronous APIs you can publish all this sensory data but without the traditional format of a request and response where the device constantly needs to poll for this data. Asynchronous APIs do not fit very well within the REST structure.
Experience API’s
With every web and mobile application today integrating multiple threads of data, pulling them all together into one interface/ dashboard can be a daunting task, since it may require multiple API requests at the same time, thereby increasing server processing load and bandwidth. Example if you are a content publisher on web/ mobile, you need developers who can create applications on your API, for content providers to publish using your platform. Increasing the number of API requests for each content streaming application on the cloud will make the developer’s life difficult and increase time required by the customer to access that content as well. At this point, creating internal APIs at the server and publishing very usage specific “experience APIs’ can make a huge difference for clients and developers alike.
SDK’s
More and more organizations today are creating customized solutions which are integrated with their operating systems and service architecture. In most cases the functionality of all these solutions are being derived from languages like Python, Ruby, Java etc, which are then fed via APIs into a consumable model for customers. To keep the experience of their eco-system intact, many API providers are creating prebuilt client libraries for these languages (Google, Facebook, Apple 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 or a more RPC-like usage of HTTP resources (for example with JSON-RPC).
Binary Protocols
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.
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.
To summarize as mentioned by Daniel Jacobson;
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.
