incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <markus.koh...@gmail.com>
Subject Re: Patch submitted, working towards API design
Date Tue, 03 Nov 2009 18:21:31 GMT
Hi Ethan,
Here come a few comments to
http://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design

- it's not 100% clear to me what you mean with
api2/user/tracks
Do you mean api2/{USERID}/tracks where {USERID} is replaced by a valid
USERID?
or do you mean that depending on the authenticated user one would get back
different results?
I would not recommend to use the second approach, because that means you
cannot bookmark the URLs anymore.

-Regarding PUT and DELETE not available on all clients one option would be
to use google's approach in gdata and put an additional header into a POST
request:

X-HTTP-Method-Override: PUT



- as already commented  api2/session is not really Restful. I haven't read
the details about why it's currently done this way, but wouldn't simple HTTP
basic authentication work, at least if user and password are given?


- "Streaming" as far as I understand is about "push" functionality.
I would not go as far as to say "polling is bad". Since twitter is not real
time ESME would maybe not need to be real time as well. This means one could
poll infrequently (every few minutes?) using conditional GET's, which would
not be that inefficient. Comet has the disadvantage that without special
server support (available in Jetty, but not in Netweaver CE for example)  it
causes a lot of threads to be created on the server, which is also not
really efficient.
IMHO defining a pagination protocol would be more important.

In general I think it makes sense to define the URL pattern, but one has
always to be careful to not fall into the trap and forget about HATEOS (
http://blogs.sun.com/craigmcc/entry/why_hateoas).
With proper HATEOS support, the exact URL's would be less important, and
evolving the API  would be easier.
Since the response format is not yet specified, I think there's no issue
yet.

<http://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design>Regards,
Markus

On Tue, Oct 27, 2009 at 5:17 PM, Ethan Jewett <esjewett@gmail.com> wrote:

> This is working on Stax!
>
> On Tue, Oct 27, 2009 at 3:41 AM, Richard Hirsch <hirsch.dick@gmail.com>
> wrote:
> > The new api is deployed on stax.
> >
> > D.
> >
> > On Mon, Oct 26, 2009 at 8:09 AM, Richard Hirsch <hirsch.dick@gmail.com>
> wrote:
> >> I don't see any probs with putting this in the trunk. The existing
> >> rest api remains unchanged.
> >>
> >> D.
> >>
> >> On Mon, Oct 26, 2009 at 1:28 AM, Ethan Jewett <esjewett@gmail.com>
> wrote:
> >>> Hi all,
> >>>
> >>> This has been cooking for a little while (I think it was about 6 month
> >>> ago that I mentioned I should put my money/code where my mouth was),
> >>> but I finally submitted a patch for the ESME-14 Jira issue
> >>> (https://issues.apache.org/jira/browse/ESME-14). This patch creates a
> >>> new branch called "new_api". The sole purpose of this branch is to
> >>> create a new API endpoint /api2/ where we can start converting the API
> >>> to a format that aligns with discussions occurring on the wiki
> >>> (http://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design).
> >>>
> >>> The current diff has a working API at /api2/ that has pretty much the
> >>> same methods as the old one (I just copied them after all), but
> >>> arranged in the resource/object hierarchy outlined on the wiki. I've
> >>> also moved some parameters out of the query (part of the URL after the
> >>> ?) and into the path of the URL, when these parameters actually refer
> >>> to resources/objects.
> >>>
> >>> The diff should actually exist nicely alongside the existing API and
> >>> functionality, but I figured the easiest and safest way to get it in
> >>> initial was in a branch.
> >>>
> >>> Here's what I'm looking at doing next, not necessarily in this order:
> >>>
> >>> 1. Create new handlers to fill out the object/resource hierarchy
> >>> 2. Fix up the existing code in the API2.scala file so that it all
> >>> behaves the same way
> >>> 3. Work on aligning and documenting the naming of parameters that API
> >>> handlers expect
> >>> 4. Work on accepting XML or JSON representations of new or changed
> >>> resources, rather than using query parameters
> >>> 5. Write tests/specs (I'm working on figuring out how to do this. Any
> >>> pointers on how to make an HTTP request from Scala/Lift would be
> >>> extremely helpful, as I think this is level at which I need to test
> >>> the API.)
> >>>
> >>> See the wiki page for longer-term discussions and approaches.
> >>>
> >>> Any comments or questions? I've got to note that this is the first
> >>> Scala I've ever written (though truly, it's mostly copied and adjusted
> >>> at this point) outside of examples from books, so please please please
> >>> tell me how I should be doing things differently.
> >>>
> >>> Thanks,
> >>> Ethan
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message