[uf-rest] REST opacity and URL schemes.

[Dan Kubb]

-----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-----