Description
Each operation in OpenAPI 3.0 and 2.0 needs a nonempty responses object with at least one response definition. This differs from an empty, unused reusable-response map such as components.responses or the OpenAPI 2.0 top-level responses.
Potential impact
Without a response contract, consumers may not know the status codes or data formats to expect, and SDK generation or document-based validation may be incomplete.
Remediation
Define at least one actual response in each operation’s responses. Describe normal responses and known errors, using default where appropriate. Do not invent a 200 response that the server does not return merely to fill the document.
Examples
These OpenAPI 3.0 operation-response excerpts omit info. The first operation’s responses: {} lacks the required response definition.
Before
{
"openapi": "3.0.0",
"paths": {
"/": {
"get": {
"responses": {}
}
}
}
}
After
{
"openapi": "3.0.0",
"paths": {
"/": {
"get": {
"responses": {
"200": {
"description": "OK"
}
}
}
}
}
}
The second defines a 200 response, assuming that this is the actual normal result. Add returned content and error responses according to the real contract.