[FoRK] overhead of RESTful stuff
sdw at lig.net
Thu Mar 8 10:24:22 PST 2012
+1, but note that there is, in practice, a big difference between normal HTTP web caching and application caching via something like
memcached. The main difference is that, generally, the former can only be used for things that are guaranteed to be immutable for
the timeout period. You can make use of that in an application by using dynamic URLs, but generally memcached is nice because you
can easily and efficiently invalidate information. Additionally, it may be that the page or REST data cannot be cached for various
reasons, but the app can avoid a very expensive database or similar operation. Typically, I think, with an AJAX REST app, the data
request is essentially tunneled through the web server in a way that is hard for it to cache. It's conceivable to have app server
capability to invalidate web cache items, and some web proxies like Squid have extensive protocols, but I don't think anyone does it
On 3/8/12 10:11 AM, Lisa Dusseault wrote:
> On Thu, Mar 8, 2012 at 4:25 AM, Eugen Leitl<eugen at leitl.org> wrote:
>> There's some enthusiasm for SOA and RESTful stuff at my dayjob lately
>> (yeah, we're always trailing state of the art by a decade or two),
>> so I'm worried about overhead.
> The main overhead I've seen in Web API designs was from bad resource
> selection (or worse, if the developers aren't doing REST, bad message
> granularity choices).
> The biggest theoretical savings in overhead from REST is from caching. The
> fastest way to handle a request is to set it up so you don't have to handle
> it at all (in the app server). But it's really very common for developers
> to break cachability, often without knowing it, because hardly anybody
> (compared to the population of so-called RESTful programmers) understands
> HTTP caching at this level.
> The next crazy thing I see is operators not even turning caching on! As
> you've no doubt seen, many programmers would rather comb through code
> optimizing their string concatenation (our founder did this once on a big
> java codebase) than find out how to install, configure and maintain a
> caching server, and show which API results can be cached. This should be
> an even more embarrassing omission now that one can outsource caching to
> the cloud.
More information about the FoRK