JAX-RS/Jerseyの優れた点 - containerResponseFilterまたはMessageBodyWriter Providerを使用していますか？

Question

私はJersey Serverを使用しているAPIに取り組んでいます。私は現在、コンテナの応答フィルタを使ってリソース（別のBean）からの応答をラップするBeanに定義された共通のルート要素を持っています。それは素晴らしい作品です。

それは基本的にこれを返します。

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

だから、基本的に豆の周りの取引要素と状況要素がjavax.xmlバインディングアノテーションで注釈されたリソースから返されたラップ。

私たちは、AtomスタイルのXMLとJSONを提供するODataフォーマットの実装を検討しています。どちらも実際には異なるフォーマットです。したがって、返されるよう要求されたメディアタイプがapplication/xmlの場合、フィルタは今のように動作します。要求されたメディアタイプがapplication/atom + xmlの場合、原子スタイルのxmlドキュメントを返す必要があります。私は設定に関しては、オンラインドキュメントと例を見つけた

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

：要求されたメディアタイプは、アプリケーション/ JSONの場合は

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

が、それはこのようなものであるのODataのJSON形式を返す必要がありますMessageBodyWriterを実装しています。私は各タイプごとに1つのプロバイダを持つことができます。したがって、生成アノテーションには適切なメディアタイプがあり、isWriteableメソッドは適切なタイプをチェックします。 writeToメソッドは、リソースから返されたBeanのフォーマットを変更し、正しいフォーマットをその周りにラップすることができます。しかし、そのようなユニークなプロバイダは本当に意図ですか、そして、これら3つの可能なリターンを達成するための最良の方法ですか？

また、私はすでにコンテナ応答フィルタクラスに追加することを考えていました。私はすでに返されているメディアタイプをチェックし、それに応じてフォーマットする必要がありますが、フィルタが "大きく"なる可能性があるフィルタにはあまりにも多くのことをしていますが、それが本当に懸念されているかどうかはわかりません。

また、各リソースメソッドでBeanを構築し、それに応じてフォーマットすることもできますが、それを1回または3回一意に実行し、すべてのBeanに適用される時間を節約できます。

どの方向が良いですか？これらの2つのオプションよりもさらに優れたオプションがありますか？

ありがとうございます！

Answer 1

フォーマットに関連付けられた特定のメディアタイプを持ち、そのようなメディアタイプのすべてのリクエストのシリアル化を同じ方法で処理したい場合は、独自のMessageBodyWriterを書くことが間違いなく正しい方法です。