REST中的元信息：信封与HTTP头

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

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

这是我的：

使用HTTP头-这样做的主要原因是HTTP已经提供了一个信封，那么为什么要在协议的信封中插入一个新的自定义信封呢？此外，HTTP是一种应用程序协议，应该支持应用程序交互。然而，将新信息推送到标题部分有两个缺点：首先，您将包含自定义内容，这与“统一接口”的建议不太相符。 此外，通过查看标准头，您将看到绝大多数与连接和信息交换相关（

接受

，

连接

，

转发

，

主机

，

用户代理

等），并以非常不可知的方式引用有效负载（

内容类型

，

如果匹配

，

Etag

，等等）。对于特定于资源的信息，它似乎是一个不合适的上下文

使用信封-这种策略很好，有两个原因：它非常灵活，99%的客户都会在这里查看metainfo。从理论上看，我们可以说包含对象的信封是我们资源的表示。当要求提供汽车对象时，服务器可以自由地ovide是该请求最有意义的表示形式。糟糕的是，它听起来非常类似于完全反对REST的SOAP方法

---

中介-我的想法是务实的：不要滥用标题自定义，而是使用您已有的标题自定义。如果需要实现HATEOAS，请使用

链接

标题。如果需要表示缓存资源，请使用

ETag

。如果需要大量自定义，请使用信封作为资源并在信封部分提供所需的元信息。

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

---

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

所有三种方法都可以。事实上，您没有建议第四种方法：将元数据嵌入模型数据处或之下（而不是像第三种选择中建议的那样，将元数据嵌入模型数据周围的信封中）

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

---

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

非常感谢您的回答。我同意您对实用主义的考虑，但我的问题更侧重于模型方面。我的意思是，我知道使用web工具使用标题和信封的优缺点。但是，t是什么他做得对吗？为什么？