AJAXをガンガン扱うと、だんだん例外や画面遷移をいかにクライアント側でAJAXで判断してユーザーにレスポンスを返すかという形になってくる。Formによる画面全体のsubmitはまずなくなるだろう。画面遷移もAjaxレスポンスをみてクライアント側でやるのが望ましい感じに。
しかしそのためには例外をどういうフォーマットで返すかなどをあらかじめきれいにまとめておく必要がある。
JAX-RSは例外をどういうフォーマットでクライアントに返すかということを記述することが可能だ。
アプリ開発側としては例外を投げるだけでよい。
たとえば例外をだしてしまったとする。
@Path("hoge") public class HogeResource { @GET @Produces("application/json") public String getJson() throws SQLException { if(true){ throw new SQLException("うおっDBこわれたぜ例外"); } return "{\"response\":\"正常\"}"; } }
このままだとそのままデフォルトのアプリケーションサーバーのステータス500がかえるのでこんなマッピングを書く。
@Provider public class SQLExceptionMapper implements ExceptionMapper<SQLException>{ @Override public Response toResponse(SQLException exception) { return Response.status(500).type("text/html"). entity("<html><title>えらーだよん<title><body>"+ exception.getMessage()+ "</body></html>"). build(); } }
@Providerというのは以前もでてきたが、設定関係であることを示すアノテーション。これがないと自動検出されないので注意。
結果は上で生成されたHTMLをステータス500で返す。例外の種類ごとに超簡単にカスタマイズができるのがわかると思う。
ExceptionMapperで実装するResponseというのは通常のリソースでも戻り値として使えるものだが、それをそのまま使えるために非常にカスタマイズが容易だ。
この辺をうまく使えばAjaxでpostしたあと例外のダイアログを表示させるべきか、続行可能か、画面遷移させるべきなのか、どの部分を再レンダリングするのかなども全部自動で行うフレームワークがきれいに作れる。
もっともそういったのは基本的なものならJSF 2.0でできるけど。JSF 2.0はAjaxによる送信でも画面遷移できるんだよね(しかもAjax未使用とまったく同じコードで)。どの部分を再レンダリングするのか、画面遷移なのかというのをきっちりいれこんだフレームワークと思ってよい。