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" <josh.el...@gmail.com> 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" <hoo...@hoodel.com >> <mailto:hoo...@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 >> >>
