rest - 如何在接受不同的Accept header 值的REST端点中处理错误响应。

Question

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

据我所知，最好的方法是使用带有Accept值的text/csv header ，然后添加一个能够对此使用react的转换器，并将返回的主体转换为正确的CSV表示形式。

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

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

更快的解决方法是忘记Accept header ，并包含一个指示预期格式的url参数。这样，我将能够在 Controller 中直接更改响应的content-type和数据解析，因为GET请求将不包含任何Accept header ，并且它将能够接受任何内容。代码的某些部分已经在执行此操作，其中唯一的预期响应格式是CSV，因此除非有更好的处理方法，否则我将很难捍卫Accept header 的使用。

Answer 1

my frontend is going to need to read the content-type returned and parse the value based on the type of representation returned.

Is this the normal approach to handle this situation?

是。
例如， RFC 7807描述了描述问题的通用格式。因此，服务器将在响应中发送问题的 application/problem+json或 application/problem+xml表示形式，以及 header 中的常规元数据。
知道 application/problem+json的消费者可以使用in解析数据，并将有用的问题描述转发给用户/日志。不了解表示形式的消费者仅限于对 header 中的信息进行操作。

A faster workaround would be to forget about the Accept header and include a url parameter indicating the format expected.

很好-更准确地说，您可以拥有一个不同的资源来负责所支持的每种不同的媒体类型。
查看 section 3.4 of RFC 7231可能有用，它描述了内容协商的语义。