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