用于重载 GET 动词的 REST 策略答案

【问题标题】：REST strategy for overloading GET verb用于重载 GET 动词的 REST 策略
【发布时间】：2018-09-29 04:29:56
【问题描述】：

考虑需要创建一个 GET 端点以使用 4 个选项中的任何一个来获取成员详细信息（这在具有 RPC 调用的遗留应用程序中很常见）

在实现 REST 精神的同时提供这种灵活性的推荐策略是什么？

我能想到的一些选项是：

基于参数

/user/{ID}  
/user?ssn=?
/user?phone=?&lname=?

单独的端点

/user/{ID}
/user/SSN/{SSNID}
/user/{lname}/{phone}

用于自定义的 RPC

/user/{ID}
/user/findBySSN/
/user/findbycontact/

【问题讨论】：

由于客户端不应该解释 URI，而只能根据通过随附的链接关系名称所做的决定来调用它们，因此您使用哪种样式并不重要。更重要的是，您以某种方式命名链接关系名称，以便让客户端了解是否调用 URI。您甚至可以对参数进行编码，即通过 base64、自定义算法或其他不使用的算法，或者实际上使用 tiny-url。服务器至少需要知道如何以某种方式提取实际参数。
将 SSN 放在 url 中可能不明智。这是非常敏感的信息，而且网址有点泄漏。不要拿用户的隐私冒险。

标签： rest

【解决方案1】：

REST 不在乎您对标识符使用什么拼写。

例如，想想您将如何在网络上执行此操作。您将提供表格，每组搜索条件一个。消费者会选择要使用的表单并提交表单，而无需知道 URI 是什么。

对于 HTML 表单，有特定的处理规则来描述如何将表单信息复制到 URI 中。该表单采用URI Template 的形式。

URI 模板既提供 URI 空间的结构描述，又提供变量值时的机器可读指令，说明如何构造与这些值对应的 URI。

但没有任何规则限制服务器提供 URI 模板，该模板指示客户端将变量值复制到路径段而不是查询字符串中。

换句话说，在 REST 中，服务器保留对自己的 URI 空间的控制权。

您有时可能更喜欢使用 path 段，因为它们具有层次结构，如果您希望客户端在您的表示中使用 relative resolution 或 relative references，这可能会很方便。

【讨论】：

【解决方案2】：

REST ≠ 漂亮的 URL。两者是正交的。
我觉得你的问题是关于后者的。

虽然其他答案都很好，但如果您希望 API 使用 HTML 表单，请在集合 /user 资源上为所有字段（即使是 ID）使用查询参数（假设人类根据他们从桌子上的纸上获得的信息等）

如果您的服务器能够生成指向每条记录的链接，请始终生成规范链接，例如 /users/{id}，不要在不同 URL 下重复数据。

【讨论】：