[Logo]
Forums Register Login
Unable to understand idempotent
I'm planning to apply http methods as follows

Create - POST request
Edit/Update - PUT request
Delete - DELETE request
Read - GET request

I'm confused when i searched for applying it with idempotent. Will there will a flaw in applying the above methods.

I have read lots of articles about idempotent but still couldn't understand it properly

Can someone review the above and help me with the suggestions/comments with code snippet if possible?

Thanks.
Idempotent literally means "done the same". In the context of HTTP requests it means that the same request, sent twice in succession, returns the same results and leaves the application in same final state. Same request means that all data that you send along with the request are also the same (including query string parameters, request body and cookies).

For GET this means that if you send the same request twice in succession, you get the same results. GET must not change any application state.

For PUT it means that the first request updates the application state and returns some results, and the second request doesn't change any state, but just returns the same results.

DELETE is the same as PUT, except for deleting data, rather than updating it. The first request deletes something, the second request doesn't; it just returns the same results.

Finally there is POST. It is special in that it is not required to be idempotent. As a matter of fact, its entire reason for existing is to be able to make requests that are not idempotent. Browsers know this, and when you use the 'back' button to go to a page that you initially arrived at through a POST request, they will ask you if you want to make the request again, because the second time it could result in something completely different.

POST is usually used to add new data to an application. Sending the same data twice results in two new entries, not one.
Simply, Idempotent (Receiver) is a pattern to deal with the situation when you could potentially receive the same message multiple times.
As Stephan described some REST methods are Idempotent, some (like POST) are not.  Found this; http://restcookbook.com/HTTP%20Methods/idempotency/
 
Stephan, theoratically it's fine..Don't understand it practical issues

Any code snippet would be great to understand for PUT and DELETE
Imagine you have a controller that uses a dictionary as an in-memory repository of some resource type. You can then implement it like this:

I made a mistake earlier when I said that idempotent methods are required to return the same result for successive calls. Idempotent methods are required to have no side effects after the first time they are called. They can still return different results. An example:

If I request DELETE /books/bbcff625a88e45fcaf28f2a535997982 twice in succession, the first time it may delete a book and return status code 200, and the second time it must not delete anything, but it may return status code 404.
Assume i handle the status code or the business accordingly on delete.

Ex: verifying whether the record exist and throw an exception. then status code automatically changes..

In such a case, i don't need to worry about the idempotent. is that right ??
(1 like)
You do. DELETE must be idempotent. That means for instance, that you can not create an action like DELETE /books/last that will delete the last book added to the application. If you call it twice in succession, it will produce a new side-effect the second time, which is not good.
So what would be the best practice to do ??
 

Kathir jeyap wrote:So what would be the best practice to do ??



To do what?
You do. DELETE must be idempotent. That means for instance, that you can not create an action like DELETE /books/last that will delete the last book added to the application. If you call it twice in succession, it will produce a new side-effect the second time, which is not good.

Shall i do as follows?

1. First time delete - delete the entity and return success
2. Second time delete - delete the entity, if entity not found or already deleted - throw an error instead of success.

The question is if the second time delete - already throws NOT_FOUND status.

Can i catch the NOT_FOUND and throws entity not found for the given id?

Usually we will throw the entity not found exception in the business layer and custom exception will be thrown.

I am not sure what will be the side effect if i follow the above, please advise
Why do you throw an exception at all when the entity is not found?
Concurrency issue or user wants to know whether the attempt got failed..

Assume due to some reason the primary key got updated differently.
(1 like)
But why throw an exception? There's nothing the user did wrong if the item couldn't be found. Just use an Optional in your business layer.
Thanks for the explanation and we can close this.
Wink, wink, nudge, nudge, say no more ... https://richsoil.com/cards


This thread has been viewed 259 times.

All times above are in ranch (not your local) time.
The current ranch time is
May 25, 2018 02:44:20.