Skip to main content

Naming Checks

Configuring breaking change checks

Different case conventions can be applied to different parts of your API:

  • Query parameters
  • Header parameters
  • Request properties
  • Response properties

Supported Case Conventions

  • camelCase
  • snake_case
  • param-case
  • PascalCase
ruleset:
- "naming":
queryParameters: param-case
headerParameters: param-case
requestProperties: camelCase
responseProperties: camelCase

Choosing the right strategy to apply these new conventions

Applying casing conventions to an existing OpenAPI specification can be complicated because some parameters and properties already in the specification are not using the correct case. If this is an internal API, and you control the consumers, then maybe it is worth 'fixing' them. If this is a public API other people use, fixing all the cases will absolutely case breaking changes which will upset users.

This is problem is why we built two strategies for your case convention checks to filter out false postiives:

  • applies always - every name in you API spec will be checked against the convention
  • applies added - every new parameter, property or header name will be checked against the convention. The governance applies to only new surface area, but legacy parts of the API are skipped and will not cause errors.