Just A Summary : Joined up thinking: why your resources want links

Comment on Joined up thinking: why your resources want links by Paul Mison

Fri, 22 Feb 2008 06:39:52 -0600

While I can see the sense in serving URLs for convenience, I can see cases where serving the chunks that build the URLs instead is more useful.

As an example, Flickr’s API tends to return a photo element complete with all the resources needed to build a URL for an image (indeed, multiple versions of that image) or the page showing that image. (To be fair, they also offer a flickr.photos.getSizes call that returns all the URLs for you, but that requires an “API join”: http://blech.vox.com/library/post/the-api-join-and-avoiding-it.html.)

So, more generally, if you serve a URL which contains information that may be more useful on its own, aren’t you then forcing the API user to parse that URL for its useful information? Perhaps the answer is to serve both the URL and the constituent chunks, but I accept that increases app overhead.

Comment on Joined up thinking: why your resources want links by Aristotle Pagaltzis

Fri, 22 Feb 2008 10:39:23 -0600

Piers:

I can rant for ages about the awfulness of RoR’s routing system, but the bidirectional nature of them trumps almost all my complaints.

Catalyst’s routing goes both ways too… and while my experience with it so far is limited, it does not seem at all awful to me. :-)

(PS.: your preview is broken. I hope this comment comes out OK. Why does everyone these days go pure Ajax for their previews?)

Paul Mison:

aren’t you then forcing the API user to parse that URL for its useful information?

No. No no no no no. Clients don’t parse URIs. Ever. If it’s not a URI you minted, you have no business peering at its pieces. It’s good for many reasons for URIs to be readable, but as far as the client is concerned, “/topic/42/post/23” is completely equivalent to “/0913-jdq981k1j187”.

If the client needs to have some information, you give the client that information explicitly, not by implying it within the URI.

Flickr’s API tends to return a photo element complete with all the resources needed to build a URL for an image (indeed, multiple versions of that image) or the page showing that image.

Right; and if they also gave you a URI Template so you didn’t need to hardwire any knowledge of their URI space into your client, that would be fine. It’d be the equivalent of a form in HTML.

Clients constructing URIs is perfectly RESTful as long as their a priori knowledge is limited to the algorithm for doing so and does not include specifics of the server’s URI space.

Comment on Joined up thinking: why your resources want links by Paul Mison

Sat, 23 Feb 2008 10:00:22 -0600

Aristotle: thanks for the reply. I think we’re agreed that the API consumer parsing the URI is not desirable (although you seem to be a bit more hardcore about it than I do), hence my argument that if there’s information that may be useful that’s in the URI, it should be provided separately in the response. (Just because something’s wrong, doesn’t mean people won’t be tempted to do it, if you like.)

On the subject of URI templates, they seem to be newer than Flickr’s API, which instead provides a human-readable guide to constructing URLs from response information.

(Regarding the Textile preview, it didn’t work for me on Safari for Windows but does on the Mac. Slightly odd.)

Comment on Joined up thinking: why your resources want links by Piers Cawley

Sat, 23 Feb 2008 11:38:14 -0600

That’s because there was a problem with the way the javascript was served when you wrote your first post, but it got fixed in the second. Now I just need to tweak the javascript to keep the text entry box in the viewport at all times and I’ll be laughing…