API Evangelist API Evangelist
API Learnings
APIs
API Governance
API Solutions
API Discovery
API Building Blocks
API Evangelist LLC
API Learnings
APIs
API Governance
API Solutions
API Discovery
API Building Blocks
API Evangelist LLC

Need help?

Contact us
Naftiko
Sponsored by Naftiko

Naftiko Signals
Sponsored by Naftiko Signals

OpenAPI Rules

This page is dedicated to outlining the API governance rules for managing individual APIs. The Spectral rules format, applicable to any JSON or YAML schema, is used here to identify patterns and anti-patterns relevant to governing HTTP APIs.

OpenAPI provides a way to define all of the technical details for the surface area of any individual APIs, and these rules represent the common patterns that will matter when it comes to producing and consuming APIs already in production, or are being developed.

The OpenAPI Specification

The OpenAPI Specifications provide a formal standard for describing HTTP APIs. This allows people to understand how an API works, how a sequence of APIs work together, generate client code, create tests, apply design standards, and much, much more.

openapi: 3.1.0
  info:
    title: Example API
    description: |
      API for finding and booking train trips across Europe.
    version: 1.0.0

OpenAPI Info Rules

These are the Spectral rules which can be used to lint for the common information applied within an OpenAPI, helping improve discovery and onboarding with APIs.

OpenAPI - Having an info object provides much of the metadata needed for the collection of APIs described in an OpenAPI
OpenAPI Title - 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
OpenAPI Title Upper Case - 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
OpenAPI Description Eval Tag - 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.
OpenAPI 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
OpenAPI Description Script Tag - 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.

OpenAPI External Docs

Blah Blah Blah

openapi: 3.1.0
  info:
    title: Example API
    description: |
      API for finding and booking train trips across Europe.
    contact:
      name: API Support
      url: https://www.example.com/support
      email: [email protected]
OpenAPI External Docs - Having an external documentation link present in the OpenAPI for an API, makes it easy for API producers or consumers to find their way to the rest of the operations and resources available around an API

OpenAPI Info Contact Rules

These are the Spectral rules which can be used to lint for the contact information applied within an OpenAPI, helping improve feedback and support with APIs.

openapi: 3.1.0
  info:
    title: Example API
    description: |
      API for finding and booking train trips across Europe.
    contact:
      name: API Support
      url: https://www.example.com/support
      email: [email protected]
OpenAPI Contact - Having a contact object associated with the technical contract ensures that anyone who comes across the API has someone to contact and get more information
OpenAPI Contact Name - Having a contact name associated with the technical contract ensures that anyone who comes across the API knows who to contact
OpenAPI Contact Email - Having a contact email address associated with the technical contract ensures that anyone who comes across the API has someone to email and get more information
OpenAPI Contact Url - Having a contact url associated with the technical contract ensures that anyone who comes across the API knows where to go to contact someone

OpenAPI Versioning

These are multiple properties within an OpenAPI for versioning and helping manage change, which can be linted and governed for consistency.

openapi: 3.1.0
  info:
    title: Example API
    description: |
      API for finding and booking train trips across Europe.
    contact:
      name: API Support
      url: https://www.example.com/support
      email: [email protected]                         
    version: 1.0.0
OpenAPI Version - Publishing a version for your OpenAPI technical contract helps you communicate change with consumers using Semantic or date-based versioning published to the info version property
OpenAPI Version Semantic - Publishing a version for your OpenAPI technical contract helps you communicate change with consumers using Semantic versioning published to the info version property
OpenAPI Version Date - Publishing a version for your OpenAPI technical contract helps you communicate change with consumers using date-based versioning published to the info version property

OpenAPI Tags

Blah Blah Blah.

openapi: 3.1.0
  info:
    title: Example API
    description: |
      API for finding and booking train trips across Europe.
    contact:
      name: API Support
      url: https://www.example.com/support
      email: [email protected]                         
    version: 1.0.0
OpenAPI Tags Description - Tags used as part of an OpenAPI should have descriptions, providing more of a narrative behind what a tag means when it is applied to an API
OpenAPI Tags Name - Tags used as part of an OpenAPI should have names, providing a simple key word or phrase that represents the tag being applied to APIs
OpenAPI Tags Object - There needs to be a central tags object applied to the OpenAPI, providing central tags that can be applied across all operations within an OpenAPI

OpenAPI Paths

