我正在尝试向REST端点添加新的内容类型。目前它只返回json但我现在需要能够返回一个CSV文件。
据我所知，最好的方法是使用值为Accept的text/csv标头，然后添加一个能够对此作出反应并将返回的主体转换为正确的CSV表示的转换器。
我已经能够做到这一点但是我遇到了处理异常的问题。直到知道，返回的所有错误都在json中。前端期望任何500状态代码包含具有错误的特定正文。但现在，通过添加选项将application/json或text/csv返回到我的端点，如果出现错误，用于转换主体的转换器将是jackson转换器或我的自定义转换器，具体取决于通过的Accept头。此外，我的前端需要读取返回的content-type并根据返回的表示类型解析值。
这是处理这种情况的正常方法吗？
更快的解决方法是忘记Accept标头并包含指示预期格式的url参数。这样做，我将能够直接在控制器中更改响应的content-type和数据解析，因为GET请求将不包含任何Accept标头，它将能够接受任何内容。代码的某些部分已经在这里做了唯一预期的响应格式是CSV所以我将很难保护Accept头的使用，除非有更好的方法来处理它。
我的前端需要读取返回的内容类型，并根据返回的表示类型解析值。
这是处理这种情况的正常方法吗？
是。
例如，RFC 7807描述了描述问题的通用格式。因此，服务器将在响应中发送问题的application/problem+json或application/problem+xml表示，以及标头中的常用元数据。
了解application/problem+json的消费者可以使用in解析数据，并将问题的有用描述转发给用户/记录任何内容。不理解该表示的消费者仅限于对标题中的信息进行操作。
更快的解决方法是忘记Accept标头并包含一个指示预期格式的url参数。
这也很好 - 更确切地说，您可以拥有一个不同的资源来负责您支持的每种不同媒体类型。
查看section 3.4 of RFC 7231可能很有用，qazxswpoi描述了内容协商的语义。