RE: Using Content Negotiation to relate "data resources" to AJAX user interfaces

Martin,



The base URL for Gmail is http://mail.google.com/mail/ which appears to redirect to http://mail.google.com/mail/#inbox. Within your inbox, you can click on an email - if you do, Gmail will open your email and the browser address bar will change to something like this: http://mail.google.com/mail/#inbox/11f804dfae358bd9. An improbable number of POSTs and GETs go on under the covers before this URL appears and none of them would make you expect that this URL would appear, but somehow it does - GMail is not simple. Security will hopefully stop you from following this link to this email, but I can do it. So GMail provides me with URLs for each of my emails of the form http://mail.google.com/mail/#inbox/11f804dfae358bd9, and it makes those URLs appear in the address field, which is where users would expect they would appear.

 

There's two aspects here. The first one is not to be ignored, an email is an IR, and identifying the email "the thing" and the email "the byte stream" doesn't make much sense. The hash URI exist only because of javascript limitations that prevent the location bar from changing when navigation is done from within the page. I think it's important to highlight the fact that this is not a technical choice but a workaround current browser limitations.


L representation, content-negotiation would again give the right thing. This is a huge improvement in usability of my solution.

So why don't we just implement thisdesign? The objection, pointed out by several of our developers (and me) is that it's a distortion to say that the GMail HTML returned by http://mail.google.com/mail/#inbox/11f804dfae358bd9 is a representation of the email. It's more reasonable to think of it as a JavaScript program that turns around and does a bunch of further GETs and POSTs in whose responses are somewhere buried a representation of the email. I'm guessing this is why the authors of the paper cited above advised against using content negotiation for this case - it seems like a hack that is not in the spirit of the web architecture.

 

Conneg should be used when two documents are the same enough that they can be swapped around without too much limitation. Enabling rfc822, xml and json on such a "data URI" is quite a valid approach.
 
What I have implemented in the past is a methodology for discovery of the real URI for a hash URI. This looks like this:
/mail/inbox/1 is the email on which conneg can be done amongts formats with enough sameness
/mail#inbox/1 is the hash URI for the email that is used for identifying it in the browser (until javascript is given access to the location bar)
/mail is a resource containing the links to the email entries for clients given the hash uri so they can redirect themselves to the correct location
 
mail contains links using either a standard media type or a custom format. For example:
200 OK
Content-Type: application/vnd.acme.maillist+xml
Vary: Accept
 
<mailbox>
 <link identifier="inbox/1" href="/mail/inbox/1" />
</mailbox>
 
The html document contains javascript code that goes and fetch the email identified by the fragment. In REST parlance, we're talking about mobile code to provide a user-agent that doesn't understand a media type specifics to parse it.
 
And indeed, the reosurce you're accessing is *not* your email, it's the /mail resource, for which you have a fragment URI.
 
Provided you define your media type to define the @identifier attribute to be the handler of the fragment, and ideally provided that you indeed, in the original /mail html representation, you have a <a name="xxx"> as a link to the mail, you are approaching the sameness requirement.
 
The last contentious bits is, in the case of html, to redirect /mail/inbox/1 to /mail and deliver the mobile code to process the request.
 
This is necesary, because from the point of view of the http server, there is no such thing as a hash uri, it is (in this scenario) for processing by the client.
 
I've used this pattern in several implementations. Any feedback would be more than welcome (especially if, as I do often, I completely missed the point and suddenly broke the whole web architecture).
 
Sebastien Lambla
_________________________________________________________________
Love Hotmail?  Check out the new services from Windows Live! 
http://clk.atdmt.com/UKM/go/132630768/direct/01/