The method info part is not generic after all.
(Makes it easier to test different representations of
ApiHandler without having to adapt all the other methods as
well.)
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
This way we do not need to carry the body type into the CLI
router and can instead just require the body to be
Into<Bytes>.
This also makes more sense, because previously a method
could in theory implement multiple ApiMethodInfo types with
different bodies which seems pointless.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
In order to get parameters from the command line into the
API we need to get them into a json value, so that we can
pass it down the handler which deserializes them into their
real type and runs verifications.
For this we need to define how the type is going to be
converted into a json Value. We cannot simply use
Deserialize as that would for instance require quotes
around strings. So instead, we have a ParseCli trait, which
is a nop (direct serde_json::Value::String()) for string
types, and uses .parse() (the std::str::FromStr trait) for
everything else.
Currently this uses a `default fn` as an example of the
specialization feature, but I'll probably remove this and
use yet another mass-impl macro since there isn't much
activity on that feature's issue tracker. (The issue itself
seems to be outdated ...
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
Since we already know we'll want to be using hyper::Body and
bytes::Bytes as API output, we need to allow making routers
for each kind.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We'll have a separate router for the command line, so the
http router won't live in the root module.
It is still exported at the root level, though, via
proxmox::api::Router.
Also move ApiType into api_type.rs, makes more sense.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
