W3C home > Mailing lists > Public > www-archive@w3.org > April 2011

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

From: Nathan <nathan@webr3.org>
Date: Sat, 02 Apr 2011 17:11:36 +0100
Message-ID: <4D974AB8.20703@webr3.org>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Cameron Heavon-Jones <cmhjones@gmail.com>, mike amundsen <mamund@yahoo.com>, public-html@w3.org, public-html-comments@w3.org, www-archive <www-archive@w3.org>
Julian Reschke wrote:
> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>> 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.

Yes, or when you (/server) want to specify/suggest where the resource 
should be PUT to within the HTML (after all, any predetermined value in 
the form @action for PUT will be precisely that).

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

Likewise, I strongly feel that some common use cases for PUT would be say:

1) coupling <form>, <input type="file"> and <progress> together in some 
way to allow somebody to say PUT an image/jpeg (with the correct 
Content-Type value)

2) PUTting some text/* or application/* specified in a <textarea> to a 
location, again with the correct Content-Type set.

If those are supported then all manner of clever domain specific server 
side juggling of representations can be done for those that want to try 
and juggle between application/x-form-urlencoded and say application/json.

I'd suggest that it would be easy to foresee a simple apache mod that 
enabled simple PUTting and DELETEing on resources, storing the 
representations as received, and that any efforts to support either PUT 
or DELETE should be focussed towards something people can actually use, 
out of the box, without any complex code implementation or domain 
specific understanding of experimental media types like 
application/x-form-urlencoded or POST centric ones like multipart/form-data.

Best,

Nathan
Received on Saturday, 2 April 2011 16:12:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT