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
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 <[EMAIL PROTECTED]> wrote: