Guys,
I've got a Play 2.2.X (www.playframework.org) application that is
essentially a REST API on top of Accumulo. It is CRUD based and designed
for small payloads. I posted two play libraries to GitHub in support of
this API:
https://github.com/jschwartz73/play2-accumulo
https://github.com/jsc
I have chosen the rest.li framework for creating the API. I will also have
a look at the frameworks you all have mentioned and keep you all posted.
Thanks again
Vaibhav
On 15-Apr-2015 2:40 am, "Josh Elser" wrote:
> yes/no, IMO.
>
> Enabling SPNEGO would be a nice direct integration point with Acc
yes/no, IMO.
Enabling SPNEGO would be a nice direct integration point with Accumulo
1.7 (now that we have the Kerberos client auth groundwork in place), but
I would imagine that reusing HTTP basic authentication (in conjunction
with HTTPS) is probably a more standard way to go about this.
Yo
For the auth part, using SPNEGO will put you in line with most other
components.
--
Sean
On Apr 14, 2015 9:37 AM, "Kurt Christensen" wrote:
>
> Accumulo seems to invite the following structure for URIs.
>
> https://host/table/row
> https://host/table/row/columnFamily
> https://host
Accumulo seems to invite the following structure for URIs.
https://host/table/row
https://host/table/row/columnFamily
https://host/table/row/columnFamily/column
On the other hand, because the various keys (row, columnFamily, column)
can be arbitrarily long, URIs built this way can
(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 sing
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 th
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 a
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.
Vaibhav - who is the intended user for your rest api?
On Mon, Apr 13, 2015 at 4:16 PM, vaibhav thapliyal
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 yo
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-
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
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
13 matches
Mail list logo
