Although it is tempting to think of PUT as an update, this is very misleading. It is actually more like an insert. POST is more like an update. So I think these are the wrong way around in the article.
As Roy Fielding says in http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
" Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent."
""[idempotent means] the side-effects of N > 0 identical requests is the same as for a single request"
...
Update is never idempotent, whereas insert i[s]."
Somebody help me with this... It would seem to me the other way around: Update should be idempotent, not Insert. If you update, say, an employee #127's name to "Smith" multiple times, it's the same as doing it once. But if you Insert a new employee named Smith multiple times, you get multiple new employees, whereas if you do it once, you get one new employee. Thus, intuitively at least, Update is idempotent and Insert is not.
What am I missing?
Anyway, I appreciate the knowledgeable debate on PUT vs. POST. It is a confusing issue.
On POST[1]: " Extending a database through an append operation."
On PUT[2]: " The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server."
HTTP was originally created for managing collections of documents.
PUT is intended to be used for adding new documents. A PUT only becomes an 'update' when the specified document already exists. PUT can effectively be both CREATE and UPDATE.
POST is really much more general than either a CRUD CREATE or a PUT. (Joe, I think you did yourself a disservice with the quote that you pulled from section 9.5 of the HTTP spec.)
There is, however, a more subtle point that isn't explicit in the article. From section 9.6:
"The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource."
While I tend to disagree with the CRUD table in the article, I don't have the same issue with the final table which shows the protocol and reflects that a POST as CREATE is performed against the 'All Employees' collection and the PUT as UPDATE is performed against a specific 'employee'.
I do have one question: What does it mean to POST to an employee?
This is very good . I will try to implement this later on tonight. I am pretty new to REST, so hopefully I can figure it out
best interest rates on savings (http://bestinterestratesonsavings.net) | spandex shorts (http://spandex-shorts.org)
"I do have one question: What does it mean to POST to an employee?"
The best you can say is that POST isn't defined for an employee by this article. Then again neither is OPTIONS, or LOCK, or any of the other methods you could apply. It does mean that a later spec or article could come along and define what it means to POST to an employee.
Previous Message
