accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Features that should he part of a rest client for accumulo
Date Tue, 14 Apr 2015 21:07:38 GMT
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" <hoodel@hoodel.com
> <mailto:hoodel@hoodel.com>> 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
>

Mime
View raw message