My archive-search-foo is apparently weak and I can't find any of the old
discussions. Do you have pointers to any of them?
David Medinets wrote:
This topic has been discussed several times. Unless you're working on
this project to develop a prototype or for research purposes, please
research the previous REST API in the mailing list archives. I know
one of the issues was performance; at the very least using a REST API
involves serializing and de-serializing which affects performance.
On Mon, Apr 13, 2015 at 4:49 PM, vaibhav thapliyal
<[email protected]> 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]> wrote:
Vaibhav - who is the intended user for your rest api?
On Mon, Apr 13, 2015 at 4:16 PM, vaibhav thapliyal
<[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]> 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
