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:
[table id=6 /]
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.