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.
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. Example should be added for success scenario 204 Created.
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.
These schemas could be used in the API specification as below:
This change would also introduce change in the object returned for these API implementation methods in the Controller class.
Adding Examples
You can add examples to parameters, properties and objects to make OpenAPI specification of your web service clearer. Examples can be read by tools and libraries that process your API in some way. For example, an API mocking tool can use sample values to generate mock requests. In CPS, the examples are added at object and property level.
Note: ErrorMessage is a common schema used for all error scenarios. And as the examples as defined at property level, different errors correspond to the same example.