Folks, 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. Thanks, David On Sun, Dec 21, 2008 at 4:23 AM, Hirsch, Richard <[email protected] > wrote: > Just found this after following a link on the scala reddit ( > http://www.innoq.com/blog/st/2008/12/esme_twitter_clone_in_scala.html) > > http://tech.groups.yahoo.com/group/rest-discuss/message/11862 > > "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 http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
