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/jschwartz73/play2-accumulo-ext 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. Sincerely, Jeff Schwartz On Tue, Apr 14, 2015 at 6:02 PM, vaibhav thapliyal < [email protected]> wrote: > 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" <[email protected]> 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" <[email protected] >>> <mailto:[email protected]>> 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 >>> (http://api.soccer.restapi.org__) >>> >>> Rule: Consistent subdomain names should be used for your client >>> developer portal >>> (http://developer.soccer.__restapi.org >>> <http://developer.soccer.restapi.org>) >>> >>> 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 >>> >>>
