errors optionally returning a X-Reason header without a response body feels... out of the ordinary? i also don't think it'll scale well or provide the best developer experience.
if the protocol is leaning into json, why not return errors as json? example:
{
"error": "pov_required",
"message": "Algorithm 'for-you' requires a pov."
}
- additional fields can be added more easily than entirely new headers.
- it's much more common to log or convert the response to an error object than pick out specific headers.
X-Reason would have to be exposed for cors.- idea: i've found a machine-readable
error code of sorts to be helpful in discriminating between different errors.
errors optionally returning a
X-Reasonheader without a response body feels... out of the ordinary? i also don't think it'll scale well or provide the best developer experience.if the protocol is leaning into json, why not return errors as json? example:
{ "error": "pov_required", "message": "Algorithm 'for-you' requires a pov." }X-Reasonwould have to be exposed for cors.errorcode of sorts to be helpful in discriminating between different errors.