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
 209.85.220.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=IqZyKvb5CaLtT9FJAqR9XgwlMSHw8gRIniAnigHrlZC4y1wxAGzep/JmB0z7BQ3nff
         nVwtFIeeM24wGrh0wlx08ePhpfcQsZvgpsTKW1MVLvm3FlGu5TvK8d3sSM0hETp6qlUT
         ooqCK1/reZRwAkAjWKmcKVyk3Rtz64WEKOZvM=
MIME-Version: 1.0
Date: Sun, 2 Aug 2009 10:45:53 -0500
Message-ID: <68f4a0e80908020845s6607d2e6y2eb64d193e6fac5f@mail.gmail.com>
Subject: Current REST-API - Sessions
From: Ethan Jewett <esjewett@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all,

Last week I said I was going to start working on a YQL-wrapper for the
ESME API, hoping that my work in that area would start to drive API
development again. (After the whole RPC vs. REST uproar we ended up
with one blog post, one page on the wiki at
http://incubator.apache.org/esme/restapi.html and that was it, which
was mostly my fault for losing interest for various reasons.)

Today I started and almost immediately ran into the requirement of the
current API to sustain a session in the client. I know it would be
possible to simulate this by manually creating the appropriate headers
in Javascript, however I don't think this is a reasonable approach
with YQL as YQL itself has no mechanism to allow storing a session key
across requests, so session key storage would have to be managed by
the YQL client, and then the session key passed in the YQL request.

I'd like to revisit the use of sessions in the API. I do not know
Lift, but my understanding is that we gain some ease of use in the
scenario of interfaces built on top of the API using Lift because of
its automatic handling of sessions. Are there other reasons?

I'd like to understand all the reasons for this approach so that we
can figure out if there is an alternate way to handle this that is
more in line with the way web APIs are programmed these days (and
subsequently will hopefully be more useful with web API interaction
tools like YQL work).

Thanks,
Ethan