How to implement an empty path in YAML file - rest

I am trying to implement the below calls:
POST https://host/sessions
DELETE https://host/sessions/{session_id}
The POST call is to establish a session, the DELETE call is to log out an established session.
So, in the YAML file, how to have an empty base path? It's currently a slash in the YAML file as it's a required filed, but the slash is redundant. Any idea? Thanks.
swagger: '2.0'
info:
version: '0.0.1'
title: authenticate
#description: To be provided
# #termsOfService:To be provided
contact:
name: test
basePath: /sessions
paths:
/:
post:
summary: eatablish a session
description: sessions is a collection.This POST creates a new session in the sessions collection and the name of the session returned by this command is the session token.
consumes:
- "application/json"
parameters:
- in: header
name: user_name
type: string
required: true
- in: header
name: password
type: string
required: true
responses:
200:
description: establish a session successfully
400:
$ref: "#/responses/BadRequest"
500:
description: unexpected error
schema:
$ref: '#/definitions/errorModel'
/{session_id}:
delete:
summary: log out
description: use sessionid to log out an established session.
produces:
- application/json
parameters:
- in: path
name: session_id
type: string
required: true
responses:
200:
description: log out a session successfully
400:
$ref: "#/responses/BadRequest"
500:
description: unexpected error
schema:
$ref: '#/definitions/errorModel'

Swagger defines
A relative path to an individual endpoint. The field name MUST begin with a forward slash (/).
Therefore, the slash is required and you can't have an empty path.

Related

AWS HTTP API Integration with AWS Step Functions -> Sending Multiple Values in the Input

I have a Type: AWS::Serverless::HttpApi which I am trying to connect to a Type: AWS::Serverless::StateMachine as a trigger. Meaning the HTTP API would trigger the Step Function state machine.
I can get it working, by only specifying a single input. For example, the DefinitionBody when it works, looks like this:
DefinitionBody:
info:
version: '1.0'
title:
Ref: AWS::StackName
paths:
"/github/secret":
post:
responses:
default:
description: "Default response for POST /"
x-amazon-apigateway-integration:
integrationSubtype: "StepFunctions-StartExecution"
credentials:
Fn::GetAtt: [StepFunctionsApiRole, Arn]
requestParameters:
Input: $request.body
StateMachineArn: !Ref SecretScannerStateMachine
payloadFormatVersion: "1.0"
type: "aws_proxy"
connectionType: "INTERNET"
timeoutInMillis: 30000
openapi: 3.0.1
x-amazon-apigateway-importexport-version: "1.0"
Take note of the following line: Input: $request.body. I am only specifying the $request.body.
However, I need to be able to send the $request.body and $request.header.X-Hub-Signature-256. I need to send BOTH these values to my state machine as an input.
I have tried so many different ways. For example:
Input: " { body: $request.body, header: $request.header.X-Hub-Signature-256 }"
and
$request.body
$request.header.X-Hub-Signature-256
and
Input: $request
I get different errors each time, but this is the main one:
Warnings found during import: Unable to create integration for resource at path 'POST /github/secret': Invalid selection expression specified: Validation Result: warnings : [], errors : [Invalid source: $request specified for destination: Input].
Any help on how to pass multiple values would so be appreciated.

Cannot pass dynamic query parameters when using `express-openapi-validator`

The idea is taken from here stack-overflow
After adding a parameter that is supposed do allow dynamic query parameters, it gives error.
Query Example:
/pets:
get:
description: |
Returns all pets
operationId: findPets
parameters:
- name: params
in: query
required: false
schema:
type: object
# If the parameter values are of specific type, e.g. string:
# additionalProperties:
# type: string
# If the parameter values can be of different types
# (e.g. string, number, boolean, ...)
additionalProperties: true
# `style: form` and `explode: true` is the default serialization method
# for query parameters, so these keywords can be omitted
style: form
explode: true
responses:
'200':
description: pet response
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/Pet'
default:
description: unexpected error
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
Executing a query, returns
{"message":"Cannot convert undefined or null to object"}
To Reproduce
Clone this repository
run npm install
run npm start
run curl http://localhost:3000/v1/pets\?type\=dog\&limit\=10\&test\=query
Expected behavior
It must allow all the query strings
This was the bug in the express-openapi-validator package.
It is now fixed in v4.4.2
To test out the functionality, see this example project

Openapi3 and CSV response (for Dredd)

