esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Current REST-API - Sessions
Date Mon, 03 Aug 2009 15:29:56 GMT
Hi Vassil,

Replies inline below.


2009/8/3 Vassil Dichev <>:
> 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
> ;-)

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

View raw message