In this article, we will explain all parts of API Management through a restaurant example. Sometimes when explaining technical topics, we forget that not everyone has technical knowledge. So it is important to take a step back and find a common language to explain some terms.

So, what do you do?Link to So, what do you do?

Hello, my name is Ertugrul and I am the Co-Founder and Developer of a product called Apinizer. One of my biggest challenges is explaining to my mom/dad what my job is. Even if I explain something like “We develop the Apinizer product, we monitor and secure APIs!”, she says hmm that's cool, but it doesn't convince her or make her understand what I do.

It is necessary to explain what API and API Management is with a concrete example. The restaurant example is something that everyone can easily relate to. You may have seen it in many other articles.

Restaurant AnalogyLink to Restaurant Analogy

  • Client(Customer): We use the same term in API Management. The client is the sender of the request and makes these requests through the API.
  • API Specification (menu): A menu in a restaurant is like an API specification (WSDL and Swagger/OpenAPI). In the menu you can find what you can order and a description of each item.
  • Back-end App (kitchen): The kitchen is like the place that prepares your order. You don't need to care about what's going on in the kitchen, the important thing is that your order arrives as you want it.
  • Waiter (API): The waiter is the bridge between the customer and the kitchen. He takes orders, passes them to the kitchen and brings back the results (Response). APIs work in the same way; they receive requests, process them and pass the results back.

The backend of your app is the equivalent of a restaurant kitchen. The kitchen will prepare your food, plate it and present it beautifully, and with a little luck, it will give you exactly what you ordered. This is the backend's responsibility - to provide you with the information you need, to apply the necessary processing to the data, and perhaps to ask for more information from other sources. The kitchen will handle the processing of the food, for example freezing, thawing, slicing, chopping and cooking. The kitchen may have to request more ingredients. With all this information and processing going on, you as a customer don't need to know about it, or even care about it, to get your order!

The customer wants food, why do you need a waiter in the kitchen?Link to The customer wants food, why do you need a waiter in the kitchen?

Now we have a client (Client), a menu (API specification) and a kitchen (backend system). A key element is missing here. How will the kitchen know what you want? Sure, you can go to the kitchen yourself and ask the chef directly, but he is nervous and doesn't want to talk to a lot of people at dinner time. Also, it's not very hygienic for people to walk into a kitchen, and it's not very practical for 50 or so customers to walk in and shout their orders. So how are we going to cope with taking orders from a group of 10 newcomers, while trying as much as possible not to make the children at the other end of the room cry? Garson This is where API Gateway becomes our waiter 


Waiters are the equivalent of APIs (API Proxy in Apinizer terminology). The waiter goes to the customer, takes their order and brings it. They also do the following:

  • They prevent overconsumption (I think two meals are enough (Rate Limit))
  • They suggest adaptations if something is not available on the menu (smoked salmon is out, but smoked trout is an excellent alternative)
  • They adjust the timing and arrival of requests in certain situations (let me get some bread for your children now)

When the food is ready, they will also provide the appropriate cutlery for the dishes and generally deliver the expected experience. A waiter works in a very similar way to APIs, between your requests (ordering from the menu) and the responses (dishes brought to your table). When you make API calls and receive responses (called policies in Apinizer terminology) a number of things happen, for example:

  • API helps secure your calls (sorry, you've had enough)
  • Applies data transformation (Transformation) (I'll stop eating for your child)
  • Gets more information so that the backend can do its job (Validation) (do you have any allergies that the kitchen needs to know about?)
  • Processes a response (you ordered soup, I will bring a spoon)

How do APIs know how to handle these situations? Of course, there are common issues like security, data transformation, but how do we handle specific organization policy? Let's go back to our restaurant example. There are many common tasks (taking and delivering orders), but the restaurant might have some specific policies, such as handling queues of both customers waiting to get in and the orders themselves, prioritizing certain orders, or perhaps certain ground rules that should be applied in the restaurant in general.

API ManagementLink to API Management

API Management is similar to what a restaurant manager does. Managers determine how the waiters (APIs) work between the kitchen (background application) and the customers. They also analyze customer traffic and make sure things run smoothly. For example, they manage and determine what policies the waiters (APIs) must follow.

ConclusionLink to Conclusion

API Management with restaurant example can be summarized as follows:

  • Restaurant: System architecture.
  • Customer: Client application.
  • Menu: API specification.
  • Kitchen: Background application.
  • Waiter: API.
  • Restaurant Manager: API Management System.

This is my way of explaining my job to my mom, and I hope it will be useful for people like you who work in the tech industry. Simplifying technical terms makes our work more understandable, which in turn strengthens collaboration.

Final ThoughtsLink to Final Thoughts

In our team we talk about gateways, proxies, policies, API, Web Service xml, json etc. all day long. However, the important thing is to understand what users are trying to achieve. Asking “why?” allows us to understand the real needs beneath the surface and helps us build better solutions. If you can explain something even to a six-year-old, it means that you really know something about it!

I hope Mom or Dad understood us