[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] REST vs. HTTP in the real world



John Elliot wrote:
On Wed, 30 May 2007, Nathan de Vries wrote:
	GET users/nathan/tiles/1
	Host: tilefile.com
	Accept: text/html

But when I do this, I get a JSON representation of the same resource:

	GET users/nathan/tiles/1
	Host: tilefile.com
	Accept: application/x-json

This is a different discussion... but I've thought long and hard about that one, and I think you'd be better served thinking like this:


 	GET users/nathan/tiles/1.html

and

GET users/nathan/tiles/1.json

I'm actually interested in more opinions about this point. Right now (admittedly, as a newbie to Web programming) I'm using John's approach (essentially) -- that is, encoding the data format in the URI. The reason is that quite often two different representations of the same resource (I think I'm using the nomenclature correctly?) are so radically different that there really isn't anything gained from using the same URI: they may as well be different resources.


To take my example, an HTML representation of policies in a bug tracker might list each policy in a textual, human-readable format, surrounded by a DIV or whatever, perhaps with a title and sidebar containing links to other information. The same representation in JSON is a computer-readable list. OK, they happen to include some of the same *data* ultimately (the list of policies) but there is to my mind nothing to be gained from giving them the same URL and then specifying "human format" or "computer format". There doesn't seem to be any way that I would benefit from being able to switch formats mid-way, because nobody would ever do that.

In this case, why not be as explicit as possible and make what are essentially two separate resources accessible via two separate URIs?

- N


- You are subscribed to the progsoc mailing list. To unsubscribe, send a message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.