|
|
 |
Article:
|
|
How to Create a REST Protocol
|
| Subject: |
PUT is not an update |
| Date: |
2004-12-02 21:01:02 |
| From: |
John Schlesinger |
|
|
|
|
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."
Update is never idempotent, whereas insert it.
John Schlesinger
|
- PUT is not an update
2005-05-04 07:06:11 Lars Huttar
[Reply]
""[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.
Thanks,
Lars
- PUT is not an update
2004-12-03 04:58:54 jgregorio
[Reply]
To quote from RFC 2616:
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."
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
|
|
Sponsored By:
|
Previous Message
