esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Pollak" <>
Subject Re: Pretty scathing critique of our REST API
Date Mon, 22 Dec 2008 05:11:39 GMT
While technically correct, that the ESME APIs are not pure REST, barring
some study of the problems we're trying to solve and some suggestions about
how to solve them in a more RESTful manner, I think it's just a bunch of
folks who like to grumble about how uncool others are.

If we take a look at ESME's object hierarchy... it's not overly OO.  A
hardcore Smalltalk purist would have a similar reaction to ESME's object
model.  The fact that it's simplistic does not detract from the fact that it
gets the job done and is reasonably understandable.

Because ESME APIs are stateful, they are, by strict definition, not RESTful.
 REST requires statelessness.  It also means authentication credentials
(rather than a session cookie) are sent with every request.  But, if we
wanted to get into a semantic war, we could claim that the session cookie
isn't really a session cookie, it's a temporary authentication credential
that's obtained by passing more durable credentials.  And then, each request
is authenticated with the temporary credentials and, like magic, our APIs
are more RESTful.

But the problem that REST and a whole bunch of other web technologies don't
address is long polling and push/pseudo push.  Long polling consumes lots of
resources keeping a connection open for a long time while state has not
changed on the server side.  You can't do this with anything short of a real
sessions shared between the client and server.  And, just to be clear, long
polling is an order of magnitude more efficient than REST-style polling and
long polling is a more natural semantic for the kind of highly interactive
application that is ESME.

Two years ago, when I started designing Lift, I bucked a lot of trends that
Rails defined.  I looked at the kind of applications I was writing and that
others were writing and built Lift into something that could handle those
applications.  Lift is not pure.  It's practical.  It's oriented to making
common things in highly interactive web sites super easy.  These days, I'm
getting more and more Rails converts in Lift-land who are looking to escape
the Rails dogma.  I think this situation has many parallels.

Mrinal was the prime API customer.  He asked for APIs that, IMHO, are sane,
simple and usable.  I 100% endorse his requests and choices and believe that
they are better than the choices I would have made.  Our XML/JSON APIs are
borne out of practicality and simplicity.

With all that being said, I think we can improve.  The recommendation about
unifying the "message" API by looking at GET vs. POST was a good suggestion.
 I welcome other suggestions like that.  I welcome suggestions from other
API users such that we can enhance ESME and ESME's APIs to suit the needs of
a broader range of developers.

But that does not mean purity for purity's sake.  It means practicality for
our customers and consumers and end user's sake.

My Sunday night 2 cents worth of rant.



On Sun, Dec 21, 2008 at 4:23 AM, Hirsch, Richard <
> wrote:

> Just found this after following a link on the scala reddit (
> "Esme's API is as bad anything I saw in the SOAP/XMLRPC days. I'm
> dumbfounded this can get incubated in the ASF."
> Yikes.
> D.

Lift, the simply functional web framework
Collaborative Task Management
Follow me:
Git some:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message