Return-Path: Delivered-To: apmail-incubator-esme-dev-archive@minotaur.apache.org Received: (qmail 63241 invoked from network); 27 Oct 2009 16:17:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Oct 2009 16:17:51 -0000 Received: (qmail 52082 invoked by uid 500); 27 Oct 2009 16:17:51 -0000 Delivered-To: apmail-incubator-esme-dev-archive@incubator.apache.org Received: (qmail 52031 invoked by uid 500); 27 Oct 2009 16:17:50 -0000 Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: esme-dev@incubator.apache.org Delivered-To: mailing list esme-dev@incubator.apache.org Received: (qmail 52021 invoked by uid 99); 27 Oct 2009 16:17:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Oct 2009 16:17:50 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of esjewett@gmail.com designates 209.85.160.41 as permitted sender) Received: from [209.85.160.41] (HELO mail-pw0-f41.google.com) (209.85.160.41) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Oct 2009 16:17:42 +0000 Received: by pwj11 with SMTP id 11so195967pwj.20 for ; Tue, 27 Oct 2009 09:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=lxIykzIikclhA8JQPxVLjdHezg0WkEOjo7JLWiXwTv0=; b=i0Ujsdz/rZsmzF1bv+Td5E1Pocpg29IDfNCtY2FPKY9qw7mvaDX27O+kdC1PdVql4w e4h/qUisVteFw79cvLr7BvsxaBk/lqzFtXshNdehcAoCxrjgJy2I797dbvGfYWswt9C5 hpWPdmJs8spPKwPDGsnV3Al+0BB2xhgLRoe/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SNgz+R9CVIcbjhT2KBMgjz0W1K+VTIJsknK9Lq22M5/HzCBd7/4vRe35FcA0deK7hk AUNcGRlLDhUUfA1V3hmustvv1Cf6EDJU1B1rzBEHdJ8oHtIkfZzuXSCiQ5chQCrkz4NY e9QvN60RWXYwP/2IBufnabPjqc8Rfo7m310XA= MIME-Version: 1.0 Received: by 10.140.141.21 with SMTP id o21mr2054508rvd.292.1256660241400; Tue, 27 Oct 2009 09:17:21 -0700 (PDT) In-Reply-To: References: <68f4a0e80910251728te9c1248j10f1aa99c9f7cd2e@mail.gmail.com> Date: Tue, 27 Oct 2009 12:17:21 -0400 Message-ID: <68f4a0e80910270917r408588fbva0f47e73125afa4d@mail.gmail.com> Subject: Re: Patch submitted, working towards API design From: Ethan Jewett To: esme-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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 >>> (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 >>> >> >