设计一个可能在路径分辨率上有歧义的REST API被认为是不好的做法吗？例如：
GET /animals/{id} // Returns the animal with the given ID
GET /animals/dogs // Returns all animals of type dog
好的，这是设计的，因为你实际上只是做GET /dogs，但希望它说明了我的意思。从路径解析的角度来看，您似乎不知道您是在寻找具有id="dogs"的动物还是只是dogs所有
具体来说，我对泽西岛是否会解决这个问题感兴趣。如果您知道id是一个整数怎么办？
答案 0 :(得分：6)
＆＃34;具体来说，我对泽西岛是否会解决这个问题感兴趣＆＃34;
不，这不是问题。如果查看confirmation，您将看到将请求与资源方法匹配的算法。
[ E 是匹配方法的集合] ......
使用每个成员中的文字字符数作为主键（降序），捕获组的数量作为辅助键（降序）和捕获组的数量来排序 E 非默认正则表达式（即不是'（[^ /] +？）'）作为三级键（降序）
所以基本上它说的是数字或字面字符是排序的主键（注意它是短路的;你赢得了主要，你赢了）。因此，例如，如果请求转到/animals/cat，@Path("/animals/dogs")显然不在该集合中，因此我们不必担心它。但是如果请求是/animals/dogs，则两个方法都在集合中。然后按照文字字符数对该集合进行排序。由于@Path("/animals/dogs")的文字字符比@Path("/animals/")更多，因此前者获胜。捕获组{id}不计入文字字符。
＆＃34;如果你知道id是一个整数怎么办？＆＃34;
捕获组允许正则表达式。所以你可以使用@Path("/animals/{id: \\d+}")。任何不是数字的东西都不会通过并导致404，除非它当然是/animals/dogs。