There are several ways in which the paths of APIs can be linted and govern for common patterns and anti-patterns, and these are the rules currently for governing this area.

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
OpenAPI No Api In Path - There are very few situations where you actually want the acronym API in the path of your API, only when it is a resource.
OpenAPI Path Kebab Case - The query delimiter should not be included as part of any API path.
OpenAPI No Api In Path - The query delimiter should not be included as part of any API path.
OpenAPI No Path Trailing Slash - It is common to be explicit and consistent about whether or not to have a trailing slack on each API path
OpenAPI Version In Path - The majority of public APIs available on the Web today put the major version of the API as part of the path for each API
OpenAPI Path Declarations - There must be a paths property and have paths declared, providing the minimum viable definition for an API.

OpenAPI Operations

These are the rules for managing individual operations, governing the metadata and other details of the operations in a consistent manner.

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Operations Summary - Having short and intuitive summary for each API operation helps API consumers understand what is possible with each API request
OpenAPI Operations Summary Period - Operation summaries should not have a period, keeping the primary summary foreach API as consistent as possible for publishing in documentation.
OpenAPI Operations Description - Having a paragraph or two description of each API operation helps API consumers understand what is possible with each API request
OpenAPI Operations Operation Ids - Operation identifiers provide a unique way to identify each individual API, which then used for SDK generation and other automation
OpenAPI Operations Operation Ids Camel Case - Operation identifiers provide a unique way to identify each individual API, and requiring them to have consistent casing reduces friction when generating SDKs and automating around APIs
OpenAPI Operations Operation Ids Special Characters - Operation identifiers provide a unique way to identify each individual API, and requiring them to have consistent casing reduces friction when generating SDKs and automating around APIs.
OpenAPI Operations Tags - 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
OpenAPI Operations Tags Upper Case - 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
OpenAPI Operation Security Definitions - Each API operation should have a security definition referencing the central security scheme express for an OpenAPI
OpenAPI Operation Security Definitions API Keys - Each API operation should have a security definition referencing the central security scheme express for an OpenAPI referencing apiKeys property.

OpenAPI Paramters

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Parameters Componentized - Having all parameters using the central OpenAPI components parameters object helps increase the reusability of parameters across API operations, but it also help standardize parameter across all APIs
OpenAPI Components Parameters - Having a components parameters object allows all parameters used across an API to be centralized, allowing for reuse and easier governance of the parameters used to configure API requests
OpenAPI Components Parameters Name - Providing a simple, intuitive, and consistent names for your parameters helps make it easier for API consumers to understand how they are able to configure their API requests
book-open
OpenAPI Parameters Optional Examples - Optional parameters should include examples to support API mocking, testing, and documentation. While not strictly required, examples help consumers understand the range of acceptable values.
globe
OWASP API7 2023 Concerning URL Parameter - Using external resource URLs based on user input for webhooks, file fetching, custom SSO, URL previews, or redirects can lead to Server Side Request Forgery (SSRF) and other security issues.
OpenAPI Components Parameters In - Providing an in property for parameters gets explicit about whether a parameter is in the path, query, or a header, making it clear to consumers where they can configure their request
OpenAPI Components Parameters Required - Providrequiredg an required property for parameters gets explicit about whether a parameter is required the path, query, or a header, makrequiredg it clear to consumers where they can configure their request.
OpenAPI Components Parameters Casing Camel - Providing parameters with consistent naming helps make it easier for API consumers to understand how they are able to configure their API requests
OpenAPI Components Parameters Description - Having a parameters description provides more depth to what a parameter does and will be displayed via documentation, and other tooling used across the API lifecycle
OpenAPI Components Parameters Example - Parameters must always possess a example to help define the format and shape of the parameter, setting expections with consumers about what should be passed in
OpenAPI Components Parameters Schema - Parameters must always possess a schema to help define the format and shape of the parameter, setting expections with consumers about what should be passed in
OpenAPI Components Parameters Schema Ref - Parameters must always use a schema reference that utilizes reusable schema that are defined as part of a centralized schema components library
OpenAPI Components Parameters Schema Type - Parameters must always have their schema type defined, being precise about what type of data can be inputted and used to configure an API request
OpenAPI Components Parameters Schema Type String Minlength - Parameters that are of the string schema type must have their minimum value set, defining the shape of parameter data passed in with a request
OpenAPI Components Parameters Schema Type String Maxlength - Parameters that are of the type string schema type must have their maximum value set, defining the shape of parameter data passed in with a request
OpenAPI Components Parameters Schema Type String Pattern - Parameters that are of the string schema type must have a pattern set, using a regex to define the shape of parameter data passed in with a request
OpenAPI Components Parameters Schema Type Integer Minimum - Parameters that are of the integer schema type must have their minimum value set, defining the shape of parameter data passed in with a request
OpenAPI Components Parameters Schema Type Integer Maximum - Parameters that are of the integer schema type must have their maximum value set, defining the shape of parameter data passed in with a request
OpenAPI Components Parameters Schema Items Array - Parameters that are of an array type should always have the items defined, being explicit about what is continued as part of the array
OpenAPI Components Parameters Enum - Providing enums for your parameters helps reduce errors and keeps the inputs for your API requests more consistent for consumers
OpenAPI Components Parameters Enum Casing - Keeping parameters enumerator casing consistent across APIs helps reduce confusion by consumers, and can keep aligned with services and applications putting an API to work

