3.3. JAX-RSサポート/JSR399/HTTPメッセージングの機能比較

ここでは、以下の機能比較を示す。

ちなみに

NablarchのJAX-RSサポートとHTTPメッセージングのみ、表内のマークをクリックすると、解説書の説明ページに遷移する。

機能比較（○：提供あり　△：一部提供あり　×：提供なし　－:対象外）
機能 JAX-RS
サポート		 HTTP
メッセージング		 JSR 339
リクエストとリソースメソッドのマッピング △ ○ ○
リクエストとパラメータのマッピング △ × [1] ○
HTTPメソッドのマッチング △ × [1] ○
メディアタイプに応じた
リクエスト/レスポンスの変換		 △ × [1] ○
エンティティのバリデーション ○ ○ ○
リソースクラスへのインジェクション(CDI) × [2] × [2] ○
リクエスト/レスポンスに対するフィルター × [3] × [3] ○
ボディの読み書きに対するインターセプター × [4] × [5] ○
クライアントAPI × [6] ○ ○
非同期処理 × [7] × [7] ○
エラー時ログ出力 ○ ○ －
リクエストボディの最大容量チェック × [8] ○ －
証跡ログの出力 × [9] ○ －
再送制御 × [9] ○ －
サービス提供の可否チェック × [10] × [10] －
トランザクション制御 × [11] × [11] －
業務処理エラー時のコールバック × [12] ○ －
[1](1, 2, 3) HTTPメッセージングはRESTを考慮した作りになっていない。RESTfulウェブサービスには、JAX-RSサポートを使用する。
[2](1, 2) JAX-RSサポートとHTTPメッセージングは、Nablarchのウェブアプリケーションとして動作するため、CDIは使用できない。
[3](1, 2) リクエスト/レスポンスに対するフィルターを作りたい場合は、ハンドラを作成する。
[4]ボディの読み書きに対するインターセプターを作りたい場合は、JAX-RSサポートのBodyConverterを作成する。
[5]ボディの読み書きにはNablarchのデータフォーマットを使用している。変更したい場合は、データフォーマットのDataRecordFormatterを作成する。
[6]JAX-RSクライアントが必要な場合は、JAX-RSの実装(JerseyやRESTEasyなど)を使用する。
[7](1, 2) サーバーサイドで非同期処理が必要になる要件がないと想定している。要望があれば対応を検討する。
[8]ウェブサーバやアプリケーションサーバにあるリクエストサイズをチェックする機能を使用する。
[9](1, 2) アプリケーションごとに要件が異なると想定している。アプリケーションで設計/実装する。
[10](1, 2) Nablarchにあるサービス提供可否チェックがアプリケーションの要件にマッチする場合はそれを使用する。マッチしない場合は、アプリケーションで設計/実装する。
[11](1, 2) Nablarchにあるトランザクション管理を使用する。
[12]エラー処理は共通化し、JaxRsResponseHandlerをカスタマイズすることを想定している。業務処理で個別にエラー処理をしたい場合は、リソースメソッドにてtry/catchを使用する。