2

从服务器检索资源表示时，可能需要获取一些附加信息。我的意思是专门指资源的信息，例如一个特殊的错误消息（“请求的狗无法被检索，因为一只猫穿过马路！”）。

我做了一项研究，我对最RESTful 的方式感到有些困惑（不用说，我指的是 REST 的 HTTP 实现）。老实说，我觉得没有“标准”的方式可以采用，但我想听听不同的意见。

这是我的：

使用 HTTP Header - 这样做的主要原因是因为 HTTP 已经提供了一个信封，那么为什么要在协议的内部注入一个新的自定义信封呢？此外，HTTP 是一种应用程序协议，它应该支持应用程序交互。但是，将新信息推送到 Header 部分有两个缺点：首先，您将包含自定义内容，这不太符合“统一界面”建议。此外，通过查看标准标头，您会发现其中绝大多数都与连接和信息交换（Accept、Connection、Forwarded、等）相关Host，User-Agent并以非常不可知的方式引用有效负载（Content-Type、If-Match、Etag， ETC。）。对于特定于资源的信息，这似乎是不合适的上下文。

使用信封——这个策略有两个好处：它非常灵活，这是 99% 的客户习惯于查看元信息的地方。从理论上讲，我们可以说包含对象的信封是我们资源的表示。当被要求提供汽车对象时，服务器可以自由地为该请求提供最有意义的表示。不好的是，它听起来与完全反对 REST 的 SOAP 方法非常相似。

调解- 我的想法是务实的：不要滥用 Header 自定义并使用您拥有的自定义。如果您需要实现 HATEOAS，请使用LinkHeader。如果您需要代表您的资源进行缓存，请使用ETag. 如果您需要大量定制，请使用信封作为资源并在信封部分提供您需要的元信息。

4

2 回答 2

3

在内容（“信封”）中包含元数据似乎更容易处理，也更难错过。另一方面，可以在不破坏向后兼容性的情况下将 HTTP 标头添加到现有服务中。

如果没有严格的要求，我会选择更方便的。务实的方式对我来说很好。

于 2016-11-28T10:50:52.153 回答
2

这三个选项都很好。事实上，您并没有提出第四个建议：将元数据嵌入模型数据处或下方（而不是像您的第三个选择中所建议的那样，将元数据嵌入它周围的信封中）。

您对信封的厌恶是可以理解的，因为它类似于 SOAP，但 SOAP 的非 RESTful 特性更多地与信封中真实方法/缓存/日期元数据的隐藏传输有关，而不是在 HTTP 层中，而不是仅仅存在一个信封。正如您所指出的，信封成为资源表示的一部分，只要您的媒体类型描述正确，就可以了！

就个人而言，我会尽可能多地放入标准HTTP 标头，以及表示中的所有其他内容（模型数据之外或邻近模型数据，我不在乎）。我不会使用自定义标题。据我所知，这与您的第三选择一致。

于 2017-01-02T21:26:38.427 回答