• 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:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Devaka Cooray
Saloon Keepers:
  • Ganesh Patekar
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
Bartenders:
  • Ron McLeod
  • Frits Walraven
  • Pete Letkeman

What does it mean when it says "GET" is read only and "PUT" is to create new resource in RESTful WS?  RSS feed

 
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I have to submit a form and I decide method="get" for that form, the object is received at Controller by @POST of REST and there you may perform an insert operation with that object or just use that object to fetch the matching data.
Similarly when you have "post" method for the form and you may insert that object into db so you can say you have "created a new resource." I understood it.
Regarding "PUT", when the object is received at Controller, you can create a new resource of that object too, can't you? So I'm confused how the PUT method "produces the same results if executed once or even multiple." Why cannot it create new resource every time?


Your help will be appreciated, thanks in advance.
 
Bartender
Posts: 1856
81
Android Chrome IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The differences be POST and PUT are the same as the differences between creating a record/resource and updating a record/resource as noted below.

Generally speaking there are a few "verbs" or methods that you deal with when working with web services, restful or not and they are GET, POST, PUT, DELETE.
These usually map to database operations:
- About 99% of the time GET is used to retrieve records/data/resources. If you accept GET data for anything else then you may have security flaws.
- Nearly all the time DELETE is used to remove records/data/resources.

This leaves us with POST and PUT which act nearly the same way.
POST is generally used to insert/create a record/resource.
PUT is generally used to update a record/resource.
Some times people use POST to update a record/resource and PUT to insert records/resources. This can be an acceptable way to do things.

To add to the confusion, you can get away with using only GET and POST methods and not all web services support all verbs.
 
Saloon Keeper
Posts: 9378
181
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a guideline I use for choosing between POST and PUT. If you want to update an existing record, always use PUT. If you want to create a record, it depends on whether you can uniquely identify the created record using nothing but the information you sent in the request.

Let's say that you want to register a new employee. Employees have names and employee IDs. You would use POST to create a new employee, because you don't know what ID the new employee will have until after the request has completed.

On the other hand, in my old student apartment we had an application in which we registered who cooked dinner on what day, and who would be joining dinner. You could uniquely identify a dinner by date, so creating a new dinner record would be done using a PUT request, because you send the date (the ID of the dinner) in the creation request.

Another easy to remember guideline: If sending the exact same request twice in a row would result in only one new record, use PUT. If sending the same request twice creates two new records, use POST.
 
Arun Singh Raaj
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the responses.

When you make "PUT" call using Ajax, does it automatically add "id" to the url?
And when you make "POST" call, it doesn't add any id. Is it true?
 
Arun Singh Raaj
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When the definition says "PUT" method is idempotent. Doesn't its idempotency rely on the code you write within the method?
In ajax call, when you write the method as "PUT", what difference it makes than "POST". If you decide the method as "PUT" in ajax call and you perform "save()" operation after receiving the object then how is it idempotent?
Similarly if you perform  "update()" operation from a "POST" call then didn't "POST" method become idempotent?

 
Stephan van Hulst
Saloon Keeper
Posts: 9378
181
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's what the browser does specially for each of the following verbs:

GETPuts request parameters in the URL as query string parameters.
PUT/DELETEPuts request parameters in the body of the HTTP request.
POSTLike PUT and DELETE, except when you go 'back' in your browser to a page that resulted from a POST request, the browser will ask you if you want to resend the request.

In Ajax calls though, POST works the same way as PUT and DELETE.

Other than this, the browser doesn't do anything special. In particular, it doesn't automatically add an "ID" to the URL (how would the browser know what ID to add?).

Idempotence is achieved by application layer code in the server. It's possible to write idempotent code to handle a POST request, and it's possible to write code that isn't to handle a PUT request. It will be very confusing to a client of your application though.
 
Arun Singh Raaj
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
Idempotence is achieved by application layer code in the server. It's possible to write idempotent code to handle a POST request, and it's possible to write code that isn't to handle a PUT request. It will be very confusing to a client of your application though.


So do these methods have purpose just to provide clarity to the developers?
I mean so you can understand it easily that if you see @PUT then it means the method would be performing "update", if you see @POST then it will be creating new records? is that all?

Thanks.
 
Stephan van Hulst
Saloon Keeper
Posts: 9378
181
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, because as I showed in my earlier post, the browser treats these methods differently as well. Besides, they may also be used to differentiate between requests. Sending a POST to a certain address may trigger a completely different action than sending a PUT.
 
Arun Singh Raaj
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.

Stephan van Hulst wrote:On the other hand, in my old student apartment we had an application in which we registered who cooked dinner on what day, and who would be joining dinner. You could uniquely identify a dinner by date, so creating a new dinner record would be done using a PUT request, because you send the date (the ID of the dinner) in the creation request.


Does this have any side effect if you use POST here? you pass the data from client side which received at server as POJO object, then you perform save(dinner) operation to the db to create a new resource. What makes the PUT better choice over POST in this case?

Sending a POST to a certain address may trigger a completely different action than sending a PUT.


Could you please clear this by providing an example?
 
Stephan van Hulst
Saloon Keeper
Posts: 9378
181
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Arun Singh Raaj wrote:What makes the PUT better choice over POST in this case?


The browser won't ask you to resubmit the data when you press the 'back' button. It assumes that sending the request a second time will not have any new effect, so it can just cache the result and display it without making a round-trip to the web application server. Not just browsers, but other tools that work with HTTP might be interested to know that a request is idempotent. PUT indicates that.

Could you please clear this by providing an example?


 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!