rest - REST : Envelope VS HTTP Header 中的元信息

Question

从服务器检索资源表示时，可能需要获取一些附加信息。我指的信息具体指的是资源，例如特殊的错误消息(“无法检索所请求的狗，因为猫过马路!”)。

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

这是我的:

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

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

中介 - 我的想法是务实:不要滥用标题自定义并使用您拥有的自定义。如果您需要实现 HATEOAS，请使用 Link header 。如果您需要表示缓存资源，请使用ETag。如果您需要大量自定义，请使用信封作为资源，并在信封部分提供所需的元信息。

Answer 1

在内容(“信封”)中包含元数据似乎更容易处理并且更难错过。另一方面，HTTP header 可以添加到现有服务中，而不会破坏向后兼容性。

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