This started as a comment on the blog post here, but it got too long.
I have two questions for Dion and a few comments. 1) Have you read (not just skimmed a few times) Roy's dissertation on REST? 2) Have you written both a REST service and a REST client that is in production today?
With all due respect, without actually creating REST applications, I don't think anyone is qualified to attempt to define principles relating to REST and based on your Twitter bio:
Internationally recognized business strategist, enterprise architect, keynote speaker, author, blogger, and consultant on Web 2.0, SOA, and next-gen business
you sound like a talker, not a walker. Forgive me if I am wrong.
Here are my comments on the suggested principles, I’ve tried to be as constructive as I can muster:
Principle #1: I think it is a significant oversimplification to refer to a resource as data.
Principle #2: Can you clarify what you mean by "favor granularity and depth in linkage"?
Principle #3: I am pretty sure no-one has ever said that URIs should be self descriptive. In REST the request message should be self-descriptive, the URI being just one part of the message. The statement “URI should indicate what data format is being used and indicate nested elements with URL segmentation” is way too strong, maybe if you replace “should” with “can”.
Principle #4: This idea that all legacy databases should be exposed as data-oriented REST apis is crazy-talk. REST is an architectural style for building distributed APPLICATIONS. I.e. Exposing functionality over the web, not just data. Your example of cloud computing API’s is a perfect example. The Sun Cloud API is one of the best REST examples out there at the moment, but it exposes functionality for manipulating those cloud applications. Functions like turning the instances on and off. It’s far more than just exposing data.
Principle #5: You seem to be describing benefits rather than a principle.
#6: Ok
#7: I don’t get this concept at all. Does this mean we should all be using text/plain if we want the widest audience?
#8: Maybe I don’t want my resources to crawled by an SEO. Even if I do, conforming to the uniform interface and delivering standard format representations should be sufficient to meet any search engine requirements.
#9: “higher realized value”? Are you sure this isn’t another one of those spoof manifestos?
#10: I think you are referring to the idea that a resource should only have one canonical URI. I see this topic debated regularly and I do not yet see any consensus.
Ok, I give up for the moment, I’m a bit too depressed to continue.