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

[Thomas Broyer]

On Mon, Nov 17, 2008 at 6:31 PM,  <mike at mykanjo.co.uk> wrote:
> > Would the sender of that link necessarily know all the formats the URL
> > provides?  Anyway, that's an unrealistic amount of typing -- typically
> > round here people just copy and paste a URL into an instant message
> > and send it without any surrounding text.
> >
> > Whereas without any other information, people will generally open URLs
> > in a web browser.  So it'd be faster just to send the URL of the page
> > which contains hypertext links to all the formats; at which point we no
> > longer care whether those links specify the format in the URL or
> > elsewhere.
>
> - The HTML version of that URL could provide the web page representation
> *and* provide links to all the other content types available.

How about other representations? (I know we're discussing HTML here,
and not HTTP, but what if a resource has no HTML representation? are
you proposing adding this capability to PDF, MSOffice, OpenDocument,
et al. too?)

> > What is the point of doing it in HTTP if it's being done in HTML anyway?
>
> - Nothing is 'done' in HTML, it's a markup language. It's being done (at the
> moment) in the URI. HTTP provides conneg, why would you consciously
> deny developers the opportunity to use it in browsers? Unless HTML5
> provides the markup, this isn't possible. This means Browsers don't have
> the ability to fully support HTTP without having to use JavaScript rubbish;
> there is a window of opportunity to change this with HTML5.

No. Browsers fully support HTTP in the sense that they send an Accept
header dependent of their *capabilities*.
If you want client-driven conneg, then use agent-driven/transparent
(RFCs 2295/2296), not server-driven conneg. This is explicitly noted
in RFC 2616 that server-driven negotiation has limits and can be
disadvantageous depending on your needs.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12

> > True.  But if the current way of doing it is good enough, there's no
> > incentive to change."
>
> - Define 'enough'..! I don't know why/how you get the authority to
> make that assumption! And before you say it; I'm not assuming any
> authority myself - I'm trying to encourage you to help browsers conform
> to the protocol they make use of.

Maybe you could explain how browsers do not conform to HTTP? (and no,
HTTP does not mandate user-agents to give the control of the Accept-*
headers to the user or the... server?!)
There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the
servers the ability to describe the available variants of a given
resource in a content-type independent way. You'd rather push browser
vendors to implement TCN/RSVA than HTML5 to add a content-type
dependent equivalent.

See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5

> - I'll say it again: I'm encouraging you to help browsers become
> better HTTP clients; surely that is high on the agenda here.. right?!

No, we're discussing HTML and some "Web APIs" here, not HTTP.


> > Or what about if I wanted to mail somebody pointing out a discrepency
> > between two versions of the report, and wished to link to both of them.
> > That's tricky if they have the same URL.  Possibly I could do it like
> > you have with the wget command-line above, but that requires me knowing
> > which browsers my audience use and the precise syntax for them."
>
> - separate versions are separate resources, not separate content types. That
> has nothing to do with conneg..

s/version/variant/
Variants still need be produced by someone or something, and there
really might be discrepencies between them; that's why there's a
"quality" parameter in TCN/RSVA (and thus in Apache type-map files,
for instance)

-- 
Thomas Broyer