What are Idempotent and Safe methods of HTTP and REST [Interview Question]

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, PUTor 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. Btw, if you are a complete beginner into RESTful web services then I also suggest you take a look at the Master Java Web Service and RESTful API with Spring Boot course by Ranga Rao on Udemy. It's a great hands-on course to learn how to develop RESTful web service in Java.





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 method
GET /order/123 HTTP/1.1
This 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. You can learn more about REST API design and how to choose HTTP methods for your REST API on REST API Design, Development & Management, one of the best REST design courses on Udemy irrespective of programming language and tech stack. 

best course to learn REST API design and basics


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.

You can also read RESTful Web Services by Leonard Richardson, Sam Ruby, and David Heinemeier Hansson for more details on HTTP and REST mapping. 

best book to learn RESTful web services

You should also join the HTTP Fundamentals course on Pluralsight to learn more about HTTP methods in detail. It's absolutely critical to understand the HTTP protocol in-depth to design a better RESTful API.

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.
Here is a slide that explains which methods of the HTTP protocol are safe and which are Idempotent

Difference between HTTP Safe and Idempotent methods REST


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. 

Further Learning
REST API Design, Development & Management 
REST API Automation testing from scratch-(REST Assured java)
RESTFul Services in Java using Jersey By Bryan Hansen

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)

Thanks for reading this article so far. If you find my explanation and differences of Idempotent vs safe HTTP methods then please share this with your friends and colleagues. If you have any questions or feedback then please drop a note. 

P.S. - If you want to learn how to develop RESTful Web Services using Spring Framework, check out Eugen Paraschiv's REST with Spring course. He has recently launched the certification version of the course, which is full of exercises and examples to further cement the real-world concepts you will learn from the course.

5 comments :

Unknown said...

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.

javin paul said...

@Nikolay, good spot, Yes, It should be GET, PUT and HEAD, which are idempotent mehtods in HTTP.

Unknown said...

Nice explanation!!

TheDarkOne said...

And I always thought that post is an idempotent method. Well explained!

Artem said...

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