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

[Hallvord R M Steen]

> If you want to precisely identify the PDF *representation* (version) of that
> *resource* (document), you need the URI and your Accept headers set
> correctly. To that end, the solution to this problem would be to put
> example.com/document into a PDF reader.

>From a usability stand point, that sucks..
And what if I want to open the document with the PDF reader *plugin*
inside the browser? "Reconfigure the browser" is not the correct
answer. I want my browser to request HTML, *not* PDF though I in one
specific case want to see the PDF version of something with the PDF
plugin.

> Or if you were writing an HTML page,
> and you wanted to indicate in the <a> tag that the browser should
> specifically request the PDF representation, you include an
> Accept="application/pdf" attribute.
>
> Does that not count as a use case for this proposal? Perhaps not, if you
> believe that content negotiation belongs in the URI.

Well, I do. :-) It's more usable any way you look at it.

Here's the logic: URLs are in fact the primary user interface of the
HTTP protocol.
Any user interface should expose the options that users care about. If
users care about what format they want a resource in, this option
SHOULD be in the URL. I don't care if you as a developer think you're
providing different "representations" of the same "resource" - if I as
an end user consider what representation I want to see significant,
the option to choose between them should be right there - in HTTP's
main UI, i.e. in the URL.

Now I suggest you spend a week where you try pasting every URL you
want to see into a) Acrobat Reader b) OpenOffice.org c) Microsoft
Office and d) a browser (in that order) just to figure out how user
friendly the "put the same URL into a different application to get a
different representation" idea *actually* is. If you spend a week
doing that we can continue this discussion :-p

-- 
Hallvord R. M. Steen