Dion Hinchcliffe details 17 principles in his recent blog post entitled “A Web-Oriented Architecture (WOA) Un-Manifesto“. It’s nice to see somebody attempt to steer (if ever so slightly) away from the “manifesto” cliché…and doubly nice that he left out the tacky photoshop filtered image with an angelic glow eminating from his forehead.
17 is too many
While hoping this doesn’t reveal me as a closet numerologist, numbers like 3, 5, 10, and maybe 12 would make a more concise declaration. If simpler resources are more likely to be used, perhaps shorter un-manifesto’s are more likely to be read and heeded. This is a list in need of pruning, and randomly removing 3 would still result in a better list.
Why do REST enthusiasts grasp GET, POST, PUT, DELETE, but ignore HTTP Accept?
Principle #3: Resources and their network addresses (URIs) are self-descriptive so that WOA clients can determine how to consume them. In general, a URI should indicate what data format is being used and indicate nested elements with URL segmentation.
I wonder if he has some standard in mind. Content negotiation via HTTP response-type should be included here. Some URL’s indicate the response via extension (foo.xml), some in query params (foo?type=xml), and some in the URL path (foo/xml/). I think the URI should be cleansed of data format, and the client should indicate which formats it accepts, and allow the api to decide and declare what format is returned (json, xml, atom, rss, rdf). This concept is baked into RESTlets, so I know I’m not alone in this opinion.
Let’s not be too orthodox
Principle #10: Copying of resources is discouraged: The network effect of Web resources is increased when they are linked to from other Web resources instead of replicated. Caching is encouraged however, as long as it’s at the same URI.
This principle seems a bit preachy. Copying a resource doesn’t prohibit the applicability or effectiveness of WOA. The Microformats community has demonstrated that you can copy a snippet of data such as an event, and import it into your offline calendar application. I think it makes more sense to merely encourage copying, along with the source URI, so that the resource can be kept up to date when the network is available.