API Testing Tutorial Part 6 – Idempotent Methods in HTTP Methods
In previous post, we have seen that how can we categorised HTTP methods in Safe and Unsafe methods.
In this post, we will see how can we categorised HTTP methods in Idempotent and Non-idempotent methods.
Let’s understand the term “Idempotent” first:
My name is Amod. If you ask me my name, I will say Amod. If your friends ask I will say Amod. If anyone asks me my name, I will say Amod. My name is not changing on who is asking and how many times it is asked. This Is called Idempotence.
I have a watch who shows time with timestamp. If you ask me time, I will say current 01:20:35. If your friend asks me I will say latest time as per my watch which is exactly not same as time I told to you. Every time, current time will be changed. It is called non-idempotence.
The same concept is for HTTP methods.
An HTTP method is called idempotent, if it produces the same results when method is executed once or multiple times. For example, If there is a GET method which gets you LastName of a resource say Amod, It should give lastName as “Mahajan” always for single or multiple calls to same method. Yes if some other method call update my lastName, result will be different from result before updating.
Now I will change my above statement as below:
An HTTP method is called an idempotent method if multiple request to same method has the same state of resource on the server as after first request (Conditional). In more easy word: You hit a request, request performs some action on resource which may or may not change state of resource. Now you hit the same request again, it will do the same action again. Nothing new will happen.
A GET request supposed to be idempotent. You hit a GET request to retrieve my lastName. In response you get my lastName as “Mahajan” and a timestamp of current time. When you hit the same request again, You will get lastName as “Mahajan” but timestamp will be different. So idempotence Is not related to response received at client side. It is considered how state of resource on server after multiple calls. GET request does not change anything of resource at first call also. This is the reason I wrote conditionally in bracket above. This method has better categorisation as nullipotent.
A PUT request updates state of resource. Say it updates my lastName as “Verma”. Now how many times you hit the same request, it will have no impact as it will be rewriting same values again and again. So multiple same put request will not impact on state of resource after impact of first request.
I hope, now you understand the term “Idempotent”.
Below table categorized HTTP methods in Safe and Idempotent methods:
|HTTP Methods||is Safe?||is Idempotent?|
More about API Testing in upcoming posts. Stay tuned.
If you have any doubt, feel free to comment below.
If you like my posts, please like, comment, share and subscribe.
3 thoughts on “API Testing Tutorial Part 6 – Idempotent Methods in HTTP Methods”
Hello Amod, This is really informative and helpful.
The is one word “once” used in the sentence “An HTTP method is called idempotent, if it produces the same results when method is executed once or multiple times” . I feel it should be twice. What do you think?
It means that you hit a request once or multiple times, you will get same output. It doesn’t depend upon times of hit.
Thank you never read such good things on internet about API on various sites.
I think for PUT and Delete you can mention they are idempotent only after the first request run.
Also why is PATCH not idempotent as in the previous post we have seen it updates the information partially. So is it not like put. so should be idempotent