esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: Current REST-API - Sessions
Date Mon, 03 Aug 2009 06:44:14 GMT
> 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

View raw message