esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Patch submitted, working towards API design
Date Thu, 29 Oct 2009 14:19:09 GMT
I've committed the changes - what is missing in the API?


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 <> 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 <> 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
>>>> ( 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