Have you considered using protocols and records to achieve a similar result? e.g.

    (GET "/todo" []
      example.model.Todo{:items []})

This would separate your data structure from its representation.

You could then use middleware to convert it into the format the user requests.

I can see what you are saying, that is definitely something that would work.

This library also handling some of the other interaction as well, for instance conditional requests (i.e. only GET the resource if it's changed since a certain date or if the ETag is different) as well as populating some header values on behalf of the application (supplying last modified dates and ETag values). I think that this could also be done in middleware and that would allow a more modular approach (i.e. you only care about conditional requests you could just use that piece).

For myself, I really wanted one widget that'd make it easier to figure out what I needed to do to get my web service to behave in a predictable way; I really wanted the whole enchilada. :)

I've recently become interested in HTTP caching myself, though I've started from the client side rather than the server.

My current idea is to have a ref that represents a HTTP resource, and takes advantage of the various caching headers like ETag and Cache-Control to limit requests to the server when you deref it.

I think that's a really interesting idea. I've been thinking a little bit about how this could be leveraged on the client-side as well.