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

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.

Received on Monday, 17 November 2008 04:32:58 UTC