Hi Vassil, Replies inline below.
Thanks, Ethan 2009/8/3 Vassil Dichev <[email protected]>: > > For a start, you could use the Twitter API, where nothing is stateful, > and you don't need to be logged in. Yup, I'm aware of the Twitter API. I'd like to be able to use an API that exposes all of the functionality of ESME, which definitely goes way beyond what Twitter and the Twitter API provide. > 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 wasn't aware of the existence of two versions of this API method. >From the old REST API documentation it looked to me like I had to have a session set up to use any of the API methods. I may have missed this though. Is it on the old REST API page on Google Code? >> 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 > Right, got it. It was a bad choice of words. I don't claim more expertise on this than anyone here. Perhaps somewhat different expertise, but not more. What I meant was this: I think for programming interfaces there is something to be said for sticking to a convention unless there are good technical or usability reasons to break with the convention. The fact is that few existing APIs require the use of sessions and because of this very few of the environments and libraries with which API clients are programmed have robust session support. My impression is that in this case (YQL) and in other cases (dynamic languages, server-based programming environments, etc), interoperability would be improved by removing sessions. I'm wondering if there are specific reasons this choice was made, as I still don't understand the trade-off. Apologies if I'm being thick, but David's earlier rant didn't really clarify things for me if it is the one I'm thinking of (I'm on a plane as I write this, so I don't have immediate access to it). I assure you, I carefully read all rants I receive, though I don't usually find it very useful to respond. :-)
