Re: [Resteasy-developers] RESTEasy client changes

[Solomon D. <sd...@gm...>]

Bill,

Yeah, I understand the protocol well enough...  The problem is chosing an
cache implementation technology.

RESTful caching requires per-resource value for "max time to live" because
each URL can have a different value.  You'll definitely need a wrapper
object to store ETag info; however, it would be nice to use the caching
technology's expiration/eviction settings rather than having to build that
yourself.

All of the caching technologies I've seen, except for memcached, have a per
cache setting for "max time to live" (determined by an XML file, or
programmatically).  Memcached allows you to set a timeout per cached
instance rather than per cache, but you probably rule out memcached because
a purely distributed cache system seems like a totally wrong solution for a
RESTful client.

Unless I'm mistaken, you'll have to either modify a caching technology to
allow a per instance timeout (which I assume you can do with your pull with
the JBoss caching team, Bill), or to write a layer on top of an existing
solution that manually checks max-age/Expires values in order to do
expiration.

-Solomon

On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re...> wrote:

> <snip>



> As far as the caching client goes: I'm not quite sure which existing
>> caching solution best fits a RESTful request.
>>
>
> Read up on Cache-Control header.  Basically the server passes a response
> header that states the cache policy.  Its a pretty rich protocol.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>