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 Wed, 25 Feb 2009 18:47:35 GMT
My responses are inline below.

On Wed, Feb 25, 2009 at 9:38 AM, David Pollak <
> wrote:

> 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 meaningless.

The return on using OAuth is in two areas: interoperability around the token
exchange, and security of the token exchange process.  By supporting OAuth
we make the auth mechanism of the ESME API interoperable with any consumer
that supports OAuth and we make it possible for ESME API developers to make
use of the many OAuth libraries that exist.  Further, I would not be
surprised to see services like Yahoo Pipes or Tarpipe begin supporting OAuth
in the near future (Shindig already does).  None of these services support
sessions.  Interoperability with these and similar services would be a huge
selling point for ESME.

As an aside here, it's worth noting that Alex Payne (a Twitter lead
developer) has stated that Twitter will at some point deprecate basic auth
in their API and require OAuth.  Because of this, we will start to see
Twitter clients support only OAuth in the future.  If ESME's Twitter API
will remain useful it will have to support OAuth at some point.

> 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.

If long-polling is technically dependent on HTTP sessions, then I think that
is fine.  In this case, it might make sense in the short term to provide a
REST API, possibly with OAuth, that does not provide support for
long-polling. Another option (longer-term) might be to change the
long-poller functionality to construct the listener based either on the
beginning of a session, or on the first use of long-polling request using an
API token from a specific IP address, for example.

Regarding the ability to page out resources, are there any other ways to
determine resource "freshness" aside from using HTTP session information?
 Possibly the application could keep a memory cache of recently used
resources, users, etc?  I'm just not very clear on how sessions help with
this, but there's a lot I don't understand about Lift and Scala.  Maybe we
can come up with a way to handle this in a stateless way.

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.

Why is ESME necessarily a stateful application?


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