Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of vdichev@gmail.com designates
 209.85.219.223 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=on/99vZOymaqUHorODlw/lydwcDbnxK5L+2hwa+iD2GmrO7UlfoIGM1aRVaQ9tZSil
         PSmkP4yGT4JuwLZJ6BWsuKBZu3ActrMd+9ha1wcrt26HuUZPgA1q33EA2axxD/rnDOMu
         Y5NOsuphvEyRWjqqr5+wVlA1MyVsj80rTBzck=
MIME-Version: 1.0
Sender: vdichev@gmail.com
In-Reply-To: <68f4a0e80908020845s6607d2e6y2eb64d193e6fac5f@mail.gmail.com>
References: <68f4a0e80908020845s6607d2e6y2eb64d193e6fac5f@mail.gmail.com>
Date: Mon, 3 Aug 2009 09:44:14 +0300
Message-ID: <c7fc82820908022344v3d6ad906y1c16d561d1ed4e67@mail.gmail.com>
Subject: Re: Current REST-API - Sessions
From: Vassil Dichev <vdichev@apache.org>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

For a start, you could use the Twitter API, where nothing is stateful,
and you don't need to be logged in.

> 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 don't think I understand the question. We *can* use stateful *and*
stateless calls in Lift, too. For instance, the post_msg has two
versions, and for one of these, you don't need to be logged in. Surely
you don't want ESME to reimplement its own version of a RESTful API
creation library, when there's a convenient one in Lift already?

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

Ethan, "the way web APIs are programmed these days" may not always be
the most appropriate thing to do for any project. I don't think you
need another rant from David, there is an old one on the topic already
;-)

http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/200812.mbox/%3Ccdbebedf0812212111k7d618729r5d3a10a5844b0a74@mail.gmail.com%3E