Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of esjewett@gmail.com designates
 74.125.46.157 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Wi7IKZeCkzWNNI6VEHFQmWcH/OaqrQ7musOYGRlgtGrmrnOUqbQGx5uxT3ZjeyV6gE
         a4wSLm09eUyswbC/F35mzdmkzxbr+3VBqX43hefP8eewtW89fCu2Cd+113kMX6wmYbIQ
         1dMRSd7gECUv41aBYEmjS20dv530RNEuTiKDE=
MIME-Version: 1.0
In-Reply-To: <f767f0600902250715h69e3707agf53d379307e3059@mail.gmail.com>
References: <0015175cb7c2aef2f80463096aa3@google.com>
	 <f767f0600902250715h69e3707agf53d379307e3059@mail.gmail.com>
Date: Wed, 25 Feb 2009 09:17:40 -0800
Message-ID: <68f4a0e80902250917i51e73802oc8f892ab88fe23a0@mail.gmail.com>
Subject: Re: RESTful ESME API - Design
From: Ethan Jewett <esjewett@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00221532c5b4c1be790463c1692e

--00221532c5b4c1be790463c1692e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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
>

--00221532c5b4c1be790463c1692e--