jguertin
commented
4 years ago For HTTP requests, we can expand as needed, but typically I've found the following to be sufficient for most use cases:
- 404 (NOT FOUND): Obviously, only when the resource requested in the URL path is not found. For example, a GET of an individual financial statement should provide a 404 if the provided id isn't found. This doesn't apply for data that isn't found but is specified by other means (url parameter, request body)
- 400 (BAD REQUEST): General problems with user input. We should include a message helping the user identify the issue. These errors should be correctable by the end user. Any validation errors or other incorrect data provided should result in this type of message. Generally, these exceptions would explicitly be thrown in the application.
- 500 (INTERNAL SERVER ERRORS): These are unexpected errors that happen within the application. It may be an intentional response that occurs when a downstream resource is unavailable or it may be some internal to the application such as a null reference error. Error messages for these responses should provide very little detail to the end user. However, they are typically actionable problems and must be captured in the logs at a high severity level.
- 401 (UNAUTHORIZED): When access is attempted without providing a valid JWT in the expected fashion
- 403 (FORBIDDEN): The user does not have permission to view the requested resource, or perform the requested action. For example, we might consider using this error code if a user attempts to access a Financing Statement for which they are not the registering party.
We should specify what the response body looks like for error messages, and it should be consistent. Across the board.
We should do a little pre-planning of what HTTP status codes will be returned by the /search endpoint of the ppr-api. This should be documented in the AOS docs.