0

我正在尝试向 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

4

1 回答 1

1

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

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

是的。

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

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

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

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

查看RFC 7231 的第 3.4 节可能很有用，该节描述了内容协商的语义。

于 2018-09-05T16:53:56.733 回答