Problem details for HTTP APIs HTTP status codes are sometimes not sufficient to convey enough information about an error to be helpful. The RFC 7807 defines simple JSON and XML document formats to inform the client about a problem in a HTTP API. It's a great start point for reporting errors in your API. It also defines the application/problem+json and application/problem+xml media types.
8 Matching Annotations
- Mar 2023
-
stackoverflow.com stackoverflow.com
-
- Sep 2022
-
rororo.readthedocs.io rororo.readthedocs.io
-
"detail": [ { "loc": [ "body", "name" ], "message": "Field required" }, { "loc": [ "body", "email" ], "message": "'not-email' is not an 'email'" } ]
not complient with Problem Details, which requires
detailsto be a string
-
-
lurumad.github.io lurumad.github.io
-
jonathancrozier.com jonathancrozier.com
-
For example, let’s consider the type property. For most of the projects I am working on, it isn’t practical to have a webpage dedicated to each type of possible error.
That's not required. The standard doesn't require this to be a URL locator — merely a URI! So you can just make up a URI and use it even if it's not resolvable. ... like you did for the URN below.
-
For the instance property, the most practical way I’ve found of implementing this is to define a URN that encapsulates additional information regarding the error. Here is an example URN for reference. urn:companyname:api:error:protocol:badRequest:f29f57d7-e1f8-4643-b226-fa18f15e9b71
-
-
blog.restcase.com blog.restcase.com
-
"type": "https://example.com/problems/request-parameters-missing"
-