How to provide separate examples for each HTTP status code? - swagger

I run into problem while trying to instruct Dredd to issue a different requests to trigger two distinct scenarios: success with code 201 and failure with code 400.
I tried to setup a separate example per HTTP status code but couldn't manage to do that.
I can add example section in requestBody but then it will be used in both example - for success and failure.
openapi: 3.0.2
info:
description: Body example per HTTP code illustration
version: 1.0.0
title: Profile
tags:
- name: profile
description: User profiles
paths:
/profiles:
post:
tags:
- profiles
summary: Create profile
operationId: createProfile
requestBody:
description: Create Profile
content:
application/json:
schema:
$ref: '#/components/schemas/CreateProfile'
required: true
responses:
'201':
description: Successful operation
headers:
Location:
schema:
type: string
description: Profile location
'400':
description: Profile is invalid (missing fields/null values)
content:
application/json:
schema:
$ref: '#/components/schemas/ProfileCreationError'
examples:
failing_scenrio:
summary: An example tailored to work with Dredd
value:
name: can't be blank
email: can't be blank
components:
schemas:
CreateProfile:
type: object
required:
- name
- email
- age
properties:
name:
type: string
email:
type: string
age:
type: integer
format: int32
minimum: 0
ProfileCreationError:
type: object
properties:
name:
type: string
email:
type: string
age:
type: integer
I would like to be able to run tests for both HTTP codes: 201 and 400. Bonus points for an example of how to do same thing with path param. For example, to provide both found and not found examples for /profiles/{id} (i.e. 200 and 404).

The OpenAPI 3 support is currently (July 2019, Dredd v11.2.9) experimental and this particular behavior is still undefined. The problem is tracked as a GitHub issue #1257. I recommend you to subscribe to the issue to see when it gets resolved or consider contributing a solution.

Related

Swagger : Get method using body is not working also changed into the query, path, header still not working

i am making openapi.yaml till now as well as deploying my test API's on the google cloud endpoints is working but now i made some changes i am sending parameter in body to the get api (e.g email) and getting some response but actually on the local it is working fine with postman after deploying openapi.yaml file it is not working on the google cloud endponits portal
So, anybody has any solution or answers for this so please help me
For safety i am also sharing error screenshot also y code snippet
"/api/getRecords":
get:
description: "Get All Records Details."
operationId: "getRecords"
produces:
- "application/json"
parameters:
- description: "Message to getRecords"
in: query
name: getRecords
type: object
required: false
schema:
$ref: "#/definitions/echoMessage"
responses:
200:
Also,
Try your code like this :
# [START swagger]
swagger: "2.0"
info:
description: "A simple Google Cloud Endpoints API example."
title: "Endpoints Example"
version: "1.0.0"
host: "abc.appspot.com"
# [END swagger]
parameters:
email:
name: email
in: query
type: string
required: true
Then use shorthand syntax in the path:
path:
"/api/getRecords":
get:
description: "Get All Records Details."
operationId: "getRecords"
parameters:
- $ref: "#/parameters/email"
responses:
200:
description: "Get records details"
schema:
$ref: "#/definitions/postMessage"
It will work.

Swagger/open api 3.0 links not rendered properly [duplicate]

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

Is it possible to create environment specific paths in OpenApi 3?

My Goal:
I am working on a set of endpoints in an application and I have a swagger 2.0 file with all of the endpoints. They are working on our test environment, but we will not yet make them available in prod.
My question is:
If I upgrade to OpenApi 3, is it possible to hide the paths I don't want to be visible in prod via the servers object?
I didn't think it was from reading the docs, but I would love to be wrong there because I'd prefer to have just one api.yml instead of one for each environment.
Thank you!
I did some testing and the answer is no.
You CAN chose which servers users can run a "try it out" test. Which is a great feature
But, you can NOT hide an endpoint based on which server is chosen from the dropdown at the top of the page. Which was the original goal
Below is the OpenAPI yaml I used in an online editor to verify. I used the online editor here: Swagger Editor and used the petstore.yaml example provided at the OpenAPI-Specification github repo as a starting point. I removed all but one endpoint to shorten things. If you are starting an open api document I would recommend visiting OpenAPI or Swagger to find documentation and a full example.
openapi: "3.0.0"
info:
version: 1.0.0
title: Swagger Petstore
description: Try to not show get when prod server is chosen
license:
name: MIT
servers:
- url: http://prod
- url: http://test
- url: http://dev
paths:
/pets:
get:
summary: List all pets
operationId: listPets
tags:
- pets
parameters:
- name: limit
in: query
description: How many items to return at one time (max 100)
required: false
schema:
type: integer
format: int32
servers:
- url: http://test
- url: http://dev
responses:
200:
description: An paged array of pets
headers:
x-next:
description: A link to the next page of responses
schema:
type: string
content:
application/json:
schema:
$ref: "#/components/schemas/Pets"
default:
description: unexpected error
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
components:
schemas:
Pet:
required:
- id
- name
properties:
id:
type: integer
format: int64
name:
type: string
tag:
type: string
Pets:
type: array
items:
$ref: "#/components/schemas/Pet"
Error:
required:
- code
- message
properties:
code:
type: integer
format: int32
message:
type: string

