This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.
This document obsoletes RFC 7807.
Thanks, and you are basically correct on both counts:
I supported an API that had a Batch endpoint that could be “partial success” – and that was a mess.
I have been experimenting with something where you have standardized elements because the Fetch API doesn’t throw on 4XX/5XX, so having one if check, rather than two, makes sense.
Status codes for batch operations is always a mess. Do you return a 400 because one request made no sense even if the rest succeeded, or return a 200? 207 exists but it’s not really directly part of the HTTP spec and only seems to support XML response bodies.
Edit: @[email protected] if the RFC proposed a solution to responses for batch operations where some responses may contain errors, then that would be interesting. The RFC, from what I understand, proposes a format for error responses, but does not seem to support mixed error/success responses.
Thanks, and you are basically correct on both counts:
At this point, it’s an experiment.
Status codes for batch operations is always a mess. Do you return a 400 because one request made no sense even if the rest succeeded, or return a 200? 207 exists but it’s not really directly part of the HTTP spec and only seems to support XML response bodies.
Edit: @[email protected] if the RFC proposed a solution to responses for batch operations where some responses may contain errors, then that would be interesting. The RFC, from what I understand, proposes a format for error responses, but does not seem to support mixed error/success responses.