OpenAPI Request Bodies

Some HTTP Methods can have request bodies as part of each individual operation, and there are a number of rules that can be used to govern the bodies for each request.

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Method DELETE Error - DELETE HTTP methods should be available.
OpenAPI Method DELETE - DELETE HTTP methods should be available.
OpenAPI Method GET Error - GET HTTP methods should be available.
OpenAPI Method GET - GET HTTP methods should be available.
OpenAPI Method POST Error - POST HTTP methods should be available.
OpenAPI Method POST - POST HTTP methods should be available.
OpenAPI Method PUT Error - PUT HTTP methods should be available.
OpenAPI Method PUT - PUT HTTP methods should be available.
OpenAPI No Request Body On Get - GET HTTP methods should not have a request body, keeping API requests compliant with the HTTP standard
edit-3
OpenAPI Request Bodies PATCH Merge Patch - PATCH operations should use application/merge-patch+json content type as defined in RFC 7396, providing a standardized approach for partial updates to resources.
OpenAPI Request Body On Post - POST HTTP methods can have a request body, providing a structured payload for configuring each API request
OpenAPI Request Body On Put - PUT HTTP methods can have a request body, providing a structured payload for configuring each API request
OpenAPI No Request Body On Delete - DELETE HTTP methods should not have a request body, keeping API requests compliant with the HTTP standard
OpenAPI Request Bodies Description - It is helpful to provide a description for request bodies, providing a simple explanation of what can be configured as part of the request payload
OpenAPI Request Bodies Required Property - It is important to be explicit about whether or not the request body for an API operation is required or not
OpenAPI Request Body Content On Post - POST requests with a request body should have content defined, providing more detail on what is contained within the API request body
OpenAPI Request Body Content On Put - PUT requests with a request body should have content defined, providing more detail on what is contained within the API request body
OpenAPI Request Body Have Application Json - Request bodies use the application/json media type to encode the request payload is a common data format
OpenAPI Request Body Have Application X Www Form Url Encoded - Request bodies use the application/x-www-form-urlencoded media type to encode the request payload is a common data format
OpenAPI Request Body Have Examples - POST, PUT, and PATCH request bodies should have examples, providing one or more examples of what should be submitted for different types of requests
OpenAPI Request Body Have Examples Ref - POST, PUT, and PATCH request bodies should have examples using references to centralized component examples, providing one or more examples of what should be submitted for different types of requests

OpenAPI GET Responses

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Response Get 200 Status Code - GET responses should have a 200 success HTTP status codes, communicating a successful response to consumers
OpenAPI Response Get 200 Description - GET 200 success HTTP status codes should have a description, describing what an API consumer can expect as a result
OpenAPI Response Get 200 Content - GET 200 success HTTP status codes should have content property that provides the ability to describe the response content
OpenAPI Response Get 200 Media Type - GET 200 success HTTP status codes have a application/json media type, standardizing the response payload returned for a successful response
OpenAPI Response Get 200 Media Type Examples - GET 200 success HTTP status codes have examples to show one or many examples of responses for different types of API requests
OpenAPI Response Get 200 Media Type Examples Ref - GET 200 success HTTP status codes have example references to show one or many examples of responses for different types of API requests
OpenAPI Response Get 400 Status Code - GET responses should have a 400 not found HTTP status code, communicating nothing was found to consumers
OpenAPI Response Get 401 Status Code - GET responses should have a 401 unauthorized HTTP status code, communicating that consumers do not have access
OpenAPI Response Get 403 Status Code - GET responses should have a 403 forbidden HTTP status code, communicating that consumers are not allowed to access
OpenAPI Response Get 404 Status Code - GET responses should have a 404 not found HTTP status code, communicating that nothing was found to consumers
OpenAPI Response Get 429 Status Code - GET responses should have a 429 too many requests HTTP status code, communicating a consumer has made too may requests
OpenAPI Response Get 500 Status Code - GET responses should have a 500 internal server erorr HTTP status code, communicating the API had a problem to consumers

