Re: [Fwd: Re: PUT and DELETE methods in 200 code]

On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
> ...
>>> Personally I'd add "should integrate well with servers which already support
>>> PUT and DELETE, such as WebDAV servers"
>>
>> sounds ok.
>>
>
> I would hesitate at making references to WebDAV. This is an extension of HTTP and as such introduces additional functionality which, IMO, is not appropriate for the top-level specification.
> ...

As a normative reference, no. As a use case to be considered, yes.

> ...
>
> I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...
>
> why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.

There are use cases for PUT-to-create. Namely, when you *want* to enable 
the client to name the resource.

> ...
>> Yeah, Snell's notion seems closer to what might be desireable. Of
>> course, having agent add a new (optional) header will not likely
>> improve the results from any existing servers.
>>
>
> I suggested using the Accept header as this is how content negotiation works everywhere... why reinvent what is already there? Why should it be ignored just because the request is from a form submission?

The reason why I'm nervous is that I'm not sure that Accept: ever has 
used for this purpose, and it also doesn't convey the intent of a client.

Remember that "Accept: text/html" doesn't tell the server *what* the 
client wants to see, just the format. So do you return a status message, 
or a representation of the resource?

> I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.

That is true.

What I want to avoid though is that a server can't support PUT for both 
forms and other kinds of clients on the same URI.

> Current implementations of PUT and DELETE definitely won't be returning content but then these services currently aren't designed for human interaction anyway. They will require forms to be created and they will require the HTML results of processing those forms to be created too.

Sorry? They are not designed for *browser* interaction, but still 
they'll interact with users.

> ...
>>> How *are* they handled by UAs? (Is this in HTML5?).
>> Excellent question<g>. I have _assumed_ since servers are free to emit
>> 201/202/204 for POST today that the HTML WG had no real concern for
>> this case. It's not clear to me why adding PUT/DELETE to the list of
>> supported methods alters the importance of handling these types of
>> responses, but I'm open to hearing more about it.
>>
>
> I would suggest that ALL http responses MUST be rendered by the user agent. It should make no matter what the response status is for a user to see the result of their request.

Is this the case today? Need test cases.

 > ...

Best regards, Julian

Received on Saturday, 2 April 2011 15:59:31 UTC