如何设计api以REST风格的非主键检索一个资源？
原来，我们有一个API GET /users/:id通过其主键检索user。如何设计api以REST风格的非主键检索一个资源？
现在我们需要一个新的API来检索user的电子邮件。
GET /[email protected]似乎想要一个集合。
GET /users/byEmail/:email包括非名词词byEmail。
还有其他的选择吗？
您建议的两种方法都是有效的，但我可能不会这样做，因为最好坚持每个资源使用一个 URI。要做到这一点的另一种常用方法是：
/users/id/:id
或
/users/email/:email
我应该指出的是，查询参数VS网址参数或/name/:value VS /:value的选择不是什么使服务“REST风格”。换句话说，拥有“漂亮”或“可读”的URL并不意味着你的服务是RESTful的。
REST的关键点之一是通过URI进行资源识别，即特定的URI将始终指向特定的资源。在电子邮件的情况下，这可能会改变（用户可能想要更改他们的电子邮件地址），所以此URL不再随时识别此用户。
更RESTful方法是使明确的，这是一个真正的搜索而不是标识，并有一个URI是这样的：
/search/users/email/:email
这是更RESTful的，因为这个URI总是标识相同的资源，即该电子邮件地址的搜索结果。请注意，这种情况下的资源是搜索结果，而不是用户资源本身。
我喜欢在路径末尾有/的URIs集合的约定。所以GET /[email protected]返回一个项目，GET /users/[email protected]返回一个具有单个项目的集合。但是。你不必使用这个约定。
另一个选项是使用/users/:email，如果你能解决服务器，或/users-by-email/:email或/users/email-:email等的路由...你选择哪个URI结构，只要您的REST API与HATEOAS constraint满足这并不重要。
你试图做的不是一个很好的做法。 Stack Overflow有很多这样的问题。请检查此：http://stackoverflow.com/questions/11104466/restful-url-to-get-resource-by-different-fields – zilvinas