On 13/12/2011, at 5:01 PM, Julian Reschke wrote: > 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. >
What are the "different requirements on response type" if not the media type of the response? No, sorry. With all due respect, I am in complete disagreement with you here. Perhaps others can try different tacks to convince either one of us but this is where we left it last time and looks to be just one of our unresolvable understandings. To progress, i have no problem with people using the Prefer header, can we just say that if people want to they can and leave it at that? It's another arrow in the quiver. >>>> 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. I disagree with negotiating *what* is represented within a single format and that this is of relevance to form specification. If the Preference token is not enough can you please state what additional problem must be addressed? > >> ... > > Best regards, Julian Thanks, Cam
