"One of the issues that comes up over and over again with regard to cache invalidation is that the HTTP spec automatically invalidates the cache when an unsafe operation such as PUT, POST or DELETE is called upon a URI."
Poorly worded above paragraph. Better worded as follows: "One of the issues that comes up over and over again with regard to cache invalidation is the invalidation of related items in the cache. The HTTP spec automatically invalidates the cache when an unsafe operation such as PUT, POST or DELETE is called upon a URI." On 6/7/13 11:53 AM, "Owens, Steve" <[email protected]> wrote: >One of the issues that comes up over and over again with regard to cache >invalidation is that the HTTP spec automatically invalidates the cache >when an unsafe operation such as PUT, POST or DELETE is called upon a URI. > >I am not sure about this and I am certainly open to correction, but I >believe that ATS uses the Content-Type as part of the cache key. > >So if for example I were to call > >GET .../users/xyz222 >Accept: application/json; model=com.bla.bla.User.address > >The result would end up in one cache entry. > >And if I were to call >GET .../users/xyz222 >Accept: application/json; model=com.bla.bla.User.credentials > >The result would end up in a different cache entry. > > >What would be fantastic however is if I could some how configure ATS such >that if it were called with > >PUT .../users/xyz222 >Content-Type: application/json; model=com.bla.bla.User.address > > >That any content at .../users/xyz222 would be cache invalidated regardless >of the content type delivered. > > >Thoughts? >
