On Sun, Aug 2, 2009 at 8:45 AM, Ethan Jewett <[email protected]> wrote:
> 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). There are some ESME APIs for which stateless/"RESTful" is appropriate (things that refer to entities that are stable... basically things that map to RDBMS calls) and things where stateless is not appropriate (things that refer to event streams.) There are clients for which stateless is appropriate (in this case YQL) and clients for which stateless is not as appropriate (i.e., UI clients, web based or desktop based.) We have limited resources and I don't want to have duplication API implementations (or even filters) for stateful and stateless because that's just more work for us, more stuff for us to maintain, and this is the first use case for actually having stateless that's appeared on this list. So, I'll work on a way to address your issue, but it's not going to be "all stateless." There will be things in the stateful APIs that will not exist in the stateless ones. I'll also ping Sam Pullara about wether YQL is totally stateless or whether it's possible to have session cookies as part of a request set. Thanks, David > > > Thanks, > Ethan > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
