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

[mike at mykanjo.co.uk]

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


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

"Not just browsers, as I pointed out.  Also many databases which have
tables with URL fields would need extra fields adding."

- I suggested the attribute should be optional, so it would make no difference; one would simply avoid using it if it was a big problem.


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


"There's little point in making browsers implement extra functionality and inventing new mark-up and evangelizing it, only to end up with the same functionality we started with; there has to be more.  And the greater the effort involved, the greater the benefit has to be to make it worthwhile."

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



"Typing that would require my knowing that URL of the PDF also serves
other formats.

But, moreover, it requires typing.  Currently the URL can be pasted in,
the text that the browser copied to the clipboard.  There's no way that
my browser's 'Copy Link URL' function is going to put on the clipboard
the exact syntax of wget command-line options.  Having to type that lot
in massively increases the effort in this task -- even if I can type the
relevant media type in from the top of my head, without needing to look
it up."

- You're using a command line and complaining about having to type too much? If it mattered that much it would be a 2 second job to write a wrapper script of some kind.. wget is a developer tool it's not supposed to be convenient anyway.

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

if you wanted my take on it I'd do it like this:

example.com/report (automatically provides latest report)
example.com/report/versions (list all versions)
example.com/report/versions/0.1 (version 0.1)
example.com/report/versions/5.6 (version 5.6)

obviously I'd make each of those available as json, xml, html, pdf, xls, and whatever else worked! :)

Regards,
Mike