Open DavidBiesack opened 4 years ago
By output, do you mean the representation of the parameter in code samples?
It is not represented anywhere. I'd like to see it in the table that describes the parameters. It is just defined as array[string]
The code samples do not show parameters.
Ok, we're very constrained for space in the tables such as that for parameters. Any ideas for how to represent things would be gratefully received.
My comment about code samples referred to required query parameters, which do get included (in some templates).
We have our own custom templates for parameters, so I can add include {{p.style}}
in our layout.
(We use a simpler two columns, Name in the left column, with optional <br>(**required**)
if required, and Description column that contains the type `
description
constraints like minimum/maximum/readOnly, etc. so we can include the style with the other parameter metadata there.
For the generic case, I suggest augmenting the type column in parameters.def
from array[string]
to include the style after {{p.safeType}}
such as one of
array[string]<br> style: pipeDelimited
array[string]<br> style: spaceDelimited
array[string]<br> style: simple
(maybe omit if it is the default form
style??)
You could insert a newline to keep the column narrower, since the param description
often causes the parameter row to fold over multiple lines anyway.
Hmm, good thoughts. I'd like to avoid leaking direct OpenAPI terminology such as style
and explode
though and make it more descriptive or use an example or links.
If a parameter type is an
array
withcollectionFormat:
(OpenAPI 2.0.0) orstyle:
(OpenAPI 3.0.x), the output does not describe the format or string delimiter (comma for default, or|
forpipes
, etc.)Input OpenAPI 2.0 and 3.0 attached.
openapi2.yaml.txt openapi3.yaml.txt