> 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/%[email protected]%3e
