In a bustling city of New York, there was a renowned restaurant named "Giovanni". This restaurant was unique for it's traditional meals from south of Italy, and they served meals in the same concept of idempotency in API development.
In the sphere of APIs, idempotency means that regardless of how many times one makes identical request, the outcome remains unchanged after the first request is made. This principle is ingeniously applied in the old Giovanni's restaurant.
Enter our protagonist, a chef named Marco, culinary virtuoso. Marco's kitchen was the heart of idempotency magic. Each dish was like a unique response to the API request made by the customer. Made with love, taste and never duplicated.
One summer evening, a couple on their first date arrived at "Giovanni" restaurant. Arthur and Brenda.
Arthur ordered a nice stake, while Brenda ordered a dish called "Palermo delight". Order went to kitchen with unique identifier "table #6 - order 130". Arthur was a rascal and always ready for some misdeeds. He called waiter and ordered same meals again, hoping to see if they would end up with two dishes instead of one.
Back in the kitchen chef Marco received again identical order with same unique identifier "table #6 - order 130".
Marco immediately recognized the duplicate. He informed entire team in the kitchen that this is idempotent request and they should prepare only one stake and one Palermo delight. In any other restaurant this would resulted with duplicate order, but not in Giovanni's.
Rascal Arthur and Brenda were served with one order, corresponding to their first order.
Let's break down the process from order to serving of the meal.
1. MEAL ORDER = POST REQUEST
Arthur and Brenda's first order of stake and Palermo delight equals to a POST request to an API.
When POST request is made, it sends data to the server, ordering to cook meals.
2. ORDER NUMBER = UNIQUE IDENTIFIER
Once Arthur and Brenda told what they want to eat, waiter assigned a table number and order number to it. Order was taken to the kitchen. This unique identifier is crucial.
It ensures that even if same order is placed 20 times, it will be recognized as duplicate.
This means, when api request is made, we assign it a unique identifier, ensuring server recognizes it and prevents duplications, server overload and poor user experience.
3. KITCHEN PROCESSING ORDER = SERVER PROCESSING THE REQUEST
Kitchen took the order with unique identifier, and places it into schedule of cooking. Arthur thought he is clever, but chef Marco's idempotent system is without flaw.
You can look at this as user making same api request again and again, perhaps due to network issue or serial clicking mania :-)
All of these requests will be recognized to who they belong, they will then be ignored, and only first request will be executed.
User is unaware of checks that occur behind the scenes, and he is served with what he requested in the first place. And that is most important.
How do you look at idempotency? Share your view.
Top comments (0)