Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Various Rules #16

Closed
32 of 40 tasks
lottamus opened this issue Sep 28, 2018 · 0 comments
Closed
32 of 40 tasks

Implement Various Rules #16

lottamus opened this issue Sep 28, 2018 · 0 comments
Labels
enhancement New feature or request

Comments

@lottamus
Copy link

lottamus commented Sep 28, 2018

Combination of rules taken from sway, swaggerHub, and in-house

API Info

  • API title must be present and non-empty string~~ (included in spec schema)
  • API description must be present and non-empty string
  • API license must be present and non-empty string
  • API contact must be present and non-empty string

Paths

  • Query strings in paths are not allowed.
  • Path parameter declarations do not allow empty names (/path/{} is not valid)
  • (custom) Path parameter definition need a matching parameter declaration
  • (custom) Path parameter declaration need a matching parameter definition
  • (custom) Path strings must be (equivalently) different (Example: /pet/{petId} and /pet/{petId2} are the same)
  • (custom/sibling?) Path parameters must have required: true

Operations

  • operationId must be present and non-empty string
  • (custom/unique?)operationId values must be unique within the API definition
  • Operation summary must be present and non-empty string
  • summary should start with upper case and end with a dot
  • Operation description must be present and non-empty string
  • Operation must have a tag and non-empty string
  • Operation must have one and only one tag
  • (custom/atLeast?) Operation must have at least one 2xx response
  • Operation must have a default response
  • (xor with path extension) Operation cannot have both a in:body and a in:formData` parameter
  • (custom/max?) Operation must have only one in:body parameter
  • (custom/unique?) Operations must have unique (name + in combination) parameters
  • (custom/includes?) Operations with Parameters of in: formData must include application/x-www-form-urlencoded or multipart/form-data in their consumes property

Parameters

  • (custom/sibling/includes?) Default values must be present in enum
  • (skip since we don't allow type file in the ui) Parameters with type: file must have in: formData

Models

  • skip (custom/truthy? but how nested?) All model properties must have examples
  • API must not have local definitions (i.e. only $refs are allowed)
  • skip (custom) Combine models when practical
  • Every model should have a description
  • skip (custom) List all required properties before any optional properties
  • (custom) Declared definition was not used in the document

Security

  • Security requirements must match a security definition
  • (covered by resolver) Security scope definition ${scope} could not be resolved

References

  • (xor?) Sibling values are not allowed alongside $refs
  • (resolver) References must point to existing documents or document fragments
  • $ref paths must begin with #/
  • [covered by resolver] $refs must reference a valid location in the document
  • (pattern) $ref values must be RFC3986-compliant percent-encoded URIs

Schemas

  • Schemas with type: array require a sibling items: field
  • items must be an object
  • The required properties for a Schema Object must be defined in the object or one of its ancestors
  • [PUNT] minimum must be lower value than maximum
  • [PUNT] minLength must be lower value than maxLength
  • [PUNT] minProperties must be lower value than maxProperties
  • Schema type key must be a string
  • Read only properties cannot be marked as required by a schema.
  • \Z anchors are not allowed in regular expression patterns

Naming strategy

  • (custom/pattern?) Enforce naming strategy for paths, parameters and property names: snake_lower | Snake_Upper | camelLower | CamelUpper
  • (custom/pattern?) Avoid using reserved words for model/property names (e.g. error, return, type, input) for paths, parameters and property names
@lottamus lottamus added the enhancement New feature or request label Sep 28, 2018
@casserni casserni changed the title Implement Style Validations Implement Various Validation Rules Oct 1, 2018
@casserni casserni changed the title Implement Various Validation Rules Implement Various Rules Oct 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants