Re: PUT and DELETE methods in 200 code

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 19:44:04 UTC