Misusing instance field in the problem description of the error response #49
-
|
After re-reading RFC-7807 and pondering deeply the purpose of the Instance field, it appears that this spec is misusing the "instance" field pretty drastically. RFC 7807 describes instance as "A URI reference that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced." It also identifies the "instance" field as an optional field, not required. This indicates that the URI contained in the "instance" field should point not at the URI where the error occurred, but rather to a URI which identifies the specific error that occurred. If we're planning on requiring the instance field on SPS applications, we should think deeply about if and how we want to surface the further information that may be present at the URI referenced in the instance field. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Agreed that "instance" is best positioned with a specific reference to the exact error. It is much more anemic and less helpful as just an instance of the associated problematic resource. Feel free to provide the best contextual "instance" information you have in your API Error Responses, or do not use it at all if you cannot as it is optional like you say. Hopefully as the SPS REST API Standard usage matures at SPS, we will be able to approach the usage of "instance" more effectively, along with well-defined and specific "types" as well. |
Beta Was this translation helpful? Give feedback.
Agreed that "instance" is best positioned with a specific reference to the exact error. It is much more anemic and less helpful as just an instance of the associated problematic resource. Feel free to provide the best contextual "instance" information you have in your API Error Responses, or do not use it at all if you cannot as it is optional like you say.
Hopefully as the SPS REST API Standard usage matures at SPS, we will be able to approach the usage of "instance" more effectively, along with well-defined and specific "types" as well.