accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Schwartz <>
Subject Re: Features that should he part of a rest client for accumulo
Date Wed, 15 Apr 2015 02:36:00 GMT

I've got a Play 2.2.X ( 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:

These two projects wrap up the Accumulo driver into a Play framework plugin
and provide a simple document model around the Accumulo records.

The API has a lot of propriety business logic as it is the engine for my
web front-end, but I could probably rip that out and get it down to solely
an accumulo REST API.

It's been a while since I've looked closely at it, but I believe there are
a few API calls:

POST /api/v1/tableName (auto generates a row-id)
GET /api/v1/tableName/{row-id}  (gets the document with row-id)
PUT /api/v1/tableName/{row-id}  (updates/inserts a document with row-id)

Let me know if any of this would be of assistance.

Jeff Schwartz

On Tue, Apr 14, 2015 at 6:02 PM, vaibhav thapliyal <> wrote:

> I have chosen the 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 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.
>> Your choice of Java library (resteasy/jersey/etc) probably have their own
>> way to automatically do this for you with a little bit of wiring up.
>> Sean Busbey wrote:
>>> 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/table/row/columnFamily>
>>>     https://host/table/row/__columnFamily/column
>>>     <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 be
>>>     problematic. Some or all of the key data may need to be URLencoded
>>>     as well.
>>>     For CRUD, the following seems to be common practice:
>>>          Create: Method="PUT" [or "POST"]
>>>          Read: Method="GET"
>>>          Update: Method="POST"
>>>     Delete: Method="DELETE"
>>>     It seems to me that the whole user
>>>     identification/authentication/__authority determination is the hard
>>>     part for the general audience. You can't really count on having a
>>>     PKI/CAS infrastructure, which would solve that issue. Stateful
>>>     authentication could be done via log-in and made part of the
>>>     client's signature (perhaps a cookie).
>>>     I'm just starting to go through "REST API Design Rulebook" by Mark
>>>     Massé (O'Reilly 2012). You might want to check it out. Here are the
>>>     first few "rules" from Chapter 2 (note the difference between the
>>>     use of MUST versus SHOULD). Rules continue throughout the book.
>>>     Chapter 3: "Interaction Design with HTTP" covers CRUD operations.
>>>     Rule: Forward slash separator (/) must be used to indicate
>>>     hierarchical relationship
>>>     Rule: A trailing forward slash (/) should not be included in URIs
>>>     Rule: Hyphens (-) should be used to improve the readability of URIs
>>>     Rule: Underscores (_) should not be used in URIs
>>>            [underscore is masked by underline]
>>>     Rule: Lowercase letters should be preferred in URI paths
>>>     Rule: File extensions should not be included in URIs
>>>            [I don't like this one. The author says that negotiation
>>>     should be according to an Accept request header.]
>>>     Rule: Consistent subdomain names should be used for your APIs
>>>            (
>>>     Rule: Consistent subdomain names should be used for your client
>>>     developer portal
>>>            (
>>>     <>)
>>>     I hope that helps.
>>>     Kurt
>>>     On 4/13/15 3:33 PM, 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
>>>     --
>>>     Kurt Christensen
>>>     P.O. Box 811
>>>     Westminster, MD 21158-0811
>>>     ------------------------------__----------------------------
>>> --__------------
>>>     "Perfection is not attainable, but if we chase perfection we can
>>>     catch excellence." -Vince Lombardi

View raw message