CODEWITHSUNDEEP
resthttppostput
Meena Chaudhary
Meena Chaudhary

Reputation: 10715

Clarification on using Http PUT & POST and their differences

I found this good post about understanding Http PUT & POST.

http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/

So the take away from the post are:

PUT:

POST:

All good, but I have following questions:

  1. I know it is possible to create new objects using PUT. That means even if I don't specify the location or id where object should be put, PUT method works. So, the statement made by the author PUT should be used when the client specifies the location for the page makes little sense or unconvincing when deciding when to use PUT.
  2. My second question is regarding this statement POST sends some data to a specified URL. The server on the other end of this URL can do whatever it wants with this data. But the same is possible with PUT method once the data has been received on the server. Which leads to conflict with his another statement PUT is a limited operation that never does anything more than PUT one page at a specified URL.
  3. Finally, are Http methods(PUT, POST, GET etc) more of a design concept or have technical implications when used.

Upvotes: 0

Views: 535

Answers (4)

Niks
Niks

Reputation: 4842

HTTP methods are more about semantics than actual implementations (that answers your 3rd question I guess). I would suggest that don't take any single person's opinion literally.

In general, I believe the following is true

  1. PUT

PUT needs an identifier in the url. And it will replace existing resource with whatever you provided. Replace here is important because, if you need partial updates, you should go for PATCH instead. If you expect the server to create a resource, you should call POST and not PUT. Calling a PUT with an imaginary id and expecting server to create the resource with that id does not make sense. Now this is what should be followed, but I have seen code which does otherwise just for convenience :)

  1. POST

POST should always create a resource. If the resource with similar details already exists, service may choose to return some kind of error code to denote that (may be 400 or 409)

Upvotes: 0

Biraj B Choudhury
Biraj B Choudhury

Reputation: 684

The Page analogy you gave doesnt fit into the context of PUT and POST.

PUT,POST,GET,DELETE etc are all HTTP operations to do certain operations on a resource

Let us consider a simple resource , this enpoint is written by a pet house who wants to track dogs through a REST based back-end(server side software)

/dogs

When we want to add a dog to the records of dogs, we do a 

POST /dogs with body

{
   color:'black'
   breed:'xyz'
   puppies: 0
   bla
   bla
   bla
}

It creates a new dog under /dogs resource with a unique identifier say identifier 1

Now the owner of the pet house wants to see all the dogs he/she has so the call made is

GET /dogs

This will list all the dogs and I can see what colour, what bred they are etc etc etc

I want to see a specific Dog, what do I call

GET /dogs/1 (Here 1 is the Identifier of the dog)

Which gives all details of Dog with identifier 1

Now let us say the Dog now gets married and has puppies (just so that it looks good socially) and we want to update the number of puppies to 3, what do you do 

PUT /dogs/1  with body

{
   color:'black'
   breed:'xyz'
   puppies: 3
   bla
   bla
   bla
}

and now the record of Dog 1 is updated.

Now the unfortunate moment the Dog dies , the owner makes this call

DELETE /dogs/1 and that resource is deleted from the records.

Another thing to understand is PUT is idempotent POST is not which means if you do

POST /dogs for 10 times 10 different instances of dogs are created if you do for 10 times PUT /dogs/1 , it still does the same thing to that 1 dog.

Upvotes: 0

kasoban
kasoban

Reputation: 2167

Your question #3 is on the right track: The HTTP methods don't have a technical implication on their own, but display a certain intent. These are defined in for example RFC 7231 / Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Theoretically, nothing stops you from implementing software that listens on a DELETE to trigger something other than a delete, create new entities from a PUT or delete when receiving a POST. Is that useful? Probably not, but definitely not impossible.

The HTTP methods are well defined as a kind of contract how they should be used, to allow interaction between different software components.

Upvotes: 1

Filippo Fratoni
Filippo Fratoni

Reputation: 399

POST is used to create new object while PUT is used to update existing object. If a server doesn't respect this rule it breaks the semantic.

Upvotes: 1

Related Questions