Hi Jia, I am OK with the idea of having standard HTTP API, this will help development of (non-Java) tools.
It is not clear to me if we are going to add an http API useful for "managing bookies" or a new HTTP REST-like Client API to BookKeeper. I am referring to the fact that in the proposal there are API calls to create ledgers and to read data. I think we should separate this two aspects and maybe it is better to address the 'bookie management' first, which is the work that Yiming started. Another point very important to me is that if we are going to introduce management operations via http we have to take into account security, at least TLS and some kind of authentication. About TLS it is very simple to achieve this, every HTTP server supports TLS (https) About authentication the problem is not so simple, Kerberos on HTTPs is very complex, but we need to introduce some auth mechanism. IMHO We can require the 'http server implementation' to implement security but out of the box we have to supply basic support at least for one provider bundled in the distribution package. Some API can return very large result sets like 'list ledgers', actually the HTTP Server subsystem exchanges strings in memory, we will need to introduce some more smart way because it would be easy to bring down the bookie just by calling that API multiple times concurrencly (it is just an example) IMHO The 'create ledger' API is not useful, due to the design of BK you have to create a ledger and then write immediately to it, I think that such an API should allow the client to stream the contents of the ledger in the HTTP body at least. But I think that a more stateful http API needs to be designed to implement a pure Http client Maybe we should add a more narrowed motivation and add the only useful APIs to address those issues. For instance in my company we would like to start creating a BookKeeper Web UI, so we need some way to talk to bookies and exchange data, but in this case I am interested in asking to bookies their status and the effective contents of the bookie -- Enrico 2017-09-13 6:09 GMT+02:00 Yiming Zang <yz...@twitter.com.invalid>: > Sure, I think the current HTTP endpoints in Twitter are only designed for > Twitter specific, such as check quorum loss, check rack/region diversity. > So the endpoints convention in Twitter are not the same as in the proposal. > I think it would be great to have an agreement on the API naming design, so > I like the API design in the proposal, I think the proposal looks good to > me. > > Besides, we're currently only using GET functionalities in Twitter, but I > notice there're a lot of POST and PUT APIs in the proposal which could > change the bookie state or trigger some heavy workload. These APIs looks a > bit risky to me if we don't have any authentication enabled (in Twitter). > > On Tue, Sep 12, 2017 at 6:11 PM, Sijie Guo <guosi...@gmail.com> wrote: > > > + Yiming > > > > Yiming, if you have time, please take a look at this BP. let's see if > > there are any conflicts with those you added for autorecovery. > > > > - Sijie > > > > On Tue, Sep 12, 2017 at 8:00 AM, Jia Zhai <zhaiji...@gmail.com> wrote: > > > >> Hi all, > >> > >> Based on Github #278 <https://github.com/apache/bookkeeper/pull/278>, > I > >> have just posted a proposal regarding define BookKeeper public http > >> endpoints: > >> > >> https://cwiki.apache.org/confluence/display/BOOKKEEPER/BP- > >> 17%3A+Define+BookKeeper+public+http+endpoints > >> > >> > >> Github #278 <https://github.com/apache/bookkeeper/pull/278> introduces > >> BookKeeper Http Endpoint module. However there are only two endpoints, > >> which is “/heartbeat” and “/api/config/serverconfig”, defined in #278. > In > >> order to fully leverage the http modules, The goal of this BP is to add > >> more endpoints to this modules. > >> > >> Any comments are welcome and appreciated. > >> > >> > >> Thanks. > >> > >> -Jia > >> > > > > >
