如何在接受不同 Accept 标头值的 REST 端点中处理错误响应。答案

【问题标题】：How to handle error responses in a REST endpoint that accepts different Accept header values.如何在接受不同 Accept 标头值的 REST 端点中处理错误响应。
【发布时间】：2019-02-10 17:53:34
【问题描述】：

我正在尝试向 REST 端点添加新的内容类型。目前它只返回 json 但我现在还需要能够返回一个 CSV 文件。

据我所知，最好的方法是使用带有值 text/csv 的 Accept 标头，然后添加一个能够对此做出反应并将返回的正文转换为正确的 @987654323 的转换器@ 表示。

我已经能够做到这一点，但是我在处理异常时遇到了问题。直到知道，所有返回的错误都在json 中。前端期望任何500 状态代码都包含带有错误的特定正文。但是现在，通过添加将application/json 或text/csv 返回到我的端点的选项，如果出现错误，用于转换正文的转换器将是jackson 转换器或我的自定义转换器取决于传递的Accept 标头。此外，我的前端将需要读取返回的 content-type 并根据返回的表示类型解析值。

这是处理这种情况的正常方法吗？

更快的解决方法是忘记Accept 标头并包含一个指示预期格式的url 参数。这样做，我可以直接在控制器中更改响应的content-type 和数据解析，因为GET 请求将不包含任何Accept 标头，它将能够接受任何东西。代码的某些部分已经这样做了，其中唯一预期的响应格式是CSV，所以除非有更好的处理方法，否则我将很难为Accept 标头的使用辩护。

【问题讨论】：

标签： rest error-handling content-type http-accept-header

【解决方案1】：

我的前端将需要读取返回的内容类型并根据返回的表示类型解析值。

这是处理这种情况的正常方法吗？

是的。

例如，RFC 7807 描述了描述问题的常用格式。因此，服务器将在响应中发送问题的application/problem+json 或application/problem+xml 表示，以及标头中的常用元数据。

了解application/problem+json 的消费者可以使用 in 解析数据，并将对问题的有用描述转发给用户/日志。不了解表示仅限于对标头中的信息进行操作的消费者。

更快的解决方法是忘记 Accept 标头并包含一个指示预期格式的 url 参数。

这也很好 - 更准确地说，您可以让不同的资源负责您支持的每种不同的媒体类型。

查看section 3.4 of RFC 7231 可能会有所帮助，它描述了内容协商的语义。

【讨论】：

我没想到会有一个回答说使用参数也可以，但实际上我发现了与此相关的讨论，还添加了第三个使用扩展的选项 (softwareengineering.stackexchange.com/questions/139654/…)。据我了解，最终是务实/学术之间的权衡，因为有很多关于协议解释和 REST 论文的讨论。