Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Unable to understand idempotent  RSS feed

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 9145
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 965
9
Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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/
 
 
Kathir jeyap
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan, theoratically it's fine..Don't understand it practical issues

Any code snippet would be great to understand for PUT and DELETE
 
Stephan van Hulst
Saloon Keeper
Posts: 9145
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kathir jeyap
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ??
 
Stephan van Hulst
Saloon Keeper
Posts: 9145
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kathir jeyap
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So what would be the best practice to do ??
 
Sheriff
Posts: 23646
49
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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



To do what?
 
Kathir jeyap
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Stephan van Hulst
Saloon Keeper
Posts: 9145
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do you throw an exception at all when the entity is not found?
 
Kathir jeyap
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Concurrency issue or user wants to know whether the attempt got failed..

Assume due to some reason the primary key got updated differently.
 
Stephan van Hulst
Saloon Keeper
Posts: 9145
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kathir jeyap
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the explanation and we can close this.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!