Closed jlurien closed 1 year ago
If it is not too late, perhaps we could also explore RFC 7807 to define Error Info as ProblemDetails
. This provides a format that will be uniform across APIs and each API can extend or provide detailed scenario examples as appropriate.
My preference is option 1 (common ErrorInfo
schema with specific examples). For most clients, that should be enough information.
In my experience, it is rare for a client to implement any sort of logic to automatically recover from errors, other than to try again with the same request (for any timeout or not available error), or to refresh the OAuth token if that has expired. Otherwise, the operation fails and the error gets logged. And then somebody may investigate if it keeps happening.
Common model errors defined and consensuated in CAMARA API Guidelines, are focused on make the same error logic in all APIs implementations in all Telcos involved.
ErrorInfo Schema is defined to be enriched by the specific error types.
Totally Agree with @jlurien
My preference is for approach 1
My preference is also for approach 1.
Approach 1 is more simple, my preference
Changes applied on PR #162
As we got an agreement on this issue (refer to common ErrorInfo model), I proceed to close it. Thanks to all for your valuable feedback.
In the different WGs we have 2 approaches to specify the schema for error responses:
1) Reference to the common
ErrorInfo
model:2) Reference to the specific model for the status and code:
In the second case there is a strict specification that for certain error response the
status
andcode
values must be the one in theenum
, while in the first case, we are relying on examples and external doc to guide implementations. On the other hand, the first approach is more simple and it may ease the code generation as schema model is reused.It would be convenient to define a global guideline son all APIs follow the same approach.