---
rules:
  openapi-info-description-error:
    description: >-
      Having a detailed description as part of the OpenAPI info object helps
      describe what a collection of paths and operations does for consumers,
      providing a short, concise, and relevant couple of paragraphs about the
      value that is represented as the OpenAPI
    message: Info MUST Have Description
    severity: error
    given: $.info
    then:
      field: description
      function: truthy
  openapi-info-description-eval-error:
    description: >-
      Eval functions MUST not be included in the description of an API, keeping
      descriptions to just the text that is needed, and relying on the rest of
      the OpenAPI to describe what is possible.
    message: Info Description MUST NOT Have Eval Tag
    severity: error
    given: $.info
    then:
      field: description
      function: pattern
      functionOptions:
        notMatch: ^\b(<eval)\b
  openapi-info-description-eval-info:
    description: >-
      Eval functions MUST not be included in the description of an API, keeping
      descriptions to just the text that is needed, and relying on the rest of
      the OpenAPI to describe what is possible.
    message: Info Description Does Not Have Eval Tag
    severity: info
    given: $.info
    then:
      field: description
      function: pattern
      functionOptions:
        match: ^\b(<eval)\b
  openapi-info-description-info:
    description: >-
      Having a detailed description as part of the OpenAPI info object helps
      describe what a collection of paths and operations does for consumers,
      providing a short, concise, and relevant couple of paragraphs about the
      value that is represented as the OpenAPI
    message: Info Has Description
    severity: info
    given: $.info
    then:
      field: description
      function: falsy
  openapi-info-description-length-error:
    description: >-
      Having a restriction on the length of the API description expressed as the
      OpenAPI info description helps provide constraints for consumers when
      adding a description, and keeps portals, landing pages, documentation, and
      discovery results more consistent
    message: Info description MUST be less than 500 characters.
    severity: error
    given: $.info
    then:
      field: description
      function: length
      functionOptions:
        max: 500
  openapi-info-description-script-error:
    description: >-
      Script tags MUST not be included in the description of an API, keeping
      descriptions to just the text that is needed, and relying on the rest of
      the OpenAPI to describe what is possible.
    message: Info Description MUST NOT Have Script Tag
    severity: error
    given: $.info
    then:
      field: description
      function: pattern
      functionOptions:
        notMatch: ^\b(<script)\b
  openapi-info-description-script-info:
    description: >-
      Script tags MUST not be included in the description of an API, keeping
      descriptions to just the text that is needed, and relying on the rest of
      the OpenAPI to describe what is possible.
    message: Info Description Does Not Have Script Tag
    severity: info
    given: $.info
    then:
      field: description
      function: pattern
      functionOptions:
        match: ^\b(<script)\b
  openapi-info-title-error:
    description: >-
      Having a intuitive and helpful title for your API using the OpenAPI info
      title is the first impression you will make on the consumers of your API
    message: Info MUST Have Title
    severity: error
    given: $.info
    then:
      field: title
      function: truthy
  openapi-info-title-info:
    description: >-
      Having a intuitive and helpful title for your API using the OpenAPI info
      title is the first impression you will make on the consumers of your API
    message: Info Has Title
    severity: info
    given: $.info
    then:
      field: title
      function: falsy
  openapi-info-title-length-error:
    description: >-
      Having a limitation on the length of the title for your API helps provide
      constraints for teams naming it, but also keep consistent with other APIs
      from across teams
    message: Info Title MUST Be Less Than 50 Characters
    severity: error
    given: $.info
    then:
      field: title
      function: length
      functionOptions:
        max: 50
  openapi-info-title-upper-case-error:
    description: >-
      Having a consistent casing for the title for your API helps provide
      constraints for teams naming the API, but also keep consistent with other
      APIs from across teams
    message: Info Title Has First Characters Capitalized
    severity: error
    given: $.info.title
    then:
      function: pattern
      functionOptions:
        match: '[A-Z]\w*'
  openapi-info-title-upper-case-info:
    description: >-
      Having a consistent casing for the title for your API helps provide
      constraints for teams naming the API, but also keep consistent with other
      APIs from across teams
    message: Info Title Has First Characters Capitalized
    severity: info
    given: $.info.title
    then:
      function: pattern
      functionOptions:
        notMatch: '[A-Z]\w*'
  openapi-operations-description-info:
    description: >-
      Having a paragraph or two description of each API operation helps API
      consumers understand what is possible with each API request
    message: Operation Has Description
    severity: info
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: description
        function: falsy
  openapi-operations-description-length-error:
    description: >-
      Having a length limitation for each description of each API operation
      helps apply constraints to how you describe your APIs, while helping drive
      consistency across APIs when it comes to search, documentation, and other
      ways an API is made available
    message: Operation Description MUST Be Less Than 250 Characters
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: description
        function: length
        functionOptions:
          max: 250
  openapi-operations-summary-error:
    description: >-
      Having short and intuitive summary for each API operation helps API
      consumers understand what is possible with each API request
    message: Operation MUST Have a Summary
    severity: error
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: summary
        function: truthy
  openapi-operations-summary-info:
    description: >-
      Having short and intuitive summary for each API operation helps API
      consumers understand what is possible with each API request
    message: Operation Has a Summary
    severity: info
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: summary
        function: falsy
  openapi-operations-summary-length-error:
    description: >-
      Apply length constraints to the operation summary helps keep them
      consistent for publishing in documentation
    message: Operation Summary MUST Be Less Than 50 Characters
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: summary
        function: length
        functionOptions:
          max: 50
    type: style
  openapi-operations-summary-period-none-error:
    description: >-
      Operation summaries should not have a period, keeping the primary summary
      for each API as consistent as possible for publishing in documentation
    message: Operation MUST Not Have a Period.
    severity: error
    given: $.paths[*][*].summary
    then:
      function: pattern
      functionOptions:
        notMatch: \.$
  openapi-operations-summary-period-none-info:
    description: >-
      Operation summaries should not have a period, keeping the primary summary
      for each API as consistent as possible for publishing in documentation
    message: Operation Has a Period.
    severity: info
    given: $.paths[*][*].summary
    then:
      function: pattern
      functionOptions:
        match: \.$
  openapi-operations-tags-error:
    description: >-
      Having tags applied to each API operations helps organize and group APIs
      in portals, documentation, search, and other ways in which APIs are made
      available
    message: Operations MUST Have Tags
    severity: error
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: tags
        function: truthy
  openapi-operations-tags-info:
    description: >-
      Having tags applied to each API operations helps organize and group APIs
      in portals, documentation, search, and other ways in which APIs are made
      available
    message: Operations Has Tags
    severity: info
    given: $.paths.*[get,post,patch,put,delete]
    then:
      - field: tags
        function: falsy
  openapi-operations-tags-one-error:
    description: >-
      Having tags applied to each API operations helps organize and group APIs
      in portals, documentation, search, and other ways in which APIs are made
      available
    message: MUST Be At Least One Operation Tag
    given: $.paths.*[get,post,patch,put,delete]
    severity: error
    then:
      field: tags
      function: length
      functionOptions:
        min: 1
  openapi-operations-tags-upper-case-error:
    description: >-
      Having the first letter of each word applied as a tag to API operations
      helps keep a consistent layout when published via search, documentation,
      and other ways APIs are made available
    message: Operation Tag Names MUST Have First Letter in Each Word Capitalized
    severity: error
    given: $.paths.*[get,post,patch,put,delete].tags.*
    then:
      function: pattern
      functionOptions:
        match: '[A-Z]\w*'
  openapi-operations-tags-upper-case-info:
    description: >-
      Having the first letter of each word applied as a tag to API operations
      helps keep a consistent layout when published via search, documentation,
      and other ways APIs are made available
    message: Operation Tag Names Have First Letter in Each Word Capitalized
    severity: info
    given: $.paths.*[get,post,patch,put,delete].tags.*
    then:
      function: pattern
      functionOptions:
        notMatch: '[A-Z]\w*'
  openapi-schema-description-error:
    description: >-
      Schema should have descriptions that provide a narrative of what a schema
      object is for, and how it can be used, leaving examples to demonstrate
      what can actually be expected
    message: Schema MUST Have a Description.
    severity: error
    given: $.components.schemas.*
    then:
      field: description
      function: truthy
  openapi-schema-description-info:
    description: >-
      Schema should have descriptions that provide a narrative of what a schema
      object is for, and how it can be used, leaving examples to demonstrate
      what can actually be expected
    message: Schemas Has a Description.
    severity: info
    given: $.components.schemas.*
    then:
      field: description
      function: falsy
  openapi-schema-description-length-error:
    description: >-
      Schema should have a length limit applied, restricting how long schema
      descriptions can be, helping keep them concise and consistent
    message: Schema Description MUST be Less Than 250 Characters
    severity: error
    given: $.components.schemas.*
    then:
      field: description
      function: length
      functionOptions:
        max: 250
  openapi-schema-names-error:
    description: >-
      Schema names, keeping the naming of them consistent across APIs,
      standardizing how consumers can use in their applications.
    message: Schema Names MUST Exist
    severity: error
    given: $.components.schemas
    then:
      field: '@key'
      function: truthy
  openapi-schema-names-info:
    description: >-
      Schema names, keeping the naming of them consistent across APIs,
      standardizing how consumers can use in their applications.
    message: Schema Names Exist
    severity: info
    given: $.components.schemas
    then:
      field: '@key'
      function: falsy
  openapi-schema-names-length-error:
    description: >-
      Schema should have a length limit applied keeping the names of schema
      consistent across APIs
    message: Schema Names MUST Be Less Than 25 Characters
    severity: error
    given: $.components.schemas
    then:
      field: '@key'
      function: length
      functionOptions:
        max: 25