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
IMHO the PathItem definition abuses of the patternProperties feature. Since the list of valid Operation properties is kown and finite, I think that we should use specific properties for each one.
Advantages:
Defined properties help code tools to be smarter and to assist better in coding. If we define those properties specifically, editors which use an improved language completion based on schema will offer a better completion experience - IntelliJ IDEA only offers validation for this, but after improving the schema as per the PR I will attach, it does offer completion for get|put|post... - and this is the reason nº1 for this improvement.
Offers a clearer undesrtanding of the allowed properties when reading the schema, with plain full-matching literals instead of a regex.
Avoids misuse of the patternProperties feature, which IMHO is for the need to allow an open set of constrained properties matching a pattern, or for a defined huge set of properties which can be expressed in a form of a pattern.
Schema is ready for future diferent Operation specifications from different request methods - maybe?
Disadvantages:
Longer schema.
Somewhat repeating code.
Attaching PR immediately.
The text was updated successfully, but these errors were encountered:
axelcostaspena
added a commit
to axelcostaspena/OpenAPI-Specification
that referenced
this issue
Feb 5, 2020
IMHO the PathItem definition abuses of the patternProperties feature. Since the list of valid Operation properties is kown and finite, I think that we should use specific properties for each one.
Advantages:
Disadvantages:
Attaching PR immediately.
The text was updated successfully, but these errors were encountered: