On 2011-12-13 17:54, Cameron Heavon-Jones wrote:
On 13/12/2011, at 4:29 PM, Julian Reschke wrote:
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.
This is exactly where "Accept" should be used. Either the script should advertise it wants
"text\plain" status message or maybe an "application\json" response.
The media type of the response isn't relevant here. "Accept" is the
wrong header to negotiate on. Sorry.
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.
while it is possible to vary on another header, it is not desirable. this is
relatively immaterial for this discussion tho.
Sorry?
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.
yes, you are negotiating the representation. i have no problem with any of this but as a
recommended practice i would not vary on anything other than "Accept" and
question why a user of one html-client should see something different from a user of
another html-client.
What needs to be negotiated is *what* is represented (a status message
as opposed to current state as opposed to...), not the format.
...
Best regards, Julian
