esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: RESTful ESME API - Design
Date Wed, 25 Feb 2009 17:17:40 GMT
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 <bdelacretaz@apache.org
> 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
>

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