Network Monitor for REST and WebSockets communication

One of the features which we have not managed to finish for NetBeans 7.3 was a Network Monitor. When developing an application which talks to a server all sorts of problems can happen. Server may not respond and simply abort communication; server may send different data than expected; the data which our application sent to a server were not processed on the server as expected; etc. In times like that it is invaluable to be able to analyse what exactly is being exchanged between the server and our application. Did our application used the right URL? did it set right request headers? what exact data are being send to server? what exact data has server responded with? in what format the data are? These and other questions can now be answered with help of the Network Monitor. The feature just landed into nightly builds of next NetBeans release. It is not completely finished, the UI needs to be polished but it is good enough for a first round of review.

Let's look at what it does. When running a project in "Chrome with NetBeans Integration" browser or "Embedded WebKit" browser the Network Monitor monitor window will open automatically similarly to the Browser Log window or debugging session windows:


As I said the UI is preliminary. Trigger a REST or WebSocket communication in your browser application and you will notice network requests to start appearing in the Network Monitor UI. As mentioned on the previous screenshot not all network requests are monitored. The focus of NetBeans network monitoring is to help resolve common problems which happen during development of applications which are using REST and WebSocket communication. Network requests like loading of static resources (ie. images, css, etc.) are automatically filtered out. If you need to see those you can analyse them directly using your browser tooling for example in Chrome Developer Tools. However, any network request which fails is logged and brought to attention regardless of whether it is REST, WebSocket or plain static resource request.

Let's look how network requests are presented:


Above screenshot shows three network requests recorded. First one failed and is therefore shown in red color. The last one is a call to the Twitter Search REST API and shows request and response headers. Switch to Response tab to see data received from the service:

The response from server in this case is JSONP (notice that content-type in the response headers in previous screenshot was "application/javascript") and IDE automatically extracted JSON data from the javascript response and reformatted the single line JSON stream into a more readable form. If it is desirable to see data as they came from the service just tick "Raw Data Response" checkbox at the right bottom corner. In this instance the outcome is:


The last tab shows callstack which triggered this network request and links allow you to quickly dive into your application's code:


For monitoring WebSocket communication the UI is similar but instead of response data you get to see list of textual frames as they happen:

Blue color indicates that WebSocket request is still open and more data frames may be received/sent.

When a network request fails the Network Monitor shows server's status code in the Headers panel, for example "404 - Not Found". There is one error case which the Network Monitor is distinguishing and trying to provide more help than that. It is the case of REST service call which your browser aborted due to Same Origin Policy:

This can happen for example if you are developing REST service and deploying it to a GlassFish server (which by default runs on port 8080) and at the same time you are trying to access this REST service from your HTML5 project which runs on NetBeans lightweight web server (which by default runs on port 8383). In this scenario browser's Same Origin Policy stops your JavaScript code from accessing REST service because the policy says that JavaScript can access only resources on the same server, using the same port and the same protocol.

There are few options how to resolve this. You could run both projects on single server. Or you could enhance your REST service to support JSONP and use JSONP from your JavaScript which would workaround the Same Origin Security policy. However, if you plan to make your REST service publicly accessible then the best approach is to utilize Cross-Origin Resource Sharing (CORS) and amend your REST service to tell browser that it can be called from different domains. For REST services developed in the NetBeans using Jersey this can be as simple as following the "Jersey Cross-Origin Resource Sharing Filter" wizard (in the Web Services category) to create subclass of Jersey's ContainerResponseFilter SPI and provide all necessary CORS headers:

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

The wizard automatically registered the filter in web.xml for you.

Hope you find this feature helpful! Any feedback or suggestions are appreciated.

Comments:

We already have tools for this. How about fixing some of the major bugs instead?

Posted by impatientiguest on March 27, 2013 at 12:19 AM PDT #

is this going to work with JavaFX??? If I have a bunch of REST calls on a JAVAFX app and this would be excellent. so I dont need to use third party apps.

Posted by guest on April 08, 2013 at 10:36 AM PDT #

Unfortunately it will not work with JavaFX.

The Network Monitor works by connecting to WebKit based browser and listening on browser network events. Anything what runs in the browser can be monitored. The NetBeans IDE has also HTTP Monitor which on the other hand runs on your server and reports network events from the server point of view.

Posted by David Konecny on April 08, 2013 at 12:59 PM PDT #

thank you sir! After spending going through 30+ sites for ansers, this one actually worked!

Posted by guest on September 01, 2013 at 01:22 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This is the blog of the NetBeans client-side web team, which develops the support for HTML5 applications in the NetBeans IDE.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today