使用其他查询选项命名GET

Question

假设您有一个已经通过id获取用户的REST服务，因此该URL看起来像

GET /users/{userId}

但您想创建一个通过电子邮件获取用户的重复Web服务，所以：

GET /users/{email}

哪个更好？

方法1：

同样的方法：

  /users/{input}
  ...
  if(isEmail(input)) queryByEmail(input);
  else queryById(input);

方法2：

不同的方法：

GET /users/{userId}

GET /usersByEmail/{email}

Answer 1

由于电子邮件地址和ID之间没有实际重叠。我只想使用相同的端点。特别是如果GET /users/{id}已经是发布的界面。

所以，我会选择第一种方法。

GET /users/{identifier}

然后在API服务器上，您必须添加一个小支票，无论{identifier}是否为数字。

我还想注意一下，＃＆＃34;漂亮的网址＆＃34;不要让它成为REST :)你可能会想看这个讲座：https://www.youtube.com/watch?v=pspy1H6A3FM

Answer 2

我个人的偏好是，

GET /users/id/{id}
GET /users/email/{email}

但这一切都取决于你的其他终点是什么样的。

Answer 3

  

哪个更好？

REST并不关心;从客户端的角度来看，URI是不透明的。客户关注的是链接/提交表单/完成模板。

编码到URI中的信息由服务器自行决定并由其自己独占使用。

所以你可以使用你喜欢的任何拼写。通常，遵循本地拼写约定是一个好主意（与代码中的变量名称应符合您的编码约定的方式非常相似）。但是您的客户不应该知道这些约定的细节。

/users/{input}
...
if(isEmail(input)) queryByEmail(input);
else queryById(input);

请注意，您不一定非常致力于一种方法;这是将标识符与表示分离的 point 的一部分。例如，您的实现可能很容易看起来像

/users/{input}
...
if(isEmail(input)) redirectTo(/users/email/{input});
else redirectTo(/users/id/{input});

允许已为原始URI添加书签的客户端到达正确的资源。