Comments on: POST vs. PUT http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/ Ranting and Raving Thu, 18 Mar 2010 19:01:40 -0500 http://wordpress.org/?v=2.9.1 hourly 1 By: Mark http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-862315 Mark Tue, 26 Jan 2010 12:37:30 +0000 http://blog.elharo.com/blog/?p=46#comment-862315 If you have to use the analogy: PUT = REPLACE (http://dev.mysql.com/doc/refman/5.0/en/replace.html) POST = CALL (stored procedures) If you have to use the analogy:

PUT = REPLACE (http://dev.mysql.com/doc/refman/5.0/en/replace.html)

POST = CALL (stored procedures)

]]> By: PUT or POST: The REST of the Story « Open Sourcery http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-555370 PUT or POST: The REST of the Story « Open Sourcery Thu, 16 Oct 2008 22:51:23 +0000 http://blog.elharo.com/blog/?p=46#comment-555370 [...] POST vs. PUT [...] [...] POST vs. PUT [...]

]]> By: Elliotte Rusty Harold http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-553027 Elliotte Rusty Harold Mon, 13 Oct 2008 13:14:43 +0000 http://blog.elharo.com/blog/?p=46#comment-553027 Your understanding of HTTP is understandable but incorrect. AtomPub is correct. PUT is update or create with a user-supplied URL. POST is create with a server generated URL. There are no custom actions at all. That is one of the key principles of REST. Resolving an incident, reopeningt a ticket, etc. are all defined as one of four actions (PUT, POST, GET, DELETE) on a resource. For instance to reopen a ticket, you might PUT the text "true" to http://www.example.com/tickets/42389349/opened. Your understanding of HTTP is understandable but incorrect. AtomPub is correct.

PUT is update or create with a user-supplied URL. POST is create with a server generated URL. There are no custom actions at all. That is one of the key principles of REST. Resolving an incident, reopeningt a ticket, etc. are all defined as one of four actions (PUT, POST, GET, DELETE) on a resource. For instance to reopen a ticket, you might PUT the text “true” to http://www.example.com/tickets/42389349/opened.

]]> By: Daniel Woo http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-552745 Daniel Woo Mon, 13 Oct 2008 09:44:12 +0000 http://blog.elharo.com/blog/?p=46#comment-552745 Our understanding of HTTP methods for generic Restful web service: PUT --> create or update (idempotent) POST --> custom actions (like resolve incident, reopen a ticket, activate a workflow etc) DELETE --> delete GET --> read (safe, idempotent) HEAD --> existence (safe, optional)    But Atom Publishing Protocol use POST for creation: PUT --> update POST --> create DELETE --> delete GET -- > read   Why PUT for Update while POST for creation? PUT is create or update in HTTP specification, so it’s best to follow HTTP specification, however Atom uses a different strategy here. I think the reason why Atom Publish Protocol uses POST for entry creation is because in most cases this will return a new ID. While this kind of creation is not appropriate for PUT, since PUT must use the record ID at the end of the URL, eg /rest/person/2012, when the ID is an auto-increment ID at the service end, you can not use PUT to create a record. For POST, the URI would be /rest/person and the service end has the knowledge to generate an ID let’s say 2013 and put the new record’s resource URI “/rest/person/2013” in the response header “location”. This exactly follows HTTP spec.   But for those entities you can specify a PK or ID when creating them, and there is no pre-conditions to create them, surely PUT is a better way. Our understanding of HTTP methods for generic Restful web service:
PUT –> create or update (idempotent)
POST –> custom actions (like resolve incident, reopen a ticket, activate a workflow etc)
DELETE –> delete
GET –> read (safe, idempotent)
HEAD –> existence (safe, optional)
  
But Atom Publishing Protocol use POST for creation:
PUT –> update
POST –> create
DELETE –> delete
GET — > read
 
Why PUT for Update while POST for creation?
PUT is create or update in HTTP specification, so it’s best to follow HTTP specification, however Atom uses a different strategy here.
I think the reason why Atom Publish Protocol uses POST for entry creation is because in most cases this will return a new ID. While this kind of creation is not appropriate for PUT, since PUT must use the record ID at the end of the URL, eg /rest/person/2012, when the ID is an auto-increment ID at the service end, you can not use PUT to create a record. For POST, the URI would be /rest/person and the service end has the knowledge to generate an ID let’s say 2013 and put the new record’s resource URI “/rest/person/2013” in the response header “location”. This exactly follows HTTP spec.
 
