incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Patch submitted, working towards API design
Date Tue, 27 Oct 2009 07:41:48 GMT
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
View raw message