模棱两可的 URL，一个带有 PathVariable 的 URL答案

【问题标题】：Ambiguous URLs, one with PathVariable模棱两可的 URL，一个带有 PathVariable 的 URL
【发布时间】：2015-07-31 12:26:56
【问题描述】：

我有 Spring 3.2 Web 应用程序，并且我有具有以下请求映射的控制器：

@RequestMapping(value = "/test/{param1}", method = RequestMethod.GET)
public String method1(@PathVariable(value = "param1") String param1, ..

@RequestMapping(value = "/test/login", method = RequestMethod.GET)
public String method2(//..

我可以确定如果有人要求 url /test/login 方法 2 将被调用吗？是否有任何因素基于哪个弹簧决定如何处理它？如果存在，它是否总是选择没有 PathVariable 的 URL？我在 Spring 文档中找不到任何内容。

【问题讨论】：

Ordered RequestMapping in spring MVC 的可能重复项
@so00m 没有接受的答案。并且对这个问题的回答有很好的评论：“一个方便的实现细节要知道。是否有任何公共文档（除了源代码）定义了 api 的这种行为？”

标签： spring spring-mvc

【解决方案1】：

我可以确定如果有人请求 url /test/login 方法 2 会被调用吗？ 是的。

映射由特异性解决，相关文档可用here

URI 变量和通配符数量较少的模式是考虑更具体。例如/hotels/{hotel}/* 有 1 个 URI 变量和 1 个通配符，被认为比 /hotels/{hotel}/** 其中 1 个 URI 变量和 2 个通配符。

如果两个模式的计数相同，则较长的一个是考虑更具体。例如/foo/bar* 更长并且被认为比/foo/* 更具体。

当两个模式具有相同的计数和长度时，模式与更少的通配符被认为更具体。例如 /hotels/{hotel} 比 /hotels/* 更具体。

如果两个映射匹配一个请求，将应用更具体的映射。在这两个映射中，/test/login 更具体。

【讨论】：

/hotels/{hotel}/{a}/{b}/{c} 如果我使用这样的 URL，如何获取 a、b、c 的值？
您只需向处理程序方法添加一个参数，并使用 @PathVariable(value ="a") String aValue 等进行注释
对不起，我必须撤消这个答案，它似乎没有按预期工作。它会导致非常奇怪的行为，所以我建议不要使用这种网址。
@jgr 你能详细说明你遇到了什么奇怪的行为吗？我做了一些测试，它似乎对我有用？ tnx
@Master Slave 您能否指出描述您提到的这种行为的确切文档？谢谢

【解决方案2】：

恐怕这不是预期的答案，但由于它没有在文档中指定，它应该被视为未定义。

您可以尝试（如果是源文件，最终将“/test/logging”方法放在首位），但即使它有效，您也不能确定它是否仍然适用于另一个版本的 Spring Framework。

我的建议是：如果可以，请避免使用此类模棱两可的 URL，如果不能，请使用一个包罗万象的 @RequestMapping 并从其手动转发：

@RequestMapping(value = "/test/{param1}", method = RequestMethod.GET)
public String method0(@PathVariable(value = "param1") String param1, ...
    ) { // union of all parameters for both method1 and method2
    String ret;
    if ("login".equals(param1)) {
        ret = method2(/* pass parameters for method 2 */ ...);
    }
    else {
        ret = method1(/* params for method1 */ param1, ...);
    }
    return ret;
}

public String method1(String param1, ..

public String method2(//..

这样，您可以完全控制哪些方法处理哪些 url。不一定是最好的方法，但它至少是健壮的......

【讨论】：