Dudes, this is so not REST

Re:Dudes, this is so not REST by enduser on Tuesday March 15, 2011 @05:29PM (#2329476)

That is still a case of using two URIs to refer to the same resource. If you use one URI per resource, URIs (and bookmarks) can be shared between clients dealing with different media types. Suffixed URIs require mangling to request a different media type.

Clearly it is a pragmatic trade-off and is popular (Google and Twitter do it). The correct answer will be arrived at by considering the total architecture of your application.

[ Parent | on HN ]

Re:Dudes, this is so not REST by Darrel on Tuesday March 15, 2011 @07:54PM (#2330031)

As soon as you decide to create two URLs such as /user/1.json and /usr/1.html you are creating two distinct resources. The litmus test for determining if two URLs refer to the same resource is you do a GET on both and only one of them returns a 200 the other returns a 303 with the Location header set to the URL that returned a 200.

[ Parent | on HN ]

Re:Dudes, this is so not REST by Groxx on Tuesday March 15, 2011 @05:38PM (#2329514)

That's a good reason to differentiate by header (plus no .jpg vs .jpeg shenanigans in the url). Though I can't say I've ever heard of it being used... I'll have to keep it in mind if I'm ever architecting something that anticipates many different kinds of clients in a large API, however.

[ Parent | on HN ]