I'm using Swagger Editor to document an existing API, built in Node, but it keeps giving me the following error:
Schema error at paths./upload/Rate.post.parameters[0]
is not exactly one from <#/definitions/parameter>,<#/definitions/jsonReference>
This error appears in 3 places of my code:
paths./upload/Rate.post.parameters[0]
paths./upload/Rate.post.parameters[1]
paths./users/register.post.parameters[0]
I've searched quite a bit, but, for example, this link did not solved my problem although it's the same error:
Swagger parameter error "is not exactly one from <#/definitions/parameter>"?
Here is my Swagger definition:
/users/register:
post:
tags:
- "users"
description: Allows an user to register at the Server
produces:
- application/json
parameters:
- name: body
in: body
description: JSON Object with information for a Register request from an User
schema:
type: object
required:
- username
- password
- weight
- height
- gender
- restRate
- age
properties:
username:
type: string
password:
type:
format: password
weight:
type: integer
height:
type: integer
gender:
type: string
restRate:
type: integer
age:
type: integer
# Expected responses for this operation:
responses:
# Response code
200:
description: Register successful
schema:
type: string
/upload/Rate:
post:
tags:
- "upload"
description: Allows an user to upload a file into the server
produces:
- application/json
consumes:
- multipart/form-data
parameters:
- name: body
in: formData
description: JSON Object with information for an upload request from an User
required: false
schema:
type: object
required:
- user
- overlap
- window
- latitude
- longitude
- time
- date
properties:
user:
type: string
overlap:
type: string
window:
type: string
latitude:
type: string
longitude:
type: string
time:
type: string
date:
type: string
- name: files
in: formData
description: File with the corresponding Rate
required: false
schema:
type: object
required:
- rate
properties:
rate:
type: file
# Expected responses for this operation:
responses:
# Response code
200:
description: Login successful
schema:
type: string
Maybe this will help, but the post route (upload/Rate) should receive a request that will be something like this, once I've parsed its parameters:
user = req.body.user;
rr = req.files.rate;
overlap = req.body.overlap;
windowT = req.body.window;
latitude = req.body.latitude;
longitude = req.body.longitude;
time = req.body.time;
date = req.body.date;
Thank you for your help and time!
There are multiple issues.
/upload/register:
Schema property password is missing the value for type.
Property name mismatch - restHR (under properties) vs restRate (in the required list).
upload/Rate:
The problem here is caused by object parameters in a multipart/form-data request. In OpenAPI (fka Swagger) 2.0, form parameters can be primitive values and arrays, but not objects. So your example cannot be described using OpenAPI 2.0.
If you were designing a new API (or if you could and were willing to change the API implementation to be compatible with OpenAPI 2.0), possible solutions would be:
Change the operation to consume application/json and combine all input parameters into a single JSON object. The file parameter would need to be implemented as a base64 string - type: string with format: byte.
Use multipart/form-data but split object parameters into individual form parameters.
The upcoming OpenAPI 3.0 will support object parameters in form data:
https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md#special-considerations-for-multipart-content
Related
I'm getting the "bad indentation of mapping entry" error in the Swagger Editor for the OpenAPI definition below. Can anyone tell what's wrong with the code below?
responses:
'200':
description: List all applicable errors for API
headers:
x-request-received-at:
type: string
description: A datetime stamp of when the request was received
x-response-sent-at:
type: string
description: A datetime stamp of when the response was sent
schema:
$ref: '#/definitions/ErrorResponse'
default:
description: An unexpected error occurred
schema:
$ref: '#/definitions/Error'
'/funeral/{contractReference}/agreement':
get:
summary: Get the funeral policy and debit order mandate agreement for the client to sign
operationId:
- get801FuneralCoverPlanAgreementHtml
- getAUTHORITYANDMANDATEFORPAYMENTINSTRUCTIONSHTML
tags:
- "FuneralCoverService"
- "InternalAPI"
parameters:
- name: contractReference
in: "path"
required: true
type: string
description: "Unique contract reference linked to the quote and estimate prepared for the client which should be used as input to the agreements."
maxLength: 80
Parameter attributes are misaligned. All attributes must have the same indentation level.
Wrong:
parameters:
- name: contractReference
in: "path"
required: true
type: string
description: "Unique contract reference linked to the quote and estimate prepared for the client which should be used as input to the agreements."
maxLength: 80
Correct:
parameters:
- name: contractReference
in: "path"
required: true
type: string
description: "Unique contract reference linked to the quote and estimate prepared for the client which should be used as input to the agreements."
maxLength: 80
I am writing API documentation using OpenAPI 3.0. At the moment I have:
paths:
/script/update:
post:
tags:
- "Script"
summary: Update a script
operationId: updateScript
responses:
'200':
description: OK
"404":
description: Not Found
requestBody:
description: A script object in order to make the request
required: true
content:
application/x-www-form-urlencoded:
schema:
type: object
properties:
subsite_id:
type: string
script:
type: object
properties:
script:
$ref: '#/components/schemas/ScriptType'
type:
type: string
enum:
- custom
- interface
- freshbot
- feeder
- getter
- smcf
status:
$ref: '#/components/schemas/ScriptStatus'
comment:
type: string
format: string
reason:
type: string
format: string
To problem comes when I try to use to Swagger UI.
The only thing that appears is the following:
What I want is that the script object can be filled out field by field for each of the properties it has, like the subsite_id. What am I missing?
Swagger UI 3.x and 4.x do not have a form editor for JSON objects, so all JSON data needs to be entered in the JSON format: { "prop": value, ... }
Here's the corresponding feature request you can track:
https://github.com/swagger-api/swagger-ui/issues/2771
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 am starting a REST service, using Swagger Codegen. I need to have different responses for different parameters.
Example: <baseURL>/path can use ?filter1= or ?filter2=, and these parameters should produce different response messages.
I want my OpenAPI YAML file to document these two query params separately. Is this possible?
It is not supported in the 2.0 spec, and not in 3.0 either.
Here are the corresponding proposals in the OpenAPI Specification repository:
Accommodate legacy APIs by allowing query parameters in the path
Querystring in Path Specification
If you're still looking, I found out a way around this problem. It's a bit of a hack, but it works.
Basically, you can have two definitions to the same path by adding a slash (/) in the URL.
That way, you can set a response for <baseURL>/path with the ?filter1= parameter and set another response for <baseURL>//path with the ?filter2= parameter. It's also important that you give an unique operationId for each of the definitions.
paths:
/path/you/want:
get:
summary: Test
operationId: get1
parameters:
- name: filter1
type: string
in: path
required: true
responses:
200:
description: Successful response
schema:
$ref: '#/definitions/SomeResponse'
/path/you//want:
get:
summary: Another test
operationId: get2
parameters:
- name: filter2
type: string
in: path
required: true
responses:
200:
description: Successful response
schema:
$ref: '#/definitions/SomeOtherResponse'
I tried this with a path parameter and it worked just fine!
In swagger defining location,type explicitly is what defines these variables.
You have all the required fields to avoid collision of variables, for a json body you have to reference a declaration or use an example schema as shown below. For my case I have used a schema example rather than a declaration reference
/auth/account/password/reset/{userId}/{resetToken}:
post:
consumes:
- application/json
parameters:
- in: path
name: userId
type: string
required: true
- in: path
type: string
name: resetToken
required: true
- in: header
name: authorization
required: true
type: string
- in: body
name: body
required: true
schema:
type: object
example:
password: password
confirmPassword: password
responses:
"200":
description: OK
In Swagger you can add ? to make endpoints different.
i.e. /articles and /articles?:
When using ? in Swagger editor you will see error:
However on your final Swagger page there will be mark VALID
Additional information:
Remember about unique operationId for duplicated entries
I have a service that can have two different kind of body parameters based on the Content-Type header.
E.g. for path /Pet:
If Content-Type: application/somecustom.resource+json is used, then POST can take up Pet as the body parameter.
If Content-Type: application/somecustom.function+json is used, then POST should take up some different body parameter to invoke a function and return a different response.
Any suggestion on how to manifest this in OpenAPI (Swagger)?
OpenAPI 3.0 supports different schemas per media type.
openapi: 3.0.0
...
paths:
/pet:
post:
requestBody:
required: true
content:
application/somecustom.resource+json:
schema:
$ref: '#/components/schemas/Pet'
application/somecustom.function+json:
schema:
$ref: '#/components/schemas/Foo'
No, it's not possible to define a two different body parameters for the same operation, in the same path item. The path item name are unique by virtue of being property names (and therefore "keys" in the JSON key-value map), and Swagger specification allows at most one body parameter in a given operation.
There are a few alternative approaches to address this need:
Create two separate path items
For example:
/pets/createFromDescription:
post:
summary: Create a pet from a basic description
operationId: createPetFromDescription
parameters:
- name: petDescription
in: body
required: true
schema:
$ref: "#/definitions/PetDescriptionObject"
responses:
200:
description: OK
/pets/createFromCatalog:
post:
summary: Create a pet from a standard catalog entry
operationId: createPetFromCatalogEntry
parameters:
- name: petCatalogEntry
in: body
required: true
schema:
$ref: "#/definitions/PetCatalogEntry"
responses:
200:
description: OK
Create subtypes, with a discriminator
Described in the Swagger–OpenAPI 2.0 specification here.
Example:
/pets:
post:
summary: Create a pet
operationId: createPet
parameters:
- name: petSource
in: body
description: Structured pet information, from which to create the object
required: true
schema:
$ref: "#/definitions/CreatePet_Request"
responses:
200:
description: OK
definitions:
CreatePet_Request:
type: object
properties:
requestVariant:
type: string
required:
- requestVariant
discriminator: requestVariant
PetDescriptionObject:
allOf:
- $ref: "#/definitions/CreatePet_Request"
- type: object
properties:
name:
type: string
description:
type: string
PetCatalogEntry:
allOf:
- $ref: "#/definitions/CreatePet_Request"
- type: object
properties:
SKU:
type: string
Breed:
type: string
Comments:
type: string
Neither of these methods is keyed to the media type of the request. While your request may accept multiple media types, if the use of a particular media type implies some requirement about the request body, you'd have to document that in the description property of the operation or body parameter.