Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.220.175 as permitted sender)
Message-ID: <552C5B67.8010907@gmail.com>
Date: Mon, 13 Apr 2015 20:12:23 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: user@accumulo.apache.org
Subject: Re: Features that should he part of a rest client for accumulo
References: 
 <CADXX17MRUEMHEKUosksj-PYXCDUkC+ZryRey1+vAgk_gb9bKwg@mail.gmail.com>
 <552C1ED5.4010606@gmail.com>
 <CADXX17O4qSRJ5MgwByF6tXSKvYRSR8jSRXBxE=6nuW9-z07fkA@mail.gmail.com>
 <CAOiJXP6R_GB9006yK+Jf0bSmrKKSWqJ7A0c5Y4hOiZYp_9XW_Q@mail.gmail.com>
 <CADXX17Mg8BwfcNB-gyJr4TZMGVMM7tu4FNYBQUpv0xh+vRh65g@mail.gmail.com>
In-Reply-To: 
 <CADXX17Mg8BwfcNB-gyJr4TZMGVMM7tu4FNYBQUpv0xh+vRh65g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

(forgot to add this last time) I think CRUD is a good target to aim at. 
A lot of the serialization concerns come around sending egregious 
amounts of data through a single webserver (big accumulo nodes, 
itty-bitty webserver).

An API that doesn't support many Key-Value pairs returned from a single 
call will simplify things greatly.

vaibhav thapliyal wrote:
> There is no specific intended user here. Basically I want to use
> accumulo in the software as a service format. So that if someone who is
> not well versed with accumulo doesn't need to worry about that. They can
> make use of the rest api for crud operations. All in all I am aiming for
> a generic api.
>
> Thanks
> Vaibhav
>
> On 14-Apr-2015 2:10 am, "David Medinets" <david.medinets@gmail.com
> <mailto:david.medinets@gmail.com>> wrote:
>
>     Vaibhav - who is the intended user for your rest api?
>
>     On Mon, Apr 13, 2015 at 4:16 PM, vaibhav thapliyal
>     <vaibhav.thapliyal.91@gmail.com
>     <mailto:vaibhav.thapliyal.91@gmail.com>> wrote:
>      > Thank you josh for pointing out the key features. I would
>     appreciate if you
>      > could elaborate your first point about the API being as stateless as
>      > possible.
>      >
>      > Also I would like you to point out to any coding conventions
>     followed by
>      > accumulo dev team so that my code follows them.
>      >
>      > Thanks
>      > Vaibhav
>      >
>      > On 14-Apr-2015 1:24 am, "Josh Elser" <josh.elser@gmail.com
>     <mailto:josh.elser@gmail.com>> wrote:
>      >>
>      >> Hi Vaibhav,
>      >>
>      >> This is something that comes up every now and again, but I don't
>     think
>      >> there's been any big interest internal to the project itself so
>     far. That's
>      >> not to say a REST API is without value: there just hasn't been
>     anyone who
>      >> stood up to own the feature. It's great that you want to do this
>     and it
>      >> would be a good way to get more involved.
>      >>
>      >> Some thoughts on the important bits:
>      >>
>      >> * As stateless of an API as possible
>      >>   - This is a little tricky as the server itself would need to
>     hide this
>      >> state in how it connects to Accumulo, as well as some notion of
>     a "cursor"
>      >> if a scanning API is supported. It may be easier to write an API
>     around gets
>      >> and puts as a first go and try to tackle scanning later as that
>     gets real
>      >> tricky, real fast.
>      >>
>      >> * User authentication
>      >>   - Having a good authentication story for clients to ensure
>     that they
>      >> receive only the data they should is tantamount. Lots of ways to
>     go about
>      >> this -- it would be good to identify the scope of the problem
>     you want to
>      >> solve then work towards that.
>      >>
>      >> * User authorization
>      >>   - Close together with authentication. The simple approach is
>     to require
>      >> Accumulo accounts for users connecting to the webservice. A more
>     advanced
>      >> approach (with more flexibility) is to build a
>     delegation/impersonation
>      >> service where the webserver would authenticate as some
>     monolithic user and
>      >> manage user authorizations on its own. This can be tricky to get
>     correct,
>      >> but is likely easier to manage resources this way.
>      >>
>      >> * Check out other systems' services before coding
>      >>   - This might seem a little odd, but I would take a look at
>     what other
>      >> projects like HBase or Cassandra have along this line. HBase has
>     Stargate as
>      >> a REST service (not sure how well it's maintained now) and I see
>     a bunch of
>      >> different projects for Cassandra. Getting an idea of what other
>     have found
>      >> useful in an API would be good and help make a usable API. You
>     would likely
>      >> be able to find some good discussions about what works well and
>     what is
>      >> problematic in these other projects. Thinking about those
>     problems up front
>      >> might help you avoid bigger problems down the road.
>      >>
>      >> In general, start small and get a nice, tested codebase. That
>     will help in
>      >> the long run. Keep us informed! This sounds great :D
>      >>
>      >> vaibhav thapliyal wrote:
>      >>>
>      >>> Dear all,
>      >>> I am trying to build a Rest-api for accumulo. I would like to
>     know the
>      >>> minimum features that should be there in the rest api?
>      >>>
>      >>> Also are there any plans to make a rest api for accumulo by the
>      >>> development team at accumulo itself?
>      >>> Thanks and regards,
>      >>> Vaibhav Thapliyal
>      >>>
>      >
>