OpenAPI POST Responses

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Response Post 201 Status Code - POST responses should have a 201 success HTTP status codes, communicating a success created response to consumers
OpenAPI Response Post 201 Description - POST 201 success HTTP status codes should have a description, describing what an API consumer can expect as a result
OpenAPI Response Post 201 Content - POST 201 success HTTP status codes should have content property that provides the ability to describe the response content
OpenAPI Response Post 201 Media Type - POST 201 success HTTP status codes have a application/json media type, standardizing the response payload returned for a successful response
OpenAPI Response Post 201 Examples Ref - POST 201 success HTTP status codes have example references to show one or many examples of responses for different types of API requests
OpenAPI Response Post 201 Media Type Examples - POST 201 success HTTP status codes have examples to show one or many examples of responses for different types of API requests
OpenAPI Response Post 400 Status Code - POST responses should have a 400 not found HTTP status code, communicating nothing was found to consumers
OpenAPI Response Post 401 Status Code - POST responses should have a 401 unauthorized HTTP status code, communicating that consumers do not have access
OpenAPI Response Post 403 Status Code - POST responses should have a 403 forbidden HTTP status code, communicating that consumers are not allowed to access
OpenAPI Response Post 404 Status Code - POST responses should have a 404 not found HTTP status code, communicating that nothing was found to consumers
OpenAPI Response Post 429 Status Code - POST responses should have a 429 too many requests HTTP status code, communicating a consumer has made too may requests
OpenAPI Response Post 500 Status Code - POST responses should have a 500 internal server erorr HTTP status code, communicating the API had a problem to consumers

OpenAPI PUT Responses

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Response Put 204 Status Code - PUT responses should have a 204 success HTTP status codes, communicating a success created response to consumers
OpenAPI Response Put 400 Status Code - PUT responses should have a 400 not found HTTP status code, communicating nothing was found to consumers
OpenAPI Response Put 401 Status Code - PUT responses should have a 401 unauthorized HTTP status code, communicating that consumers do not have access
OpenAPI Response Put 403 Status Code - PUT responses should have a 403 forbidden HTTP status code, communicating that consumers are not allowed to access
OpenAPI Response Put 404 Status Code - PUT responses should have a 404 not found HTTP status code, communicating that nothing was found to consumers

OpenAPI DELETE Responses

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Response Delete 204 Status Code Error - DELETE responses should have a 204 success HTTP status codes, communicating a success created response to consumers
OpenAPI Response Delete 204 Status Code - DELETE responses should have a 204 success HTTP status codes, communicating a success created response to consumers
OpenAPI Response Delete 400 Status Code - DELETE responses should have a 400 not found HTTP status code, communicating nothing was found to consumers
OpenAPI Response Delete 400 Schema Ref - DELETE 400 bad request HTTP status codes have a schema references to standardize the response payload returned for the error response
OpenAPI Response Delete 401 Status Code - DELETE responses should have a 401 unauthorized HTTP status code, communicating that consumers do not have access
OpenAPI Response Delete 401 Schema Ref - DELETE 401 unauthorized HTTP status codes have a schema references to standardize the response payload returned for the error response
OpenAPI Response Delete 403 Status Code - DELETE responses should have a 403 forbidden HTTP status code, communicating that consumers are not allowed to access
OpenAPI Response Delete 403 Schema Ref - DELETE 403 forbidden HTTP status codes have a schema references to standardize the response payload returned for the error response
OpenAPI Response Delete 404 Status Code - DELETE responses should have a 404 not found HTTP status code, communicating that nothing was found to consumers
OpenAPI Response Delete 404 Schema Ref - DELETE 404 not found HTTP status codes have a schema references to standardize the response payload returned for the error response
OpenAPI Response Delete 429 Status Code - DELETE responses should have a 429 too many requests HTTP status code, communicating a consumer has made too may requests
OpenAPI Response Delete 429 Schema Ref - DELETE 429 too many requests HTTP status codes have a schema references to standardize the response payload returned for the error response
OpenAPI Response Delete 500 Status Code - DELETE responses should have a 500 internal server erorr HTTP status code, communicating the API had a problem to consumers
OpenAPI Response Delete 500 Schema Ref - DELETE 500 internal server error requests HTTP status codes have a schema references to standardize the response payload returned for the error response

