[FoRK] overhead of RESTful stuff
eugen at leitl.org
Fri Mar 9 01:20:12 PST 2012
On Thu, Mar 08, 2012 at 10:11:45AM -0800, 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).
You can assume our programmers are not well aware of costs of calls.
> 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
We cannot cache for this use case. E.g. if you're rendering a chemical
structure from registry ID of many millions of entities that rendering
call will likely to never recur.
> 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.
We've been actively resisting the cloud, but it's pretty obvius this
new development will make outsourcing of most hitherto DIY in-house and
colo-hosted physical layer stuff to a competent but cheap domestic provider.
I'm looking at OpenQRM and OpenStack with a mix of underlying virtualization
technologies (so far we do VMWare and Linux VServer, will probably keep
VMWare but also do KVM and LCX when it's finally usable, same applies
More information about the FoRK