REST Error Handling
- Trip Gilman
Target release | 7.0 |
|---|---|
Epic |
|
Document status | DRAFT |
Document owner | @Trip Gilman |
Designer |
|
Tech lead |
|
Technical writers |
|
QA |
|
Objective
Provide a standardized way for errors to be returned from REST requests made to OpenMethods service endpoints.
Requirements
Requirement | User Story | Importance | Jira Issue | Notes | |
|---|---|---|---|---|---|
| 1 | Follow REST best practices for errors | HIGH |
|
| |
| 2 | Ability to differentiate between system level errors and application errors |
|
|
|
|
| 3 | Support for compound errors |
|
|
|
|
| 4 | Error content should be context survivable | The error content should contain enough information about the context in which it happened so it can be logged and understood later |
|
|
|
User interaction and design
Example Error Content
{
"requestURL": "<full url that produced the error>",
"requestMethod": "<GET | POST | PUT | PATCH | DELETE | OPTIONS>",
"requestBody": "<any post/put/patch content of the request>", //optional
"httpStatus": "<http response code>",
"errorCode": "<error code>", //optional
"errorMessage": "<human readable error message>",
"errorRawMessage": "<original third-party error message>", //optional
"stackTrace": "<encoded text blob containing language specific stack trace information>", //optional
"causedBy": //optional
{
<full content of error>
}
}Open Questions
Question | Answer | Date Answered |
|---|---|---|
|
Out of Scope
Related content
This document may contain confidential and/or privileged information belonging to OpenMethods. If you are not the intended recipient (or have received this document in error) please notify the sender immediately and destroy this document. Any unauthorized copying, disclosure, or distribution of the material in this document is strictly forbidden.