Good stuff!

I want to clarify that I, also, don’t give a rat’s arse what the URL looks like. Rather, I care that a conceptual resource only have one URI for all representations if the resource is described as RESTful. Otherwise it’s misleading and makes generic client libraries hard to develop and obfuscates the set of available resources and representations.

I don’t think interlinking is important, necessarily. Rather, the parts of Dr. Fielding’s thesis (ch05) I’m referencing herein has no requirement that one representation link to another representation. When content negotiation is used, a link actually can’t specify alternate representations, as the URI would be the same and the headers would be used for the negotiation.

As for “…doing it wrong…maybe.” I think the phrase is as helpful as I wanted it to be. That is, it speaks a truth: bolting on new URIs or a new namespace (like api.* subdomains) does stray from one of the major benefits of RESTful design: one URI per concept, with some subset of HTTP 1.1 verbs and some subset of available content types available.

To reiterate: I don’t care what a URI *looks like* and consider URIs opaque. I just want one URI per resource. To use my Twitter example, I want the URI for my most recent 20 statuses (the concept) to be available at the same URI (or URI template) no matter what representation format I choose, if possible.

As Nick described, there can be strong reasons to stray from the “one URI per resource” rule – usually due to a particular representation (usually the HTML representation) being a clusterfuck of uncacheable, state-based supplemental data. Still, the default, if a system claims to be RESTful, should be to follow to the basic rules.

Adding URIs for XML and JSON chunks over HTTP is not necessarily RESTful, despite the splintering the term has taken after the Rails bloggers got ahold of it.

The linkability part of the restful style seems more important than semantic debates about what constitutes a separate resource and what constitutes a representation of an existing resource. This seems under-specified and not worth worrying overly about. Certainly phrases like “you’re doing it wrong” aren’t helpful.

I mostly map it directly to Fielding’s thesis and ignore damn near everything after that (sort of). I think a representation can often be pretty different among formats without impacting the style. I mean, an SVG or PNG representation of a product and an XML representation of the product attributes could be the same concept and same URI. Or not. I think it depends. The loophole/power is definitely in the concept you’re conveying. It’s where the art can come in… or the abuse!

And I think all views can be “REST views” in that the REST style isn’t about the contents of the representations as much as the roles of components/connectors/resources/representations and the transfer mechanisms and rules about the verbs and the mapping of concepts to URIs…

I am not as dogmatic about the choice, but:

1. I do love when I have a truly REST-compliant system to work with
2. If you say it, do it and have it make sense, or I will curse you. And there is nothing worse than a tobyjoe curse, obviously!

On an e-commerce site, the “people who bought this also bought” list on a product page makes sense in the HTML view. Does it make sense in a REST view? (maybe it doesn’t)

Do attributes and their relevance differ for different views of the same model? (I mean this is clearly the case for the .html view. For example, most places don’t output things like primary keys on their HTML view.)

I fear that once we codify “REST-compliant” it will morph into what has happened to “agile” where we now have IBM waterfall type-guidelines for “Agile Certified Development.”

Maybe it’s like the Supreme Court with porn. I know its REST when I see it.

There’s also a possible loophole for *some* highly dynamic “site” resources: treat them as a different concept. Don’t offer alternate representations if those representations are of naturally different concepts.

If you’re showing a chunk of XML for a product on your store at URL_A, but the HTML representation includes lists of recommendations, aggregates from related content objects, etc, you’re *probably* modeling different concepts.

Most of the time, in my experience, a very divergent “site” representation (aka, dot-html) is more a sign that an alternate format isn’t appropriate.

I don’t want to make the case that all concepts should support all representation formats through conneg or anything – just that, if you do choose to support multiple representations of the *same* resource, the default should be to use the same URI.

Or, don’t call it REST-compliant?

Presumably, you don’t want your entire front-end site to go down if an errant developer floods the API with lots of calls. Imagine if Facebook did this and their fbconnect API gets overloaded…

I guess you can partition based off header, but that becomes a performance nightmare (in terms of Apache or something doing the routing to different server farms.)

Also, I’ve found that there’s a pretty striking difference between the performance profiles of a web site and a REST API. (And, it’s inevitably impossible to optimize for both.)

Like the idea in theory though. And certainly the same app can (and should) power both…