[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

[mike at mykanjo.co.uk]

Just to clarify - I was suggesting that the type-less URI and Accept header method was a better solution, not the "example.com/report?type=application/rss+xml" example I gave.

Also; "including an optional header" should be "including an optional attribute".

Sorry for any confusion!

Regards,
Mike

---------------

Adrian,

The server is not obliged to respect the Accept header, there is nothing 
preventing the server from returning a gif even if the Accept header indicates 
solely png. This is actually the case with specifying content type in the URL, 
since there is nothing preventing example.com/index.html returning a jpeg for 
example.

A URI is a resource identifier - content-type is seperate from that, and 
concerned with a specific representation of a resource rather than the resource 
itself. This was the intention of the Accept header being included in the HTTP 
protocol, as per my understanding from the rfc and Roy Fielding's thesis.

>From my perspective, it seems wasteful to ignore this opportunity to expand 
the ability of the markup to better reflect best-practice HTTP transactions by 
including an optional header. Surely it is better if HTML and browsers can 
support this natively without having to resort to javascript hackery.

as an example:

<a href="http://example.com/report">html report</a>
<a href="http://example.com/report" Accept="application/pdf">pdf report</a>
<a href="http://example.com/report" Accept="application/rss+xml">xml 
report</a>

So I can send a colleague a message; 'you can get the report at 
http://example.com/report', and they can use that URL in any user agent that is 
appropriate. A browser is a special case in which many different content-types 
are dealt with. The same benefit is not achieved if the content is negotiated 
via the URL, since the user would have to know the type their user agent 
required and modify the URL accordingly:

example.com/report?type=application/rss+xml

To me, this is a much cleaner and more appropriate use of a URI. Not to mention 
more user-friendly. Something, I believe should be encouraged - this is why I 
feel it would be an important addition to HTML5.

Any thoughts?

Regards,
Mike

On 17/11/2008 11:29, "mike at mykanjo.co.uk" <mike at mykanjo.co.uk> wrote:
> Does anyone else agree that an Accept attribute would be a useful tool for
> making browser interaction more RESTful? Is it worth persuing this issue 
with
> the HTML5 working group?

I don't see why the Accept header when following links or requesting images
should be controlled by anything other than the browser.  It's the browser
that has to decide actually render the returned content so it's in the best
position to decide what it can accept, not the page author.

On the other hand, XMLHttpRequest should be able to control the Accept
header because the page author will control the JavaScript which has to
handle the response. I would have thought this was already possible though.

Is there a particular use case you had in mind where the HTML author would
know what the browser accepts better than the browser does?

Regards,

Adrian Sutton.