APIs connect. A fundamental part of the new neural network, fabric and interlaced composition of the cloud and the modem web, Application Programming Interfaces (APIs) have become the linchpins (figuratively and literally) of connected applications and services.

Written to a defined syntax and structure, APIs forge links between applications, smaller application components, application services or higher-level operating systems.

When rideshare firm Uber needed a maps interface to create geolocation-aware depictions of cities, streets and towns, it didn’t build a mapping service – it plugged into Google Maps because Google had ‘exposed’ its API for use by approved external third-party services. Hence, a favorite API example was born.

If you API it, they will come

But just because an organization, technical group, Cloud Services Provider (CSP), enterprise technology vendor or other creates an API, its existence does not guarantee connection in and of itself. There is no magical if you build (code) it, they will come factor here.

Deeper into this point, when someone creates an API, we need to start thinking about who or what machine is connecting to it. Philosophically, we could say, if an API exists but nobody and nothing connects to it, then does it really even exist in the first place? Conversely, if an API is enjoying mass connections, can it handle that pressure and is it built to scale appropriately for the job?

The truth is, an API creator never knows where their API might end up being used.

“Keeping track of who’s using your API is key to performance improvement and next-stage innovations – and the easiest way to do that is by adding authentication. Adding API authentication helps prevent abuse of the services created, plus, it also gives us a way to uniquely identify each application that’s calling our API endpoints,” said Michael Heap, director of developer experience, Kong Inc, the cloud native API company.

For the API mechanics and software engineers now working as dedicated gurus in this space, there are several different options available for authentication.

This is where technologists are fond of using the term ‘lightweight’ (meaning low code footprint, but still enough software to do the job), which in this case could involve a lightweight API key authentication, where the API caller (that would be Uber in our above example… or any other connecting app or service in the wider world) sends a random string in an Authorization header. More asymmetric complex authentication methods also exist in order to add more security.

API authentication equates to control

“In an enterprise organization setting, software engineers might need to restrict access to specific people by integrating with an identity provider through OpenID Connect,” explained Heap. “But no matter which authentication strategy an organization chooses, the outcome is the same i.e. systems will be protected from anonymous abuse. This means that the company will know who is using its API and be able to understand usage patterns better and start to improve the service that the API exists to provide in the first place.”

As a company that works specifically in this space, the Kong team says that once a company knows who’s calling its API, it can start to dig further.

Questions to be asked will include whether (for example) 75% of the traffic an API sees comes from a single consuming source i.e. one other organization or web service? If an organization creates an API that spreads out to a number of different endpoints, why is it that one particular company ignores 90% of what is on offer and only calls an endpoint or two? Or going further, are most of the errors that an API is returning being sent to people in a specific industry?

“By recording incoming request endpoints and the HTTP code sent back, an organization can start to build up a picture of how people are using its API. If you have an endpoint that is very expensive to maintain and fewer than 10% of customers are using it, should you consider deprecating it? Identify your top consumers and start a conversation with them. Ask them why they use your platform, and what their main use cases are,” said Heap.

The suggestion here is that this process could open up new opportunities in specific industries as the organization learns what pain points are out there in terms of customer and partner API connections – this can pave the way to specialized APIs to capture common workflows.

Making it self-service

Nothing puts users off a service more than having to request access and wait for it to be approved. When that happens, they have usually found an alternative and implemented what they need, before their request is even reviewed. By using an API developer portal an organization can provide API documentation in a format that consumers are expecting such as OpenAPI. This can be public, or it can require developer signup in order to access it (so long as there’s no approval process).

“These portals can also handle application registration, where developers create an application and generate credentials without any interaction with another person. This provides self-service credential management which is key when building integrations that need to be used in multiple environments, such as staging and production. Many leading API companies such as Twitter, Stripe and Slack provide a self-service developer portal to help consumers get started as quickly as possible,” stated Kong’s Heap.

Unfortunately, not every consumer of your API is going to be well-behaved. Not from a security point of view per se, but in terms of the frequency and accuracy of the API calls that are being made. Sometimes there is malicious intent, but most times an API is badly behaved it’s because the service calling it doesn’t know any better and so calls an API too frequently, or sends malformed requests, or payloads that are too big to be processed.

Dealing with malicious consumers is of course time consuming. In this scenario, Heap advises that organizations need to implement strategies such as ‘rate limiting’ to handle request volumes (and share the counts between multiple instances of an application).

“When this happens, IT teams should implement strict validation rules, and sometimes configure your HTTP server itself to reject large requests in order to protect your application,” said Heap. “Building all of this functionality takes time. Following recent economic shocks and the scarcity of developer talent, this represents time and resources that your organisation can’t afford to spare, rather than enhancing your APIs to serve your customers.”

Get it all for free

But what if you could protect your APIs with rate limiting and validation for free? What if someone else could provide a developer portal with self-service credential generation? How about usage analytics broken down by consumer? This scenario actually already exists via projects like API gateway authentication, which is full of authoritative content.

“Implementing an API gateway can be done without changing any of your application code. The proxy sits in front of your application and adds all of the above functionality without needing you to change a thing. Being able to change your application’s behavior without deploying it is even more key in the cloud age. Your application runs on distributed systems across multiple clouds. It’s not a single application running on a single server any more. API gateways allow you to scale how you manage your APIs with minimal effort, no matter if you have 10 or 10,000 deployments,” clarified Heap.

APIs need us humans too

So, back to our philosophical question. If no one uses an API, does it really exist? Rather like a tree falling down in a forest when there’s nobody there… does it makes a sound? Does the silent API with no use actually exist?

Kong’s Heap says, no, definitively.

Unused software componentry of almost any kind that enjoys no interfacing keystrokes and clicks from users, experiences no connection to software machine engines of any description (be they virtual cloud-based machines, or physical pieces of hardware in the device universe) and is in no way integrated with (or part of) some other live data service that creates the firmament of the cloud does not exist, effectively.

“One of the biggest reasons that an API receives no use is that it hasn’t been publicized. By building a developer portal to catalog all of an organization’s API offerings and by providing detailed documentation and self-service registration, a company can increase the adoption of its API dramatically. As it gains traction, it can use that same API management platform to provide security and analytics for its APIs,” concluded Heap.

We need APIs and – perhaps surprisingly, maybe paradoxically, definitely comfortingly – they need us, humans, too in order to oversee their management, health and wellbeing and to define their place right in the world and make it work right.

API ‘happiness’ is a thing, the clue’s in the name, right?

The following Adrian Bridgwater, from 2022 provides their research perspective. HERE