This class implements RFC7807 "problem detail", a way to carry machine-
readable details of errors in a HTTP response to avoid the need to
define new error response formats for HTTP APIs.
Consumers MUST use the "type" string as the primary identifier for
the problem type; the "title" string is advisory and included only
for users who are not aware of the semantics of the URI and do not
have the ability to discover them (e.g., offline log analysis).
Consumers SHOULD NOT automatically dereference the type URI.
The "status" member, if present, is only advisory; it conveys the
HTTP status code used for the convenience of the consumer.
Generators MUST use the same status code in the actual HTTP response,
to assure that generic HTTP software that does not understand this
format still behaves correctly. See Section 5 for further caveats
regarding its use.
Consumers can use the status member to determine what the original
status code used by the generator was, in cases where it has been
changed (e.g., by an intermediary or cache), and when message bodies
persist without HTTP information. Generic HTTP software will still
use the HTTP status code.
The "detail" member, if present, ought to focus on helping the client
correct the problem, rather than giving debugging information.
Consumers SHOULD NOT parse the "detail" member for information;
extensions are more suitable and less error-prone ways to obtain such
information.
Note that both {@link BaseProblemDocumentProperties.type type} and {@link BaseProblemDocumentProperties.instance instance} accept relative URIs; this means
that they must be resolved relative to the document's base URI, as
per [RFC3986], Section 5.
This class implements RFC7807 "problem detail", a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.
Official Documentation @ https://datatracker.ietf.org/doc/html/rfc7807
Consumers MUST use the "type" string as the primary identifier for the problem type; the "title" string is advisory and included only for users who are not aware of the semantics of the URI and do not have the ability to discover them (e.g., offline log analysis). Consumers SHOULD NOT automatically dereference the type URI.
The "status" member, if present, is only advisory; it conveys the HTTP status code used for the convenience of the consumer. Generators MUST use the same status code in the actual HTTP response, to assure that generic HTTP software that does not understand this format still behaves correctly. See Section 5 for further caveats regarding its use.
Consumers can use the status member to determine what the original status code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without HTTP information. Generic HTTP software will still use the HTTP status code.
The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information.
Consumers SHOULD NOT parse the "detail" member for information; extensions are more suitable and less error-prone ways to obtain such information.
Note that both {@link BaseProblemDocumentProperties.type type} and {@link BaseProblemDocumentProperties.instance instance} accept relative URIs; this means that they must be resolved relative to the document's base URI, as per [RFC3986], Section 5.