‘APIs Are Full Stack’

APIs started in the early days as a way for us to connect our monolithic applications with mobile. Everybody wanted to provide a mobile experience, and the best way to connect a monolithic application to a mobile application in 2009 was through an API. We will refer to this API usage as** ‘mobile APIs.’**

The API technology also heralded a new revolution – the API Economy. In the API Economy, companies offer an ‘API-as-a-Product.’ In the ‘API-as-a-Product’ model, companies – like Twilio and Stripe – allow developers to utilise their technology in their own products at a cost (either fixed or commission). The connection between the API Provider’s servers and the external product is done through API requests. We will refer to this type of API as** 'external APIs.'** 

Talking about microservices,** internal APIs** are used in many microservices to communicate with each other. In fact, for every API request at the edge, there are 50-150 internal requests that are happening internally to serve that one request.

The future of API is full-stack.

Even if you just want to build an external API, you are going to be using internal and mobile APIs in the course of your product. It is, therefore, best to think of APIs as full-stack. 

How to Build a Modern API

Just creating an API is a fraction of the work. Before one can offer it to another team at the edge or even an internal developer, one needs to make sure that protocols are in place to ensure its security, observability, and how it integrates with other APIs.

Key Aspects of an API

Whatever API you build, certain things are critical: zero-trust and speed. Zero-Trust To secure our APIs, we must remove the concept of trust. Trust is exploitable. The future of API is going to be a future built around zero-trust. A full-stack API connectivity platform is a great way to use zero-trust across the system.   Speed ‘Slow is the new down.’  To give the best experience to the end-users, speed is critical. An unreliable API slows things down. This is especially true when using internal APIs to power a microservice, where there will be much more back and forth of requests within our applications when running functions using API requests, as opposed to in the monolith where one runs functions from the same underlying codebase. By replacing monoliths with microservices, we are replacing the reliability of the CPU with the unreliability of the network.  Therefore, microservices need to be fast, and optimizing the internal API request for speed is super important in a microservice where ‘slow is the new down.’

What Technology to Use in an API?

I would recommend everybody thinking of building on API to start from the interface, not from the implementation. The API is as useful as the interface – the requests and responses that we want others to consume. Successful implementation can only happen after we know what the API and the interface are going to look like. So let's start from the interface top-down.

How is that API going to be consumed?

Building an API for a mobile application (use GraphQL)

If that API is going to be consumed heavily by mobile applications, GraphQL is a great option, as it allows us to create flexible queries on an API endpoint in such a way that we don't have to make multiple requests from the mobile app to the API. Therefore, we can save on performance and bandwidth by making just one request instead of 50.

Building an internal API for microservices (use gRPC as an HTTP protocol + event sourcing) 

Furthermore, **if we want to propagate the state in a consistent way, use a log collector. **This is because service-to-service requests eventually fail. Using events, we can leverage a log collector to keep the state across our infrastructure, even if the connection isn’t always consistent. If the connection drops, whenever it picks up again, the subscriber is going to receive the event on time.  Event-based microservices are great if we want to move state and change the state of our services around the infrastructure.  One shouldn’t be scared off by the complexity of event-sourcing, as it's becoming a lot more accessible with the introduction of tooling that allows us to build very reliable event-based architecture. Tools are available that allow one to use a gateway technology to convert synchronised service-to-service requests into events.

Building an external API as a SaaS/PaaS (technology varies by use case)

In the next decade, the use of **external APIs **will grow 50-fold as more monoliths migrate to microservices that can better utilise APIs. APIs will be the new nervous system of the digital world, and API Marketplaces like Mashape which I initially developed, will gain traction.  Just like any other product, an API-as-a-Product needs to have a lifecycle to create new versions, upgrade users, decommission older versions, document it and secure it. This means we are going to have different versions of that API, which will differ in how we allow users to consume it, discover it, and pay for it.

You are going to need to use an API gateway to satisfy common requirements like rate limiting, AuthN/AuthZ use cases, and more. The API itself will need to be running over the HTTP protocol (i.e., REST, SOAP, GraphQL or gRPC), yet the exact type would depend on the API. APIs also vary on the use of UDP and TCP protocols. 

Why You Might Want to Use a Service Mesh

A service mesh allows us to provide a network management function on the infrastructure layer without needing to build it for each application. This means that when somebody builds an API for any purpose in the organisation (internal, external, mobile, etc), they can just ‘plug’ it into the service mesh, and the new API gateway will inherit things like API security, API observability, API monitoring, and API connectivity. This option might be particularly relevant when thinking of APIs in a full-stack way. 

Conclusion In this article, we discussed APIs – how they are best thought of as full-stack when it comes to managing them. We discussed the various types of APIs (mobile, internal, external) and how your product might incorporate all of them. We then discussed important factors that make a successful API, and we touch on various technologies one should consider when developing an API for each use case.