Doubts about Links

, Oct 12, 2007

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="" />

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.

On October 13, 2007 12:00 AM, Erik said:

I think people assume REST-ful links are mainly for related data or alternative formats. As I mentioned in Tim Ewald’s “wow” posts last April, it may not be practical for a message to even contain links to all potentially related resources. Also, no matter how good you make your URI constructs, it hasn’t been proven to me you can really eliminate the need for out-of-band knowledge.

But that’s a minor piece of what REST is all about. The primary reason, IMO to put links into a message is to direct a process. In other words, the links tell the caller how to transition a resource through its life-cycle. Taking a RESTful approach without developing a state transition strategy basically limits REST to CRUD.