[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
mike at mykanjo.co.uk
mike at mykanjo.co.uk
Mon Nov 17 04:37:39 PST 2008
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!
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
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
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
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:
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.
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
> 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
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?
More information about the whatwg