Should a given URI in a RESTful architecture always return the same response?

Question

This is kind of a follow-up question to this one.

So is having a unique response for any given URI a core tenant of RESTful architecture? A lot of discussion here tends that direction, but I haven't seen it anywhere as a "hard and fast" rule.

I understand the value of it (for caching, crawling, passing links, etc), but I also see things like the twitter API violate it (A request to http://api.twitter.com/1/statuses/friends_timeline.xml will vary based on the username given), and I understand there are times when it may be necessary--not to mention that a chronologically paged resource will also change as new elements are added.

Should I strive for varied responses from the same URI to be eliminated altogether, or do I just accept that sometimes it isn't practical, and as long as I minimize its occurrence, I'll be in decent shape.

Answer 1

Nothing in REST says same response - but you shuld be prepared to handle stuff like the "If Modified Since" request headers WHEN THEY MAKE SENSE ;)

The tritter API has other issues, obviously - as in: this is a design decision. Once you allow friend timelines to be isolated, for example, it would make sense to put the timeline below a friend name element - they obviously decided against this ;)

It runs down to design decisions. Look at OData (like http://odata.netflix.com/Catalog/) - here it makes snse to return the same data for every URL for a given time (caching), because it is a fully public cataloque. For other scenarios it may make no sense.

Answer 2

Some request headers do change what is returned (while still being RESTful):

1. Clearly the cache-headers are expected to be used to determine if a 304 or 200 is returned
2. The Accept header can be used to determine the format of the response (HTML vs XML vs JSON)
3. The Authorized header can at least determine if a 401, 403, or 200 is returned.
4. Also, resources are allowed to change over time.

The real question is whether the Authorized header (which determines the user) can be used to change the content of the response. I haven't seen any official statement about it, but I suspect a number of people would rather have the user in the URL and the Authorized header used to validate access. I suspect either way is still RESTful.

Answer 3

Not the same response, but a representation (wich depends on conneg and conditional request headers) of the same resource. In a Rest Architecture, a URI identify one and only one resource (but a resource can have several URI). Presenting different resource depending on the authorized user (being HTTP Auth, cookies, ...) is bad practice, since the same URI represent a different resource for each user, as in the Twitter example. I can't allow you to view my timeline and give you the URI, since this is the same URI for your timeline. The user must be encoded in the URI, and access limited by the authorization mecanism. To have a single access point presenting different resource depending on the authenticated user, use a redirect (e.g. 303 See Other, 302 Found, ...)