3.3. JAX-RSサポート/JSR339/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を使用する。