我开发了一个移动应用程序，需要访问和更新服务器上的数据。我想在每个请求中包含例如设备 ID 和一些令牌。
我目前正在正文中包含这些内容，因此即使要求从服务器读取数据，我也只有 POST 请求。但是，读取数据的请求应该是 GET，但我如何包含这些信息？我应该只向 GET 请求添加一个正文吗？我应该添加一些标题吗？如果是这样，我可以只创建任何名称的自定义标头吗？感谢您的指导。
您的 FCM 令牌和设备 ID 实际上是请求的身份验证凭据。在 HTTP 中，通常将Authorization标头与方案一起使用以向服务指示
在这种情况下，可以在 HTTPAuthorization标头中使用持有者令牌。 虽然持有者令牌通常与 JWT 令牌一起使用，但它们不需要是该特定格式。
您可以像基本身份验证方案一样连接 FCM 令牌和设备 ID。
顺便说一句，不建议在 GET 请求中使用正文，因为某些代理可能不会保留它。
好吧，REST基本上只是基于浏览器的Web中已经使用多年的概念的概括。在应用程序中一致地应用这些概念后，您将可以自由地发展服务器端，同时获得对客户端更改的鲁棒性。但是，为了从这些强大的属性中受益，因此需要遵循一定数量的约束，例如遵守底层传输协议的规则或依赖 HATEOAS 来进一步驱动应用程序状态。与服务交互所需的任何带外信息都将导致耦合，因此有可能中断客户端或阻止服务器将来更改。
REST 架构设计中一个常见的误解是 URI 应该是有意义的，并向客户端表达语义。但是，在 REST 体系结构中，URI 只是指向客户端永远不应解析的资源的指针。是否调用 URI 的决定应基于随附的链接关系名称，该名称可以在媒体类型或通用标准中进一步描述。即在可分页的集合链接关系上，如prev、next、first或last，可以使客户端选择翻阅集合。因此，URI 的实际结构对 REST 来说根本不重要。过度设计的 URI 可能会进一步导致类型化资源。因此，我实际上不喜欢 restful-url 这个词。那么非 restful-url 是什么样子的呢？
虽然通过POST请求发送所有内容在技术上是一个有效的选择，但它也有一些缺点需要考虑。IANA 维护着您可能使用的可用 HTTP 方法的列表。每种方法都传达不同的前提和语义。即，在服务器上调用GET操作的客户端应该可以安全地假设调用资源不会导致任何状态更改(安全)，并且在出现网络问题的情况下，可以再次重新发出请求而无需任何进一步的考虑(幂等)。这些对于网络爬虫来说是非常重要的好处。除此之外，中间节点可以根据请求方法和生成的响应确定是否可以缓存响应。虽然这在将客户端与服务器分离方面不一定是一个问题，但它有助于从服务器本身消除不必要的工作负载，尤其是在资源状态很少变化时，从而提高整个系统的可伸缩性。
另一方面，POST并不传达这种特性。在发送POST请求以检索数据时，客户端无法确定该请求是否真的导致资源状态发生变化。在网络问题上，请求可能已经到达服务器，并且可能已经创建了一个新资源，尽管响应只是中途丢失，这可能会使客户端处于不确定状态，无论它是否可以重新发送请求。此外，默认情况下，POST 操作的响应不可缓存，只有在显式添加频率信息后才能缓存。POST方法调用请求目标资源处理提供的表示形式，这些表示形式编码为资源自己的语义。由于实际上任何东西都可以发送到服务器，因此服务器教客户端请求应该是什么样子是很重要的。在HTML中，这是通过Web表单完成的，用户可以将数据填写到某些输入字段中，然后在单击提交按钮时将数据发送到服务器。同样的概念也可以应用于移动或REST应用程序。重复使用 HTML 表单或定义自己的application/vnd.company-x.forms+json，公开(或在 IANA 注册)该媒体类型的描述，都可以帮助您做到这一点。
不幸的是，关于在哪里包含某些数据的实际问题是通用的，以给出一个简短的答案。这进一步取决于数据是否应该可共享或具有一些与安全相关的问题。虽然参数可能在一定程度上通过 URL 参数(查询、矩阵、路径)传递到服务器，但通常它可能不是最佳选择，即使查询参数在 SSL 交互中是加密的。但是，如果 URI 应该可粘贴而不会丢失信息，则此选项很方便。当然，这不应该包含与安全相关的数据。与安全相关的信息几乎总是应该在 HTTP 标头中传递，或者至少在实际有效负载本身中传递。
通常，您应该区分内容和描述内容的元数据。虽然内容应该是请求/响应的实际有效负载，但描述内容的任何元数据都应该放在标头中。考虑要传输的图像。由于您不想弄乱图像的字节，因此您只需附加图像名称，压缩格式以及描述如何将字节转换回标头中的图像表示的其他属性。这种区分可能最适合标准化表示格式，因为您需要在规范的能力范围内保证互操作性。不过，即使在那里，事情也可能开始变得模糊。即在EDI领域，存在几个定义明确的标准，如Edifact，Tradacoms等，可用于交换不同的消息格式，如发票，订单，订单响应，...尽管不同的ERP系统说不同的俚语，但这就是事情开始变得复杂和混乱的地方。
如果您控制您的表示格式，因为您可能没有标准化它或只是模糊地定义它，那么事情可能更难确定是将其放在您的文档中还是通过标题附加它。在这里，它完全取决于您的设计。我还看到了在有效负载中定义自己的标头部分的表示形式，因此重新创建了类似于 envelop-header-body 结构的 SOAP。
关于您的问题，是否可以根据您的要求创建自定义标头。我的回答是肯定的。
如上所述，您可以使用标准授权标头在每个请求中发送令牌。另一种替代方法是定义自定义标头。但是，您必须通过服务器端实现一个逻辑来支持该自定义标头。
您可以在此处阅读更多相关信息