refactor: RFC 9457 obsoletes 7807, refer to it

[scop]

No substantial changes that would run at odds with the elaboration in the guidelines that I can see.

[tfrauenstein]

👍

[ePaul]

Thanks for the pointer, I missed this new RFC.

There are these changes from RFC-7807 to RFC-9457 (mentioned in the Appendix D) :

• Section 4.2 introduces a registry of common problem type URIs

  The registry so far doesn't have any types which seem to be generally useful (except the default about:blank).

• Section 3 clarifies how multiple problems should be treated

  • For multiple problems of the same type, use an extension with more problem objects in it (only the relevant fields).
  • For multiple problems of different types, just keep the most important/urgent one.

• Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced

  It also contains this recommendation:

  As a result, 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").

  This goes contrary to our existing recommendation to not use absolute problem types (though it fits the "use full path" one).
  I suggest we discuss in our next API guild meeting whether it makes sense to adjust our guideline here. (Related: Improvements for Problem guideline (176) #763)

[tkrop]

Section 3 clarifies how multiple problems should be treated

For multiple problems of the same type, use an extension with more problem objects in it (only the relevant fields).
For multiple problems of different types, just keep the most important/urgent one.

Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced

@ePaul I don't think that the difference is so big compared to the short sentences in https://www.rfc-editor.org/rfc/rfc7807#section-3.1. We deliberately decided to not follow the convention of absolute URIs to relief our API designers from providing a registry of error types. I still support this decision.

[tkrop]

👍