A pure per-client in-memory cache implemented as a client filter would do. No need to dig into shared or persistent caches, as the target is to speed up the single client instance by preventing unnecessary repeated GETs and handling If-Modified and If-Not-Modified conditional requests out of the own JVM's RAM. Is that what you meant with "to"?
> -----Original Message-----
> From: Bill [mailto:bill_at_dehora.net]
> Sent: Mittwoch, 11. Mai 2011 01:57
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Markus KARG; 'Marek Potociar'
> Subject: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-39]
> Client Cache Support to MINOR
>
> On 10/05/11 17:45, Markus KARG wrote:
>
>
> > So I just do not see any technical reason to *not* implement caching
> in the JAX-RS API
>
> I'm not inclined to think we can get a HTTP Cache API right never mind
> a
> reference implementation (what would it cache 'to'?).
>
> > or have a need for configuration.
>
> Ok. I think we could allow a Cache to be "transparently" added as a
> client filter if the cache directives were cleanly exposed.
>
> I imagine we'll have the same discussion on transparently introducing
> Authorization support so a common pattern seems desirable.
>
> Bill