When people think about links, with regard to tying together information on the web, the usual thoughts are of URLs. Either absolute URLs, or a URL relative tosome base (either implicitly the URL of the resource that contains the link,or explicitly via some kind of xml:base-like annotation).
But I wrestle with this.
Here's one issue. Let's say I have multiple representations of my resourcesavailable; today you see this typically as services exposing data as either JSONor XML. If that representation includes a link to other data that can be exposed as either JSON or XML, do you express that link as some kind of "platonic URL"? Or if you are doing content-negotiation via'file name extension' sort of processing, does your JSON link point to a.json URL, but your XML link point to a .xml URL?
Seea discussion in the JSR 311 mailing listfor some thoughts on this; I stole the term "platonic URL" from this discussion.
The godfather had something interesting to say in a recent presentation. In"The Rest of REST",on slide 22, Roy Fielding writes:
Hypertext does not need to be HTML on a browser
- machines can follow links when they understand the data format and relationship types
Where's the URL? Perhaps tying links to URLs is a constraint we can relax. Consider,as a complementary alternative, that just a piece of data could be considered a link.
Here's an example: let's say I have a banking system with a resource representinga person, that has a set of accounts associated with it. I might typically representthe 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 thekey). With the account number, and knowledge of how to construct a URL toan account given that information (and perhaps MORE information), the URL to theaccount can easily be constructed.
The up-side is that the server doesn't have to calculate the URL, if all they have is theaccount number. They just provide the account number. The notion of content-type-specificURLs goes away; there is only the account number. The resources on the server can bea bit more independent of themselves; they don't have to know where the resourceactually resides, just to generate the URL.
Code-wise, on the server, this is nice. There's always some kind of translationstep on the server that's pulling your URLs apart, figuring out what kind of resourceyou're going after, and then invoking some code to process the request. "Routing". For that codeto also know how to generate URLs going back to other resources, means the code needsthe reverse information.
The down-side, of course, is that you can't use a dumb client anymore; yourclient now needs to know things like how to get to an account given just anaccount number.
And just generally, why put more work on the client, when you can do it onthe server? Well, server performance is something we're always trying to optimize -why NOT foist the work back to the client?
I realize that's a bad example for me to use; me being the guy who thinks browsers area relatively terrible application client, but what the heck; that's the way thingsare today.
For folks who just want the data, and not the client code, because they havetheir own client code, well, they'll need some kind of description of how everything'slaid out; the data within a resource representation, and the locations of theresources themselves. But the server already knows all that information, and couldeasily provide it in one of several formats (human- and machine-readable).
As an proof point of all of this, consider Google Maps. Think about how the maptiles are being downloaded, and how they might be being referenced as "links". Do youthink that when Google Maps first displays a page, all the map tiles for that first map vieware sent down as URLs? Think about what happens when you scroll the map area, and newtiles need to be downloaded. Does the client send a request to the server asking for theURLs for the new tiles? Or maybe those URLs were even sent down as part of the originalrequest.
For Google maps, it's easy to imagine programmatically generating the list oftiles based on location, map zoom level, and map window size. Assuming the tilesare all accessible via URLs that include location and zoom level somewhere in the URL.In that case, the client code for calculating the URLS of the tiles needed is just a math problem.Why make it more complex than that?
I think there are problem domains where dealing with 'links' as just data, insteadof explicit URLs make sense, as outlined with Google Maps. Remember what Roy wrote in his presentation:"machines can follow links when they understand the data format and relationship types".Of course, there's plenty of good reason to use continue to use URLs for links as well, especially with dumb-ish clients.