Since HTTP GET, HEAD, OPTIONS and TRACE methods do not make any modification on the server side i.e. they are only intended for retrieving data, they can be called multiple times without any side effects.
What is Idempotent Operation? Which HTTP methods should be made idempotent
Upasana | December 07, 2019 | 2 min read | 1,800 views
In computer science, the term idempotent is used more comprehensively to describe an operation that will produce the same results if executed once or multiple times. In arithmetic, adding zero to a number is idempotent.
wikipedia.org
What is the need for idempotency?
Since networks are brittle, we should always design our services to accept repeated calls without any side effects. We can add some unique identifier to each request so that service can ignore the duplicate request sent over the network due to network failure/retry logic.
Which methods should be made idempotent?
Ideally we shall make HTTP POST, PUT and DELETE methods as idempotent.
| Note that while idempotent operations produce the same result on the server upon multiple invocation with same request, the response itself may not be the same. |
Example scenario for idempotent operation
Let’s assume we have a banking microservice that handles money transfer requests from clients. We can have a method in this service that add some money to an account. A JSON message for adding money to account may look like below:
Account credit payload
{
"credit" : {
"forAccount" : "123456790"
"amount" : "1000",
"currency" : "INR"
}
}Now, let’s further assume that the first attempt to credit amount to a given bank account fails due to some network issues. The failure may have happened after microservice actually credited the amount to target bank account but before it could respond back to the client who called this api. Since client is bound to retry the failed request using some kind of retry logic, the client sends the same message again. This will result in two exactly same messages on the server side. So there are high chances that the banking microservice will process the duplicate message and credit the account twice.
A common way of ensuring that an operation is idempotent is by adding a unique identifier to the message and making sure that the service only processes the message if the identifiers do not match. Below is an example of the same message, but with an identifier added.
Account credit payload with unique identifier
{
"credit" : {
“creditID” : “3h7e456-e89b-12d3-a456-766655440000”,
"forAccount" : "123456790"
"amount" : "1000",
"currency" : "INR"
}
}Now the banking service can check if the message has already been processed before processing it, there by avoiding duplicate requests. This unique identifier makes our service idempotent to account credit requests. We can apply the same logic at other places, or may be at a centralized place.
Top articles in this category:
- Http methods for RESTful services
- 50 Java Interview Questions for SDET Automation Engineer
- HTTP Head request using Java 11 HttpClient - Kotlin
- Using Java 11 HttpClient with Kotlin Coroutines
- Create self signed HttpClient and RestTemplate for testing
- HTTP GET request with Java 11 HttpClient - Kotlin
- Java 11 HttpClient with Basic Authentication
Recommended books for interview preparation:
Book you may be interested in..
Book you may be interested in..
