Ethan, 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 meaningless.
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. Thanks, David On Wed, Feb 25, 2009 at 9:17 AM, Ethan Jewett <[email protected]> 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 < > [email protected] > > 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 http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
