(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" <[email protected]
<mailto:[email protected]>> wrote:
Vaibhav - who is the intended user for your rest api?
On Mon, Apr 13, 2015 at 4:16 PM, vaibhav thapliyal
<[email protected]
<mailto:[email protected]>> 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" <[email protected]
<mailto:[email protected]>> 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
>>>
>
