If you are learning REST and want to understand the difference between the Idempotent and safe method then you have come to the right place. Earlier, I have shared the best books and courses to learn RESTful Web services and in this article, I will answer this popular REST Interview question. In order to efficiently work with REST and RESTful web service, good knowledge of HTTP is really helpful. Even though REST seems easy, designing a uniform and consistent RESTful API is a tough job. One of the tricky tasks is choosing right the HTTP method for the right job like when to use PUT vs POST. Once you know the meaning and purpose of different HTTP methods, it helps to choose the right method for the right job.
You can divide HTTP methods into two main categories safe and idempotent. Safe methods are HTTP methods that do not modify the resource like a GET request is safe because it doesn't modify the resource you are requesting like data of a Book.
Another safe HTTP method is HEAD, which doesn't change the resource representation on the Server, but all other HTTP methods like POST, PUT, or DELETE are non-safe.
Coming to idempotent methods, they are HTTP methods that can be called multiple times and they will produce the same result. They are considered the safe option to update a resource on the Server.
Some examples of idempotent HTTP methods are GET, PUT, and PATCH. No matter how many times you call them, they will produce the same result with the same URI.
This fundamental knowledge of HTTP protocol goes a long way in creating a production-grade REST API that can stand the test of time.
Another safe HTTP method is HEAD, which doesn't change the resource representation on the Server, but all other HTTP methods like POST, PUT, or DELETE are non-safe.
Coming to idempotent methods, they are HTTP methods that can be called multiple times and they will produce the same result. They are considered the safe option to update a resource on the Server.
Some examples of idempotent HTTP methods are GET, PUT, and PATCH. No matter how many times you call them, they will produce the same result with the same URI.
This fundamental knowledge of HTTP protocol goes a long way in creating a production-grade REST API that can stand the test of time.
What are Safe Methods in HTTP and REST?
These are HTTP methods that don't change the resource on the server-side. For example, using a GET or a HEAD request on a resource URL should NEVER change the resource. Safe methods can be cached and prefetched without any repercussions or side-effects to the resource. Here is an example of a safe methodGET /order/123 HTTP/1.1This will retrieve the order with orderId 123. No matter how many times you execute this method, the order in the server will not be modified or impacted.
That's why the GET method is a safe method. Let's see a couple of more details about Idempotent and safe methods in HTTP and RESTFul web services.
What are Idempotent Methods in HTTP and REST?
These are methods that are safe from multiple calls i.e. they produce the same result irrespective of how many times you call them. They change the resource in Server every time you call them but the end result is always the same. Maths is a good place to explain idempotent methods, consider the following example:int i = 30; // idempotent i++; // not idempotent
Here the assignment operation is idempotent, no matter how many times you execute this statement, i will always be 4. The second example is not idempotent. Executing this 10 times will result in a different outcome as when running 5 times. Since both examples are changing the value of i, both are non-safe methods.
Idempotency is an important thing while building a fault-tolerant RESTful API. Idempotency is also the reason why should you use PUT over POST to update a resource in REST.
For example, suppose a client wants to update a resource through POST. Since POST is not an idempotent method, calling it multiple times may result in incorrect updates.
In the real world, it's quietly likely that your POST request may timeout, what will happen to the resource that. Is the resource actually updated? Does the timeout happen during sending the request to the server, or the response to the client?
Can we safely retry again, or do we need to figure out first what has happened with the resource? By using idempotent methods like PUT, you don't have to answer this question, but we can safely resend the request until we actually get a response back from the server.
Summary
Here is a nice overview of which HTTP methods are safe and Idempotent:- GET is both Safe and Idempotent.
- HEAD is also both safe and idempotent.
- OPTIONS is also safe and idempotent.
- PUT is not safe but idempotent.
- DELETE is not safe but idempotent.
- POST is neither safe nor idempotent.
- PATCH is also neither safe nor idempotent.
That's all about the safe and idempotent methods in HTTP and REST. Remember, safe methods don't change the representation of the resource in the Server e.g. GET method will not change the content of the page your accessing. They are the read-only methods of the object-oriented programming world.
Similarly, idempotent methods will not throw different outcomes even if you call them multiple times. They are safe for updating resources on Server. They will always return the same result unless you change the URL.
Other RESTful WebService articles you may like to explore
- Difference between SOAP and RESTful web service in Java? (see here)
- How to consume JSON from REST API in Java (example)
- My favorite books to learn RESTful Web Service (books)
- Restlet HelloWorld Example in Java and Eclipse (tutorial)
- Top 10 Java Web service interview questions (see here)
- When to use the PUT vs POST method in REST? (answer)
- 3 ways to convert String to JSON Object in Java? (example)
- 5 Books to prepare Java EE interviews (list)
- 5 Best Courses to learn RESTful Web Service (best courses)
- 15 REST Web Services framework Interview Question (see here)
- What are idempotent and safe methods of HTTP and REST? (answer)
- Top 10 RESTful web services interview questions for Java developers (see)
- What is the purpose of different HTTP methods in REST? (answer)
- 5 JSON parsing library Java and JEE developer should know (article)
- 20+ Spring and REST Interview Questions (answers)
5 comments :
Hi. First you say "Some examples of idempotent HTTP methods are GET, PUT, and PATCH." but then you say also say "PATCH is also neither safe nor idempotent.".
I guess in the first statement you mean HEAD instead of PATCH.
@Nikolay, good spot, Yes, It should be GET, PUT and HEAD, which are idempotent mehtods in HTTP.
Nice explanation!!
And I always thought that post is an idempotent method. Well explained!
I think you can't be sure about method idempotentement by name. It depends on api implementation. Good api has all idempotent methods.
Post a Comment