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衝突

回答

相關問題