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 Thu, 26 Feb 2009 00:08:51 GMT
On Wed, Feb 25, 2009 at 10:47 AM, Ethan Jewett <> wrote:

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

I'm not sure you understand the existing APIs and/or OAuth.  OAuth is a
mechanism for two services to negotiate an authentication token.  OAuth does
not specify how the authentication token is used in the web-based APIs
themselves.  As I've already stated, we have an authentication token
mechanism.  OAuth is the way that the services negotiate the token.  The
token, after it is negotiated between the two services, is then used by one
service to authenticate itself against the other service.

We currently support tokens for authentication in our APIs.  In fact, we
don't support username/password authentication in our APIs.  So, today,
right now, without modification to our APIs, we support token-based
authentication.  After we implement OAuth for *negotiation* of the token
(this negotiation happens one time per new service registration), we will
not change our APIs at all.  Not one little tiny bit because our APIs
already support token-based authentication.

The discussion of token negotiation (OAuth) and tokens used for
authentication are orthoganal issues.  We will support OAuth for token
negotiation at some point.  We'll prioritize it based on need, but so far,
it seems that pools/groups and federation are higher priorities.  Even after
we support OAuth for token negotiation, it's not going to change our APIs.
They are already "OAuth ready."

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

OAuth has nothing to do with sessions.  So, what's the point here?

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

Yeah, when I was helping out at Twitter last year, I had a bunch of chats
with Blaine Cook (one of the OAuth spec authors) and Alex about OAuth.  Yes,
Blaine designed OAuth to avoid having to give out Twitter credentials to
everyone.  Yes, at some point Twitter will support 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.

This depends.  Negotiation between a client (e.g., Twirl) and Twitter for
the OAuth creditials is going to be pretty tough.  It's likely that Twitter
will implement a "generate token" feature like the current ESME mechanism
and that users copy/paste the token into their client.  In this case, ESME
will work fine.  I also believe that we will have the OAuth token
negotiation stuff working long before Twitter shuts off username/password
basic auth support.

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

You mean like the current support for message sending without a session?
Yes, we already support a subset of the API that does not require login, but
simply passing the auth token as part of the request.

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

Yeah and another option is to re-write ESME in Basic and run it on a TRS-80.

Perhaps we should focus on the actual use case as to why we want to make
particular design decisions rather than focusing on the dogma of REST.
Rather than removing one of the most compelling features of ESME, real time
updates for thousands of concurrent users, in the name of dogma, how about
if we focus on what's important in ESME and try to do the best we can to
adapt design patterns to ESME goals?

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

Because ESME is not going to make the design mistakes that Twitter made and
is not desperately trying to unmake.

Because ESME is about information flow, not trying to make everything appear
to be a static resource (one of the design tennets of REST).

Because all applications are stateful and recognizing that rather than
sweeping state under the rug leads to better design decisions.

Because ESME is an interactive app and will facilitate real-time as well as
asynchronous communications.


> Ethan

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

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