January 27, 2010

In Fear of Sub-Requests

Suppose we design a service that is to provide data about persons, including whom they are linked to. Let's say person representations look like this:


GET /persons/4/full

200 Ok
Content-Type: application/vnd.me.person+xml
Cache-Control: no-cache


Karl Heinz
Kieler Strasse 7,20556 Hamburg













In addition, the service provides minimal person data that looks like this (note that its time-to-live is longer):


GET /persons/4

200 Ok
Content-Type: application/vnd.me.person+xml
Cache-Control: max-age=3600


Karl Heinz
Kieler Strasse 7,20556 Hamburg





Now suppose we define the processing semantics of application/vnd.me.person+xml in such a way that the user agent should follow all the friend links and retrieve the referenced persons' data. Looks like rather bad design due to all the sub-requests, doesn't it?

On the other hand, nobody complains about HTML pages that link to massive amounts of images and other media.

3 comments:

  1. If each Person can be cached then it may not be a killer, but surely if the user agent is going to follow each link we'd think about a read-only composite resource containing all the friends basic details?

    ReplyDelete
  2. @Jan
    Yeah its a good point but you can take it further, for example above Address is just included in Person but at some stage you might decide to make it a resource in its own right.

    That would mean a client that wanted the Address needs to make another request. However you can make the Address immutable, addresses don't tend to change instead people/organizations move from one address to another.

    ReplyDelete
  3. Colin, yes, good point. The principle is really to separate things with different volatility to help caching.

    ReplyDelete