The History of REST APIs In 1999, the API environment was a free-for-all. At that point, most developers had to deal with SOAP (Simple Object Access Protocol) to integrate APIs. And the “simple” part of that acronym is not to be taken literally. To make a call, they had to hand-write an XML document with an RPC call in the body. From there, they had to specify the endpoint and POST their SOAP envelope to that specified endpoint. A super simple SOAP API request looks something like this: If it looks nonsensical to you, it should. All of this is put together to meet an arbitrary set of guidelines specified in the documentation, which explains the transport bindings, types of data that can be accessed, parameter lists, operation names, and the endpoint URI. And if the call doesn’t work, there aren’t any HTTP respond codes to nudge you in the right direction. SOAP was notorious for being complex to build, complex to use, and near-impossible to debug. And the alternative, CORBA, was even worse. The problem was that there was no standard for how APIs should be designed and used. Back then, APIs were not designed to be accessible, they were only designed to be flexible. But a small group of expert developers recognized the true potential of web APIs. Thanks to this small group, led by Roy Fielding, REST was coined and the API landscape changed forever. Here’s how it all went down: The birth of REST: Roy Fielding’s dissertation In 2000, Roy Fielding and his colleagues had one objective: Create a standard, so any server could talk to any other server in the world. Here’s what he came up with in his doctoral dissertation: I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST. Uniform interface. This means we always use HTTP verbs (GET, PUT, POST, DELETE). We always use URIs as our resources. And we always get an HTTP response with a status and a body. Stateless. This means each request is self-descriptive, and has enough context for the server to process that message. Client-server. There has to be clear boundaries between roles of the two two systems. One server, operationally, has to function as the server that is being called, and the other has to function as the one making the requests. Cacheable. Unless denoted, a client can cache any representation. This is possible thanks to the statelessness—every representation is self-descriptive. Another important difference between REST and SOAP is that it’s resource-based. That means the API accesses nouns (aka URIs), instead of verbs. Then, HTTP verbs are used to access those resources. It seems like there are a lot of rules, but those rules are universal. It forces the API to be simpler, and makes the learning curve for developers trying to integrate software significantly less steep. Roy Fielding gave the disorganized internet world the gift of a common language through which their software could communicate. Learning to make money from an API Salesforce was technically the first company to sell an API as part of their “internet as a service” package in 2000, but few developer teams were able to take advantage of its complicated XML API, equipped with a 400+ page PDF manual. eBay, on the other hand, built a REST API, and has shown the world just how lucrative an accessible API can be. Seeing what Salesforce was up to, eBay jumped on the opportunity to give select partners access to its relatively easy-to-use API, equipped with thorough online documentation. When eBay first launched its API, the Wall Street Journal wrote: “eBay’s new technology—with the decidedly uncatchy name of eBay API (for eBay application programming interface)—reflects the company’s growing belief that it can get a piece of e-commerce beyond the confines of its popular online trading post at eBay.com.” eBay’s market was no longer limited to the people coming to its website. It extended to any site that could access their API. The value of extending an e-commerce product offering to other sites is obvious—more opportunities to sell their stuff. And because the implementation of their API was simple and according to the RESTful standard, lots of sites were quick to jump on the opportunity. After all, it enabled them to expand the product offering to their own customers. It didn’t take long for Amazon to follow in eBay’s footsteps. Most importantly, these e-commerce giants nudged other online platforms to start thinking about the value of their code, not just their consumer-facing product. Flickr broadens the horizon Flickr launched its own REST API in August of 2004, just in time for the rise of social networking and blogging. They quickly became the go-to platform for images, which bloggers were finally able to easily embed on their sites and social media feeds. [Flickr’s site in late 2004 advertises the option to “post to any blog” and share.] Flickr set the stage for social sharing by offering services that extended past its platform. You could take advantage of the functionality within and outside of the domain. So when Facebook launched later that year, and Twitter followed two years later, internet-savvy folks weren’t happy that the platforms didn’t have publicly-accessible APIs. Developers were quick to scrape the sites and create Frankenstein APIs. Both sites caved and released official versions of their APIs in 2006. As the demand for public APIs shot up, the state of the web began to change. Devs started building web applications on top of existing code. Easily-accessible REST APIs enabled sites to add a functionality to their site in practically no time. In 2006, Amazon Web Services(AWS) helped launch the cloud, and developers were able to access a ton of data space in minutes through AWS’ REST API. The pervasiveness of REST APIs led to what Flickr co-founder Caterina Fake labeled a Web 2.0 world. She said that “while a Web 1.0 world makes partnerships and integration challenging, the Web 2.0 world has the advantage of the API, something that removes many of the bureaucratic, legal, and technical obstacles.” Flickr’s open REST API, for example, wasn’t just used by lone bloggers and site builders—it was used as marketing for Flickr as a platform. The API economy and beyond Since 2006, the environment for REST APIs has drastically improved. Developers now know the value of creating an API that’s accessible by design. That’s why the amount of publicly available APIs built has grown more than 50-fold in the last ten years. REST APIs are the backbone of the internet and as such powerful drivers, create huge new business opportunities. A website can only reach a small portion of your audience, but an API can extend your brand’s reach far beyond what even the original designers envisioned. Today, APIs aren’t just a development technique. The creation of REST as a standard has led APIs to be used by far more people to accomplish far greater undertakings. They’re often a core part of software companies’ business models and, sometimes, are even the product itself. Whether you’re embedding photos, tweeting, or storing five terabytes of data on the cloud, you’re constantly taking advantage of a landscape made possible by RESTful APIs. For the end user, this means life is constantly getting easier. It’s easier to share documents at work, look up directions, call a taxi, and find old friends. For the developer, it means the sky’s the limit. Thanks to the evolution of REST APIs, we don’t need a team of engineers or thousand-dollar servers to build software anymore. As long as you can get an API key and access to documentation, you can integrate a functionality into your software. Now just imagine how much could be possible if we could nail down a documentation standard!