- From: John Kemp (Nokia-S&S/Williamstown) <john.kemp@nokia.com>
- Date: Thu, 31 Jul 2008 13:44:38 -0400
- To: "ext Booth, David (HP Software - Boston)" <dbooth@hp.com>
- CC: Richard Cyganiak <richard@cyganiak.de>, "T.V Raman" <raman@google.com>, "seb@serialseb.com" <seb@serialseb.com>, "www-tag@w3.org" <www-tag@w3.org>, "kidehen@openlinksw.com" <kidehen@openlinksw.com>, "tthibodeau@openlinksw.com" <tthibodeau@openlinksw.com>
ext Booth, David (HP Software - Boston) wrote: >> From: Richard Cyganiak [ . . . ] Let's say I have >> >> /resource (generic information resource with HTML and JSON >> variants) /resource.html (a HTML specific URI) /resource.json (a >> JSON specific URI) >> >> Now let's say I request /resource.json with an Accept header of >> "Accept: text/html". What should happen? >> >> One opinion is that the JSON should be served anyway, because the >> URI identifies a specific variant. > > I think serving the JSON is the best option. Serving HTML from > /resource.json would defeat the purpose of having a JSON-specific > URI. It is quite likely that the user pasted the JSON URI into a > browser to test it, and *wants* to see the JSON that is returned. > Everyone knows how to paste a URI into a browser; few know how to > configure their browsers to specify their desired MIME types. One point to note here is that if you *do* return JSON to a browser, and you give it the MIME media type 'application/json', that even if the user *wants* to see the JSON in her browser, she may be disappointed. Last time I looked, I was prompted to download things of that type, rather than 'seeing' them in my browser. Servers might wish to consider that when performing content negotiation with a user-agent. Cheers, - johnk > > > David Booth, Ph.D. HP Software +1 617 629 8881 office | > dbooth@hp.com http://www.hp.com/go/software > > Statements made herein represent the views of the author and do not > necessarily represent the official views of HP unless explicitly so > stated. >
Received on Thursday, 31 July 2008 17:46:10 UTC