Patrick Mueller wonders about links in a RESTful HTTP app:
Here’s an example: let’s say I have a banking system with a resource representing a person, that has a set of accounts associated with it. I might typically represent the location of the account resources as a URL. But if I happen to know, a priori, the layout of the URLs, I could just provide an account number (assuming that’s the key). With the account number, and knowledge of how to construct a URL to an account given that information (and perhaps MORE information), the URL to the account can easily be constructed.
IMO, this would break what I perceive one of the main benefits of the REST approach — IDs would become something that can only be interpreted with out-of-band knowledge.
For example, in an RPC-style interface, IDs are simple parameters to methods:
Customer getCustomer(ID id);
If I have an id, I need to know that a) it is, indeed, a customer ID and b) that I have to call get
getCustomer() method to retrieve more information. There’s no agreement, no uniformity to the interface.
In an XHTML document, a relation to a customer could be expressed as a link:
<a href="http://example.com/192879202039374738" />
Knowledge about XHTML means that I know
<a> means a link, and the value of the
href attribute contains a URL. In other words, using URIs to link to resources — hypermedia — is key for the uniform interface, and thus an essential part of REST.