Swagger 2.0 duplicated mapping key parser error

I have a swagger file for an API that is going to reside inside IBM API Connect. I typed it out from an IBM tutorial, and I was trying to replicate what the instructor was doing(he did not provide any source files, so I had to type it out).
The tutorial is available here: https://www.youtube.com/watch?v=hCvUYd67rbI
The guy is copy-pasting the swagger file inside the APIConnect local designer around 21:40.
I took the swagger file and put it into http://editor.swagger.io/ and I got a bunch of parser errors:
Errors
Hide
Parser error duplicated mapping key
Jump to line 31
Semantic error at definitions.shipping.properties.xyz.type
Sibling values are not allowed alongside $refs
Jump to line 86
Semantic error at definitions.shipping.properties.cek.type
Sibling values are not allowed alongside $refs
Jump to line 89
I did some digging, and I did not find a lot of resources for my kind of problem. I double-checked if I typed it out correctly from the tutorial. Maybe it has something to do with an older version of API Connect being used in ths tutorial.
Thanks in advance for anyone who can help.
EDIT:
Sorry, it was a bit late so I was tired, I am adding the source code in the yaml file:
info:
x-ibm-name: logistics
title: logistics
version: 1.0.0
schemes:
- https
basePath: /logistics
consumes:
- application/json
produces:
- application/json
securityDefinitions:
clientIdHeader:
type: apiKey
in: header
name: X-IBM-Client-Id
security:
- clientdHeader: []
x-ibm-configuration:
testable: true
enforced: true
cors:
enabled: true
gateway: datapower-gateway
catalogs:
apic-dev:
properties:
runtime-url: $(TARGET_URL)
properties:
shipping_svc_url:
value: 'http://shipping.think.ibm:5000/calculate'
description: Location of the shipping calculator service
encoded: false
paths:
/shipping:
get:
responses:
'200':
description: 200 OK
schema:
$ref: '#/definitions/shipping'
summary: Calculate shipping costs to a destination zip code
operationId: shipping.calc
parameters:
- name: zip
type: string
required: true
in: query
description: Destination zip code.
/stores:
get:
responses:
'200':
description: 200 OK
schema:
$ref: '#/definitions/store_location'
tags:
- stores
summary: Locate store near zip code
operationId: get.stores
parameters:
- name: zip
type: string
required: true
in: query
definitions:
rates:
properties:
next_day:
type: string
example: '20.00'
two_day:
type: string
example: '17.00'
ground:
type: string
example: '8.00'
required:
- two_day
- next_day
- ground
shipping:
properties:
xyz:
type: string
$ref: '#/definitions/rates'
cek:
type: string
$ref: '#/definitions/rates'
required:
- xyz
- cek
store_location:
properties:
google_maps_link:
type: string
example: 'https://www.google.com/maps?q=34.1030032,-118.4104684'
required:
- google_maps_link
There's typo: securityDefinitions defines clientIdHeader, but security refers to clientdHeader (..ntd.. instead of ..enId..).
"Sibling values are not allowed alongside $refs" is not a syntax error, but rather a warning. It's caused by this line:
definitions:
rates:
properties:
...
shipping:
properties:
xyz:
type: string # <---------------
$ref: '#/definitions/rates'
$ref is a JSON Reference, it works by replacing itself and all sibling attributes with the content the $ref is pointing at. So, the type attribute and any other attributes alongside $ref will be ignored. The warning informs you about this in case there are important attributes alongside $ref -- these attributes need to be moved into the $ref'erenced schema to have effect.
That said, xyz being type: string does not make sense, because rates is an object and not a string.
You should also consider adding type: object to the rates, shipping and store_location definitions to indicate that they are objects.

OpenAPI Spec Connection Refused

I am having problem with my OpenAPI spec file. I am trying to call an exposed url to 'GET' an id but every time i port forward the service to my local and then try to send request through API document my connection is refused. I would appreciate any help. The id that i am expecting would be in JSON format. Below is my spec file
openapi: "3.0.0"
info:
version: 1.0.0
title: Id Generator
servers:
url: www.someurl.com
paths:
/posts:
get:
summary: Get Id
operationId: id
tags:
- posts
responses:
200:
description: successful operation
content:
application/json:
schema:
$ref: "#/definition/Post"
default:
description: unexpected error
content:
application/json:
schema:
$ref: "#/definition/Error"
definition:
Post:
type: object
properties:
id:
type: string
Error:
properties:
id:
type: string
As of June 21 2017, OpenAPI Specification 3.0 is not out yet and Swagger UI does not support OpenAPI 3.0 yet, so your example can't possibly work. Keep an eye on Swagger UI releases page to know when support for OpenAPI 3.0 is available.
Also, you'll need to fix the errors in your spec to make it a valid OpenAPI 3.0 spec:
servers is an array, so change that to:
servers:
- url: http://www.someurl.com
Response status codes must be quoted: "200" or '200'.
Indent the $ref under schemas:
schema:
$ref: "#/definition/Post"
...
schema:
$ref: "#/definition/Error"
Change definition to components->schemas and fix the indentation for Post:
components:
schemas:
Post:
type: object
properties:
id:
type: string
Error:
properties:
id:
type: string

Resources