[FoRK] overhead of RESTful stuff

Stephen Williams sdw at lig.net
Thu Mar 8 13:11:13 PST 2012

A key reason to lean toward carefully managed caching interfaces is that in a high traffic situation, traffic that is important to 
cache may be dwarfed by traffic that doesn't need to be cached.  Or won't be used so caching it is bad.  In some cases you might not 
know ahead of time which is which.  Twitter may be one example, although you have some recent history there.  It may be that you 
don't want afford just caching everything, or caching everything may slow you down in important ways.

Details all the way down...


On 3/8/12 11:23 AM, Gregory Alan Bolcer wrote:
> Of course.  Meant reusable (and decentralizable) data should be 100% cachable as the definition.
> But that's the definition of a cache, no?
> Greg
> On 3/8/2012 11:04 AM, Lisa Dusseault wrote:
>> On Thu, Mar 8, 2012 at 10:46 AM, Gregory Alan Bolcer<greg at bolcer.org>wrote:
>>> +1 to Lisa also, but that cuts to the heart of REST though, right?  A
>>> truly compliant REST application would be 100% cachable.
>>> Only if its data never, ever changed :)

More information about the FoRK mailing list