I wonder if a possible solution would be to allow a timestamp to be
passed into the API calls? Those calls which would appear to require
state could be made stateless if called as "get me the data since this
timestamp", and would return the timestamp of the last item in the data
returned. This would mean that the client could guarantee to receive all
the data from the server, but a session ID would not be required.
Just a thought,
Darren
Ethan Jewett wrote:
Hi David,
Thanks for looking into this. I definitely agree that we need state on
some calls. Partly I'm curious as to if sessions are the best way to
do this, but I'm good with whatever we have and I'm aware of the
resource constraints.
I've been wondering if there is a good way to provide optional state
through sessions as well as a stateless mode for some calls. Is this
what you mean by filters?
I'll see if I can get in touch with Sam on this topic as well, as he's
offered help to me on other YQL interfaces I've worked on.
Ethan
On Mon, Aug 3, 2009 at 9:02 AM, David
Pollak<[email protected]> wrote:
On Sun, Aug 2, 2009 at 8:45 AM, Ethan Jewett <[email protected]> wrote:
Hi all,
Last week I said I was going to start working on a YQL-wrapper for the
ESME API, hoping that my work in that area would start to drive API
development again. (After the whole RPC vs. REST uproar we ended up
with one blog post, one page on the wiki at
http://incubator.apache.org/esme/restapi.html and that was it, which
was mostly my fault for losing interest for various reasons.)
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.
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'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).
There are some ESME APIs for which stateless/"RESTful" is appropriate
(things that refer to entities that are stable... basically things that map
to RDBMS calls) and things where stateless is not appropriate (things that
refer to event streams.) There are clients for which stateless is
appropriate (in this case YQL) and clients for which stateless is not as
appropriate (i.e., UI clients, web based or desktop based.)
We have limited resources and I don't want to have duplication API
implementations (or even filters) for stateful and stateless because that's
just more work for us, more stuff for us to maintain, and this is the first
use case for actually having stateless that's appeared on this list.
So, I'll work on a way to address your issue, but it's not going to be "all
stateless." There will be things in the stateful APIs that will not exist
in the stateless ones. I'll also ping Sam Pullara about wether YQL is
totally stateless or whether it's possible to have session cookies as part
of a request set.
Thanks,
David
Thanks,
Ethan
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
