时间戳

首页 > 解决方案 > 构建 REST API：如何决定哪些参数用于标头、正文、URL 或查询？

rest - 构建 REST API：如何决定哪些参数用于标头、正文、URL 或查询？

问题描述

你如何决定参数的去向？假设 API 用于一个对象，该对象有一个 ID、几个字段，并且每个请求可能有也可能没有令牌。对象必须有 GET、PUT、POST 和 DELETE 请求。

标签： rest

解决方案

通常，您希望将标识资源所需的所有参数直接编码到某处的 URI中。这允许您为 URI 添加书签以供以后重复使用，并与其他人/进程共享该书签。

例子：

此资源所需的所有上下文都GET在这里。您可以单击它、保存它、通过电子邮件发送它，它本身仍然很有用。

那么信息在 URI 中的什么位置？

如果仅在下载表示后客户端才需要该信息，那么您可以考虑将其编码到片段中。

URI 的片段标识符组件允许通过参考主要资源和附加标识信息来间接标识次要资源。

在 Web 上，片段很有用，因为它们允许您调用用户代理来关注表示中的特定元素。该片段不通过网络发送，而仅在客户端使用。想想数据传输对象——一个大的可缓存文档（所以我们不需要很多往返），其中有很多指向其中特定信息的 URI。

其他参数可以编码为路径段或查询字符串。机器不在乎（20 年前，这有点不太正确——我们有时不得不解决不能正确处理 URI 的查询部分的缓存）。

通过查询字符串配置参数的 URIapplication/x-www-form-urlencoded在 Web 上很方便，因为 HTML 支持在客户端上创建这些标识符。

如今，我们可以使用URI 模板来描述如何计算新的 URI，这为您提供了更多选择。

相对分辨率为我们提供了一种通用机制，用于根据给定的引用标识符计算新的 URI。考虑带有符号链接的点引用。该机制主要基于导航 URI 的分层部分，即path。

机器不关心资源的层次结构，标识符的层次结构是并行的

# Here's an identifier for a collection
/collection
# Here's an identifier for a member of this collection
/collection/member

# Here's an identifier for a collection
/2c957fb6-ac92-4fdb-a086-02292c3b7c7c
# Here's an identifier for a member of this collection
/41d36a69-d10c-4503-8e5e-3b2d64e9c3a6

就机器而言，所有这些样品都很好；但人类往往更容易与顶级组合一起工作。

标头是属于“通过网络传输文档”领域的元数据。

正文是文档本身——它是通过网络传输的消息（http 请求和标头在某种意义上是承载消息的信封）。是的，这有时意味着消息中的信息也会被复制到标头中，或者通过模板复制到 target-uri 中。

推荐阅读