-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
* If "/books/4" represents the "record", the PUT would need to
contain _everything_ about that record; synthesizing additional
fields (like last modified) seems like 'cheating', and
inconsistent with PUT semantics
Could you tell me what other resources than http://www.w3.org/
Protocols/rfc2616/rfc2616-sec9.html expand on this interpretation
of PUT? My naive reading of 9.6 PUT seems to be that it talks all
about updating and modifying. Not necessarily only complete
replacements. But I'm new here, so perhaps I just have an
incomplete picture.
I will say that PUT would seem a ton more useful if it didn't have
as strict a usage pattern as you imply. If that's the case, PUT
seems to be unusable for most web application purposes. And if
that's the case, I really question whether its worth doing other-
verbs-over-post mapping at all in Rails. Doesn't seem worth the
trouble just to get DELETE.
I think its important to separate what PUT was intended to do by
the spec authors, and what PUT has been used for in specific
implementations.
People familiar with PUT normally think of it in a WebDAV way
where it only makes sense to completely replace an existing file
with a new file. In most cases it doesn't make sense to replace
a part of a file with a chunk of data.
Just because its used this way in WebDAV doesn't mean that
its the only way PUT can be used.
The specs that David references is clear on the differences
between POST and PUT:
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. If the server
desires that the request be applied to a different URI, it MUST
send a 301 (Moved Permanently) response; the user agent MAY then
make its own decision regarding whether or not to redirect the
request.
(from http://rfc.net/rfc2616.html#s9.6)
So this means that POST is a way of sending data to a resource
that handles the request directly and/or can delegate the handling
to something else at its discretion. PUT is a way of changing
the state of a resource explicitly identified by its URI.
The spec is even pretty explicit that it doesn't dictate how PUT
should be handled by the server:
HTTP/1.1 does not define how a PUT method affects the state of an
origin server.
(from http://rfc.net/rfc2616.html#s9.6)
This sentence is the key -- the spec goes out of its way to
say it does not impose any restriction on what PUT should do
except to say that state will change in some way that is
application specific.
In this light I see no reason that PUT cannot be used to update
specific attributes of a resource. If you *could not* use PUT
in any other way except as a total replace function I would assert
that it has pretty much zero value outside of the file management
space.
- --
Thanks,
Dan
__________________________________________________________________
Dan Kubb
Autopilot Marketing Inc.
Email: [EMAIL PROTECTED]
Phone: 1 (604) 820-0212
Web: http://autopilotmarketing.com/
vCard: http://autopilotmarketing.com/~dan.kubb/vcard
__________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFESxP+4DfZD7OEWk0RAt+1AJ9Cxju/P/tO8FBRDScRXf/cH1SX7QCgpEAi
sH0M1CSYSi1+7hg86Z01Jb4=
=EmCv
-----END PGP SIGNATURE-----
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
