Closed devNoiseConsulting closed 3 years ago
Hi @devNoiseConsulting thanks for your support :-), I'm working in another feature but as soon as I finish this one I will review in deep the pull request for now I just have some comments:
The encoding
field that you have added it not correct, you can check on https://editor.swagger.io/?_ga=2.261323918.2075431757.1627116347-1191844855.1621186828, the encoding field should be at same level as the schema
but in this case I think is not too useful as if you read the OpenAPI spec say:
If the property is a primitive, or an array of primitive values, the default Content-Type is text/plain That means for primitive types we should not inform the encoding as the spec already define that are
text/plain
and also say that If the property is a type: string with format: binary or format: base64 (aka a file object), the default Content-Type is application/octet-stream wich is exactly the case of the FIle types because we are already putting thetype: string, format: binary
so the specs say that this means encodingapplication/octet-stream
. So for our use case we really don't need to create theencoding
field in the OpenApi specs.
The require
field that you have added is not correct, you can check on https://editor.swagger.io/?_ga=2.261323918.2075431757.1627116347-1191844855.1621186828, the require field in an object schema is a top level properties with an array of the required fields, I think that is a cool feature but is not worth to implement as is something that normally is ignored by the UI tools that use OpenAPI, I mean, normally they just print the schemas and in this case would be more useful to have an external schema that is a pending feature...
feat: adding x-www-form-urlencoded support feat: form data encoding support refactor: form data accumulator functions move to named functions refactor: improving the mapFormData function