esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: RESTful ESME API - Design
Date Wed, 25 Feb 2009 17:38:42 GMT
Even if we use OAuth, we cannot drop sessions from ESME's APIs.

The current token mechanism is half-way to OAuth.  The current token
mechanism provides for the same unique identifier that OAuth requires.  The
part of OAuth that ESME does not yet support is the automatic credential
generation between two services.  Given that for the most part, the ESME
tokens are being used in clients, the credential negotiation part is

So, ESME currently uses the same kind of unique tokens as OAuth for
authenticating external services.

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.  Further, I expect to "page out" resources that have not received a
message in some future version of ESME.  Not having the session mechanism as
a guide for which user actors to page out is a significant negative.

While I understand how there are nice mappings between REST and CRUD, ESME
is not a CRUD application.  ESME is stateful, eventful, and sessionful.
 Forcing REST's stateless design onto ESME is a bad decision that will have
negative performance and semantic ramifications.



On Wed, Feb 25, 2009 at 9:17 AM, Ethan Jewett <> wrote:

> Hi,
> I'm in agreement that it is desirable and possible to avoid using HTTP
> sessions.  At one point in the past I suggested using OAuth because it is a
> standard way to handle session tokens and authorization delegation for API
> clients.  It also provides the benefit of fully specifying how credentials
> should be provided along with the request and it does not rely on HTTP
> sessions.  I'd still recommend that OAuth be the end-goal for an ESME API
> authorization scheme.
> If we get rid of HTTP sessions, we should be able to drop the "sessions"
> resource from the API entirely.
> What I don't understand is what affect this might have on long-polling, as
> I'm not sure how the technical mechanism of long-polling works.
> Ethan
> On Wed, Feb 25, 2009 at 7:15 AM, Bertrand Delacretaz <
> > wrote:
> >
> >
> > Are these HTTP sessions, or something else?
> > (I'm not familiar with the current EMSE API, bear with me if this is a
> > silly question).
> >
> > Looking at your suggested API, it seems like minor changes would make
> > it possible to avoid HTTP sessios altogether, for example:
> >
> > PUT /api/messages/USERID
> >
> > Using a Content-Type and representation (XML, JSON, whatever) that
> > describes the message, using parameters similar to what you have
> > above. And credentials to restrict access, of course.
> >
> > With this kind of change, I think you could avoid HTTP sessions, and
> > make the API more RESTful.
> >
> > WDYT?
> >
> > -Bertrand
> >

Lift, the simply functional web framework
Beginning Scala
Follow me:
Git some:

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