This is based on a cross post from http://www.innoq.com/blog/st/2009/01/link_and_self.html.

Subbu and <Stefan Tilkov have been discussing URI Equivalence, linking to self and Resource Identities, so here is my view.

Subbu's last remark asks the question

>>>
On January 18, 2009 4:32 AM, Subbu Allamaraju said:
Here is a longer response that is longer than a comment <img src='http://brettdargan.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />

http://www.subbu.org/blog/2009/01/uris-vs-identifiers-take-two

IMHO URI non-equivalence does not imply resource non-equivalence. And if that is really important to your application there SHOULD be ways to handle it.

I agree with Stefan on providing a canonical resource.

You can argue both ways that person and person with address book are either two representations of a person resource, or two different resources, that is the great thing about the Web.

For this case in the atom self link what about using the <b>rev tag</b> to identify the canonical resource that makes sense for your application.

Since rev also accepts space separated list of link-types you could mark it with both the type and the uri of the canonical resource.

<link href="http://www.example.org/person/abc?include=addressBook" rel="self" rev="canonical http://www.example.org/person/abc"/>

As to whether or not two different entities that returned from different URI are based on the same version of the canonical resource or not:

I would use an EntityTag that encoded some value of resource state and some value of the representation. Eg. template for xhtml representation may change without resource state and the ETag must change in order to reflect that.

To KISS.

If you had an ETag consisted of something like "resourceVersion=20,reprVersion={date}" Then your application could extract out the self links with identical rev tags and extract from the ETag the resourceVersion.

Looking at URI design, there are a lot of cross-cutting concerns across many a resource. It would be great to come up with some conventions for the most common.

These are some of the ones I've been percolating on.

You can see there are a broad range, including:

• different views or representations of a resource, around breadth/depth of it's data and relations
• user request based affects on a representation
• resource version
• application supporting mechanisms, returning fragments and forms or form fragments
• temporality

There are a few more, but the trick is having less, right.

See also ISO8601

I've come across a few posts about Matrix Parameters recently and there is a lot of misunderstanding.

There are several old posts that discuss and describe these things:

• Query Strings Considered Harmful
• w3c MatrixURIs

I've summarised what I think is important:

• urls with query params won't have their response cached by intermediaries/proxies (at present)
• matrix parameters may appear anywhere in path
• calculating the relative uri is different
• much more than uri convention
• query params are generally abused to add new verbs instead of using existing methods on resources
• matrix parameters are not resources, they are aspects that help reference a resource in an information space that is difficult to represent within a hierarchy

Tip: If you're not sure if you should use them then don't.

Matrix parameters are used with

• YUI paging widgets
• RoR /some/resource/id;edit
• J2ee fallsback to ;jsessionid=xxx when no cookies can be set.
• Jersey (JAX-RS RefImpl) has good support