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 21:20:25 GMT
> 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 wasn't sure what you're trying to do, but this sounds like a pretty
complicated use of YQL.

> 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?

Noted. Maybe it's not even on the old page, but in a mail somewhere in
the old mailing list, which I agree is next to useless.

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

I'm sorry if it sounded like I'm disparaging your efforts to stick to
the REST principles- I didn't mean to. I just recalled that the "whole
RPC vs. REST uproar" was caused by a guy who had some valid points but
in the end wasn't aware of how ESME works and the reasons it's
designed this way. So if I was a bit bitter, it was because of this
case when someone jumps to conclusions and condemns ESME as being all
wrong because we called it REST instead of RESTful or REST-like.

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

Let us know about the use case (what do you want to achieve?), so we
are better prepared to help. If it's not in the Twitter API, then it
must be pretty specific to ESME. What are you trying to use- actions,
pools, tagclouds, tracking...?

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

For me the takeaway point of the rant was that we shouldn't try to fit
everything into a mold. Not all apps should conform completely to a
design pattern at all costs. One should understand the underlying
reasons for sticking to a best practice before trying to apply it
everywhere, otherwise one might be trying to fit square pegs into
round holes. What this means for ESME- it's fine to use some of the
advice regarding REST, but the prescription that all interaction is
stateless doesn't fit with ESME, where state is important and is
central to the application design.

Maybe as a result of this old discussion we should have outlined the
things that we can do to improve things and stuff that we are not
going to change, because it doesn't make sense. This way there should
be no false expectations regarding what we wanted to do.


View raw message