按照惯例，REST方法应该是名词，应该回答“什么？”的问题。而不是“如何？”。
因此，鉴于我只需要使用find-by-id方法，我可以轻松地提出RESTful路径/foo/{id}，其中括号中的部分被某个数字替换。
现在，我还需要添加find-by-name方法，但我不能使用已经采用的/foo/{name}。
我不能在路径中添加'name'-section（即路径看起来像/foo/name/{name}），因为它意味着“此方法返回Foo的名字”。
构成这条道路的合适方法是什么？
答案 0 :(得分：1)
同时拥有/foo/{name}和/foo/{id}并没有错。 URI语义对REST是透明的。尝试在URI中嵌入行为在REST中没有多大意义，其中该行为应该来自媒体类型，URI仅提供其位置。 /foo/name/{name}并不意味着“此方法返回Foo的名称”。这意味着任何超链接的来源都会为您提供URI模板所说的内容。
执行所需操作的适当方法是让/foo返回超链接标题“Find Foo by name”或类似名称。此超链接可以是一个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来说根本不是问题。
答案 1 :(得分：0)
我想正确的方法就像是
/foo?name=bar
通过以这种方式查询，您将能够返回多个具有相同名称的foo。如果一个name总共不超过一个foo，则可能名称应该是您的ID。