Overlay Specification v1.0.0

Version 1.0.0

More details about this document
This version:
https://spec.openapis.org/overlay/v1.0.0.html
Latest published version:
https://spec.openapis.org/overlay/latest.html
Latest editor's draft:
https://github.com/OAI/Overlay-Specification/
Editors:
Darrel Miller
Greg Dennis
Kevin Swiber
Lorna Mitchell
Mike Kistler
Mike Ralphson
Ron Ratovsky
Participate
GitHub OAI/Overlay-Specification
File a bug
Commit history
Pull requests

What is the Overlay Specification?

The Overlay Specification is an extension or companion to the [OpenAPI] specification. An Overlay describes a set of changes to be applied or “overlaid” onto an existing OpenAPI description.

The main purpose of the Overlay Specification is to provide a way to repeatably apply transformations to one or many OpenAPI descriptions. Use cases include updating descriptions, adding metadata to be consumed by another tool, or removing certain elements from an API description before sharing it with partners. An Overlay may be specific to a single OpenAPI description, or be designed to apply the same transform to any OpenAPI description.

Status of This Document

The source-of-truth for this specification is the HTML file referenced above as This version.

1. Overlay Specification

1.1 Version 1.0.0

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document is licensed under The Apache License, Version 2.0.

2. Introduction

The Overlay Specification is an extension or companion to the [OpenAPI] specification. An Overlay describes a set of changes to be applied or “overlaid” onto an existing OpenAPI description.

The main purpose of the Overlay Specification is to provide a way to repeatably apply transformations to one or many OpenAPI descriptions. Use cases include updating descriptions, adding metadata to be consumed by another tool, or removing certain elements from an API description before sharing it with partners. An Overlay may be specific to a single OpenAPI description, or be designed to apply the same transform to any OpenAPI description.

3. Definitions

3.1 Overlay

An Overlay is a JSON or YAML structure containing an ordered list of Action Objects that are to be applied to the target document. Each Action Object has a target property and a modifier type (update or remove). The target property is a JSONPath query expression that identifies the elements of the target document to be updated and the modifier determines the change.

4. Specification

4.1 Versions

The Overlay Specification is versioned using a major.minor.patch versioning scheme. The major.minor portion of the version string (for example 1.0) SHALL designate the Overlay feature set. .patch versions address errors in, or provide clarifications to, this document, not the feature set. The patch version SHOULD NOT be considered by tooling, making no distinction between 1.0.0 and 1.0.1 for example.

Note: Version 1.0.0 of the Overlay Specification is being released after spending some time in draft, and after being adopted by tool providers. Check with your tool provider for the details of what is supported in each tool.

4.2 Format

An Overlay document that conforms to the Overlay Specification is itself a JSON object, which may be represented either in JSON or YAML format.

All field names in the specification are case sensitive. This includes all fields that are used as keys in a map, except where explicitly noted that keys are case insensitive.

In order to preserve the ability to round-trip between YAML and JSON formats, YAML version 1.2 is RECOMMENDED along with some additional constraints:

4.3 Document Structure

It is RECOMMENDED that the root Overlay document be named: overlay.json or overlay.yaml.

4.4 Relative References in URLs

Unless specified otherwise, all properties that are URLs MAY be relative references as defined by [RFC3986] Section 4.2. Unless specified otherwise, relative references are resolved using the URL of the referring document.

4.5 Schema

In the following description, if a field is not explicitly REQUIRED or described with a MUST or SHALL, it can be considered OPTIONAL.

4.5.1 Overlay Object

This is the root object of the Overlay.

4.5.1.1 Fixed Fields
Field Name Type Description
overlay string REQUIRED. This string MUST be the version number of the Overlay Specification that the Overlay document uses. The overlay field SHOULD be used by tooling to interpret the Overlay document.
info Info Object REQUIRED. Provides metadata about the Overlay. The metadata MAY be used by tooling as required.
extends string URL to the target document (such as an [OpenAPI] document) this overlay applies to. This MUST be in the form of a URL.
actions [Action Object] REQUIRED An ordered list of actions to be applied to the target document. The array MUST contain at least one value.

This object MAY be extended with Specification Extensions.

The list of actions MUST be applied in sequential order to ensure a consistent outcome. Actions are applied to the result of the previous updates. This enables objects to be deleted in one update and then re-created in a subsequent update, for example.

The extends property can be used to indicate that the Overlay was designed to update a specific [OpenAPI] document. Where no extends is provided it is the responsibility of tooling to apply the Overlay documents to the appropriate OpenAPI document(s).

4.5.2 Info Object

The object provides metadata about the Overlay. The metadata MAY be used by the clients if needed.

4.5.2.1 Fixed Fields
Field Name Type Description
title string REQUIRED. A human readable description of the purpose of the overlay.
version string REQUIRED. A version identifer for indicating changes to the Overlay document.

This object MAY be extended with Specification Extensions.

4.5.3 Action Object

This object represents one or more changes to be applied to the target document at the location defined by the target JSONPath expression.

