REST中的元信息：Envelope VS HTTP Header

Question

从服务器检索资源表示时，可能需要获取一些其他信息。我所说的信息是指特别到资源，例如一个特殊的错误信息（“由于猫过马路而无法检索到请求的狗！”）。

我进行了一项研究，我对最强 RESTful方式感到有点困惑（不言而喻，我指的是REST的HTTP实现）。老实说，我觉得没有“标准”的采用方式，但我希望听到不同的意见。

这是我的：

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

使用信封 - 这种策略有两个原因：它非常灵活，这是99％的客户用来查看metainfo的地方。从理论的角度来看，我们可以说包含对象的信封是我们资源的表示。当被要求提供汽车对象时，服务器可以自由地为该请求提供最有意义的表示。糟糕的是，它听起来与完全反对REST的SOAP方法非常相似。

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

Answer 1

在内容中包含元数据（＆＃34;信封＆＃34;）似乎更容易处理，更难以错过。另一方面，可以将HTTP标头添加到现有服务，而不会破坏向后兼容性。

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

Answer 2

这三个选项都很好。实际上，您还没有建议第四个：将元数据嵌入模型数据中或模型数据下方（而不是在第三个选项中建议的信封周围）。

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

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