Bring Wendy upto date with the new Bob

[lispyclouds]

With the complete overhaul of Bob and its REST API. wendy is yet to be updated.
Apart from this since the fact that Bob exposes its api.yaml, Wendy's CLI can be fully generated from the OpenAPI spec on the fly resulting in a smarter, simpler codebase.

REST API of Bob: https://bob-cd.github.io/pages/api-reference.html

[TimoKramer]

How would you fetch the api.yaml from the server? would you create a client? but in a CLI program that client will need to be recreated everytime because the CLI process doesn't persist.
Fetch the api.yaml everytime? or store the api.yaml in a local cache?

[lispyclouds]

I would say fetching the API all the time for starters is easy to begin with. Later we can make a request and cache it for sometime. Eventually when bob starts versioning the API we can cache till the version changes?
Fetching the API yaml all the time shouldn't be that much of a perf issue for now I think.

[lispyclouds]

Also I have some ideas on how to make the CLI parser:

• stuff after the first / become the category in the path
• The REST method becomes the subcommand: GET -> ls, POST -> create, DELETE -> delete etc
• All the things following the next /s are --options
• All the path {params} are values to it
• Whereever POST bodies are needed we can pipe: cat pipeline.json | wendy pipeline create --group dev --name test

What say?

[TimoKramer]

I think the parsing could work that way.
So Wendy would know a connection where to speak to bob and then when I enter wendy --help it would fetch it and show me the options?

[lispyclouds]

Yeah, by default it should assume http://localhost:7777

[TimoKramer]

• parse the yaml from /api.yaml
• transform yaml to cli-matic config
• interpolate args to url path and query params
• read body from stdin
• send requests to apiserver

[TimoKramer]

I made the body a slurp parameter now. Will investigate how to use stdin for future:

l3nz/cli-matic#28