You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+19-12
Original file line number
Diff line number
Diff line change
@@ -1,21 +1,28 @@
1
-
# Overlay-Specification
1
+
# OverlaySpecification
2
2
3
-
The [Overlay Specification](https://spec.openapis.org/overlay/latest.html)is a community-driven open specification within the [OpenAPI Initiative](https://www.openapis.org/), a Linux Foundation Collaborative Project.
3
+
The [Overlay Specification](https://spec.openapis.org/overlay/latest.html)defines a document format for information that augments an existing OpenAPI description yet remains separate from the OpenAPI description's source document(s).
4
4
5
-
The Overlay specification defines a way of creating documents that contain information to be merged with an OpenAPI description at some later point in time, for the purpose of updating the OpenAPI description with additional information.
5
+
This specification is a community-driven, open specification within the [OpenAPI Initiative](https://www.openapis.org/), a Linux Foundation Collaborative Project.
6
6
7
-
Overlays can address a wide range of scenarios that have been frequently requested by OpenAPI users:
7
+
Overlays support a range of scenarios, including:
8
8
9
-
-Support multi-language API descriptions by using Overlays to contain language translations.
10
-
-Provide configuration information for different deployment environments.
11
-
-Allow separation of concerns for metadata such as gateway configuration or SLA information.
12
-
-Support a traitslike capability for applying a set of configuration data, such as multiple parameters, or multiple headers to a targeted object.
13
-
-Provide default responses, or parameters where they are not explicitly provided.
14
-
-Apply configuration data globally or based on filter conditions.
9
+
-Translating documentation into another language
10
+
-Providing configuration information for different deployment environments
11
+
-Allowing separation of concerns for metadata such as gateway configuration or SLA information
12
+
-Supporting a traits-like capability for applying a set of configuration data, such as multiple parameters or multiple headers, for targeted objects
13
+
-Providing default responses or parameters where they were not explicitly provided
14
+
-Applying configuration data globally or based on filter conditions
15
15
16
-
## Current Status
16
+
## Tools that Support Overlays
17
17
18
-
The current specification is sufficiently stable for implementers to start experimenting. We are looking for implementation experience to guide our decisions on the remaining open issues.
18
+
If you are looking for tools to use with Overlays, try these:
Copy file name to clipboardexpand all lines: versions/1.0.0.md
+46-29
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,9 @@
1
1
# Overlay Specification
2
2
3
+
## Abstract
4
+
5
+
The Overlay Specification defines a document format for information that augments an existing [[OpenAPI]] description yet remains separate from the OpenAPI description's source document(s).
6
+
3
7
## Version 1.0.0
4
8
5
9
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](https://tools.ietf.org/html/bcp14)[RFC2119](https://tools.ietf.org/html/rfc2119)[RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
@@ -8,12 +12,10 @@ This document is licensed under [The Apache License, Version 2.0](https://www.ap
8
12
9
13
## Introduction
10
14
11
-
The Overlay Specification is an extension or companion to the [[OpenAPI]]specification.
15
+
The Overlay Specification is a companion to the [[OpenAPI]]Specification.
12
16
An Overlay describes a set of changes to be applied or "overlaid" onto an existing OpenAPI description.
13
17
14
-
The main purpose of the Overlay Specification is to provide a way to repeatably apply transformations to one or many OpenAPI descriptions.
15
-
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.
16
-
An Overlay may be specific to a single OpenAPI description, or be designed to apply the same transform to any OpenAPI description.
18
+
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.
17
19
18
20
## Definitions
19
21
@@ -25,10 +27,9 @@ An Overlay is a JSON or YAML structure containing an ordered list of [Action Obj
25
27
26
28
### Versions
27
29
28
-
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.
30
+
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.
29
31
30
-
**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.
31
-
Check with your tool provider for the details of what is supported in each tool.
32
+
**Note:** Version 1.0.0 of the Overlay Specification was released after spending some time in draft and being implemented by a few early-adopting tool providers. Check with your tool provider for the details of what is supported in each tool.
32
33
33
34
### Format
34
35
@@ -42,14 +43,9 @@ In order to preserve the ability to round-trip between YAML and JSON formats, [[
42
43
- Tags MUST be limited to those allowed by the [JSON Schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231).
43
44
- Keys used in YAML maps MUST be limited to a scalar string, as defined by the [YAML Failsafe schema ruleset](https://yaml.org/spec/1.2/spec.html#id2802346).
44
45
45
-
### Document Structure
46
-
47
-
It is RECOMMENDED that the root Overlay document be named: `overlay.json` or `overlay.yaml`.
46
+
### Relative References in URIs
48
47
49
-
### Relative References in URLs
50
-
51
-
Unless specified otherwise, all properties that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
52
-
Unless specified otherwise, relative references are resolved using the URL of the referring document.
48
+
Unless specified otherwise, all fields that are URI references MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
53
49
54
50
### Schema
55
51
@@ -65,14 +61,35 @@ This is the root object of the [Overlay](#overlay).
65
61
| ---- | :----: | ---- |
66
62
| <aname="overlay-version"></a>overlay |`string`|**REQUIRED**. This string MUST be the [version number](#versions) of the Overlay Specification that the Overlay document uses. The `overlay` field SHOULD be used by tooling to interpret the Overlay document. |
67
63
| <aname="overlay-info"></a>info |[Info Object](#info-object)|**REQUIRED**. Provides metadata about the Overlay. The metadata MAY be used by tooling as required. |
68
-
| <aname="overlay-extends"></a>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. |
64
+
| <aname="overlay-extends"></a>extends |`string`|URI reference that identifies the target document (such as an [[OpenAPI]] document) this overlay applies to. |
69
65
| <aname="overlay-actions"></a>actions |[[Action Object](#action-object)]|**REQUIRED** An ordered list of actions to be applied to the target document. The array MUST contain at least one value. |
70
66
71
67
This object MAY be extended with [Specification Extensions](#specification-extensions).
72
68
73
-
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.
69
+
The list of actions MUST be applied in sequential order to ensure a consistent outcome. Actions are applied to the result of the previous action. This enables objects to be deleted in one action and then re-created in a subsequent action, for example.
70
+
71
+
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 document to the appropriate OpenAPI document(s).
72
+
73
+
In the following example the `extends` property specifies that the overlay is designed to update the OpenAPI Tic Tac Toe example document, identified by an absolute URI.
The `extends` property can also specify a relative URI reference.
74
85
75
-
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).
86
+
```yaml
87
+
overlay: 1.0.0
88
+
info:
89
+
title: Overlay for the Tic Tac Toe API document
90
+
version: 1.0.0
91
+
extends: './tictactoe.yaml'
92
+
```
76
93
77
94
#### Info Object
78
95
@@ -98,22 +115,22 @@ This object represents one or more changes to be applied to the target document
98
115
| ---- | :----: | ---- |
99
116
| <a name="action-target"></a>target | `string` | **REQUIRED** A JSONPath expression selecting nodes in the target document. |
100
117
| <a name="action-description"></a>description | `string` | A description of the action. [[CommonMark]] syntax MAY be used for rich text representation. |
101
-
| <aname="action-update"></a>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`. |
102
-
| <aname="action-remove"></a>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`. |
118
+
| <a name="action-update"></a>update | Any | If the `target` selects an object node, the value of this field MUST be an object with the properties and values to merge with the selected node. If the `target` selects an array, the value of this field MUST be an entry to append to the array. This field has no impact if the `remove` field of this action object is `true`. |
119
+
| <a name="action-remove"></a>remove | `boolean` | A boolean value that indicates that the target object or array MUST be removed from the the map or array it is contained in. The default value is `false`. |
103
120
104
-
The result of the `target` JSONPath expression must be zero or more objects or arrays (not primitive types or `null` values).
121
+
The result of the `target` JSONPath expression MUST be zero or more objects or arrays (not primitive types or `null` values).
105
122
106
123
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.
107
124
108
125
Primitive-valued items of an array cannot be replaced or removed individually, only the complete array can be replaced.
109
126
110
-
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.
127
+
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 `update` object are recursively merged with the properties in the target object with the same names; new properties are added to the target object.
111
128
112
129
This object MAY be extended with [Specification Extensions](#specification-extensions).
113
130
114
131
### Examples
115
132
116
-
#### Structured Overlays Example
133
+
#### Structured Overlay Example
117
134
118
135
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.
119
136
@@ -141,14 +158,14 @@ actions:
141
158
tags:
142
159
```
143
160
144
-
#### Targeted Overlays
161
+
#### Targeted Overlay Example
145
162
146
163
Alternatively, where only a small number of updates need to be applied to a large document, each [Action Object](#action-object) MAY be more targeted.
147
164
148
165
```yaml
149
166
overlay: 1.0.0
150
167
info:
151
-
title: Targeted Overlays
168
+
title: Targeted Overlay
152
169
version: 1.0.0
153
170
actions:
154
171
- target: $.paths['/foo'].get
@@ -164,7 +181,7 @@ actions:
164
181
x-safe: false
165
182
```
166
183
167
-
#### Wildcard Overlays Examples
184
+
#### Wildcard Overlay Example
168
185
169
186
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.
170
187
@@ -183,7 +200,7 @@ actions:
183
200
$ref: '/components/schemas/filterSchema'
184
201
```
185
202
186
-
#### Array Modification Examples
203
+
#### Array Modification Example
187
204
188
205
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.
189
206
@@ -209,9 +226,9 @@ actions:
209
226
remove: true
210
227
```
211
228
212
-
#### Traits Examples
229
+
#### Traits Example
213
230
214
-
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.
231
+
By annotating a target document (such as an [[OpenAPI]] document) using [Specification Extensions](#specification-extensions) such as `x-oai-traits`, the author of the target document MAY identify where overlay updates should be applied.
215
232
216
233
```yaml
217
234
openapi: 3.1.0
@@ -264,4 +281,4 @@ The extensions may or may not be supported by the available tooling, but those m
264
281
265
282
| Version | Date | Notes |
266
283
| ---- | ---- | ---- |
267
-
| 1.0.0 | TBD | First release of the Overlay Specification |
284
+
| 1.0.0 | 2024-10-17 | First release of the Overlay Specification |
0 commit comments