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

[mike at mykanjo.co.uk]

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

I've adressed this subsequently:

'here's the URL: example.com/report you can open this with adobe, excel, powerpoint, word'


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

Hypertext.

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

I've also already addressed this in the original post; I was quite clear that if browsers don't store the application state when you make a bookmark (headers, URI, HTTP method), then this is an argument for continuing to use URI conneg *aswell* as HTTP conneg; rather than instead. Until the browsers fix this. ;)

Browsers should really be bookmarking the whole request/state; the only reason they don't do this is because that's not the way it's done now. The reason for that is lack of incentive due to inadequate tooling, it's not a fair justification to say 'no one does it at the moment because its not necessary', that's disingenuous. The real reason is that HTTP is not adequately supported in HTML, and so browser requests never contain appropriately descriptive headers - hence why conneg was forced into the URI.

Alot of people, including the guys in the IRC channel, seem to be blaming the "insufficiencies" of HTTP conneg on HTTP itself.

Please feel free to describe these inherent problems with HTTP conneg without implying "browsers and HTML don't do it properly". I know they don't..! I don't consider that a criticism of HTTP, for obvious reasons.

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

Here you go:

wget example.com/report --header="Accept: application/pdf"

Regards,
Mike