You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of this lib complexity lies with the resolver and expander features, but these ones bear almost no specifics about swagger specs.
Factoring out this complex but battle-tested feature could simplify the move to OAI 3.
IMHO, spec expansion should be refactored along the following lines:
moves the core functionality to a separate package (e.g go-openapi/spec/expander)
make individual spec objects Resolvable and Expandable
expose additional tooling like normalization, etc which could be factorized with go-openapi/flatten which now overlaps with this logics quite a bit
further factorization with analysis to single out common $ref functionality used by spec flattening: complete flattening logics (like name resolution, etc) would remain swagger-specific in analysis, but building blocks such as rebasing refs, replacing refs or schemas could be added to the new common set of tools
Most of this lib complexity lies with the resolver and expander features, but these ones bear almost no specifics about swagger specs.
Factoring out this complex but battle-tested feature could simplify the move to OAI 3.
IMHO, spec expansion should be refactored along the following lines:
e.g. something like equipping spec objects with:
We could provide backward compatibility by leaving methods a the package level.
The text was updated successfully, but these errors were encountered: