使用备用查询选项命名 GET

Question

假设你有一个已经通过id获取用户的REST服务，所以url看起来像

GET /users/{userId}

但是，您希望创建一个通过电子邮件获取用户的重复 Web 服务，因此：

GET /users/{email}

哪个更好？

方法一：

相同的方法：

  /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}是否是一个数字。

我还想指出，"漂亮的 URL"不会使其成为 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);

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

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

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