The with-parameters APIs were never actually about being "with
parameters" - it was simply a case of "query parameters" vs. "body
parameters". At the generated client code level, that translates to
"direct method parameters" vs. "parameters in a request struct".
This PR makes the opinionated choice to encourage the PUT/POST, "body
parameters", "request struct" versions over the GET, "query parameters",
"direct method parameters" ones because:
Direct method parameters are hard to support and additions/removals to
later.
The large majority of Vault APIs don't support this duality of
parameter conventions, so choose the one that is what users will
encounter most often in other parts of the Vault API surface.
The
with-parametersAPIs were never actually about being "with parameters" - it was simply a case of "query parameters" vs. "body parameters". At the generated client code level, that translates to "direct method parameters" vs. "parameters in a request struct".This PR makes the opinionated choice to encourage the PUT/POST, "body parameters", "request struct" versions over the GET, "query parameters", "direct method parameters" ones because:
Direct method parameters are hard to support and additions/removals to later.
The large majority of Vault APIs don't support this duality of parameter conventions, so choose the one that is what users will encounter most often in other parts of the Vault API surface.