RFC: Standardize API error messages #48
Conversation
Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io> Co-authored-by: Taylor Silva <tsilva@pivotal.io>
Signed-off-by: Taylor Silva <tsilva@pivotal.io>
Not sure why it's PR concourse#53, when the previous one was concourse#48...perhaps because of discussions? Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
chenbh
left a comment
chenbh
left a comment
There was a problem hiding this comment.
I'm not sure this qualifies as a RFC under then new guidelines, it feels like this falls under the Small features which only impact a narrow use case and affect users in an obvious way. category. wdyt?
| { | ||
| "type": "MachineReadable", | ||
| "message": "human readable" | ||
| } |
There was a problem hiding this comment.
I like the jsonAPI idea of enclosing this inside a top level errors field, makes it more obvious it's an error if I forgot to look at the status code
{
"errors": [
{
"type": ...
}
]
}| If further arbitrary details are required any number of extra keys can be added | ||
| to the JSON object. |
There was a problem hiding this comment.
What do you think of generating an UUID on 5xx errors? It could make errors a lot easier to track down in the logs
|
|
||
| # Proposal | ||
|
|
||
| When the Concourse API returns an error (4xx and 5xx status codes) it should |
There was a problem hiding this comment.
Should we differentiate between different levels of verbosity for 4xx vs 5xx codes? 4xx codes usually indicate user error and misuse of the API, in which case a helpful error message would be appreciated. 5xx codes indicate something has gone wrong on the server side and there's nothing the user can really do with the error message.
|
I agree. Going to close this. |
4 participants
Rendered
Signed-off-by: Aidan Oldershaw aoldershaw@pivotal.io
Co-authored-by: Taylor Silva tsilva@pivotal.io