Change Details

"As a Client Developer, I want error responses to follow the RFC7807 standard, so I can use a library or standard error handler to manage all error output." Original task description below. ---- The [[ https://tools.ietf.org/html/rfc7807 | RFC7807 ]] defines a standard for HTTP errors formatting and I think we need to follow the standard. The current format is mostly compatible with what the RFC is asking for with one exception of i18n - the RFC calls for content-negotiation (e.g. Accept-Language header) for translated messages, while the current implementation returns a map with wiki content language and English for all the messages. See T226598 for more details on i18n. Even if we decide not to follow the RFC7807 guidelines verbatum we need to bring our response format as close to it as practical.

"As a Client Developer, I want error responses to follow the RFC7807 standard, so I can use a library or standard error handler to manage all error output." Original task description below. ---- The [[ https://tools.ietf.org/html/rfc7807 | RFC7807 ]] defines a standard for HTTP errors formatting and I think we need to follow the standard. The current format is mostly compatible with what the RFC is asking for with one exception of i18n - the RFC calls for content-negotiation (e.g. Accept-Language header) for translated messages, while the current implementation returns a map with wiki content language and English for all the messages. See T226598 for more details on i18n. Even if we decide not to follow the RFC7807 guidelines verbatum we need to bring our response format as close to it as practical. We need to keep compatibility for the existing error message format, so we should only add RFC7807-compatible fields, without deleting the old fields. At some point, we'll deprecate the old fields and remove them at the next major API version.

"As a Client Developer, I want error responses to follow the RFC7807 standard, so I can use a library or standard error handler to manage all error output." Original task description below. ---- The [[ https://tools.ietf.org/html/rfc7807 | RFC7807 ]] defines a standard for HTTP errors formatting and I think we need to follow the standard. The current format is mostly compatible with what the RFC is asking for with one exception of i18n - the RFC calls for content-negotiation (e.g. Accept-Language header) for translated messages, while the current implementation returns a map with wiki content language and English for all the messages. See T226598 for more details on i18n. Even if we decide not to follow the RFC7807 guidelines verbatum we need to bring our response format as close to it as practical. We need to keep compatibility for the existing error message format, so we should only add RFC7807-compatible fields, without deleting the old fields. At some point, we'll deprecate the old fields and remove them at the next major API version.