REST Jersey GET PUT冲突

我使用泽西版本1.17.1 + tomcat 7.0.39 + Spring MVC 3.2.1。REST Jersey GET PUT冲突

问题是，我无法弄清楚为什么当我扩展GET处理程序的@Path时，我的PUT处理程序停止工作？

在我的Spring MVC控制器下面的配置/匹配按预期工作：

@GET 
@Path("/{id}") // <--- WORKS! 
[...] 

@PUT 
@Path("/{id}") // <--- WORKS! 
[...]

但每当我为了能够延长GET处理程序的匹配处理不仅

/anyId

请求，但也请求的形式

/anyId/ 
/anyId/anyfile.ext

再没有碰过的PUT匹配停止工作：

@GET 
@Path("/{id:.*[^/]}{fileName:.*}") // <--- WORKS! 
[...] 

@PUT 
@Path("/{id}")      // <--- Not working any longer: 
             //  "405 Method Not Allowed" 
[...]

改变GET路径匹配到上述PUT请求后得到“405不允许的方法”的状态代码。

当我像第一种情况那样简化GET路径时，PUT处理程序再次开始工作。

这是泽西岛的问题还是什么？

来源

2013-07-23 gvlax

405通常意味着找不到合适的方法。很难说只有你提供的小片段，但你需要确保你的PUT方法有适当的@Consumes注释。

您也可以尝试将@Path更改为@Path("{id: [^/]+}/{fileName: .+}")之类的内容，看看是否有帮助。如果没有，请提供完整的控制器。

来源

2013-07-23 15:49:50 jgm

我很确定这里的控制器并不重要。我故意跳过了它们。我已经使用远程调试进行了验证。当我使用更简单的映射时，两种方法（@ Path's）均可正常工作 - 两个控制器均按预期方式输入。但是，用正则表达式扩展GET @Path就足够了，然后** PUT **处理程序停止工作，并且服务器返回“方法不允许”（扩展的GET匹配工作正常）。 – gvlax

405表示没有匹配该资源请求中的方法。这将表明东西（或几个东西）有匹配的@Path注释，但该（Java）方法没有正确的方法。（如果可以的话，在查看正在发生的事情时打开详细的调试;它可以帮助你，但是当你完成时关掉它;它通常会被留在太深的地方。）

现在，它有助于理解@Path映射到与请求中的路径相匹配的正则表达式，并且如果不另外指定，则路径模板部分（{id}）与正则表达式[^?/;]+有效匹配，即as尽可能多的字符而不进入路径的下一部分，查询部分或任何矩阵参数。（不知道一个矩阵参数是什么，你可能不希望向知道吗？！）

为了满足所有这些形式：

 
/anyId  
/anyId/ 
/anyId/anyfile.ext

你是最好关闭使用两种Java方法按照HTTP方法：

@GET @Path("{id}") 
… 
@GET @Path("{id}/{file:.*}") 
…

这可行，但它很冗长。

这可能是更容易，而不是返回表示资源和对象上定义的操作：

class MyResource { 
    private String id, file; 
    MyResource(String id, String file) { 
     this.id = id; this.file = file; 
    } 
    // Can't remember if @Path is needed on these; "/" is a special case IIRC 
    @GET @Path("/") @Produces(…) 
    public String get() { … } 
    @PUT @Path("/") @Produces(…) @Consumes(…) 
    public String put(String message) { … } 
}

@Path("{id}") 
public MyResource getNoPath(@PathParam("id") String id) { 
    return new MyResource(id, null); 
} 
@Path("{id}/{file:.*}") 
public MyResource getNoPath(@PathParam("id") String id, @PathParam("file") String file) { 
    return new MyResource(id, file); 
}

这样，你拆分解析代码来自提供正确方法的代码的路径。我用CXF（另一个JAX-RS实现）做这件事情，它工作得很好。

来源

2013-07-25 13:40:10

唐纳德，正如我在我的帖子中描述的那样，我的GET处理程序** always **工作原理：在扩展它之前和之后，它可以处理以文件名结尾的请求。问题是，当我扩展GET @Path时，PUT处理程序停止匹配。我试图将我的GET处理程序分成两个独立的处理程序。再次，在PUT处理程序停止工作之后...... – gvlax

REST Jersey GET PUT冲突

回答

相关问题