按照惯例，REST 方法应该是名词并且应该回答“什么？”的问题。而不是“如何？”。
因此，鉴于我只需要创建 find-by-id 方法，我可以很容易地想出 RESTful path /foo/{id}，其中括号中的部分被一些数字替换。
现在，我还需要添加 find-by-name 方法，但我不能使用/foo/{name}它，因为它已经被占用了。
我也不能在路径中添加“名称”部分（即路径看起来像/foo/name/{name}），因为这意味着“此方法返回 Foo 的名称”。
什么是构成这条路径的合适方法？
/foo/{name}同时拥有和 并没有错/foo/{id}。URI 语义对 REST 是透明的。尝试在 URI 中嵌入行为在 REST 中没有多大意义，在 REST 中，该行为应该来自媒体类型，URI 仅提供其位置。/foo/name/{name}并不意味着“此方法返回 Foo 的名称”。这意味着无论超链接的来源为您提供该 URI 模板所说的内容。
做你想做的事情的适当方法是/foo返回一个超链接标题“按名称查找 Foo”或类似的东西。此超链接可以是一个 URI 模板，当使用 扩展时，name将检索具有所需 Foo 的搜索结果（如果存在）。
那个 uritemplate 可以是/foo/{name}, /foo?name={name}, /search?type=foo&name={name}，甚至是完全不相关的东西，比如/my/api/is/a/mess?name={name}. 这并不重要，因为客户端要做的就是检索该 uritemplate，展开它，然后检索资源。
显然，我们鼓励您仔细考虑您的路径并使它们对客户端开发人员有意义且直观，但采用一种或其他样式并不会使您的 API 或多或少 RESTful，而且您不能说它或多或少合适。如果你想太多，那可能是因为你的 API不是超文本驱动的，根本不是 RESTful。其他实现细节，比如你的框架，可能会比 REST 约束更能说明其中一个或另一个的适当程度。例如，某些框架可能无法同时路由到foo/{name}和/foo/{id}，但正如我上面所说，这对于 REST 来说根本不是问题。
我想正确的方法是 smt like
/foo?name=bar
通过以这种方式查询，您将能够返回多个foo具有相同名称的。如果一个name人总是不超过一个，foo也许名字应该是你的身份证。