Is it possible to validate example part of swagger document against corresponding schema?
I've found tools for both validating schema itself (like http://editor.swagger.io or swagger-cli etc - but that's just linting) and validating requests/responses against schema (things like swagger-express-middleware or swagger-assertions).
But I'd like to validate that examples in responses and definitions are consistent with schemas.
For example:
swagger: '2.0'
paths:
/test:
get:
description: test endpoint
produces:
- application/json
responses:
200:
description: OK
schema:
type: object
properties:
name:
type: string
id:
type: integer
example:
name: 13
id: some string
seems to be "correct" for all those tools even if example contains incorrect structure.
is there a tool that can do that?
Related
Description
Hi Everyone. I am working with open api generator and change for only use Reactor in my projects (Flux and Mono). My problem is when I generate Multipart form for object array files, the generator create #RequestPart with Mono and it's will be geerate with Flux because the object is an array.
I check the mustaches templates for form params and all it's ok.
This is part of my formParams.mustache
{{#reactive}}{{#isArray}}Flux{{/isArray}}{{^isArray}}Mono{{/isArray}}{{/reactive}}{{^reactive}}{{#isArray}}List<{{/isArray}}MultipartFile{{#isArray}}>{{/isArray}}{{/reactive}}
My question is: why the generator don't validate when "isArray" because always generate with Mono in my classes.
This is an example how to generate my ApiDelegate:
with single element (Ok): default Mono multipartSingle(Mono file, ServerWebExchange exchang
My Open api YAML is:
openapi: 3.0.1
info:
title: Test multipart
version: v1
servers:
- url: http://localhost:9111/api-test/multipart/v1
description: Generated server url
paths:
/multipart/single:
post:
tags:
- multipart
description: Single MultipartFile test
operationId: multipartSingle
requestBody:
content:
multipart/form-data:
schema:
type: object
properties:
file:
description: "One file"
type: string
format: binary
responses:
'200':
description: successful operation, name of the uploaded file
content:
application/json:
schema:
$ref: '#/components/schemas/InformationPart'
/multipart-array:
post:
tags:
- multipart
description: MultipartFile array test
operationId: multipartArray
requestBody:
required: true
content:
multipart/form-data:
schema:
type: object
properties:
files:
type: array
description: "Many files"
items:
type: string
format: binary
responses:
'200':
description: successful operation, name of the uploaded file
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/InformationPart'
components:
schemas:
InformationPart:
title: Dummy info
type: object
properties:
fileName:
type: string
additionalInformation:
type: string
with Array Files(Don't generate with Flux): default Mono multipartArray(Mono file, ServerWebExchange exchang
openapi-generator version
4.3.1
OpenAPI declaration file content or url
Command line used for generation
I use mvn clean install.
Steps to reproduce
When I generate with maven plugin for single part it's generating ok, problem is when it's generate for array object
I can resolve it changing in forms.mustache to {#isArray} to {#isListContainer} and it's works fine without changing version of plugin
I have OpenAPI 3 documentation which defines a method:
/header/somemethod:
get:
tags:
- Layout
summary: some text
responses:
200:
description: success
content:
application/json:
schema:
type: array
items:
anyOf:
- $ref: '#/components/schemas/Item1'
- $ref: '#/components/schemas/Item2'
How I can implement a Spring Boot controller which mathes this documentation?
How I can set up swagger annotations to generate this documentation?
I tried to generate a server in Swagger editor, but generated code doesn't show Item1 and Item2.
Thanks.
I believe you have configured pom.xml file for swagger code generation. To get Item1 and Item2, you need to define them in the above file like below:
paths: # path definitions here
definitions:
Item1:
properties:
Item1_name:
description: name
type: string
Item1_value:
description: value
type: number
Item2:
properties:
Item2_name:
description: name
type: string
Item2_value:
description: value
type: number
Note: Here fields in Item1 and Item2 are having fields name and value
Can I use my own custom formats in my OpenAPI definition and have the AWS API Gateway validate using them? I can't find any reference for this so I assume not?
For example, I would only like to greet guys named Dave:
swagger: "2.0"
info:
version: "1.0"
title: "Hello World API"
paths:
/hello/{user}:
get:
description: Returns a greeting to the user!
parameters:
- name: user
in: path
type: string
required: true
description: The name of the user to greet.
format: "guys-named-dave"
The documentation on this is a bit implicit, indeed. If you combine this
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-validation-set-up.html
with this
https://swagger.io/specification/#schema-object
the following should be a solution, that works (and it does!)
paths:
/hello
get:
x-amazon-apigateway-request-validator: params
parameters:
- name: user
in: path
required: true
schema:
type: string
pattern: ^.*dave.*$
x-amazon-apigateway-request-validators:
params:
validateRequestParameters: true
To allow for case insensitive names like "Dave" and "DAVE", try the pattern /.*dave.*/i. I don't know if this will work.
I am trying to define my APIs using openapi version 3.0.0. I've generated following YAML file:
openapi: 3.0.0
info:
title: My YAML
description: My YAML
version: 1.0.0
servers:
- url: http://my.server.url
paths:
/v1/service/uri:
post:
summary: Getting some information.
parameters:
- name: Content-Type
in: header
description: Content type of request body.
required: true
style: simple
explode: false
schema:
type: string
- name: Host
in: header
description: Originate host which returns the response.
required: false
style: simple
explode: false
schema:
type: string
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/MyPostRequest'
example:
my_name: "zizi"
my_age: 29
required: true
responses:
200:
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/MyPostResponse'
components:
schemas:
MyPostRequest:
type: object
properties:
my_name:
type: string
my_age:
type: integer
format: int32
MyPostResponse:
type: object
properties:
status:
type: integer
format: int32
When I copy/paste these lines into Swagger Editor, it gives me duplicated mapping key error on line 19; it is for section description of parameter Content-Type.
I have studied openapi documentation, but I didn't see anything wrong with my YAML file.
I am not sure why you get that error, I tried to find out in which language Swagger is written, as there are several YAML parsers out there that are known to have problems, but couldn't easily determine that using google or wikipedia.
You don't have any duplicate keys in your file, but it is invalid (i.e. not valid YAML) because of the indentation of the key content (the second occurrence, the one under paths →
/v1/service/uri → post → responses → 200), that should be aligned with
description as that key cannot have a value node that is both a scalar (OK) as well as a mapping node content: ....
I want to send a object in a post but with a api key.
How can I describe this in OpenAPI-Specification 2.0?
I tried this (a subset in yaml):
paths:
/eau:
post:
tags:
- Pets
summary: Send a pet
description: 'Send a pet'
operationId: sendapet
consumes:
- application/json
produces:
- application/json
parameters:
- in: body
name: pet
description: Send a pet
required: true
schema:
$ref: '#/definitions/pet'
- in: header
name: api_key
But at
- in: header
name: api_key
I get the following error:
Schema error at paths['/pet'].post.parameters[1].in
should be equal to one of the allowed values
allowedValues: body
Jump to line 36
Schema error at paths['/pet'].post.parameters[1]
should match exactly one schema in oneOf
Jump to line 36
Schema error at paths['/pet'].post.parameters[1]
should NOT have additional properties
additionalProperty: in, name
Jump to line 36
The error occurs because the header parameter is missing type.
However, API keys are related to authentication/authorization, so they should be described using the securityDefinitions and security keywords instead of a header parameter:
securityDefinitions:
apiKey:
type: apiKey
in: header
name: api_key
security:
- apiKey: []
More info: API Keys