按照惯例，REST 方法应该是名词，并且应该回答“什么？”的问题。而不是“如何？”。
所以，鉴于我只需要创建 find-by-id 方法，我可以很容易地想出 RESTful 路径 /foo/{id}，其中括号中的部分被替换为某个数字。
现在，我还需要添加 find-by-name 方法，但我不能使用 /foo/{name}，因为它已经被占用了。
我也不能在路径中添加“名称”部分（即路径看起来像 /foo/name/{name}），因为这意味着“此方法返回 Foo 的名称”。
什么是构成这条路径的合适方法？
【问题讨论】：
标签： rest naming-conventions api-design
同时拥有/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 is not hypertext driven，而不是 RESTful。其他实现细节，比如你的框架，可能会比 REST 约束更能说明一个或另一个的适当程度。例如，某些框架可能无法同时路由到 foo/{name} 和 /foo/{id}，但正如我上面所说，这对于 REST 来说根本不是问题。
【讨论】：
我想正确的方法是 smt like
/foo?name=bar
通过这种方式查询，您将能够返回多个具有相同名称的foo。如果一个name 总是不超过一个foo，也许名字应该是你的id。
【讨论】：