Why Web APIs Won
In the last decade, the “API” pattern has grown to dominate interactions between clients and servers on the Internet. Many of the largest and most-used apps on the internet today are built atop APIs.
APIs have even begun to take over communications between clients and servers within corporate networks. APIs have become so prevalent that all software developers working on the internet know one when they see one.
But, for the purposes of completeness, we will assert that APIs have the following characteristics:
Clients and servers communicate using HTTP
HTTP URIs and verbs are used to define the abstraction that the server presents
The data exchanged is primarily JSON
Requests and responses are encrypted using TLS and secured using OAuth
Any other complexity is unnecessary
In one way, APIs are just the latest instance of the client-server interaction pattern that has underpinned our work for decades. But it would be over-simplistic to say that an API is just the younger generation’s version of RPC (remote procedure call). Instead, well-designed APIs are the product of an evolution from complex, specialized technology designed by academics to simple, almost naive technology designed collaboratively by working software developers.
Useful, usable, and simple
Consider this: a well-designed API requires nothing from the client but software capable of sending an HTTP request and parsing JSON. That is in contrast to every other client-server technology that preceded it. Just as a web browser enables the user to interact with thousands of applications without installing any new software, the API enables an application developer to interact with thousands of web services without having to purchase or install a “client.” As new platforms, languages, and frameworks are developed, a good API remains useful and usable.
This simple aspect is often overlooked but it is the key to the success of the API. A developer considering using an API in his or her new product need not worry about which platforms or technologies are supported. Furthermore, developers may test the API and troubleshoot its functionality using a simple tool like “cURL,” which speeds development.
The other key aspect of the API movement is how it was built. APIs were not created by a software company or a standards body. Rather, software developers understood that ubiquitous de jure standards, such as HTTP and MIME, combined with emerging de facto standards like JSON, gave them everything they needed, so they went ahead and used them. In doing so, they ignored the complex security protocols and Byzantine data formats from previous generations of client-server technology in favor of something newer and simpler.
The risk of premature optimization
Still, the simplicity of APIs is often unappreciated. Software developers, architects, and academics continue to propose and implement client-server technology that's more complex.
For example, there's growing academic interest in the idea of hypermedia and its application to the world of APIs. This concept is nothing new—in fact, it dates back at least to the work of Roy Fielding and others on the HTTP protocol and the World Wide Web. The idea of designing clients that use hypermedia to navigate an API, discover its capabilities, and adapt to changes in the server’s behavior is a powerful one that can solve several interesting problems. But fully adopting hypermedia requires a very smart client, and it will require ever more complex protocols and more complex client stacks.
Similarly, APIs are not the most efficient way for clients and servers to communicate. Special-purpose RPC protocols can handle higher throughput with lower latency, and the world has not stopped creating new ones. Yet APIs are “good enough” for thousands of high-volume mobile applications—a fact that is often lost in the service of premature optimization.
If we’re not careful, these trends will lead us back to the world of complexity that APIs were a reaction against.