Open joolfe opened 1 year ago
From my perspective, I want to use this tool for commercial API's used in production by well-known companies that don't produce an OpenAPI spec. For example, Zendesk, Quickbooks, OpenAI. I don't see it as a generic tool to retrofit random legacy API's.
In that context, the schemas are usually very well formed so they can be easily explained and documented to customers. You don't see free form objects and dictionaries (basically user-defined data shapes). Multiple response definitions for the same endpoint are another extreme edge case. Yes it can support it, see anyOf,oneOf, etc.. but it's very uncommon because it's hard to explain to integrators.
Hey, is this issue open?...I had faced the problem of generating schemas for both request and response while I was working in a project and wrote some additional code to fix it. If you guys still want to add the automated schema generating feature I would love to do that. @joolfe
Schemas generation
Summary
The goal of this issue is to try to design a feature that includes the automatic generation of schema objects in the OpenAPI result, also this issue tries to group the different PRs and Issues about this topic as PR237, 183 and 22 and make people understand why this issue is more complicated than expected and why need time to be designed and develop, and time is something that I don't have a lot for an Open Source project, sorry.
Even if always appreciate this is not a request for help, I want to make you understand why this feature needs time, time to read specs, time to design correctly and time to develop and test.
Requirements/Decisions
These are the desired requirements and things to be decided when implementing this feature:
response
that is an array, so we need to decide if will generate multiple schemas or merged one (if supported) Multiple schemasMultiple schemas
For the Response generation we will use the postman object
item[*].response
that is an array so from an Operation we can have multiple generated schemas as a response, the strategy for that should be:200
or201
, or directly2XX
, we don´t want to use the error response schemas.2XX
we can:name
we can add something like the[required]
mark to identify that this one is the chosen one.Considerations about the OpenAPI JSON schema
We are going to focus on OpenAPI 3.0 as is our actual target (but also think that if we evolve the tool to support OpenAPI 3.1 this could change so we should implement it in a way that can be updated when this happens), in OpenAPI docs indicate that the used schema is "an extended subset of the JSON Schema Specification Wright Draft 00", so the OpenAPI schema has his rules on top of the JSON schema Draft 5.
After some reads and here and reviewing the Open API data model specs seems like the main difference between JSON schema and Open API schema is the support and change of some keywords but the main shape is the same, the supported and unsupported keywords are listed here
As summary:
null
is not supported by OpenAPI, in open API this is indicated with the keyword nullabletype
(an item cannot betype: ['string', 'number']
) but can use theoneOf
keywords with similar result but is not exactly an equivalence so we should take care of this.additionalItems
or other complex schema keywords will not be inferred from a JSON object so...nullable
andexample
seems to be inferred from a JSON object example.As summary, we can look for a library that creates a JSON schema from a JSON object example, but needs to avoid the unsupported keywords and also be careful with
nullable
, maybe extending to addexample
and multiple types. Creating the code by ourselves would depend on the result of the library analysis.Using a library
TBD...
Points to review:
oneOf
)TODO