[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Smylers
Smylers at stripey.com
Mon Nov 17 06:12:23 PST 2008
mike at mykanjo.co.uk writes:
> 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.
Except that in practice on receiving a URL like the above, nearly all
users will try it in a web browser; they are unlikely to put it into
their PDF viewer, in the hope that a PDF version of the report will
happen to be available.
> A browser is a special case in which many different content-types are
> dealt with.
It's also the most common case. Supposing I opened the above URL in a
browser, and it gave me the HTML version; how would I even know that the
PDF version exists?
Suppose my browser has a PDF plug-in so can render either the HTML or
PDF versions, it's harder to bookmark a particular version because the
URL is no longer sufficient to identify precisely what I was viewing.
Browsers could update the way bookmarks work to deal with this, but any
exterrnal (such as web-based) bookmarking tools would also need to
change.
Or suppose the HTML version links to the PDF version. I wish to
download the PDF on a remote server, and happen to have an SSH session
open to it. So I right-click on the link in the HTML version I'm
looking at, choose 'Copy Link Location' from the menu, and in the remote
shell type wget then paste in the copied link. If the link explicitly
has ?type=PDF in the URL, I get what I want; if the format is specified
out of the URL then I've just downloaded the wrong thing.
Smylers
More information about the whatwg
mailing list