HTTP请求标头和请求正文中包含什么？

我正在为移动客户端开发一组Web服务，并且要求将唯一的设备ID包含在所有请求中，存储在某些请求中，并用于过滤其他请求中的结果。

有人建议将其放在自定义HTTP标头中，因为它将包含在所有请求中，因此我开始怀疑可以使用什么标准来确定给定的数据段是否属于标头或与标头中的其他数据一起请求正文。

有没有这样的标准？

当信息很重要时，您应该将其放入体内。

为什么？

1. 允许代理服务器修改标头。许多配置为剥离不知道的任何标头。但是，这仅在使用未加密的HTTP时适用。使用HTTPS时，代理无法更改标头，因为标头已加密。
2. 使用Web服务时，通常是为了与其他设备，服务和工具实现互操作性。与Web服务一起使用的大多数API和工具都可以轻松更改请求，但是许多API和工具使添加自定义标头变得困难甚至无法实现。当然，这仅在需要互操作性时才适用。但是，当您不在乎时，您可能会想问自己，为什么首先使用Web服务，而不仅仅是在原始TCP上构建自己的协议。

尽管这条线有些模糊，但对我而言，一条经验法则是：您的业务逻辑所处理的数据应该在正文中，元数据可以/应该放在标头中。

另一种看待它的方法是：仅在特定种类的请求中出现的数据应该在正文中，而在整个应用程序中一致处理的数据应该放在标头中。

还有一种观点是：您能想象一条数据是全局处理的吗，例如通过路由器/防火墙而不是您的应用程序？如果是的话，它可能应该放在标题中而不是正文中。

应用这些规则的一些示例如下：

• 安全凭证进入标头，因为最有可能在应用程序的所有位置对它们进行相同的处理。在实现级别，可能会有一些请求过滤器拒绝没有有效凭据的请求，而不考虑实际的端点处理该请求，以防它确实通过了过滤器。
• 另一方面，如果您具有允许管理员将用户添加到系统中的端点，则要创建的用户的登录名应在请求正文中，因为：a）由应用程序的业务逻辑处理，b）它出现在此特定端点中，而不出现在其他端点中。
• 控制缓存的选项很可能适合头文件（除非缓存是应用程序业务逻辑的核心部分）。

回到关于唯一设备ID的问题：如果在任何地方都以一致的方式使用它，例如仅用于日志记录，则可以将其放在标头中。但是，如果根据端点使用不同的方式来过滤请求，则最好将其放在主体中。当然，如果您同时拥有两种用例，则最好只采用一种传递方式（可能是标头），而不是强迫API用户将相同的数据放在两个地方，这给您带来了一个难题输入不一致或实施某种形式的验证。

客户请求的内容；不会在对同一服务器的多个请求中更改的消息将成为HEADER的一部分，例如凭据，对于每个请求经常更改的其他消息将成为BODY的一部分。

要么

邮件/正文内容的属性将进入标题。例如）编码类型，内容长度，内容类型。

和

在您的情况下，应在网址中添加类似过滤器参数作为查询/请求参数。

/mobiles?type=MOTO&colour=black

在静态服务中，URL本身将引用一个对象

/conferences/{conference_id} ->指具体会议