Re: PUT and DELETE methods in 200 code

<snip>
> No; what I wanted to say is that the originator affects the kind of payload to return, not the status code.
<snip>

OK, I see that. Thanks.

IOW, this ability for originators to affect the kind of response is
added functionality that is handy for requests in general. Browsers
could implement this today for POST (not sure it makes sense for
GET/HEAD) if there was a mechanism for passing that data along (i.e.
James Snell's I-D for the Prefer header[1]).

I see how this is handy. However, I don't see agents having the
ability to send a response preference as a pre-requisite for
supporting PUT/DELETE.


[1] http://www.ietf.org/id/draft-snell-http-prefer-03.txt

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


#RESTFest 2010
http://rest-fest.googlecode.com




On Mon, Apr 4, 2011 at 15:43, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 04.04.2011 20:37, mike amundsen wrote:
>>
>> <snip>
>>>
>>> ...but it *does* depend on the semantics of
>>> the method.
>>
>> </snip>
>>
>> I'm sure this is just me being a bit dense (losing details in the
>> emails, etc.), but 'm not following that last part.
>>
>> "it" (the response code?) depends on the semantics of (PUT) the method? or
>> "it" (what the server returns?) depends on the semantics of (PUT) the
>> method?
>
> The latter.
>
>> ...
>> Since PUT supports both create and update, I assume you mean to assert
>> that servers should "know" whether this is a create or update and that
>> the response would be altered accordingly (e.g. PUT(create) MAY return
>> a 201, but a PUT(update) SHOULD NOT return a 201, etc.).  Do I have
>> that right? If that's the case, servers can make that determination on
>
> Absolutely.
>
>> their own; the same way it is done today (w/o FORMS).  I don't see how
>> introducing an HTML FORM as the initiator of the request changes that
>> (e.g. I don't know what _new_ thing HTML FORM-generated PUT introduces
>> that might 'confuse' servers as to how to handle the request and
>> generate the 'proper' response).
>
> No; what I wanted to say is that the originator affects the kind of payload
> to return, not the status code.
>
>> In addition, servers are not REQUIRED to enforce the inclusion of the
>> If-none-match (for PUT(create) or if-match (for PUT(update)) headers
>> for PUT. Therefore, any attempt to try to "infer" anything from these
>> headers will fail in cases where the headers do not appear.
>
> Indeed.
>
> Best regards, Julian
>

Received on Monday, 4 April 2011 20:14:23 UTC