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