accumulo-user mailing list archives

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