From Basic Needs to Self-Actualization: A Look at the Evolution of APIs

by Igor Gorbunov, Head of API Competency Center, EPAM

July 26, 2017

Today, APIs are a rare example of a familiar, longstanding integration technology whose relevance continues to increase. While other technologies have come and gone, APIs managed to become the foundation of a great many internet ecosystems. In fact, most Cloud platforms, SaaS offerings, IoT set-ups and mobile apps entirely rely on APIs for their operation.

To better understand how APIs reached this level ubiquity it’s helpful to consider how they evolved over time. This illustration may offer some food for thought:

As you can see, the similarities are remarkable. How can a 70-year-old psychology concept (left side of illustration) – Maslow’s pyramid of needs – describe the development of a technology so fittingly? It’s not as surprising as it first may seem, considering that it is often used beyond its original field (in sociology, management and economics, for example) because of universal supply and demand forces. As it turns out, API evolution is driven largely by the same forces.

Besides providing the classification of needs, Maslow’s concept implies a chronological approach where efforts can be focused on addressing a category only after the previous, lower-level one has been sufficiently addressed. This hierarchy essentially describes how APIs have evolved over time, which we will now look at in greater detail.

Phase I: REST vs. SOAP (2006 – 2009)

Covering the historic precursors to APIs is beyond the scope of this blog, so we’ll concentrate on more recent events. The modern segment of API evolution begins when the REST architecture style started gaining popularity in the mid to late 2000s.


The great REST vs. SOAP debate of the mid-2000s continued for a few years without producing a clear winner, but by 2010 the trend became obvious. As REST-style APIs began to cater to a wider class of web developers instead of just specialized integration teams, a virtuous cycle started: increased consumer adoption produced increases in provider adoption and created demand for improved tooling. Over time, the democratization of integration has demonstrated that the ease of use and openness of REST trumps the harder-to-digest, advanced functionality of the WS-* stack.

Somewhere around that time, even conservative providers started fielding REST APIs as their primary product while treating SOAP technology as legacy. The image of the sophisticated API provider at that time was pretty straightforward: someone who makes the REST/JSON API available to consumers.

Phase II: Cloud-Based Integration (2010 – 2015)

As the adoption of APIs continued (and accelerated), it became clear that a no-frills approach had limitations, especially for public APIs. Security, control, and analytics challenges all required providers’ attention, and around 2010-2011, the answer appeared – surprise! – in the form of another integration hub. The first cloud-based API management products were released, along with early versions of standards for REST contracts and documentation, such as Swagger, I/O Docs, and, later, RAML.

Little by little, by 2014, the API industry arrived at an architectural consensus not unlike the one we see today: a robust set of services delivered and managed via a standards-based API gateway. Solutions built on this architecture answer major “safety and control” challenges, retain the winning emphasis on simplicity, and deliver a clean, if not exceedingly user-friendly, UI.

API Management Gateway. (Source: EPAM)

Phase III: Good Problems to Have (2015 – 2016)

As API offerings matured and became “feature-complete,” successful API providers concentrated on the next set of challenges, broadly referred to as “good problems to have.” With consumer and developer communities growing significantly in size, the competition shifted toward development experience and community management.

By concentrating on the “social” segment of Maslow’s pyramid, innovators like Stripe and Twilio demonstrated what it means to be a successful mass API platform. Community events, press coverage, and efficient, live documentation became important tools for industry leaders implementing their API strategy.

Another example is Ticketmaster’s Developer Portal, which was initially rolled out as a content management system for addressing a few Apigee gaps. It has quickly grown into a hub of developer-friendly API innovation:


Not your average Swagger console. (Image source.)

The rising standards of what constitutes a state-of-the-art API are affecting the whole industry. Some established providers are rethinking their offerings and introducing second-generation APIs. Besides providing more attractive packaging, this new generation is based on lessons learned from extended API use. Patterns like versioning, naming conventions, data formats and others have all become clearer with time (Newrelic, Databricks, Jasper Reports, Docker)

Phase IV: Unbounded Creativity (2016 - ?)

Given a recent focus on usability improvements, one can be forgiven for thinking that API technology has reached a plateau of slowing innovation and growth. We beg to disagree, as a more accurate way to describe the current situation is offered, once again, by Maslow’s framework. This line of reasoning suggests that the most interesting and profound effects are observed at the peak of the pyramid, where there are no longer any impediments to creativity.

The last couple of years were in fact pretty busy with new, efficient ways to access services and describe contracts (GraphQL) and new approaches to data sharing (DaaS) emerging. Furthermore, nascent industry standards (like PSD2 or FHIR) are being introduced to address interoperability challenges from the provider perspective. Chatbots, digital assistants, and low-code platforms are recent client-driven API innovations with true transformative potential.

Taken together, not only do these innovations change the way we interact with computers, but they encourage systems to interact with each other – on Internet scale. Indeed, APIs can now be seen as social networks for machines.

APIs: Facebook for machines?  (Image source.)

This view introduces a well-known model for estimating the valuation/utility of APIs. According to this model, called Metcalfe’s Law, the value of an API-powered ecosystem is the square (n2) of the number of participants. With API ecosystems growing and merging, their impact may increase dramatically, as illustrated by Amazon’s AWS example.

Life at the Peak of the Pyramid

According to Maslow’s own estimates, only about 1% of all people operate at the “peak of the pyramid.” If this is the case, then APIs should be proud – they’ve made it to the top!

As API industry patiently worked through cycles of control, convenience and creativity, APIs transcended technology domain and became a business concept the way eCommerce, mobile and social did before.

Despite not being the newest or most advanced, APIs have managed to achieve lasting success. Based on its previous track record, we can safely assume that API technology will continue to reinvent itself and will remain key enabler for web-based innovation for the foreseeable future.