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

On 02/04/2011, at 6:50 PM, Nathan wrote:

> Cameron Heavon-Jones wrote:
>> On 02/04/2011, at 5:11 PM, Nathan wrote:
>>> 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
>> I think operating over files is a great example of how useful these operations can be and frames the problem into a far more real-world scenario for html over the way these operations are usually discussed in terms of XML and business processing.
>> I'm not sure if forms can support other media type encodings. The file input can specify an 'accept' attribute but i don't even think this would be sent with the file data under normal form encodings. 

multipart/form-data would send the content-type.

> 
> Which begs the question, is <form> even the correct approach? It appears to me that the fucntionality of forms will have to be special cased and effectively constrained just to do PUT (only certain elements make sense or would have a use, arguably) or DELETE (no elements really make any sense).
> 
> So perhaps, fresh eyes and a new approach, new elements, may be in order. That is, if it's not deemed that the use cases are so different and complicated that it infact makes more sense to just use scripting and xhr!
> 
> Best,
> 
> Nathan

Which functionality of the form will need to be special cased for PUT or DELETE? 

The only additions would seem to be the etag attributes which are non-offensive and highly desirable in my opinion.

Any content which is possible for POST must be possible for PUT.

I agree the case for customizing DELETE seems strange, why would you upload a file to delete a resource? There is nothing about the DELETE method which precludes if from containing any form of content in the body of the request, and with some further thought i can even think of where a case were this would be desirable.

What about if when DELETE-ing a resource the server requires a digital signature file to be uploaded with the request? Maybe this is a specific security mechanism on a resource-by-resource basis?

What about if there is some other conditional attributes required for a successful DELETE operation? The form element can capture these and so while security and conditions will *probably* be handled elsewhere doesn't mean they *must* be handled elsewhere. 

From the perspective of the HTTP protocol, there are no special requirements and hence i don't see any reason to introduce any special handling in HTML.

Thanks,
Cam

Received on Saturday, 2 April 2011 18:09:43 UTC