The Beginner’s Guide To API Management

By Antoine Mouliere, Product Owner, Gravitee

There are many parts to API Management, with its basic definition being that it allows organizations that create APIs or use others’ APIs to monitor activity and ensure the needs of the developers and applications using the API are met. 

But what does that actually mean? We often forget that not everybody is technically-minded, and sometimes it’s necessary to take a step back and find a relatable language to explain the meaning behind the terminology.

A Career In The Industry

One of the biggest challenges is to answer the question “what does a job in APIs look like?”

For a Product Owner of the largest Open Source API Management platform it is developing software to design, build, monitor and secure APIs.

However, do we really understand our areas of expertise if we can’t even explain it?

What’s needed is something that’s tangible, based on a real-life situation that can aptly describe the purpose of API Management. This can be achieved using the example of a restaurant.

The Restaurant Analogy

The API Specification or definition is the equivalent of a menu in a restaurant. It contains a list of what you can order and a description of what you can expect for each item.

The backend of an application is the equivalent of the restaurant’s kitchen. The kitchen will prepare your meal and with a bit of luck, give you exactly what you ordered. This is the backend’s responsibility – to provide you with the information you need, apply any processing to the data, and maybe request more information from other sources. As a client or customer, we do not need to know exactly what goes on behind the scenes as long as we are receiving the desired end result. 

Waiters are the equivalent of APIs, and work by speaking to the customer to get their order before delivering it to them. They will also prevent overconsumption, offer adaptations if something is unavailable on the menu and adapt the request timing and arrival in specific cases. 

A waiter works very much in a similar way to APIs, operating between the requests (the order off the menu) and the responses (the meals delivered to your table). There are a number of things that happen when requests and responses are made, including:

• Helping secure your API calls
• Applying data transformation 
• Getting some more information so that the backend can work effectively
• Processing a response 

So how do APIs know how to handle these cases? There are many common tasks (taking orders and delivering them), but the restaurant may have some specific policies to handle circumstances that go outside the norm.

API Management is the equivalent of a restaurant manager. The manager will define how the waiters (APIs) will work between the kitchen (backend) and the customers (clients). The manager can also analyze customer flow (monitor global traffic) and how everything is being handled. They will follow up on all the orders, as well as managing how customers are billed for their meal (API monetisation). 

In addition, API Management can take a more holistic and bigger picture view of what’s going on in the restaurant, and how to make the waiters’ (APIs) jobs easier. For example:

• Hiring security (gateway security and/or integrate access management)
• Providing a standard policy for troublesome customers (gateway caching)
• Raising awareness of what’s not currently available on the menu and suggested alternatives ahead of time (gateway dynamic rerouting)

Final Thoughts

For those in a similar tech role such as development, architecture, marketing and UX, using relatable scenarios and common vocabulary to explain the background, concepts and ultimately culture behind a career in the tech industry is beneficial. It is a lot harder to work with each other if we’re not able to share and understand the industries we work in. As a product owner/manager/team, we’re the bridge between people.

Businesses talk regularly about gateways, proxies, virtual hosts, processors, reactive development, fixing printers and all the weird and wonderful terms that come with a technical job. This works the same way when you’re helping users – what are they trying to achieve? It doesn’t matter that they’ve got an issue with a specific protocol setting, what we really want to know is why they’re using the product in this way.

What’s the best way to achieve this outcome? Keep asking questions. Being inquisitive allows you to really understand what is behind the surface – the 90% of the iceberg, and avoid misunderstanding. Don’t assume that your explanation is simple or straightforward. We all have different backgrounds so not everyone will have the same understanding of the concept as you do. If you can explain something to a six-year old, that means you really know your stuff, and will be able to help people feel comfortable with digital transformation and use it to bolster businesses both now and in the future.