OpenAPI Schema

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Schema Names - Schema names, keeping the naming of them consistent across APIs, standardizing how consumers can use in their applications.
OpenAPI Schema Names Pascal Case - Schema names are pascal case, keeping the naming of them consistent across APIs, standardizing how consumers can use in their applications
type
OpenAPI Schema Names Snake Case - Schema component keys should use snake_case naming convention for consistency, particularly in APIs that follow Python or Ruby conventions.
OpenAPI Schema 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
OpenAPI Schema Type - Schema should have a type defined, being explicit about type of data a schema describes and can be used to validate, helping standardize the type of data being made available
OpenAPI Schema Required - Schema should have a required property defined, being explicit about which properties have to be included with the schema when it is used as part of a request or response

OpenAPI Schema Properties

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Schema Properties - Schema has properties, providing more detail regarding the structure of each schema being applied as part of a request or a response
OpenAPI Schema Properties Names Camel Case - Schema property names are camel case, providing consistent casing across all the schema properties used by APIs
OpenAPI Schema Properties Descriptions - Schema properties should have descriptions that provide a narrative of the property contains, and how it can be used
OpenAPI Schema Properties String Minlength - Schema properties that are of the string type have the min length applied defining the shape of the property
OpenAPI Schema Properties String Maxlength - Schema properties that are of the string type have the max length applied defining the shape of the property
OpenAPI Schema Properties Array Items - Schema properties that are of the type array must have an items property defined
OpenAPI Schema Properties Array Minitems - Schema properties that are of the type array should have a min items property defined
OpenAPI Schema Properties Array Maxitems - Schema properties that are of the type array should have a max items property defined
OpenAPI Schema Properties Enum - Schema property has enumerators, providing consistent values chosen by consumers when making requests

OpenAPI Components

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Components Examples - Utilizing an example object in the centralized OpenAPI components library helps make examples reusable across API requests and responses
OpenAPI Components Headers - Utilizing the headers object in the centralized OpenAPI components library helps make headers reusable across API requests and responses
OpenAPI Components Responses - Utilizing the responses object in the centralized OpenAPI components library helps make responses reusable across API requests
OpenAPI Components Schemas - Utilizing the schema object in the centralized OpenAPI components library helps make schema reusable across API requests and responses

OpenAPI Component Headers

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Components Headers Rate Limit - Utilizing centralized headers rate limits allows you to reuse headers across all API requests and responses, enabling a more organized approach to handling the transport and rate limits applied consistently across all APIs.
OpenAPI Components Headers Retry After - Utilizing centralized retry after headers allows you to reuse headers across all API requests and responses, enabling a more organized approach to handling the transport and rate limiting applied consistently across all APIs.

OpenAPI Component Responses

Blah Blah Blah

openapi: 3.1.0
info:
  title: Example API
  description: |
    API for finding and booking train trips across Europe.
  contact:
    name: API Support
    url: https://www.example.com/support
    email: [email protected]                         
  version: 1.0.0
paths:
  /stations:
    get:
      summary: Get a list of train stations
      description: Returns a list of all train stations in the system.
      operationId: get-stations
      tags:
        - Stations
OpenAPI Components Responses Bad Request - Having a bad request responses in the centralized OpenAPI components library helps make error responses reusable across API requests
OpenAPI Components Responses Conflict - Having a conflict responses in the centralized OpenAPI components library helps make error responses reusable across API requests
OpenAPI Components Responses Forbidden - Having a forbidden responses in the centralized OpenAPI components library helps make error responses reusable across API requests
OpenAPI Components Responses Internal Server Error - Having a internal server error responses in the centralized OpenAPI components library helps make error responses reusable across API requests
OpenAPI Components Responses Not Found - Having a not found error responses in the centralized OpenAPI components library helps make error responses reusable across API requests
OpenAPI Components Responses Too Many Requests - Having a too many requests error responses in the centralized OpenAPI components library helps make error responses reusable across API requests
OpenAPI Components Responses Unauthorized - Having a unauthorized error responses in the centralized OpenAPI components library helps make error responses reusable across API requests