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: guidelines/REUSE.md
+45-5Lines changed: 45 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -7,17 +7,54 @@ We encourage reuse and patterns through references.
7
7
The following types are reusable, as defined by the spec:
8
8
9
9
* Parameters
10
-
* Models (or Schema Objects in general)
10
+
* Models (_or Schema Objects in general_)
11
11
* Responses
12
12
* Operations (_Operations can only be remote references_)
13
13
14
14
## Reuse strategy
15
15
16
-
When reusing components in an API design, a reference is created from the definition to target entity. The references are maintained in the structure, and can be updated by modifying the source definitions. This is different from a "copy on design" approach where references are injected into the design itself.
16
+
When authoring API design documents, common object definitions can be utilized to avoid duplication. For example, imagine multiple path definitions that each share a common path parameter, or a common response structure. The OpenAPI specification allows reuse of common object definitions through the use of "references".
17
17
18
-
The reuse technique is transparent between JSON or YAML and is lossless when converting between the two.
18
+
A reference a construct in your API design document that indicates "the content for this portion of the document is defined elsewhere". To create a reference, at the ___location in your document where you want to reuse some other definition, create an object that has a `$ref` property whose value is a URI pointing to where the definition is (more on this in later sections).
19
19
20
-
YAML anchors are technically allowed but break the general reuse strategy in OpenAPI Specification, since anchors are "injected" into a single document. They are not recommended.
20
+
OpenAPI's provides reference capabilities using the [JSON Reference](https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03) specification.
21
+
22
+
### JSON Example
23
+
24
+
```json
25
+
{
26
+
// ...
27
+
definitions: {
28
+
Person: {
29
+
type: 'object',
30
+
properties: {
31
+
friends: {
32
+
type: 'array',
33
+
items: {
34
+
$ref: '#/definitions/Person'
35
+
}
36
+
}
37
+
}
38
+
}
39
+
}
40
+
}
41
+
```
42
+
43
+
### YAML Example
44
+
45
+
```yaml
46
+
# ...
47
+
definitions:
48
+
Person:
49
+
type: object
50
+
properties:
51
+
friends:
52
+
type: array
53
+
items:
54
+
$ref: '#/definitions/Person'
55
+
```
56
+
57
+
Note: YAML has a very similar feature, [YAML anchors](http://yaml.org/spec/1.2/spec.html#id2765878). Examples from this point will only be in JSON, using JSON References.
21
58
22
59
## Techniques
23
60
@@ -46,6 +83,7 @@ An example of a local definition reference:
46
83
47
84
_Example from https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/json/petstore.json_
48
85
``` json
86
+
// ...
49
87
"200": {
50
88
"description": "pet response",
51
89
"schema": {
@@ -65,6 +103,7 @@ Files can be referred to in relative paths to the current document.
65
103
_Example from https://github.com/OAI/OpenAPI-Specification/tree/master/examples/v2.0/json/petstore-separate/spec/swagger.json_
66
104
67
105
``` json
106
+
// ...
68
107
"responses": {
69
108
"default": {
70
109
"description": "unexpected error",
@@ -79,6 +118,7 @@ Remote references may also reference properties within the relative remote file.
79
118
80
119
_Example from https://github.com/OAI/OpenAPI-Specification/tree/master/examples/v2.0/json/petstore-separate/spec/swagger.json_
81
120
``` json
121
+
// ...
82
122
"parameters": [
83
123
{
84
124
"$ref": "parameters.json#/tagsParam"
@@ -233,7 +273,7 @@ To include these parameters, you would need to add them individually as such:
233
273
234
274
### Operations
235
275
236
-
Again, Operations can be shared across files. Although the reusability of operations will be less than with Parameters and models. For this example, we will share a common `health` resource so that all APIs can reference it:
276
+
Again, Operations can be shared across files. Although the reusability of operations will be less than with Parameters and Definitions. For this example, we will share a common `health` resource so that all APIs can reference it:
237
277
238
278
Refer to [Guidelines for Referencing](#guidelines-for-referencing) for referencing strategies.
0 commit comments