REST APIdevise – 通过REST获取资源，使用不同的参数，但具有相同的url模式
我有一个有关REST的urldevise的问题。 我在这里find了一些相关的post： 不同的RESTful表示相同的资源 ，在这里： RESTful URL GET资源由不同的领域，但答复是不是很清楚最佳做法是什么，为什么。 这是一个例子。
我有代表“用户”资源的RESTurl。 我可以通过一个ID或一个电子邮件地址来获得一个用户，但是URL表示对于两者都是一样的。 通过大量的博客和书籍，我发现人们以许多不同的方式来做这件事。 例如
阅读这本书，并在一个地方stackoverflow（我似乎无法find链接）
GET /users/id={id} GET /users/email={email} 在很多博客上阅读这个练习
GET /users/{id} GET /users/email/{email}
查询参数通常用于过滤由url表示的资源的结果，但我也看到了这种做法
GET /users?id={id} GET /users?email={email}
我的问题是，在所有这些做法中，哪一个最适合开发者使用apis，为什么？ 我相信在REST的网页devise和命名规则方面没有任何规定，但我只是想知道应该采取哪条路线来帮助开发人员更好地理解API。
所有帮助赞赏！
根据我的经验， GET /users/{id} GET /users/email/{email}是最常用的方法。 我也希望如果用户不存在提供的id或email ，方法返回404未find。 看到GET /users/id/{id} ，我也不会感到惊讶（尽pipe在我看来，这是多余的）。
对其他方法的评论
-
GET /users/id={id} GET /users/email={email}- 我不认为我已经看到了，如果我看到了，这将是非常混乱。 这几乎就像试图模仿带有path参数的查询参数一样。
-
GET /users?id={id} GET /users?email={email}- 当您提到使用查询参数进行过滤时，我认为您碰到了头部。
- 用
id和email（比如GET /users?id={id}&email={email}）来调用这个资源是否合理？ 如果没有，我不会使用像这样的单一资源方法。 - 我期望这种方法检索用户筛选的可选查询参数的用户列表 ，但我不希望
id，email或任何唯一标识符参数之间。 例如：GET /users?status=BANNED可能会返回一个被禁止的用户列表。
从相关问题查看这个答案 。
从实用的angular度来看，你有一组用户：
/users # this returns many
每个用户都有一个专门的资源位置：
/users/{id} # this returns one
您还有很多方法可以search用户：
/users?email={email} /users?name=*bob*
由于这些都是查询参数/用户，他们都应该返回列表..即使它是一个列表1。
我在这里写了一篇关于实用的RESTful APIdevise的博客文章，其中讨论了这个问题，其中包括： http : //www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
关于用户资源
在path/users你总是会得到一个收集资源返回。
在path/users/[user_id] ，如果没有用户存在请求的[user_id]（或者禁止（401）），你将得到一个代表id为[user_id]的用户的单例资源访问资源等）。 每个资源path只有一个唯一的标识符，您可以使用它来查找/标识资源。 在同一资源path上不可能为同一资源使用多个标识符。 如果在响应中获得返回的资源，则标识符将作为自定义HREF来查找/标识资源。
您可以使用GET /查询参数查询path/users 。 这将返回符合要求标准的用户集合。 返回的集合包含所有用户资源的定位/标识自己的HREF。
关于电子邮件资源
如果我看看你对电子邮件的build议，我宁愿想一下：
来自用户的电子邮件也是资源。 所以我会认为/users/[user_id]/emails返回用户ID为user_id的电子邮件地址的集合。 /users/[user_id]/emails/[email_id]以user_id和['email_id']返回用户的电子邮件。 你用什么标识符取决于你，但我会坚持一个整数。 您可以通过向标识要删除的电子邮件的path发送DELETE请求来DELETE用户的电子邮件。 因此，例如，在/users/[user_id]/emails/[email_id]上的DELETE将删除具有user_id的用户拥有的email_id的电子邮件。 很可能只有该用户被允许执行这个删除操作。 其他用户将得到一个401响应。
如果一个用户只能有一个邮件地址，你可以使用/users/[user_id]/email这将返回一个单一资源。 用户可以通过PUT ting更新他的电子邮件地址，或者在该url上发布新的电子邮件地址。 如果在您的应用程序中，您不允许没有电子邮件的用户，您应该向他发送一个DELETE请求到该URL。
