esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Patch submitted, working towards API design
Date Thu, 29 Oct 2009 14:51:06 GMT
I'm hoping to be able to expand on that this weekend a bit. I'm
to keep track a bit, and if people want more resources in the API they
should add them there (and discuss on this list).

Currently Tags have been left out, Searches are an item that we might
want to add, and there are no stream-based interfaces to message
queues, which I now agree are very important. Lots of work to do there
:-) I'll try to get this stuff written up and into Jira over the


On Thu, Oct 29, 2009 at 10:19 AM, Richard Hirsch <> wrote:
> I've committed the changes - what is missing in the API?
> D.
> On Tue, Oct 27, 2009 at 5:17 PM, Ethan Jewett <> wrote:
>> This is working on Stax!
>> On Tue, Oct 27, 2009 at 3:41 AM, Richard Hirsch <> wrote:
>>> The new api is deployed on stax.
>>> D.
>>> On Mon, Oct 26, 2009 at 8:09 AM, Richard Hirsch <>
>>>> 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 <>
>>>>> 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
>>>>> ( 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
>>>>> (
>>>>> 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

View raw message