Cache-control headers in raml (and jaxrs-raml)


#1

The way the interfaces are generated with the raml-jaxrs-codegen maven plugin is nice because it makes it very easy to implement the services and not be bogged down with having to put all the jaxrs annotations on things.

One thing that is missing currently is an easy way to handle headers for caching. The response object could easily be modified to support sending back cache control headers, but for those to be of use the interface methods would need access to the incoming headers to be able to potentially short-circuit long calculations and quickly return 304’s for non-modified content.

Has anyone thought of how to do this? The authors behind the current jaxrs-raml-codegen seem to have a pretty good grasp around building code generators so I’d be interested in their take on how to add support for caching to their existing stuff (or perhaps it will require a different approach than what is currently in place)

There are a couple of articles out there about doing caching in jax-rs - like https://devcenter.heroku.com/articles/jax-rs-http-caching - but the general idea is to evaluate the headers early and return quickly if you can, otherwise return the real content.


#2

Excellent question: thanks for bringing this up!

RAML doesn’t yet have specific support for cache control directives so I think the best way currently is to create a cacheable trait that declares the Cache-Control response header and to use javax.ws.rs.core.CacheControl to build the value of the header.

With the addition of cache directives to the spec we could imagine generating an annotation-based infrastructure like this one for JAX-RS 2 users. That would actually be quite cool :smile:


#3

Where is the spec evolution discussed?

Caching and REST for many people go together hand in hand - for consuming a service it doesn’t really matter to know ahead of time (assuming your browser / client just transparently obeys cache directives) so I can see why it hasn’t been put in place yet - but if the goal is to provide something that can be used to generate most of the boilerplate server side stuff (in any language) the cache headers are important to have a way to set in the spec