1 / 5

Ticket #46 Clarify error responses and allow non-HTTP error codes

Ticket #46 Clarify error responses and allow non-HTTP error codes. General Recommendations for REST. Include the HTTP status code for clients that can't read this from the response. Include a provider specific error code for more granular error information.

abena
Télécharger la présentation

Ticket #46 Clarify error responses and allow non-HTTP error codes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ticket #46Clarify error responses and allow non-HTTP error codes

  2. General Recommendations for REST • Include the HTTP status code for clients that can't read this from the response. • Include a provider specific error code for more granular error information. • Include a human-readable error that can be presented to an end user. • Include a detailed error that can be used by a developer to diagnose the problem. • Include links to online resources with more information about the error. http://soabits.blogspot.com/2013/05/error-handling-considerations-and-best.html ​https://tools.ietf.org/html/draft-nottingham-http-problem-04

  3. Recommendation: Use Problem Details • Pros • Includes user and and developer information in title (required) and detail (optional) fields. • Includes HTTP status code (optional) in httpStatus field. • Includes provider-specific status code (required) in problemType field.

  4. Recommendation: Use Problem Details • Cons • SCIM requires HTTP status code, but this is optional in Problem Details. • SCIM may wish to dictate that this is required. • The problemType field is required and is defined as: "An absolute URI [RFC3986] that identifies the problem type. When dereferenced, it SHOULD provide human-readable documentation for the problem type (e.g., using HTML).“ • It is a nice feature to make this dereferenceable, but could be seen as an imposition on some service providers.

  5. Example HTTP/1.1 401 UnauthorizedContent-Type: application/api-problem+jsonContent-Language: en { "problemType": "​http://example.com/errors/insufficient-access", "title": "You do not have the required permissions to create a new user.", "detail": "Creating a user requires RIGHT_CREATE_USER." } Provider-specific code User-friendly message Developer-friendly message Note: This is now single-valued instead of multi-valued. Multi-valued errors are typically used to communicate errors per field in a request.

More Related