Jax-RS 重载方法/路径执行顺序 [英] Jax-RS overloading methods/paths order of execution

问题描述

我正在为我的应用编写 API，但我对 Jax-RS 如何处理某些场景感到困惑

I am writing an API for my app, and I am confused about how Jax-RS deals with certain scenarios

比如我定义了两条路径:

For example, I define two paths:

@Path("user/{name : [a-zA-Z]+}")

和

@Path("user/me")

我明确指定的第一个路径包含第二个路径，因为正则表达式包含所有字母 a-z.但是，该程序似乎没有这个问题.是不是因为它默认为最具体的路径(即/me 然后查找正则表达式)?

The first path that I specified clearly encompasses the second path since the regular expression includes all letters a-z. However, the program doesn't seem to have an issue with this. Is it because it defaults to the most specific path (i.e. /me and then looks for the regular expression)?

此外，如果我将两个正则表达式定义为有一些重叠的路径会发生什么.是否有将调用的默认方法?

Furthermore, what happens if I define two regular expressions as the path with some overlap. Is there a default method which will be called?

假设我想为三种不同的方法创建三个路径:

Say I want to create three paths for three different methods:

@Path{"user/{name : [a-zA-Z]+}")
@Path("user/{id : \\d+}")
@Path("user/me")

这是最佳做法/合适吗?它如何知道调用哪个方法?

Is this best practice/appropriate? How will it know which method to call?

提前感谢您的澄清.

推荐答案

这是在 将请求与资源方法匹配"中的规范

以(1)每个成员的字面字符数作为主键(降序)对E进行排序，(2)作为辅助键的捕获组的数量(降序)，(3) 具有非默认正则表达式(即不是'([^/]+?)')的捕获组的数量作为第三键(降序)，...

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

会发生什么是候选方法按指定的有序键"排序.我用粗体突出显示它们.

What happens is the candidate methods are sorted by specified ordered "key". I highlight them in bold.

第一个排序键是文字字符数.所以对于这三个

The first sort key is the number of literal characters. So for these three

@Path{"user/{name : [a-zA-Z]+}")
@Path("user/{id : \\d+}")
@Path("user/me") 

如果请求的 URI 是 ../user/me，则总是选择最后一个，因为它具有最多的文字字符(7，/ 计数).其他人只有5个.

if the requested URI is ../user/me, the last one will always be chosen, as it has the most literal characters (7, / counts). The others only have 5.

除了 ../users/me 其他任何 ../users/.. 都将取决于正则表达式.在您的情况下，一个只匹配数字，一个只匹配字母.这两个正则表达式无法重叠.所以它会相应地匹配.

Aside from ../users/me anything else ../users/.. will depend on the regex. In your case one matches only numbers and one matches only letters. There is no way for these two regexes to overlap. So it will match accordingly.

现在只是为了好玩，假设我们有

Now just for fun, let's say we have

@Path{"user/{name : .*}")
@Path("user/{id : \\d+}")
@Path("user/me")

如果你看前两个，我们现在有重叠的正则表达式.第一个将匹配所有数字，第二个也将匹配.那么会用到哪一个呢?我们不能做任何假设.这是一个未指定的歧义级别，我已经看到不同实现的不同行为.AFAIK，没有最佳匹配"正则表达式的概念.要么匹配要么不匹配.

If you look at the top two, we now have overlapping regexes. The first will match all numbers, as will the second one. So which one will be used? We can't make any assumptions. This is a level of ambiguity not specified and I've seen different behavior from different implementations. AFAIK, there is no concept of a "best matching" regex. Either it matches or it doesn't.

但是如果我们希望 {id : \\d+} 总是首先被检查怎么办.如果它匹配数字，那么应该选择它.我们可以根据规范来破解它.规范谈到捕获组"，基本上是 {..}s.第二个排序键是捕获组的数量.我们可以破解它的方法是添加另一个可选"组

But what if we wanted the {id : \\d+} to always be checked first. If it matches numbers then that should be selected. We can hack it based on the specification. The spec talks about "capturing groups" which are basically the {..}s. The second sorting key is the number of capturing groups. The way we could hack it is to add another "optional" group

@Path{"user/{name : .*}")
@Path("user/{id : \\d+}{dummy: (/)?}")

现在后者有更多的捕获组，因此它在排序中始终处于领先地位.它所做的只是允许一个可选的 /，它不会真正影响 API，但确保如果请求 URI 都是数字，则将始终选择此路径.

Now the latter has more capturing groups so it will always be ahead in the sort. All it does is allow an optional /, which doesn't really affect the API, but insures that if the request URI is all numbers, this path will always be chose.

您可以在此答案中看到有关一些测试用例的讨论

You can see a discussion with some test cases in this answer

这篇关于Jax-RS 重载方法/路径执行顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！