JAX-RS/Jersey有什麼更好 - 使用containerResponseFilter或MessageBodyWriter提供程序？

Question

我正在使用Jersey服務器使用API​​。我有一個通用的根元素定義在一個bean中，我現在使用容器響應過濾器來環繞資源（另一個bean）的響應。它效果很好。

它基本上返回此：

<transaction> 
    <status>Good</status> 
    <id>1</id> 
    .... 
</transaction> 

因此，它基本上包裝了交易元素和狀態元件周圍的豆從資源，其中標註有javax.xml綁定註釋返回。

我們正在考慮實現提供Atom樣式XML和JSON的OData格式。兩者真的是不同的格式。所以如果請求返回的媒體類型是application/xml，過濾器就像現在這樣工作。如果請求的媒體類型是application/atom + xml，它需要返回一個原子風格的XML文檔。

<feed xlmns="http://www.w3.org/2005/Atom" 
     xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" 
     xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"> 
    <title>resource name</title> 
    ..... 
</feed> 

如果請求的媒體類型爲application/JSON它需要返回的OData的JSON格式是這樣的：

"d" : { 
    "results" : [ 
    { 
    "__metadata": { 
     "uri" : "http://www.url.com/api/resource" 
    }, 
    "title" : "reource name", 
    .... 
    ]} 
} 

我發現在線文檔和示例中關於設置實現MessageBodyWriter的提供商。我可以爲每種類型提供一個提供者。所以生產註釋將具有相應的媒體類型，並且isWriteable方法也將檢查適當的類型。然後，writeTo方法可以改變從資源返回的bean的格式，並在其周圍包裝正確的格式。但是，像這樣一個獨特的提供商真的是這個意圖嗎？這是實現這三種可能回報的最佳方式嗎？

我也想過只是添加到容器響應過濾器類中我已經必須檢查返回的媒體類型並相應地對其進行格式化，但是我擔心過濾器可能會變得「大」，因爲它對於一個過濾器來說太過分了，不確定這是否真的是一個問題。

我也可以在每個資源方法中相應地構建bean並格式化它，但它可以節省一次或三次唯一的時間，並且適用於每個返回的bean。

哪個方向好？還有其他的選擇可能比這兩個更好嗎？

謝謝！

Answer 1

編寫自己的MessageBodyWriter絕對是正確的選擇，因爲您有與該格式相關聯的特定媒體類型，並且您希望以相同的方式處理此類媒體類型的所有請求的序列化。