4.5.3.1 Fixed Fields
Field Name Type Description
target string REQUIRED A JSONPath expression selecting nodes in the target document.
description string A description of the action. [CommonMark] syntax MAY be used for rich text representation.
update Any If the target selects an object node, the value of this field should be an object with the properties and values to merge with the node. If the target selects an array, the value of this field should be an entry to append to the array. This field has no impact if the remove field of this action object is true.
remove boolean A boolean value that indicates that the target object is to be removed from the the map or array it is contained in. The default value is false.

The result of the target JSONPath expression must be zero or more objects or arrays (not primitive types or null values).

To update a primitive property value such as a string, the target expression should select the containing object in the target document and update should contain an object with the property and its new primitive value.

Primitive-valued items of an array cannot be replaced or removed individually, only the complete array can be replaced.

The properties of the update object MUST be compatible with the target object referenced by the JSONPath key. When the Overlay document is applied, the properties in the merge object replace properties in the target object with the same name and new properties are appended to the target object.

This object MAY be extended with Specification Extensions.

4.6 Examples

4.6.1 Structured Overlays Example

When updating properties throughout the target document it may be more efficient to create a single Action Object that mirrors the structure of the target document. e.g.

overlay: 1.0.0
info:
  title: Structured Overlay
  version: 1.0.0
actions:
  - target: '$' # Root of document
    update:
      info:
        x-overlay-applied: structured-overlay
      paths:
        '/':
          summary: 'The root resource'
          get:
            summary: 'Retrieve the root resource'
            x-rate-limit: 100
        '/pets':
          get:
            summary: 'Retrieve a list of pets'
            x-rate-limit: 100
      components:
      tags:

4.6.2 Targeted Overlays

Alternatively, where only a small number of updates need to be applied to a large document, each Action Object MAY be more targeted.

overlay: 1.0.0
info:
  title: Targeted Overlays
  version: 1.0.0
actions:
  - target: $.paths['/foo'].get
    update:
      description: This is the new description
  - target: $.paths['/bar'].get
    update:
      description: This is the updated description
  - target: $.paths['/bar']
    update:
      post:
        description: This is an updated description of a child object
        x-safe: false

4.6.3 Wildcard Overlays Examples

One significant advantage of using the JSONPath syntax is that it allows referencing multiple nodes in the target document. This would allow a single update object to be applied to multiple target objects using wildcards and other multi-value selectors.

overlay: 1.0.0
info:
  title: Update many objects at once
  version: 1.0.0
actions:
  - target: $.paths.*.get
    update:
      x-safe: true
  - target: $.paths.*.get.parameters[?@.name=='filter' && @.in=='query']
    update:
      schema:
        $ref: '/components/schemas/filterSchema'

4.6.4 Array Modification Examples

Array elements MAY be deleted using the remove property. Use of array indexes to remove array items should be avoided where possible as indexes will change when items are removed.

overlay: 1.0.0
info:
  title: Add an array element
  version: 1.0.0
actions:
  - target: $.paths.*.get.parameters
    update:
      name: newParam
      in: query
overlay: 1.0.0
info:
  title: Remove a array element
  version: 1.0.0
actions:
  - target: $.paths.*.get.parameters[?@.name == 'dummy']
    remove: true

4.6.5 Traits Examples

By annotating a target document (such as an [OpenAPI] document) using specification extensions such as x-oai-traits, the author of the target document MAY identify where overlay updates should be applied.

openapi: 3.1.0
info:
  title: API with a paged collection
  version: 1.0.0
paths:
  /items:
    get:
      x-oai-traits: ['paged']
      responses:
        200:
          description: OK

With the above OpenAPI document, the following Overlay document will apply the necessary updates to describe how paging is implemented, where that trait has been applied.

overlay: 1.0.0
info:
  title: Apply Traits
  version: 1.0.0
actions:
  - target: $.paths.*.get[?@.x-oai-traits.paged]
    update:
      parameters:
        - name: top
          in: query
          # ...
        - name: skip
          in: query
          # ...

This approach allows inversion of control as to where the Overlay updates apply to the target document itself.

4.7 Specification Extensions

While the Overlay Specification tries to accommodate most use cases, additional data can be added to extend the specification at certain points.

The extension properties are implemented as patterned fields that are always prefixed by "x-".

Field Pattern Type Description
^x- Any Allows extensions to the Overlay Specification. The field name MUST begin with x-, for example, x-internal-id. Field names beginning x-oai- and x-oas- are reserved for uses defined by the OpenAPI Initiative. The value MAY be null, a primitive, an array or an object.

The extensions may or may not be supported by the available tooling, but those may be extended as well to add requested support (if tools are internal or open-sourced).

A. Appendix A: Revision History

Version Date Notes
1.0.0 TBD First release of the Overlay Specification

B. References

B.1 Normative references

[CommonMark]
CommonMark Spec. URL: https://spec.commonmark.org/
[OpenAPI]
OpenAPI Specification. Darrell Miller; Jason Harmon; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Tony Tam; Uri Sarid. OpenAPI Initiative. URL: https://www.openapis.org/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7159
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC9535]
JSONPath: Query Expressions for JSON. S. Gössner, Ed.; G. Normington, Ed.; C. Bormann, Ed.. IETF. February 2024. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9535
[YAML]
YAML Ain’t Markup Language (YAML™) Version 1.2. Oren Ben-Kiki; Clark Evans; Ingy döt Net. 1 October 2009. URL: http://yaml.org/spec/1.2/spec.html