But for those entities you can specify a PK or ID when creating them, and there is no pre-conditions to create them, surely PUT is a better way.

]]> By: James Crisp - Ruby on Rails, C#, .NET, book reviews, film reviews, mind hacks, Wing Chun and the occasional personal bit. » Practical JRuby on Rails (Web 2.0 Projects) by Ola Bini http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-208899 James Crisp - Ruby on Rails, C#, .NET, book reviews, film reviews, mind hacks, Wing Chun and the occasional personal bit. » Practical JRuby on Rails (Web 2.0 Projects) by Ola Bini Sun, 16 Dec 2007 04:36:57 +0000 http://blog.elharo.com/blog/?p=46#comment-208899 [...] REST is only mentioned briefly in a little sidebar, and the description of REST as CRUD is a bit misleading, especially when considering POST vs PUT. [...] [...] REST is only mentioned briefly in a little sidebar, and the description of REST as CRUD is a bit misleading, especially when considering POST vs PUT. [...]

]]> By: Pingala http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-96314 Pingala Tue, 10 Jul 2007 18:45:59 +0000 http://blog.elharo.com/blog/?p=46#comment-96314 I think these methods (from any Requester to any server/service) have to be consistant across broad in order to be operable as expected in a transcational conversation. That is the protocol syntax. Hence, the server/service components and the request components should implement in the same way what RFC 2616 spelled out: The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. I think these methods (from any Requester to any server/service) have to be consistant across broad in order to be operable as expected in a transcational conversation. That is the protocol syntax. Hence, the server/service components and the request components should implement in the same way what RFC 2616 spelled out:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

– Annotation of existing resources;
– Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
– Providing a block of data, such as the result of submitting a
form, to a data-handling process;
– Extending a database through an append operation.
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

]]> By: cbmeeks http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-76988 cbmeeks Fri, 25 May 2007 11:57:46 +0000 http://blog.elharo.com/blog/?p=46#comment-76988 Great article! I've never really understood why use PUT or why use POST. To me, they "seemed" to do the same thing. But your explanation made it simple. Also makes me understand why Amazon's S3 uses PUT instead of POST. Because if you upload a file, and upload it again, it doesn't duplicate...it wipes the first one out and replaces. Makes sense. cbmeeks http://www.signaldev.com Great article! I’ve never really understood why use PUT or why use POST. To me, they “seemed” to do the same thing. But your explanation made it simple. Also makes me understand why Amazon’s S3 uses PUT instead of POST. Because if you upload a file, and upload it again, it doesn’t duplicate…it wipes the first one out and replaces. Makes sense.

cbmeeks
http://www.signaldev.com

]]> By: Alex http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-63695 Alex Mon, 23 Apr 2007 00:42:11 +0000 http://blog.elharo.com/blog/?p=46#comment-63695 Thank You Thank You

]]> By: pauldwaite http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-57821 pauldwaite Fri, 30 Mar 2007 23:39:17 +0000 http://blog.elharo.com/blog/?p=46#comment-57821 Wonderfully explained. Thank you. Wonderfully explained. Thank you.

]]> By: License 2 Code » PUT vs POST - Confusion Abounds http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/comment-page-1/#comment-18946 License 2 Code » PUT vs POST - Confusion Abounds Sat, 04 Nov 2006 18:20:22 +0000 http://blog.elharo.com/blog/?p=46#comment-18946 [...] In my research on REST this last week, I’ve seen several comments noting confusion on whether to use PUT or POST. After reading several references (Elliotte Rusty Harold, Sacrificial Rabbit, and Mark Baker) , I will attempt to paraphrase the rule as: [...] [...] In my research on REST this last week, I’ve seen several comments noting confusion on whether to use PUT or POST. After reading several references (Elliotte Rusty Harold, Sacrificial Rabbit, and Mark Baker) , I will attempt to paraphrase the rule as: [...]

]]>