• Yet another thread on URI Opacitity [sic] (aka Use of Metadata in URIs)
• The Use of Metadata in URIs: How long does a FORM assertion last?

While I agree that there is a tradeoff between the ease of use/understanding gained by placing human-understandable metadata in URIs and the ease of interface change (enabled by loose coupling), I think you are leaning a bit too far on the ease of change side.

In particular, the advice in the Dan Connolly quote is out of date and out of touch with the TAG recommendation concerning this issue: http://www.w3.org/2001/tag/doc/metaDataInURI-31 . One of key its conclusions is:

“Assignment authorities may publish specifications detailing the structure and semantics of the URIs they assign. Other users of those URIs may use such specifications to infer information about resources identified by URI assigned by that authority.”

Both Tim Berners-Lee (whose “Cool URIs” is also superceded by the finding) and Dan Connolly approved this finding.

So your statement that “if you think this [Flickr’s URI template] is a “hypermedia application”, you need some serious help” seems a bit over the top, given that the TAG finding explicitly allows such templating — both in HTML FORMs and out-of-band interface documentation.

I’d be curious about your thoughts on the finding, especially what parts you disagree with. For me, the key takeaway is the following:

“Good Practice: Resource metadata that will change SHOULD NOT be encoded in a URI.”

I would generalize that to:

“Resource metadata that will change should not be encoded in the client in either hardcoded URI metadata elements or hardcoded format metadata elements.”

It doesn’t matter whether a metadata element is in a documented URI template or in a documented microformat template, or in a documented resource representation schema — if the element documented and then encoded (eg “hardcoded”) into the client, then you have tight coupling.

But there is no escaping some amount of tight coupling. All loosely coupled aspects of an interface depend directly or indirectly on tight coupling somewhere else. In other words loose coupling must be bootstrapped via tight coupling.

Thinking through what parts of an interface must be tight so that the other parts can be loose is the essence of good interface design. Choose wisely and you get stable interfaces that are productive for decades (eg TCP/IP, SCSI, HTTP, HTML, URI). Choose poorly and you get either unstable interfaces are arthritic ones.

Love the new look.

Next, take a look at what “documented oriented” RESTful applications have done: They’ve reintroduced all the fragility of APIs. Technically speaking they’re RESTful, but they require programmers to bake in knowledge, at design time, about the messages they construct. An APP client isn’t dynamic or weblike at all. To be really weblike, an Atom server would deliver a form; your client would understand the meanings of the form fields, and POST a new entry by serializing a message according to the instructions in the form. Each server could be different and evolve differently.

However, they stopped short in this Mental Health Initiative by using the word ’service’ and having a discovery resource.

I also think that PUT and DELETE detract from the essential message: that state transfer is nothing to do with methods. It’s actually misleading to go on about a ‘limited set of methods’, when the REST philosophy is really just ‘push or pull on URIs, standard schemas, containing more URIs’ - no methods at all.

Roy didn’t mention specific methods in his thesis - he threw PUT in once and that was it. Which /may/ be interpreted as a drive (at the time) towards this pull-GET, push-PUT approach. Only Roy can tell us what was in his mind at the time, of course.

And the acceptance of the non-opaque URI optimisation bugs me too: putting a chunk of your schema into the headers (well, the first header) is just a hack to save a round trip (i.e., POST query-schema resource, redirect on response to results-scheam resource). Plus transparent URIs open us up to the dreaded function-call URIs - to API damaged brains.

Taking PUT, DELETE and transparent URI schemas and dumping them into the body where they belong would go a long way to help get us free of the function-call mindset.

A resource is not an object!! Nor a service! Data is open in REST architectures - get over it! There are no methods!

OK - rant over - thanks for giving me this opportunity!! =0)

Duncan Cragg

Good article and I look forward to hearing morew on this subject. Lets hope that people take note and act but what should they do?

My answer is don’t give your card account number to Merchants.

In 2000 I filed a patent application for a secure transaction method. I received granted in July, 2004 number GB2367411. VETT UK have raised investment to promote this system to Banks, Card companies etc.

I would be pleased to hear about any other articles on the same subject.

Best regards
Garry