+1 Charlie
Dan Kubb wrote:
-----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 semanticsCould 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ microformats-rest mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-rest
