On the first point, those apps should come up with a naming scheme for identifiers to avoid collisions. I am suggesting using raw DB IDs, but you could mint URNs based on those raw IDs.

The idea of using a link in place of ID is fine. However, borrowing from Atom, you can accomplish the same with an id element/property.

In any case, the key point of this post was to show that URIs used to access a representation of a resource can not always be used to determine resource identity. How an app chooses to include identity data in representations is an implementation choice.

You and I are both exposing REST APIs for Blogs. We have blog, post and comment resources. And we are both using the same standard media types for our representations. We know nothing about each other, nor about who is using our APIs.

Jim has an aggregation application that is capable of consuming resources from both of us. When he requests a resource from both of us, its going to come from different domains, but they’re going to have the same media type and because databases issue IDs sequentially, our two resources have the same database ID. So now we have a legitimate collision that is only going to be resolved if Jim segregates those IDs by originating domain in which case origin Domain + DataBase ID which seems to me to be very much like a URI.

Or lets take the case where we have two distinct resources (maintained in different database tables) that share a common media type. Lets use the idea of a banking API and we have accounts, but we also have wire transfers, and bill payments. For what ever reason, there is an agreement that the end points of a transfer resource (that is the originating and destination accounts) must conform be able to respond with a common media type. Now my accounts, bill payment vendors and SWIFT Account descriptions all have the same media type but are independent of each other and can conceivably have colliding database IDs.

Or how do you reconcile the case when you have multiple representations of the same entity?

I would submit that dealing with the first example (I hope the most common), makes it impossible to deal with the second or the example you allude to in you comment where multiple domains have something to say about the same entity.

Identity is an issue that is certainly not new; Topic Maps have been dealing with this issue for a long time. One of the things they do is use a Published Subject Indicator (which is an URI) so that if two map are merged and there exists one or more topics with a common PSI, the refer to the same subject.

We can do the same thing here:


GET /myapp/person/abc?include=addressbook
Host: http://www.example.org

<person>
<link href="http://www.example.org/person/abc?include=addressBook&quot; rel="self"/>
<link href="urn:org:exmaple:person:subbu" rel="PublishedResourceIndicator"/>
<first-name>Subbu</first-name>
<last-name>Allamaraju</last-name>
<addresses>
<address>
...
</address>
...
</addresses>
<person>


Here I’ve coined the term Published Resource Indicator (which should be shortened to PRI) such that we can say that any two representations with identical PRIs (following normal URI interpretation) refer to the same resource, regardless of the origin of resource and its media type. Because some representations (say an image) lack hyperlink semantics, you would want to add a header to HTTP to contain the PRI.

I think this nicely resolves the issue. But there is one added benefit. If one were to use a network resolvable URI, then the question becomes, what do your get if you resolve that URI. Instead of getting a representation of the resource, I would send a human readable description (if appropriate), a list of media types known to represent the resource and a list of URIs known to return canonical representations of the resource.

So the bottle neck isn’t with the use of a URI, but rather of the meaning of “self”.

Regarding URN examples, please see http://en.wikipedia.org/wiki/Uniform_Resource_Name. URNs are URIs too, but do not imply any resource location. The best example is the URN for ISBN numbers.

Subbu, great blog btw!

Can you talk a bit more about URNs and give some examples? Personally solution #2 above appeals to me, but I don’t know much about URNs and would love to learn more.

Thanks,

- Alex

Thanks,

- Alex

When there are multiple domains dealing with the same set of entities, depending how they interact, they may need to use a common scheme for identifiers. This is already a common practice in a number of application domains.

More compelling to me is the case where you have multiple domains all using the same type. You have no reason to expect that the numbering scheme in each domain will be in compatible with the others. At that point you’re down to tying it to source domain, and media type and you’re probably just better off (unless you can guarantee that you’ll always have control over how your api is used).