- From: mike amundsen <mamund@yahoo.com>
- Date: Tue, 13 Dec 2011 10:09:01 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mirko Gustony <mirko.gustony@gmail.com>, Cameron Heavon-Jones <cmhjones@gmail.com>, thibault <thibault@miximum.fr>, public-html-comments@w3.org
Based on repeated comments about what this issue of what the browser user-agent *expects* as a return for PUT/DELETE, I wonder if things would go better if the Prefer header proposal was included in all this. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Tue, Dec 13, 2011 at 10:04, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2011-12-13 15:23, Mirko Gustony wrote: >> >> Hello, >> >> excuse me but, >> >> 2011/12/13 Julian Reschke<julian.reschke@gmx.de>: >> >>>> I think that is quite definitely Out Of Scope. If there needs to be >>>> different content for the same format this should be a different URI. >>> >>> >>> >>> I disagree. If you need separate URIs to make this work, something is >>> wrong. >> >> >> from my reading of [1] (and several other sources on that) Cameron >> seems to be right. Different content (not different representation) >> means different document and therefor different URI. > > > We're talking about a single resource (thus one URI), that gets a DELETE > request. > > Different clients have different expectations on the response payload they > get for a successful DELETE, though. Most non-HTML clients do not care about > any additional information, so sending more than a status message is a waste > of bits. > > Note that HTTP says: > > "A successful response SHOULD be 200 (OK) if the response includes an entity > describing the status, 202 (Accepted) if the action has not yet been > enacted, or 204 (No Content) if the action has been enacted but the response > does not include an entity." -- > <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7> > > So you can send a "status" page, but assuming that a server always will do > that would be incorrect because most clients will not need it. > >> I for one would welcome a solution for bringing RESTful webservices to >> HTML forms without hacks or Javascript. >> ... > > > Yes, but please let's not replace one kind of hack with a different kind of > hack. > > Best regards, Julian >
Received on Tuesday, 13 December 2011 19:08:49 UTC