[Java] Network Monitor for REST and WebSockets communication

原文はこちら。
https://blogs.oracle.com/netbeanswebclient/entry/network_monitor_for_rest_and

---

NetBeans 7.3の未完成機能の一つにNetwork Monitorがありました。サーバーと通信するアプリケーションを開発する際に様々な問題が発生する可能性があります。例えば…

• サーバーが応答せず通信が中断する
• サーバーが期待しているものとは異なるデータを送信する
• アプリケーションがサーバーに送信したをサーバーが期待通りに処理してくれなかった

などです。
こういった場合にどんなデータがアプリケーションとサーバー間でやりとりされているのかを分析できるのは非常に有益なことです。

• アプリケーションが正しいURLを使ったか？
• 正しいリクエスト・ヘッダーを設定していたか？
• 実際に送信されたデータはどういうものだったのか？
• サーバーの応答にはどんなデータが含まれていたのか？
• データのフォーマットは？

こうした類の疑問をNetwork Monitorを使うと解き明かすことができます。この機能が次期NetBeansリリースのNightly Buildに組み込まれました。まだ完全ではなく、UIを洗練する必要があるのですが、レビュー第1弾として使う上では十分かと考えています。

NewAndNoteworthyNB74
http://wiki.netbeans.org/NewAndNoteworthyNB74

では見ていきましょうか。"Chrome with NetBeans Integration"ブラウザもしくは"Embedded WebKit"ブラウザでプロジェクトを実行すると、Browser Logウィンドウやセッションデバッグ・ウィンドウと同じように、NetWork Monitor監視ウィンドウが自動的に開きます。

前述の通り、UIはまだまだです。アプリケーションでのRESTもしくはWebSocket通信を始めると、ネットワークリクエストがNetwork Monitor UIに現れ始めることに気付くでしょう。先ほどのスクリーンショットでわかるように、全てのネットワークリクエストが監視されるわけではありません。NetBeansのネットワーク監視機能は、RESTやWebSocketを使って通信するアプリケーションの開発時に起こる、よくある問題を解決するのに役立つものです。静的なリソース（イメージやCSSなど）のロードのようなネットワークリクエストは自動的にフィルタされます。これらのネットワークリクエストを確認する必要がある場合には、例えばChrome Developer Toolsのようなブラウザツールを使って直接分析することができます。しかし、失敗した任意のネットワークリクエストは、RESTやWebSocket、その他シンプルな静的リソースリクエストにかかわらず、ログを採取し、注意を向けさせます。
どのようにネットワークリクエストが表示されるか見てみましょう。

上のスクリーンショットでは、3件のネットワークリクエストが記録されています。1つ目は失敗しているため赤で表示されています。最後のリクエストはTwitter Search REST APIを呼び出しており、リクエストヘッダーならびにレスポンスヘッダーを表示しています。Responseタブに切り替えるとサービスから受信したデータを確認できます。

サーバーからのレスポンスはここではJSONP（前のスクリーンショットにあったレスポンスヘッダー中のcontent-typeが"application/javascript"であることに注意して下さい）であり、IDEは自動的にJSONデータをjavascriptレスポンスから展開し、一つのJSONストリームを可読性の高いフォーマットに変えています。
サービスからデータが到着するとデータを確認したい場合には、右下の隅にある"Raw Data Response"のチェックボックスにチェックを入れましょう。この例では、出力は以下のようです。

最後のタブではこのネットワークリクエストを呼び出しているコール・スタックを表示します。リンクをクリックすると迅速にアプリケーションコードに到達することができます。

WebSocket通信の監視用のUIはにていますが、レスポンスデータの代わりに時系列でテキストデータのリストにて確認できます。

青字はWebSocketリクエストがまだオープンの状態でまだデータフレームが到着/送信される可能性があることを示しています。
ネットワークリクエストが失敗すると、Network MonitorはサーバーステータスコードをHeadersパネルに表示します。例えば、"404 - Not Found"といった具合です。ネットワークモニタが区別して詳しいヘルプを提供しようとしている一つのエラーケースがあります。お使いのブラウザが同一生成元ポリシー（Same Origin Policy）が原因で中止したRESTサービス呼び出しの場合は次のとおりです。

例えばこの事象は次のような場合に発生することがあります。開発中のRESTサービスをGlassFishサーバー（デフォルトでは8080/tcp上で動作します）にデプロイすると同時に、NetBeansの軽量Webサーバー（デフォルトでは8383/tcpで動作します）で実行するHTML5プロジェクトからこのRESTサービスにアクセスしようとしている場合です。このシナリオでは、ブラウザの同一生成元ポリシーにより、JavaScriptコードを停止して、RESTサービスへのアクセスができません。それはこのポリシーがJavaScriptが同一ポート、同一プロトコルを使って、同一サーバーにあるリソースにのみアクセスできるように規定しているからです。
これを解決するオプションはほとんどありませんが、両プロジェクトを一つのサーバで実行したり、RESTサービスでJSONPをサポートするように書き換え、JavaScriptからJSONPを使って同一生成元ポリシーを回避するということぐらいでしょう。しかし、RESTサービスをパブリックアクセス可能にすることを考えているならば、最善の方策はCross-Origin Resource Sharing（CORS）を利用し、RESTサービスを修正してブラウザに異なるドメインから呼ぶことができるようにすることです。

Cross-Origin Resource Sharing（CORS）
http://www.w3.org/TR/cors/

NetBeansでJerseyを使って開発されたRESTサービスの場合、（Webサービスカテゴリ中の）"Jersey Cross-Origin Resource Sharing Filter"ウィザードを使って簡単にJerseyのContainerResponseFilter SPIのサブクラスを作成し、必要なCORSヘッダーをすべて提供してくれます。

public class NewCrossOriginResourceSharingFilter
              implements ContainerResponseFilter {
    @Override
    public ContainerResponse filter(ContainerRequest request, 
                                    ContainerResponse response) {
        response.getHttpHeaders().putSingle(
            "Access-Control-Allow-Origin", "*");
        response.getHttpHeaders().putSingle(
            "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        response.getHttpHeaders().putSingle(
            "Access-Control-Allow-Headers", "content-type");
        return response;
    }
}

ウィザードが自動的にフィルタをweb.xmlに登録してくれます。
この機能がお役に立てばと思っています。フィードバックやご提案をお待ちしています。