In this post, I would like to expand on the thoughts behind my suggestion to include identifiers in representations, and clear a couple of non-issues.
The first non-issue is whether URIs are permanent or not, and whether my approach to use identifiers is to compensate for potential lack of permanence of URIs. This is a non-issue because, any well-behaving server would use proper redirect rules to make sure that clients can continue to reach a resource even when it changed the URI for any reason. If a server is not doing this, it is broken, and needs fixing.
The second non-issue is whether there is a canonical resource or a canonical URI for every entity that is modeled as a resource. On the web, there are no canonical resources or canonical URIs. Every URI is a URI to a resource.
The key question is whether URI equivalence (or non-equivalence) implies resource equivalence (or non-equivalence) or not.
Given two URIs, it is possible for a client to infer that they both refer to the same resource if the URIs are equivalent (as per Sec 6 of RFC 3986). But the converse is not true. That is, given two URIs that are not equivalent, a client can not reliably say that they do not refer to the same resource.
URI comparison is not sufficient to determine whether two URIs identify different resources.
In the context of the "
self" relation, the definition is vague enough to leave some flexibility for servers to use the same or different URIs for the same entity in different representations under different contexts.
But why would a server provide different URIs for the same entity?
In general, there may not be many reasons for the server to use different URIs for the same resource. But there may be special cases where the server decides to do so. For instance, the links I get for a resource on an iPhone may refer to specialized compact representations at a domain (e.g., m.example.org) that is different from the links that I get on a desktop (e.g. www.example.org). An app that is synchronizing data between these devices can not rely on URI non-equivalence while comparing resources. Alternatively, as in the case of the examples I used in my original post, the self links may be there to answer the question of where did a client got a given representation from.
In conclusion, as described in RFC 3986, a given client can not rely on URI non-equivalence alone to say that two URIs are not referring to the same resource unless it has full knowledge or control of them (i.e. resources).
Where does this leave us? If I am a server developer, I would do the following.
- In the absence of any special requirements, make sure that URIs in self-links always refer to the same URI.
- To prevent clients from breaking if I had to break the above in future, include identifiers in my representations.
On the client side, I would do the following:
- If a given representation has both a self-link and an identifier, use the identifier to determine resource-equivalence, and URI as the location.
- If that representation has only a self-link, use it both for resource-equivalence and the location.