Implement CLI request / accept handling #5
Description
We want to support requests through the CLI which will be handled by scripts as if requesting the 'text' accept type. We will not actually do anything like request header processing for the CLI; that's what the HTTP-REST handlers are for, and if you need that, then 'curl' is your CLI.
The 'con' CLI:
- Assumes all con requests are to be handled by the local host. If you need to invoke con commands on another host, use ssh. While we have not ruled it out, there is no plan to support targeting other hosts in the con syntax.
- Data is NOT necessarily local. Resource implementations are free to make non-local requests to other services.
- Does not do security checks. Con requests are always executed as if by root. Future versions very well may parallel the web auth models. Most likely, the CLI requests will remain simple and privileged on the idea that you can always just block access to it and force requests through HTTP. Again, curl makes a better CLI for 'full blown REST from the command line.
- Responds simply and makes no attempt to emulate the whole, generally more complex JSON response. The goal is to give as little as necessary for a human to understand, whereas JSON is more about optimizing for machines. If a user wants the JSON data, they can request the format through JSON.
- The 'response-fields' parameter is processed by JSON requests and issues a warning for text responses.
- Provides aliases for common parameters. E.g., 'response-form=json' can be specified via 'f=json'.
- Provides CLI verbs that imply an HTTP verb, and may imply required and implied parameters. E.g., 'con requests start ' requires that 'work-branch' be provided and implies the operators configured user ID as the assignee. Implied parameters can always be overridden.
- All requests accept 'verbosity=<quiet|normal|talkative|debug>' (or 'v=...'). Will often have no effect. In general, 'normal' is 'scriptable' unless we really want to provide additional information. 'quiet' is meant to be unix-bash scriptable, and 'talkative' provides interesting details. Debug talks about internal stuff. Endpoints may accept accept additional parameters that modify output though for the most part we would like to NOT add additional stuff to the CLI unless there's a particularly compelling case. You can always use the REST and no problem to mix and match REST and con requests.
Implements: #4