Re: Follow-up about PUT and DELETE in form methods

On 2011-12-13 17:09, Cameron Heavon-Jones wrote:
> ...
> Let's leave WebDAV alone. What is the use case we're discussing then if not how WebDAV servers return a status message for WebDAV client and full html representation for browsers over the same "Accept" header?
> ...

For instance, a UI that allows deleting resource both through a 
script-less form (where you need a new HTML page to be displayed as 
result), and a script-driven XHR based UI (where you only want to know 
success/fail). Note that in both cases the same user agent makes the 
request, but it has different requirements on the response type.

>> Also, Content Negotiation via Accept: doesn't help here. Accept: is for negotiating the media type of the response, not what it describes. We need a different hook.
>
> Content negotiation is a valid (and the only) way for determining whether to send html or not.

It depends on what request header is used for negotiation.

> You want to send different html based on who the client is. This is bad ReST, IMO.

Wrong.

I might agree if this was about GET, but it's not. What needs to be 
negotiated is not the media type but something else; *what* the response 
should represent (the status of the request, the new state of the 
resource, whatbot). Keep in mind that in general, the response to a 
request other than GET is *not* a representation of the addressed resource.

> ...
>> You may want to consult the HTML WG's Decision Policy document for details.
>>
>> Best regards, Julian
>
>
> The decision policy is not definitive in this regard, i was trying to solicit some common consensus on the best way to proceed in the interests of this case and contributors.
>
> My opinion is that this is only going to progress as a tracker issue. i assume that your opinion is that the bug should remain RESOLVED WONTFIX as you opened the bug and are no doubt satisfied with the current status, for the time being.

I'm satisfied that the text that was in HTML5 back when I opened the bug 
has been removed, as it was causing implementations to do things they 
should not do.

I'm not satisfied with having no solution for PUT and DELETE, but having 
a proper solution in the future IMHO is much better than having a broken 
solution today that will be impossible to back out due to existing 
content relying on it.

> this leaves me in the position of requiring this to be escalated to ensure it is addressed within HTML5. i have not heard anything which changes my opinion on this and hence will request a tracker issue unless there is some reasoned objection and suggestion of an alternative path.

Best regards, Julian

Received on Tuesday, 13 December 2011 16:29:43 UTC