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
This organizes and streamlines the guidance on multipart
that was incorporated from the Media Type Object.
Lots of duplication has been removed, and the examples
reworked to show distinct use cases.
It is common to use `multipart/form-data` as a `Content-Type` when transferring request bodies to operations. In contrast to 2.0, a `schema` is REQUIRED to define the input parameters to the operation when using `multipart` content. This supports complex structures as well as supporting mechanisms for multiple file uploads.
1735
-
1736
-
When passing in `multipart` types, boundaries MAY be used to separate sections of the content being transferred — thus, the following default `Content-Type`s are defined for `multipart`:
1737
-
1738
-
* If the property is a primitive, or an array of primitive values, the default Content-Type is `text/plain`
1739
-
* If the property is complex, or an array of complex values, the default Content-Type is `application/json`
1740
-
* 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`
1741
-
1742
-
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).
1734
+
It is common to use `multipart/form-data` as a `Content-Type` when transferring forms as request bodies. In contrast to 2.0, a `schema` is REQUIRED to define the input parameters to the operation when using `multipart` content. This supports complex structures as well as supporting mechanisms for multiple file uploads.
1743
1735
1744
1736
The `form-data` disposition and its `name` parameter are mandatory for `multipart/form-data` ([RFC7578 §4.2](https://www.rfc-editor.org/rfc/rfc7578.html#section-4.2)).
1745
1737
Array properties are handled by applying the same `name` to multiple parts, as is recommended by [RFC7578 §4.3](https://www.rfc-editor.org/rfc/rfc7578.html#section-4.3) for supplying multiple values per form field.
@@ -1758,7 +1750,7 @@ See [Appendix E](#percentEncodingAndFormMediaTypes) for a detailed examination o
1758
1750
1759
1751
###### Example: Basic Multipart Form
1760
1752
1761
-
Examples:
1753
+
When the `encoding` attribute is _not_ used, the encoding is determined by the Encoding Object's defaults:
1762
1754
1763
1755
```yaml
1764
1756
requestBody:
@@ -1768,31 +1760,25 @@ requestBody:
1768
1760
type: object
1769
1761
properties:
1770
1762
id:
1763
+
# default for primitives without a special format is text/plain
1771
1764
type: string
1772
1765
format: uuid
1773
-
address:
1774
-
# default Content-Type for objects is `application/json`
1775
-
type: object
1776
-
properties: {}
1777
1766
profileImage:
1778
-
# default Content-Type for string/binary is `application/octet-stream`
1767
+
# default for string with binary format is `application/octet-stream`
1779
1768
type: string
1780
1769
format: binary
1781
-
children:
1782
-
# default Content-Type for arrays is based on the `inner` type (text/plain here)
1783
-
type: array
1784
-
items:
1785
-
type: string
1786
1770
addresses:
1787
-
# default Content-Type for arrays is based on the `inner` type (object shown, so `application/json` in this example)
1771
+
# default for arrays is based on the type in the `items`
1772
+
# subschema, which is an object, so `application/json`
1788
1773
type: array
1789
1774
items:
1790
1775
$ref: '#/components/schemas/Address'
1791
1776
```
1792
1777
1793
1778
###### Example: Multipart Form with Encoding Objects
1794
1779
1795
-
`multipart/form-data` allows for binary parts:
1780
+
Using `encoding`, we can set more specific types for binary data, or non-JSON formats for complex values.
1781
+
We can also describe headers for each part:
1796
1782
1797
1783
```yaml
1798
1784
requestBody:
@@ -1802,28 +1788,30 @@ requestBody:
1802
1788
type: object
1803
1789
properties:
1804
1790
id:
1805
-
# default is text/plain
1791
+
# default is `text/plain`
1806
1792
type: string
1807
1793
format: uuid
1808
-
address:
1809
-
# default is application/json
1810
-
type: object
1811
-
properties: {}
1812
-
historyMetadata:
1813
-
# need to declare XML format!
1814
-
description: metadata in XML format
1815
-
type: object
1816
-
properties: {}
1794
+
addresses:
1795
+
# default based on the `items` subschema would be
1796
+
# `application/json`, but we want these address objects
1797
+
# serialized as `application/xml` instead
1798
+
description: addresses in XML format
1799
+
type: array
1800
+
items:
1801
+
$ref: '#/components/schemas/Address'
1817
1802
profileImage:
1818
-
# default is application/octet-stream, need to declare an image type only!
1803
+
# default is application/octet-stream, but we can declare
1804
+
# a more specific image type or types
1819
1805
type: string
1820
1806
format: binary
1821
1807
encoding:
1822
-
historyMetadata:
1808
+
addresses:
1823
1809
# require XML Content-Type in utf-8 encoding
1810
+
# This is applied to each address part corresponding
1811
+
# to each address in he array
1824
1812
contentType: application/xml; charset=utf-8
1825
1813
profileImage:
1826
-
# only accept png/jpeg
1814
+
# only accept png or jpeg
1827
1815
contentType: image/png, image/jpeg
1828
1816
headers:
1829
1817
X-Rate-Limit-Limit:
@@ -1834,7 +1822,7 @@ requestBody:
1834
1822
1835
1823
###### Example: Multipart Form with Multiple Files
1836
1824
1837
-
To upload multiple files, a `multipart` media type MUST be used:
1825
+
In accordance with [RFC7578 §4.3](https://www.rfc-editor.org/rfc/rfc7578.html#section-4.3), multiple files for a single form field are uploaded using the same name (`file` in this example) for each file's part:
0 commit comments