[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Hallvord R M Steen
hallvors at gmail.com
Wed Nov 19 10:10:58 PST 2008
> 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
> 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
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
More information about the whatwg