esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: RESTful ESME API - Design
Date Thu, 26 Feb 2009 17:19:24 GMT
Sounds good. I'm certainly not committed to the idea that REST is the only
way to go. I think it is a design pattern worth paying attention to, but no
design pattern is the be-all-end-all for any particular application.  I
don't think anyone has made the statement that REST is the only way to go,
and if that was read into anything I said then I would like to clarify that
it should not have been.

I made my suggestion for a more RESTful API design primarily because the
current API was called a "REST" API and was patently not REST.  I took the
title of the API to be an indication that a RESTful approach was one of the
design goals.  I think using sessions to facilitate the design goals you
stated, while not "REST" in the pure sense can be reconciled with an API
design that is legitimately RESTful overall.

With regards to OAuth, it is sort of tangentially related to the actual
design of the API methods, so maybe we can take it up later.


On Thu, Feb 26, 2009 at 8:39 AM, David Pollak <
> wrote:

> On Thu, Feb 26, 2009 at 1:03 AM, Bertrand Delacretaz <
> > wrote:
> > Hi David,
> >
> > On Wed, Feb 25, 2009 at 6:38 PM, David Pollak
> > <> wrote:
> > > ...The reason for sessions has to do with long polling and the general
> > cost of
> > > setting up the machinery related to a User.  If we were to implement
> long
> > > polling without sessions, we would have to construct the entire
> listener
> > > mechanism on each long poll request rather than at the beginning of the
> > > session....
> >
> > Do I understand correctly that the need for HTTP sessions comes from
> > the mechanisms used by the Lift/Scala backend to implement long
> > polling? Just trying to understand the issues.
> Sessions set up listeners.  Listeners are stateful.  Stateful means
> sessions
> so that even if after the HTTP request is serviced, the listener can
> receive
> updates and respond with those updates immediately upon the next HTTP
> request for new messages.  The requirement is neither a Lift nor a Scala
> requirement, but an ESME design requirement.
> More broadly, trying to force ESME into a REST/CRUD model because REST/CRUD
> is the design pattern du jour is a bad thing.
> ESME is a messaging system.  I've been working on micro-messaging systems
> for nearly two years now.  See
> Prior to that, I spent many, many years working with real time data feeds
> and spreadsheets in the financial sector.  I invented the worlds first
> real-time spreadsheet as well as the first browser-based multi-user
> spreadsheet.  I have a pretty good handle on messaging systems.
> ESME is a messaging system.  It would make a lot more sense to try to adapt
> the JMS APIs to ESME than REST/CRUD APIs.
> So, I've got the Lift 1.0 launch today, a book on Scala to finish, a week
> full of meeting next week, QCon London the following week and TSS the week
> after that, so I'm not going to have a lot of time to go through another
> round of "REST is the only way to go" debates.
> David
> >
> >
> > -Bertrand
> >
> --
> Lift, the simply functional web framework
> Beginning Scala
> Follow me:
> Git some:

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