-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guidance on error responses - are error messages standardized or can they be custom? #113
Comments
Hi @trehman-gsma my 2cents:
|
@trehman-gsma Thank you for raising this issue. As RFC 9457 Problem Details for HTTP APIs was published this year we can think of using "Problem JSON" in CAMARA the same way as CloudEvents format was introduced. |
I would prefer standardized error objects too. But also over multiple APIs. So e.g. there could be one UNKNOWN_PHONENUMBER which could be reused in multiple APIs. Using very specific attributes, like in the RFC, I think it's difficult to evaluate. But the idea of global types ("type": "https://example.com/probs/out-of-credit") I would support. |
I was working towards some suggestions to #31, which is referenced above, so instead I’ll post it here.
An example of the modified QoD API (forked from v0.10.0-rc) that is making use of an example CAMARA_common.yaml can be found in the following link: https://github.com/gmuratk/QualityOnDemand-httpresponses/blob/main/code/API_definitions/qod-api.yaml |
Discussed in further issues |
Problem description
This is related to error responses within the API design guidelines.
An example of a JSON error response structure is below:
I understand that the status values and code values are standardized. Is there guidance on the message value - can it be a custom per Operator?
To elaborate, please consider this example error response from the SimSwap YAML for the scenario where an input phone number cannot be found:
I assume that for this specific scenario, all Operators must align with the same status value (404) and the same code value (SIM_SWAP.UNKNOWN_PHONE_NUMBER). For the message value, can each Operator provide a custom human readable message or must they align with the error message provided in the YAML for the specific scenario?
Possible evolution
A paragraph within the Error Responses section of API design guidelines documenting the group view on error messages.
The text was updated successfully, but these errors were encountered: