Move to a plugin/command url scheme#148
Conversation
|
Looks like a good idea |
|
We need to come up with whatever scheme works best with swagger2, for documentation and tooling |
|
My understanding is that swagger is a standardized way to specify your api but doesn’t require it to be in a specific way, however I’m happy to be corrected here. Also swagger or at least servant-swagger doesn’t seem particularly useful for the way our servant api currently looks since it only contains one route and doesn’t know about the plugins or the commands that exists so anything that tries to generate documentation from the servant type can’t document plugins and commands. Again I’m happy to be corrected here. For the json stdio I’m currently writing a documentation generator that outputs rst, but I’m happy to later merge that with the swagger docs if they turn out to be useful or to merge our http docs into that. |
Move to a plugin/command url scheme
This changes the format of url requests from
to
Imho this is a more intuitive. The double
fileparameter comes from the fact that the first is the parameter name and the second is the type so that’s nothing specific to the servant protocol.