accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vaibhav thapliyal <vaibhav.thapliyal...@gmail.com>
Subject Re: Features that should he part of a rest client for accumulo
Date Mon, 13 Apr 2015 20:49:21 GMT
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> 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> 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> 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
> >>>
> >
>

Mime
View raw message