17589Re: [rest-discuss] Clients & Expiration based caching
- Jul 1, 2011There was a thread on this here back in January:As mentioned in that thread, for the Windows platform, a single line of code adds very good client-side caching support:request.CachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.Default);Options for other platforms are mentioned in that thread, too.mca
#RESTFest 2011 - Aug 18-20
On Fri, Jul 1, 2011 at 09:38, Moore, Jonathan (CIM) <jonathan_moore@...> wrote:The Apache HttpComponents project includes a client-side cache with multiple backing stores (memory, ehcache, memcached) as of version 4.1.As one of the authors of the caching module, I agree with the assertion that getting this right is non-trivial (I think we have close to 1000 unit tests to line up requirements from RFC2616 with the implementation), so I would weigh the software investment against the operational overhead of running/scaling/maintaining the forward proxy cache.JonFrom: email@example.com [firstname.lastname@example.org] on behalf of bryan_w_taylor [bryan_w_taylor@...]
Sent: Friday, July 01, 2011 2:10 AM
Subject: [rest-discuss] Clients & Expiration based caching
In RESTful web services cookbook recipe 9.3, Subbu recommends against having clients endpoints implement caching based on expiration headers. Instead he recommends using a forward proxy. His reasoning appears to be that correct implementation of caching is non-trivial and that getting reuse of a client-side proxy is easier, safer, and less risky.
I'm wondering if others agree with his views. Are there any client side libraries that handle the trickiness for you? Is "it's hard to get right" a good enough reason.
- << Previous post in topic Next post in topic >>