oas3-tools does auth and validation of requests. If auth fails or request is not valid then oas3-tools returns http error with appropriate status code and body in format which is different than we have defined in openAPI specs.
Example of responses:
status code: 401
body:
{
"message": "unauthorized",
"errors": [
{
"path": "/v1/update-ltp",
"message": "unauthorized"
}
]
}
status code: 400
body:
{
"message": "request.body should have required property 'uuid'",
"errors": [
{
"path": ".body.uuid",
"message": "should have required property 'uuid'",
"errorCode": "required.openapi.validation"
}
]
}
However, openAPI contains schemas for all http errors (400+) with structure like:
{
"code": 0,
"message": "string"
}
That means an API consumer would expect response body in format as is described in openAPI but it will be different in reality.
We should either modify oas3-tools or change openAPI specification for all apps.
Priority:Low;
AffectedFlow:None;
oas3-tools does auth and validation of requests. If auth fails or request is not valid then oas3-tools returns http error with appropriate status code and body in format which is different than we have defined in openAPI specs.
Example of responses:
status code: 401
body:
{ "message": "unauthorized", "errors": [ { "path": "/v1/update-ltp", "message": "unauthorized" } ] }status code: 400
body:
{ "message": "request.body should have required property 'uuid'", "errors": [ { "path": ".body.uuid", "message": "should have required property 'uuid'", "errorCode": "required.openapi.validation" } ] }However, openAPI contains schemas for all http errors (400+) with structure like:
{ "code": 0, "message": "string" }That means an API consumer would expect response body in format as is described in openAPI but it will be different in reality.
We should either modify oas3-tools or change openAPI specification for all apps.