How to define a list of files in Swagger?
Here is what I did but it doesn't work.
OpenAPI 2.0
In OpenAPI 2.0 (swagger: '2.0'), you have to define each file as a separate parameter. This means you can only describe requests that send a fixed/limited number of files. There is no way to define an unbound array of files.
paths:
/something:
post:
consumes:
- multipart/form-data
parameters:
- in: formData
name: file1
type: file
- in: formData
name: file2
type: file
- ...
OpenAPI 3.0
Arrays of files are supported in OpenAPI 3.0. The request can be defined as follows:
openapi: 3.0.0
paths:
/something:
post:
requestBody:
content:
multipart/form-data:
schema:
type: object
properties:
# "reports" will be used as the name of each file part/field
# in the multipart request
reports:
type: array
items:
type: string
format: binary
OpenAPI 3.1
OAS 3.1 also supports file arrays, but the syntax is slightly different from 3.0. Specifically, file arrays use items: {} instead of binary string items.
openapi: 3.1.0
paths:
/something:
post:
requestBody:
content:
multipart/form-data:
schema:
type: object
properties:
# "reports" will be used as the name of each file part/field
# in the multipart request
reports:
type: array
items: {}
Related
I'm writing an Open API 3.0 spec and trying to get response links to render in Swagger UI v 3.18.3.
Example:
openapi: 3.0.0
info:
title: Test
version: '1.0'
tags:
- name: Artifacts
paths:
/artifacts:
post:
tags:
- Artifacts
operationId: createArtifact
requestBody:
content:
application/octet-stream:
schema:
type: string
format: binary
responses:
201:
description: create
headers:
Location:
schema:
type: string
format: uri
example: /artifacts/100
content:
application/json:
schema:
type: object
properties:
artifactId:
type: integer
format: int64
links:
Read Artifact:
operationId: getArtifact
parameters:
artifact-id: '$response.body#/artifactId'
/artifacts/{artifact-id}:
parameters:
- name: artifact-id
in: path
required: true
schema:
type: integer
format: int64
get:
tags:
- Artifacts
operationId: getArtifact
responses:
200:
description: read
content:
application/octet-stream:
schema:
type: string
format: binary
renders a link like this:
Is this expected? I ask because the operationId is exposed on the UI and parameters is shown as a JSON reference make it seem like something is not displaying properly. I would have expected a hyperlink or something to take me to the appropriate section in the Swagger web page that corresponds to the API being referenced by the link.
Yes this is how Swagger UI currently renders OAS3 links. Rendering of links is one of the things on their OAS3 support backlog:
OAS 3.0 Support Backlog
This is a collection ticket for OAS3 specification features that are not yet supported by Swagger-UI.
...
[ ] Links can't be used to stage another operation
[ ] Link-level servers are not available for executing requests
How do I set a content type other than application/json for a body parameter in Swagger UI 3.x using a Swagger (Open API) 2.0 YAML definition file?
My YAML file is as follows, with the consumes element set to application/json+fhir and application/xml+fhir:
swagger: '2.0'
info:
title: Test
version: '1.0'
host: 'server.com'
basePath: /fhir
schemes:
- http
paths:
/Patient/$getrecordsection:
post:
tags:
- Get record section
summary: Retrieve a care record section
consumes:
- application/json+fhir
- application/xml+fhir
produces:
- application/json+fhir
- application/xml+fhir
parameters:
- in: body
name: body
description: ''
required: true
schema:
$ref: '#/definitions/GetRecordSection'
responses:
'200':
description: OK
'400':
description: Bad request
definitions:
GetRecordSection:
type: object
properties:
resourceType:
type: string
default: "Parameters"
parameter:
type: string
example:
resourceType: "Parameters"
parameter:
- name: "patientIdentifier"
valueIdentifier:
system: "http://fhir.provider.net/Id/patient-identifier"
value: "9999999999"
- name: "recordSection"
valueCodeableConcept:
coding:
- system: "http://fhir.provider.net/ValueSet/record-section"
code: "ALL"
xml:
name: Parameters
However, the Swagger UI only shows application/json as the body parameter content type:
I'm using the current latest Swagger UI build - 3.11.0.
This is a problem with Swagger UI, rather than the Swagger Editor (though I know the two share a significant number of components), and so the root cause could be the same.
This is a bug in the 3.11.0 version of Swagger UI, using Swagger/Open API 2.0:
https://github.com/swagger-api/swagger-ui/issues/4257
I have a service that creates a multipart file containing:
a data byte array that represents an image buffer
a JSON that represents information about the image (coord, format, etc.)
Is it possible to model this custom response in an OpenAPI (Swagger) definition, using YAML?
Multipart responses can be described using OpenAPI 3.0, but not OpenAPI 2.0 (fka Swagger 2.0).
openapi: 3.0.0
...
paths:
/something:
get:
responses:
'200':
description: OK
content:
multipart/mixed: # <-- Content-Type of the response
schema:
type: object
properties:
# Part 1 - application/octet-stream
file: # <-- part name
type: string
format: binary
# Part 2 - application/json
metadata: # <-- part name
type: object
properties:
foo:
type: string
example: bar
required:
- foo
# Optional, see https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#encoding-object
encoding:
file:
...
metadata:
...
The optional encoding key can be used to override the Content-Type for subparts or add headers for subparts (e.g. Content-Disposition).
I have an image upload endpoint that looks like /test/{id}/relationships/image. I want to describe this endpoint using OpenAPI 2.0 (Swagger 2.0).
The endpoint has both path and formData parameters. I tried the following:
swagger: '2.0'
info:
title: API
version: 1.0.0
host: api.server.de
schemes:
- https
produces:
- application/json
paths:
'/test/{id}/relationships/image':
post:
operationId: addImage
consumes:
- multipart/form-data
parameters:
- in: path
name: id
required: true
schema:
type: integer
format: int32
- in: formData
name: file
type: file
required: true
description: The file to upload.
- in: formData
name: metadata
type: string
required: false
description: Description of file contents.
responses:
'202':
description: Uploaded
But Swagger Editor shows errors:
Schema error at
paths['/test/{id}/relationships/image'].post.parameters[0].in should
be equal to one of the allowed values allowedValues: body, header,
formData, query Jump to line 17
Schema error at
paths['/test/{id}/relationships/image'].post.parameters[0] should NOT
have additional properties additionalProperty: schema, in, name,
required Jump to line 17
What am I doing wrong?
In your path parameter, change
schema:
type: integer
format: int32
to
type: integer
format: int32
In OpenAPI/Swagger 2.0, path, header, query and formData parameters use type directly, without a schema. The schema keyword is used for body parameters only.
I'm looking for an elegant way to define an api that can consume JSON data as well as form data. The following snippet works, but it's not elegant and requires all kind of ugly code in the backend. Is there a better way to define this?
What works right now:
paths:
/pets:
post:
consumes:
- application/x-www-form-urlencoded
- application/json
parameters:
- name: nameFormData
in: formData
description: Updated name of the pet
required: false
type: string
- name: nameJSON
in: body
description: Updated name of the pet
required: false
type: string
Basic idea of how I'd like it to work:
paths:
/pets:
post:
consumes:
- application/x-www-form-urlencoded
- application/json
parameters:
- name: name
in:
- formData
- body
description: Updated name of the pet
required: true
type: string
But this doesn't work because the in value must be a string, not an array.
Any good ideas?
OpenAPI 2.0
In OpenAPI 2.0, there's no way to describe that. Form and body parameters are mutually exclusive, so an operation can have either form data OR JSON body but not both. A possible workaround is to have two separate endpoints - one for form data and another one for JSON - if that is acceptable in your scenario.
OpenAPI 3.0
Your scenario can be described using OpenAPI 3.0. The requestBody.content.<media-type> keyword is used to define various media types accepted by the operation, such as application/json and application/x-www-form-urlencoded, and their schemas. Media types can have the same schema or different schemas.
openapi: 3.0.0
...
paths:
/pets:
post:
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/Pet'
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/Pet'
responses:
'200':
description: OK
components:
schemas:
Pet:
type: object
properties:
name:
type: string
description: Updated name of the pet
required:
- name
Further info:
OAS3: Describing Request Body
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#support-for-x-www-form-urlencoded-request-bodies
https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/#requestformat