truly generic problems -- i.e., conditions that might apply to any resource on the Web -- are usually better expressed as plain status codes. For example, a "write access disallowed" problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory.
If there is no information in response other than the error status code, there is not need to return a Problem Details body in it. The response code is enough.
it is RECOMMENDED that absolute URIs be used in "instance" when possible, and that when relative URIs are used, they include the full path (e.g., "/instances/123").
Samea s the RECOMMENDATION for "type" URI
Consumers SHOULD NOT parse the "detail" member for information; extensions are more suitable and less error-prone ways to obtain such information
For machine readable info realted to problem occurence, extension members should be use (e.g. "errors" extension member that is commonly used in validation failure problem types)
The "detail" member is a JSON string containing a human-readable explanation specific to this occurrence of the problem
Things to note:
it is RECOMMENDED that absolute URIs be used in "type" when possible and that when relative URIs are used, they include the full path (e.g., "/types/123")
"type" URI SHOULD BE an absolute URI and if it is a relative URI, it SHOULD include the full path i.e. starting with /.
The data model for problem details is a JSON [JSON] object; when serialized as a JSON document, it uses the "application/problem+json" media type. Appendix B defines an equivalent XML format, which uses the "application/problem+xml" media type.
These are two new MIME types defined by this specification.
Problem type definitions MAY extend the problem details object with additional members that are specific to that problem type
What this implies is that extensions are part of the problem type definition.
Therefore if you want to use an extension field, the problem type needs to be defined (and the extension should be defined as part of that).
When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on), although it MAY be localized to suit client preferences (expressed with the Accept-Language request header).
"title" of a Problem Details object whose type is about:blank should be the same as the recommended phrase for the HTTP response status code with which the object is being returned.
If the type URI is a locator (e.g., those with an "http" or "https" scheme), dereferencing it SHOULD provide human-readable documentation for the problem type
Consider this vis-a-vis the RECOMMENDATION in section 4 that type URI SHOULD resolve to HTML documentation that "explains how to solve the problem"
A problem type URI SHOULD resolve to HTML [HTML5] documentation that explains how to resolve the problem
So "type" URI is RECOMMENDED to be:
New problem type definitions MUST document:¶ a type URI (typically, with the "http" or "https" scheme)¶ a title that appropriately describes it (think short)¶ the HTTP status code for it to be used with
The wording implies that a new problem type must be documented.
Moreover, these are the three fields that must be documented whenever a new problem type (identified by its type URI) is defined.
Moreover,
The "detail" string, if present, ought to focus on helping the client correct the problem
The language indicates this is an optional field.
Also, it can vary from occurrence to occurrence. Clearly there may be occurrence in which no detail needs to be provided. Therefore we cannot assume this field is required in general.
It SHOULD NOT change from occurrence to occurrence of the problem, except for localization
This suggests it SHOULD BE provided always.
If you could sometimes provide it and at other times not, then it would indeed change from occurrence to occurrence which SHOULD NOT happen. This, together with the fact that a type MUST be documented when defining a new probem type (see section 4 of this document), means it is reasonable to assume that this is a Required field.
The "status" member, if present, is only advisory
The language indicates it is optional (and, if present, is subject to certain constraints)
Consumers MUST use the "type" URI (after resolution, if necessary) as the problem type's primary identifier.
For consumers to be able to use it, the type URI must be part of the response