rest - REST 中的子资源和路径变量冲突？

Question

设计一个路径解析可能有歧义的 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
具体来说，我感兴趣的是 Jersey 是否会在解决这个问题时遇到任何麻烦。如果您知道 id 会怎样？是一个整数？

Answer 1

"Specifically, I'm interested in whether Jersey would have any trouble resolving this"

不，这不会有问题。如果你看 the JAX-RS spec § 3.7.2 ，您将看到将请求匹配到资源方法的算法。

[E is the set of matching methods]...

Sort E using the number of literal characters in each member as the primary key (descending order), the number of capturing groups as a secondary key (descending order) and the number of capturing groups with non-default regular expressions (i.e. not ‘([^ /]+?)’) as the tertiary key (descending order)

所以基本上它是说文字字符的数量是排序的主键(注意它是短路；你赢了主要，你赢了)。例如，如果请求转到 /animals/cat , @Path("/animals/dogs")显然不会在集合中，所以我们不需要担心。但是如果请求是到 /animals/dogs ，那么这两种方法都在集合中。然后按文字字符数对集合进行排序。自 @Path("/animals/dogs")具有比 @Path("/animals/") 更多的文字字符，前者胜出。捕获组 {id}不计入文字字符。

"What if you knew the id to be an integer?"

捕获组允许使用正则表达式。所以你可以使用 @Path("/animals/{id: \\d+}") .任何不是数字的东西都不会通过并导致 404，当然除非它是 /animals/dogs .