If you have arrived at the Nordic APIs blog there is good chance you have some inkling of what an API is and why you might need one. However, for the uninitiated, APIs (Application Programming Interfaces) and especially the API economy can be a confusing and fragmented space with some loose standards, an incredible amount of diversity, and a seemingly impenetrable barrier of technical jargon.

For those with well-developed technical chops, this is easy to comprehend and to put in context. However, for those new to web APIs or with a more business or product focus, understanding this space may not be easy, especially given APIs themselves are technical in nature.

At Nordic APIs we’ve decided to attempt to help fill the knowledge gap with some APIs 101 style analysis, aimed at giving you the information you need and avoiding tl;dr. In this post we’ll be starting from brass tacks, tackling what an API is and why you (may think you) need one.

What is an API?

Talking about what an API is (regardless of the current view of an API as a product) has to start with the technology. At its most basic form an API is a technical convenience for something that developers have been attempted to do since software was, well software: Share what they’ve written to save others from writing the same code over again.

APIs have been in existence for generations; virtually anyone who has coded seriously in a software programming language for the last 30 years will have created or used one at some point.

So far so boring, you might think; surely this is merely a technical solution to a technical problem, so what’s the big fuss? Up until 10 years ago this indeed might have been the case, but a specific brand of APIs — Web APIs or REST APIs, depending on your point of view — became more prevalent. Web APIs were considered a solution to the problem of how to share data and services efficiently with clients no longer inside the enterprise but distributed across the Internet. This was fueled by many phenomena such as the massive growth in the consumer-facing mobile application economy and the increasing geographic distribution of the workforce in many industries.

The prevalent technical standards at the time this challenging new environment began to surface were dominated by Service-Orientated Architecture (SOA). The protocols, process, and practices that go with SOA were generally considered a poor solution for meeting the challenges. Pragmatic alternatives were sought using technologies developers were familiar with such as HTTP and JSON. Their API design was also increasingly guided by Fielding’s work on Representational State Transfer (REST). REST is the key architectural style that has defined the API Economy and whilst the “RESTful” style of API rarely implements all the features of Fielding’s definition (with Fielding himself pitching in on how the majority of APIs that define themselves as RESTful do not implement all the features) REST has come to epitomize what an API is.

As an aside, the most prevalent protocol associated with SOA was SOAP. SOAP was viewed by many developers as bloated and unfit for purpose, largely due to its highly structured nature, focus on enterprise use cases (especially as the coarse grained entry point for a business operation), reliance on XML, and lack of libraries for mobile development platforms. Such characteristics made SOA technologies both ill-suited to fragmented and relatively slow mobile networks and difficult to implement for mobile app developers. For a comparison of REST and SOAP see our infographic.

The key characteristics of a RESTful API in the sense of what’s out in wild include the following:

• Implementing a server that adheres to the HTTP 1.1 standard;
• Leveraging HTTP methods as a means to read or change the state of an object or objects (called “entities” in the parlance of the standard);
• Using resources in the form of URIs to define malleable entities and collections of entities;
• Using query parameters or headers as a means to add arguments to an API call.

These four characteristics are almost ubiquitous across APIs that claim to be RESTful in nature (adhering to the spirit of Fielding’s work rather than the letter of the law) and are the essence of what an API really is: A means to modify the state of your backend or your data without giving clients direct access to the backend itself. These may seem like technical points, but they are at the heart of why APIs have become so important and the means they provide to turn your applications and services into a platform that external consumers can utilize.

Why Have APIs Become Important?

Serving clients over wide, highly distributed, and relatively unreliable networks such as 2G cell phone networks and the Internet was the original reason to provide an API. Web APIs — particularly private APIs available only to clients from the same organization — have become the de facto method of providing data and services to mobile apps.

APIs power our connected devices

However, innovation amongst organizations who offered APIs (“API providers”) was not purely limited to the needs of mobile apps — many, such as Amazon or Twitter, were acutely aware that an API can serve any client. This was piqued by the realization that APIs could be offered to any new or existing customer who wanted to consume the product or service the API had to offer. This realization — of what a public, externally-facing API could offer — was seized upon by organizations who saw APIs as a way to extend the reach of their product and to serve any client regardless of their form factor.

The list of companies that broke ground about 10 years ago in releasing their first public APIs contains many familiar names much vaunted for their efforts in the API Economy; Amazon Web Services, eBay, Twitter, Facebook, Twilio, Uber, and so on. All these companies saw how APIs can be used as a means to extend the reach of their platforms to new consumers by providing an easy to use interface. The success of these organizations in becoming API providers triggered a gold rush and fostered a huge interest in APIs, the growth of the API Economy, and the manifestation of various complementary technical solutions like API management. Moreover, the advance in security standards that support APIs, especially OAuth 2.0 as a means to provide delegated access to an API on behalf of a user, have helped mature and standardize the technological environment in which the economy has grown.

What’s In It For You?

Reeling off a list of famous names does not, however provide sufficient evidence that an organization should invest time and money in becoming an API provider. The reasons for doing so have become as diverse as the API economy itself and could be any of the following:

• Backend to mobile efficiency: Using APIs to provide backend services to a mobile device is of course still hugely relevant. Many organizations become API providers to aid their efforts in the mobile app economy and use APIs to provide data and services for their mobile apps;
• Software-as-a-Service delivery: Taking a product to market using an API is also increasingly popular. API-first products tend to be technology services that are sensibly and expediently delivered using an API supported by a great developer experience. Many start-ups take this route to quickly enter the market, with many API-first product examples in verticals including such payments, business operations, health, science, and many more.
• New customer experiences: APIs bolster an organization’s existing products and services and allow them to be delivered via a new channel. An API can deliver flexibility and choice for existing customers and attract new customers who are looking for a way to consume the product or service programmatically;
• Competitive pressure: The growth in the API Economy has also introduced an element of “keeping up with the Joneses” with organizations becoming API providers to keep pace with competitors who have already provided an API;
• Regulatory pressure: Finally, organizations are increasingly being coerced into becoming API providers due to regulatory or legal pressures with governments seeing APIs as being a way of opening markets and increasing consumer choice. Key examples in Europe include the CMA Reforms in the UK and PSD2 in the EU.

Final Thoughts

APIs still hold their status as a “magic word” in technology circles — along with AI, Big Data and Machine Learning — but understanding what they are and why they are important is crucial for organizations to see their value as a product as well as a technical solution. APIs provide convenience, flexibility and choice for API consumers and providers alike and ensure that a product can be delivered to the right audience at the right time.

Armed with the knowledge from this post you can start to make informed decisions on what more you need to research regarding APIs. The Nordic APIs digest is a good channel for that, as we share resources spanning the entire API lifecycle, including Planning, Design, Strategy, Security, Monetization, and Marketing. Consider how you can build on these foundations by becoming an API provider or simply developing an application that consumes an API, and stay tuned for more APIs 101 knowledge!