An API specification needs to specify the responses
for all API operations. Each operation must have at least one response defined, usually a successful response. A response is defined by its HTTP status code and the data returned in the response body and/or headers.
Reusing Responses
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 |
---|
language | yml |
---|
title | Response component in CPS |
---|
collapse | true |
---|
|
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 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 components.
Code Block |
---|
language | yml |
---|
title | Anchor Schema sample |
---|
collapse | true |
---|
|
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 |
Code Block |
---|
language | yml |
---|
title | Array of anchors schema |
---|
collapse | true |
---|
|
ArrayOfAnchors:
type: array
items:
type: object
properties:
name:
type: string
example: my_anchor
dataspace:
type: string
example: my_dataspace
schemaSet:
type: string
example: my-schema-set |
These schemas could be used in the API specification as below:
Code Block |
---|
language | yml |
---|
title | Get all anchors definition using response and example |
---|
collapse | true |
---|
|
'/v1/dataspaces/{dataspace-name}/anchors':
get:
description: 'Read all anchors, given a dataspace'
tags:
- cps-admin
summary: Get anchors
operationId: getAnchors
parameters:
- name: dataspace-name
in: path
description: dataspace-name
required: true
schema:
type: string
responses:
'200':
description: OK
content:
application/json
schema:
$ref: '#/components/schemas/ArrayOfAnchors'
'400':
$ref: 'components.yml#/components/responses/BadRequest'
'401':
$ref: 'components.yml#/components/responses/Unauthorized'
'403':
$ref: 'components.yml#/components/responses/Forbidden'
'404':
$ref: 'components.yml#/components/responses/NotFound' |
This change would also introduce change in the object returned for these API implementation methods in the Controller class.