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

[Adrian Sutton]

Hey Mike,
Good answers. :)

> 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.

Agreed.

> 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.

Agreed.

> 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>

Ok, this is an interesting example. Quite a few sites have a "PDF Version"
link which could be better done by linking to the same URL with different
accept headers - though you'd obviously have to set the Vary cache control
header appropriately.

> 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

This seems like a different use case to me and should be possible without
any additional modifications.  If the server is configured to return PDF if
that's the first thing in the Accept header *and* the user pastes the URL
into Acrobat instead of their browser, Acrobat would obviously prefer PDF so
list that first and have that returned by the server.

Note though, that in this case the user agent is responsible for setting the
Accept header so we don't need to change the HTML spec at all.

The reason this is basically never used today is two fold:
1. It requires correctly configuring the server, beyond just putting files
on the file system.  Very few people actually do this.
2. It requires the user to see a URL and decide that they want to paste it
into Acrobat instead of their browser, without any indication that it would
actually work.

> 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.

I agree this is pretty cool, but I don't see it every gaining traction,
because it requires so much more effort to set up than just having
report.html and report.pdf and report.xml which work correctly with the
server and caches out of the box. The fact that users are so unlikely to put
the URL into anything but a browser just makes it even less likely that this
effort would be rewarded.  Incidentally, a report.pdf in the URL would
dramatically increase the chances of the user trying to load it directly in
Acrobat instead of their browser because they can see that it's going to be
a PDF.

It is a cool idea though...

Regards,

Adrian Sutton.
______________________
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox <http://www.ephox.com/>
Ephox Blogs <http://planet.ephox.com/>, Personal Blog
<http://www.symphonious.net/>