Re: PUT and DELETE methods in 200 code

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

I am _assuming_ DELETE is not involved in your statement, but I'm not
sure of that, either<g>.

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

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.

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 13:29, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 04.04.2011 19:21, mike amundsen wrote:
>>
>> Julian:
>>
>> <snip>
>>>
>>> ...in order to decide whether to return a payload to the UA for display?
>>
>> </snip>
>> So, this is not a PUT/DELETE issue at all, since POST can (and does)
>> result in 201/202/204 response codes, too.
>> ...
>
> It's not specific to PUT/DELETE, but it *does* depend on the semantics of
> the method.
>
> Best regards, Julian
>

Received on Monday, 4 April 2011 18:38:18 UTC