I test my Api with DREDD against it's specification (written in Openapi3 considering, painfull limitations of Support by Dredd considered). No I have one endpoint, which produces CSV-data if the Accept-header is set so.
'/my-endpoint':
summary: ...
description: ...
get:
# parameters:
# -
# in: header
# name: Accept
# description: "Response format: application/json or text/csv"
# example: "text/csv"
responses:
'200':
description: ...
content:
text/csv:
schema:
type: string
example:
summary: 'csv table'
value: 'cell1, cell2'
When I run the test with Dredd the test fails with
expected:
headers:
body:
[
{
"key": "summary",
"value": "csv table"
},
{
"key": "value",
"value": "cell1, cell2"
}
]
statusCode: 200
Clearly there is something misunderstood and Dredd expects still JSON. Also the API is not told to produce the CSV Version. If I commit in the Accept header in the code abvoe I get the very same result - the expecetd result above and as actual result the JSON version of the my-endpoint-data and also ad warning:
warn: API description parser warning in .../tmp/transformed.specs.yml: 'Parameter Object' 'name' in location 'header' should not be 'Accept', 'Content-Type' or 'Authorization'
I read here and here: Header parameters named Accept, Content-Type and Authorization are not allowed. To describe these headers, use the corresponding OpenAPI keywords - but what are they? According to this and this page it seems to be enough to specify a response of the given type but that is clearly not enough to tell Dredd to produce such a header.
You got an error because the value of the example key is meant to be a literal example value. So in your case it's treated as an object with the summary and value properties.
Change your definition to:
content:
text/csv:
schema:
type: string
example: 'cell1, cell2'
Or if you want to provide a summary/description for an example, use examples instead:
content:
text/csv:
schema:
type: string
examples:
csv table:
summary: A CSV table with 2 cells
value: 'cell1, cell2'

swagger limit error codes of response

There is a swagger 2.0 file I am dealing with, where I want to specify that the error code from my response can only be USERNAME_VALIDATION_FAILED or EMAIL_VALIDATION_FAILED. This is due to a swagger-ui view of the swaggerfile where every response error can have the 20 error codes defined in the Error code enum.
How to limit the possible error codes for a specific response?
In my swaggerfile there is the request
/register:
post:
...
parameters:
...
responses:
...
400:
description: Username or email validation failed, possible values for code are USERNAME_VALIDATION_FAILED, EMAIL_VALIDATION_FAILED
schema:
$ref: '#/definitions/Error'
and my Error looks like
Error:
type: object
properties:
code:
type: string
enum:
- USERNAME_VALIDATION_FAILED
- EMAIL_VALIDATION_FAILED
- USERNAME_EXISTS
- ...
I would suggest something like
schema:
$ref: '#/definitions/Error.code.of(USERNAME_VALIDATION_FAILED, EMAIL_VALIDATION_FAILED)'
You can't override the enum of a property, so you need a separate model:
RegistrationError:
type: object
properties:
code:
type: string
enum:
- USERNAME_VALIDATION_FAILED
- EMAIL_VALIDATION_FAILED
Error:
type: object
properties:
code:
type: string
enum:
- USERNAME_VALIDATION_FAILED
- EMAIL_VALIDATION_FAILED
- USERNAME_EXISTS
- ...
If the error models have common properties, you can "inherit" them from a base model to reduce code duplication:
BaseError:
type: object
properties:
message:
type: string
RegistrationError:
allOf:
- $ref: "#/definitions/BaseError"
- type: object
properties:
code:
type: string
enum:
- USERNAME_VALIDATION_FAILED
- EMAIL_VALIDATION_FAILED
Error:
allOf:
- $ref: "#/definitions/BaseError"
- type: object
properties:
code:
type: string
enum:
- USERNAME_VALIDATION_FAILED
- EMAIL_VALIDATION_FAILED
- USERNAME_EXISTS
- ...

REST API - Swagger - Don't understand why "Not a valid parameter definition"

I face issue with my swagger file :
swagger: '2.0'
paths:
/currencies:
get:
responses:
'200':
description: ''
summary: 'list currencies summary'
x-auth-type: None
x-throttling-tier: Unlimited
produces:
- application/json
description: 'list currencies description'
'/currencies/{currencieId}':
get:
responses:
'200':
description: ''
description: 'Single currency description'
parameters:
- name: currencieId
in: path
allowMultiple: false
required: true
type: string
description: 'paramter description'
summary: 'Single currency'
x-auth-type: None
x-throttling-tier: Unlimited
produces:
- application/json
info:
title: MDM
version: v1
Here is my issue :
✖ Swagger Error
Not a valid parameter definition
Jump to line 20
Details
Object
code: "ONE_OF_MISSING"
params: Array [0]
message: "Not a valid parameter definition"
path: Array [5]
0: "paths"
1: "/currencies/{currencieId}"
2: "get"
3: "parameters"
4: "0"
schemaId: "http://swagger.io/v2/schema.json#"
inner: Array [2]
level: 900
type: "Swagger Error"
description: "Not a valid parameter definition"
lineNumber: 20
Issue in swagger editor
I am a bit lost with that ....
Thanks for your help.
Julien
Remove allowMultiple: false from the definition of the currencieId parameter. That eliminates the error.
The allowMultiple keyword does not exist in the OpenAPI (fka Swagger) Specification 2.0. It was used in v1.2, but in 2.0 it was replaced with type: array and collectionFormat.
allowMultiple: false is not correct