REST策略重载GET动词

Question

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

1. 通过ID获取成员
2. 通过SSN获取会员
3. 通过电话和姓氏（均必须通过传递）组合获取成员

采用REST精神并提供这种灵活性的推荐策略是什么？

我能想到的一些选择是：

基于参数

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

单独的端点

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

RPC自定义

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

Answer 1

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

例如，考虑一下如何在网络上进行此操作。您将提供表单，每组搜索条件一个。消费者将选择要使用的表单，然后提交表单，而不必知道URI是什么。

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

  

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

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

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

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

Answer 2

REST≠漂亮网址。两者是正交的。
我觉得您的问题是关于后者的。

尽管其他答案都不错，但是如果您希望您的API使用HTML表单，请在集合/user资源上针对所有字段，甚至对于ID使用查询参数（假设有人在其中键入这些参数）根据他们从书桌上的纸等获得的信息。

如果您的服务器能够为每个记录生成链接，请始终生成诸如/users/{id}之类的规范链接，请勿在不同的URL下重复数据。