[uf-rest] REST opacity and URL schemes.

[Charlie Savage]

+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 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: dan.kubb at autopilotmarketing.com
> 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
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
Url : http://microformats.org/discuss/mail/microformats-rest/attachments/20060423/ba94ef4e/smime-0001.bin