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