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: versions/3.0.md
+79-76Lines changed: 79 additions & 76 deletions
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ The OpenAPI Specification (OAS) is a project used to describe and document RESTf
12
12
13
13
14
14
The OpenAPI Specification defines a set of files required to describe such an API.
15
-
These files can then be used by the Swagger-UI project to display the API and Swagger-Codegen to generate clients in various programming languages.
15
+
These files can then be used by documentation generation tools to display the API and code generation tools to generate clients in various programming languages.
16
16
17
17
Additional utilities can also take advantage of the resulting files, such as testing tools.
18
18
@@ -33,39 +33,39 @@ Additional utilities can also take advantage of the resulting files, such as tes
@@ -94,7 +94,8 @@ Some examples of possible media type definitions:
94
94
application/vnd.github.v3.patch
95
95
```
96
96
##### <aname="httpCodes"></a>HTTP Status Codes
97
-
The HTTP Status Codes are used to indicate the status of the executed operation. The available status codes are initially defined by [RFC 7231](http://tools.ietf.org/html/rfc7231#section-6) and registered status codes are listed in the [IANA Status Code Registry](http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml).
97
+
The HTTP Status Codes are used to indicate the status of the executed operation.
98
+
The available status codes are defined by [RFC 7231](http://tools.ietf.org/html/rfc7231#section-6) and registered status codes are listed in the [IANA Status Code Registry](http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml).
98
99
99
100
## Specification
100
101
@@ -134,10 +135,12 @@ By convention, it is RECOMMENDED that the OpenAPI Specification (OAS) file be na
134
135
135
136
### <aname="dataTypes"></a>Data Types
136
137
137
-
Primitive data types in the OAS are based on the types supported by the [JSON Schema Specification Wright Draft 00](https://tools.ietf.org/html/draft-wright-json-schema-00#section-4.2). Note that `integer` as a type is also supported and is defined as a JSON number without a fraction or exponent part. `null` is not supported as a value.
138
+
Primitive data types in the OAS are based on the types supported by the [JSON Schema Specification Wright Draft 00](https://tools.ietf.org/html/draft-wright-json-schema-00#section-4.2).
139
+
Note that `integer` as a type is also supported and is defined as a JSON number without a fraction or exponent part.
140
+
`null` is not supported as a value.
138
141
Models are described using the [Schema Object](#schemaObject) which is an extended subset of JSON Schema Specification Wright Draft 00.
139
142
140
-
<aname="dataTypeFormat"></a>Primitives have an optional modifier property `format`.
143
+
<aname="dataTypeFormat"></a>Primitives have an optional modifier property:`format`.
141
144
OAS uses several known formats to more finely define the data type being used.
142
145
However, the `format` property is an open `string`-valued property, and can have any value to support documentation needs.
143
146
Formats such as `"email"`, `"uuid"`, etc., can be used even though they are not defined by this specification.
@@ -203,7 +206,7 @@ In subsequent versions of the OpenAPI Specification, care will be given such tha
203
206
#### <aname="infoObject"></a>Info Object
204
207
205
208
The object provides metadata about the API.
206
-
The metadata can be used by the clients if needed, and can be presented in the Swagger-UI for convenience.
209
+
The metadata can be used by the clients if needed, and can be presented in editing or documentation generation tools for convenience.
207
210
208
211
##### Fixed Fields
209
212
@@ -214,21 +217,22 @@ Field Name | Type | Description
214
217
<aname="infoTermsOfService"></a>termsOfService | `string` | A URL to the Terms of Service for the API.
215
218
<aname="infoContact"></a>contact | [Contact Object](#contactObject) | The contact information for the exposed API.
216
219
<aname="infoLicense"></a>license | [License Object](#licenseObject) | The license information for the exposed API.
217
-
<aname="infoVersion"></a>version | `string` | **Required.** Provides the version of the application API (not to be confused with the specification version). While not required, is it suggested that the `info.version` value correspond to the version of the API definition. In practice, the version of the API _implementation_ MAY evolve at an entirely different rate.
220
+
<aname="infoVersion"></a>version | `string` | **Required.** The version of the API definition (which is distinct from the OpenAPI specification version or the API implementation version).
221
+
218
222
219
223
This object can be extended with [Specification Extensions](#specificationExtensions).
220
224
221
225
##### Info Object Example:
222
226
223
227
```json
224
228
{
225
-
"title": "Swagger Sample App",
229
+
"title": "Sample Pet Store App",
226
230
"description": "This is a sample server for a pet store.",
227
-
"termsOfService": "http://swagger.io/terms/",
231
+
"termsOfService": "http://example.com/terms/",
228
232
"contact": {
229
233
"name": "API Support",
230
-
"url": "http://www.swagger.io/support",
231
-
"email": "support@swagger.io"
234
+
"url": "http://www.example.com/support",
235
+
"email": "support@example.com"
232
236
},
233
237
"license": {
234
238
"name": "Apache 2.0",
@@ -239,13 +243,13 @@ This object can be extended with [Specification Extensions](#specificationExtens
239
243
```
240
244
241
245
```yaml
242
-
title: Swagger Sample App
246
+
title: Sample Pet Store App
243
247
description: This is a sample server for a pet store.
@@ -271,15 +275,15 @@ This object can be extended with [Specification Extensions](#specificationExtens
271
275
```json
272
276
{
273
277
"name": "API Support",
274
-
"url": "http://www.swagger.io/support",
275
-
"email": "support@swagger.io"
278
+
"url": "http://www.example.com/support",
279
+
"email": "support@example.com"
276
280
}
277
281
```
278
282
279
283
```yaml
280
284
name: API Support
281
-
url: http://www.swagger.io/support
282
-
email: support@swagger.io
285
+
url: http://www.example.com/support
286
+
email: support@example.com
283
287
```
284
288
285
289
#### <a name="licenseObject"></a>License Object
@@ -575,7 +579,7 @@ Describes a single API operation on a path.
575
579
Field Name | Type | Description
576
580
---|:---:|---
577
581
<a name="operationTags"></a>tags | [`string`] | A list of tags for API documentation control. Tags can be used for logical grouping of operations by resources or any other qualifier.
578
-
<a name="operationSummary"></a>summary | `string` | A short summary of what the operation does. For maximum readability in the swagger-ui, this field SHOULD be less than 120 characters.
582
+
<a name="operationSummary"></a>summary | `string` | A short summary of what the operation does. For maximum readability in editing or documentation generation tools, this field SHOULD be less than 120 characters.
579
583
<a name="operationDescription"></a>description | `string` | A verbose explanation of the operation behavior. [CommonMark syntax](http://spec.commonmark.org/) can be used for rich text representation.
580
584
<a name="operationExternalDocs"></a>externalDocs | [External Documentation Object](#externalDocumentationObject) | Additional external documentation for this operation.
581
585
<a name="operationId"></a>operationId | `string` | Unique string used to identify the operation. The id MUST be unique among all operations described in the API. Tools and libraries MAY use the operationId to uniquely identify an operation, therefore, it is recommended to follow common programming naming conventions.
@@ -597,7 +601,6 @@ This object can be extended with [Specification Extensions](#specificationExtens
597
601
"pet"
598
602
],
599
603
"summary": "Updates a pet in the store with form data",
600
-
"description": "",
601
604
"operationId": "updatePetWithForm",
602
605
"parameters": [
603
606
{
@@ -659,7 +662,6 @@ This object can be extended with [Specification Extensions](#specificationExtens
659
662
tags:
660
663
- pet
661
664
summary: Updates a pet in the store with form data
662
-
description: ''
663
665
operationId: updatePetWithForm
664
666
parameters:
665
667
- name: petId
@@ -716,13 +718,13 @@ This object can be extended with [Specification Extensions](#specificationExtens
@@ -1088,6 +1090,7 @@ Field Name | Type | Description
1088
1090
<a name="contentTypeSchema"></a>schema | [Schema Object](#schemaObject) | The schema defining the type used for the request body.
1089
1091
<a name="contentTypeExamples"></a>examples | [Examples Array](#examplesArray) | Examples of the content type. Each example in the Examples array SHOULD be in the correct format as specified in the _content_ type. The `examples` object is mutually exclusive to the `example` object. Furthermore, if referencing a `schema` which contains an example, the `examples` value SHALL _override_ the example provided by the schema.
1090
1092
<a name="contentTypeExample"></a>example | [Example Object](#exampleObject) | Example of the content type. The example object SHOULD be in the correct format as specified in the _content_ type. The `example` object is mutually exclusive to the `examples` object. Furthermore, if referencing a `schema` which contains an example, the `example` value SHALL _override_ the the example provided by the schema.
1093
+
<a name="contentTypeEncoding"></a>encoding | [Encoding Object](#encodingObject) | Encoding of the content type. The encoding object SHOULD only apply to `requestBody` objects when the content type is `multipart`.
1091
1094
1092
1095
##### Patterned Fields
1093
1096
Field Pattern | Type | Description
@@ -1291,13 +1294,13 @@ requestBody:
1291
1294
# default is application/octet-stream, need to declare an image type only!
0 commit comments