...
As multiple operations return the same response (status code and data), the responses section is defined as a global components object and then reference via $ref at the operation level. This is useful for error responses with the same status codes and response body. In CPS, even the success scenarios are included in the responses section as shown below.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
responses:
NotFound:
description: The specified resource was not found
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorMessage'
Unauthorized:
description: Unauthorized
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorMessage'
Forbidden:
description: Forbidden
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorMessage'
BadRequest:
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorMessage'
Conflict:
description: Conflict
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorMessage'
Ok:
description: OK
content:
application/json:
schema:
type: object
Created:
description: Created
content:
text/plain:
schema:
type: string
NoContent:
description: No Content
content: {} |
The success responses Ok Created and No Content still would have the sample response irrespective of the API, hence these could still be included in the global components section. But as the response body would be different for different APIs while returning status code 200(OK), this should be defined along with the API and should not be global. We could define the response body schema under the schema ' section in global propertiescomponents.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
schemas:
AnchorDetails:
type: object
title: Anchor details by anchor Name
properties:
name:
type: string
example: Anchor_1
dataspaceName:
type: string
example: Dataspace_1
schemaSetName:
type: string
example: Schema_set_1 |
...