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
Clarify the use of "binary" and "byte" formats (OAI#3187)
Add a brief explanation as a subsection of Data Types, and
update the relevant examples. Specifically:
* Don't use `format: byte` for a whole message body
* Fix `multipart/mixed` example to be `multipart/form-data`
(because `multipart/mixed` does not name its parts and
therefore cannot be represented with an object schema)
* Add an `application/x-www-form-urlencoded` example,
which is where `format: byte` needs to be used
`string` | `date` | As defined by `full-date` - [RFC3339](https://www.rfc-editor.org/rfc/rfc3339#section-5.6)
168
168
`string` | `date-time` | As defined by `date-time` - [RFC3339](https://www.rfc-editor.org/rfc/rfc3339#section-5.6)
169
169
`string` | `password` | A hint to UIs to obscure input.
170
170
171
+
#### <aname="binaryData"></a>Working With Binary Data
172
+
173
+
Two formats, `binary` and `byte`, describe different ways to work with binary data:
174
+
175
+
*`binary` is used where unencoded binary data is allowed, such as when sending a binary payload as an HTTP message body, or as part of a `multipart/*` payload that allows binary parts
176
+
*`byte` is used where binary data is embedded in a text-only format such as `application/json` or `application/x-www-form-urlencoded`
177
+
178
+
Note that the encoding indicated by `byte`, which inflates the size of data in order to represent it as 7-bit ASCII text, is unrelated to HTTP's `Content-Encoding` header, which indicates whether and how a message body has been compressed.
171
179
172
180
### <aname="richText"></a>Rich Text Formatting
173
181
Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting.
@@ -1440,13 +1448,6 @@ application/json:
1440
1448
1441
1449
In contrast with the 2.0 specification, `file` input/output content in OpenAPI is described with the same semantics as any other schema type. Specifically:
1442
1450
1443
-
```yaml
1444
-
# content transferred with base64 encoding
1445
-
schema:
1446
-
type: string
1447
-
format: byte
1448
-
```
1449
-
1450
1451
```yaml
1451
1452
# content transferred in binary (octet-stream):
1452
1453
schema:
@@ -1537,6 +1538,7 @@ When passing in `multipart` types, boundaries MAY be used to separate sections o
1537
1538
* If the property is complex, or an array of complex values, the default Content-Type is `application/json`
1538
1539
* If the property is a `type: string` with `format: binary` or `format: byte` (aka a file object), the default Content-Type is `application/octet-stream`
1539
1540
1541
+
Note that only `multipart/*` media types with named parts can be described as shown here. Note also that while `multipart/form-data` originally defined a per-part `Content-Transfer-Encoding` header that could indicate base64 encoding (`format: byte`), it has been deprecated for use with HTTP as of [RFC7578](https://www.rfc-editor.org/rfc/rfc7578#section-4.7).
1540
1542
1541
1543
Examples:
1542
1544
@@ -1589,10 +1591,12 @@ This object MAY be extended with [Specification Extensions](#specificationExtens
1589
1591
1590
1592
##### Encoding Object Example
1591
1593
1594
+
`multipart/form-data` allows for binary parts:
1595
+
1592
1596
```yaml
1593
1597
requestBody:
1594
1598
content:
1595
-
multipart/mixed:
1599
+
multipart/form-data:
1596
1600
schema:
1597
1601
type: object
1598
1602
properties:
@@ -1627,6 +1631,26 @@ requestBody:
1627
1631
type: integer
1628
1632
```
1629
1633
1634
+
`application/x-www-form-urlencoded` is a text format, which requires base64-encoding any binary data:
1635
+
1636
+
```YAML
1637
+
requestBody:
1638
+
content:
1639
+
application/x-www-form-urlencoded:
1640
+
schema:
1641
+
type: object
1642
+
properties:
1643
+
name:
1644
+
type: string
1645
+
icon:
1646
+
# default is text/plain, need to declare an image type only!
0 commit comments