Re: rest mgmt api

[Dan Mick <dan.mick@inktank.com>]

On 02/06/2013 12:14 PM, Sage Weil wrote:
> On Wed, 6 Feb 2013, Dimitri Maziuk wrote:
>> On 02/06/2013 01:34 PM, Sage Weil wrote:
>>
>>> I think the one caveat here is that having a single registry for commands
>>> in the monitor means that commands can come in two flavors: vector<string>
>>> (cli) and URL (presumably in json form).  But a single command
>>> dispatch/registry framework will make that distinction pretty simple...
>>
>> Any reason you can't have your CLI json-encode the commands (or,
>> conversely, your cgi/wsgi/php/servlet URL handler decode them into
>> vector<string>) before passing them on to the monitor?
>
> We can, but they won't necessarily look the same, because it is unlikely
> we can make a sane 1:1 translation of the CLI to REST that makes sense,
> and it would be nice to avoid baking knowledge about the individual
> commands into the client side.
>
>   ceph osd pool create <poolname> <numpgs>
>     vs
>   /osd/pool/?op=create&poolname=foo&numpgs=bar
>
> or whatever.  I know next to nothing about REST API design best practices,
> but I'm guessing it doesn't look like a CLI.
>
> sage

Well we could easily package, say, "mon getmap" into a json
vector-of-strings for transmission as the http payload of the PUT
request, *or* encode them as a simple "s1=mon&s2=getmap", but again, the
data format is so simple that I'm not sure it buys much. We definitely
want all the interpretation centralized in the daemons, I think, so this
is just string marshalling however we choose to do it.