Miles to go 2.0 …

Arun Gupta is a technology enthusiast, avid runner, author of a best-selling book, globe trotter, a community guy, Java Champion, JavaOne Rockstar, JUG Leader, Minecraft Modder, Devoxx4Kids-er, and a Red Hatter.

REST vs WebSocket Comparison and Benchmarks

One of the common questions asked during my #JavaEE7 presentations around the world is how do WebSockets compare with REST ?

First of all, REST is a style of architecture so what really people mean is RESTful HTTP. As an architecture cannot be compared with a technology. But the term is so loosely used that they are used in place of each other commonly.

Lets start with a one line definition for WebSocket …

Bi-directional and full-duplex communication channel over a single TCP connection.

WebSocket solves a few issues with REST, or HTTP in general:

  • Bi-directional: HTTP is a uni-directional protocol where a request is always initiated by client, server processes and returns a response, and then the client consumes it. WebSocket is a bi-directional protocol where there are no pre-defined message patterns such as request/response. Either client or server can send a message to the other party.
  • Full-duplex: HTTP allows the request message to go from client to server and then server sends a response message to the client. At a given time, either client is talking to server or server is talking to client. WebSocket allows client and server to talk independent of each other.
  • Single TCP Connection: Typically a new TCP connection is initiated for a HTTP request and terminated after the response is received. A new TCP connection need to be established for another HTTP request/response. For WebSocket, the HTTP connection is upgraded using standard HTTP Upgrade mechanism and client and server communicate over that same TCP connection for the lifecycle of WebSocket connection.
  • Lean protocol: HTTP is a chatty protocol. Here is the set of HTTP headers sent in request message by Advanced REST Client Chrome extension.
    POST /websocket-vs-rest-payload/webresources/rest HTTP/1.1\r\n
    Host: localhost:8080\r\n
    Connection: keep-alive\r\n
    Content-Length: 11\r\n
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36\r\n
    Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo\r\n
    Content-Type: text/plain \r\n
    Accept: */*\r\n
    Accept-Encoding: gzip,deflate,sdch\r\n
    Accept-Language: en-US,en;q=0.8\r\n

    And the response headers received from WildFly 8:

    HTTP/1.1 200 OK\r\n
    Connection: keep-alive\r\n
    X-Powered-By: Undertow 1\r\n
    Server: Wildfly 8 \r\n
    Content-Type: text/plain\r\n
    Content-Length: 11 \r\n
    Date: Fri, 21 Feb 2014 21:27:53 GMT \r\n

    These are 663 characters exchanged for a trivial “Hello World” echo. The source code for this simple application is here.

    For WebSocket, after the initial HTTP handshake, the data is minimally framed with 2 bytes.

Lets take a look at a micro benchmark that shows the overhead caused by REST over a WebSocket echo endpoint. The payload is just a simple text array populated with ‘x’. The source code for the benchmark is available here.

The first graph shows the time (in milliseconds) taken to process N messages for a constant payload size.


Here is the raw data that feeds this graph:


This graph and the table shows that the REST overhead increases with the number of messages. This is true because that many TCP connections need to be initiated and terminated and that many HTTP headers need to be sent and received. The last column particularly shows the multiplication factor for the amount of time to fulfill a REST request.

The second graph shows the time taken to process a fixed number of messages by varying the payload size.


Here is the raw data that feeds this graph:


This graph shows that the incremental cost of processing the request/response for a REST endpoint is minimal and most of the time is spent in connection initiation/termination and honoring HTTP semantics.

These benchmarks were generated on WildFly 8 and the source code for the benchmark is available here.

Together the graph also shows that WebSocket is a more efficient protocol than RESTful HTTP. But does that mean it will replace RESTful HTTP ?

The answer to that, at least in the short term is, NO!

  • WebSocket is a low-level protocol, think of it as a socket on the web. Every thing, including a simple request/response design pattern, how to create/update/delete resources need, status codes etc to be build on top of it. All of these are well defined for HTTP.
  • WebSocket is a stateful protocol where as HTTP is a stateless protocol. WebSocket connections are know to scale vertically on a single server where as HTTP can scale horizontally. There are some proprietary solutions for WebSocket horizontal scaling, but they are not standards-based.
  • HTTP comes with a lot of other goodies such as caching, routing, multiplexing, gzipping and lot more. All of these need to be defined on top of WebSocket.
  • How will Search Engine Optimization (SEO) work with WebSocket ? Works very well for HTTP URLs.
  • All proxy, DNS, firewalls are not yet fully aware of WebSocket traffic. They allow port 80 but might restrict traffic by snooping on it first.
  • Security with WebSocket is all-or-nothing approach.

This blog does not provide any conclusion because its meant to trigger thoughts!

And if you want a complete introduction to JSR 356 WebSocket API in Java EE 7, then watch a recently concluded webinar at vJUG:

So, what do you think ?

Be Sociable, Share!

19 Responses to “REST vs WebSocket Comparison and Benchmarks”

  1. Paul Bakker says:

    You make a very good point that raw performance metrics are not very useful to look at. Even if you come up with your own protocol there will be a need for some kind of message structure, or the API wil become very hard to use.

    I do expect we will see some solutions where clients/servers start communicating in a more message based approach (JMS like) however to leverage the async infrastructure better. It could be an idea to route JMS/AMQP messages over web sockets, a web sockets client would just be another message consumer/producer.

  2. Binh Thanh Nguyen says:

    Thanks, nice comparsion.

  3. Sumit Pal says:

    Should we not have RESTFul application be based on WebSockets – then we can have the best of both worlds – as you mentioned REST is an architectural style while WebSocket is a technology.

  4. arungupta says:


    Any such architecture would need to be built on top of WebSocket. There are a few WebSocket subprotocols registered at: but no clear REST API as such.

  5. bcs says:

    How about a CRUD appl using WebSocket?

  6. arungupta says:


    I was thinking about that earlier. Do you want to send a PR at ?

  7. Justin Bertram says:

    Paul Bakker, HornetQ supports your idea already. See here.

  8. Markus Karg says:


    always interesting to find benchmarks, but as you implied already, it is like comparing apples and organges. Despite the technical differences you already mentioned, I’d like to recall that WebSockets do originally serve for a completely different purpose (pushing live updates) than REST (pulling full state). Hence, I would say that not only both are no competitors in real-world applications, but actually it is very beneficial to use both at the same time: Pull the full state using REST to gain benefits of HTTP goodies like caching, compression, selective encoding, language and data format selection, optional requests etc., and then optionally push live updates with WebSockets to keep the GUI updated constantly. BTW, it might be interesting to the readers to know that support for WebSockets was discussed by the JSR 399 Expert Group (JAX-RS 2.0), is it might make sense to use the JAX-RS API to make use of WebSockets under the hood… :-)


  9. arungupta says:


    Thanks for the insight.

    Do you want to share more details on JSR 339’s usage of WebSocket under the hood ? Is it like a subprotocol ?

  10. […] través de he llegado a esta comparativa entre REST y WebSockets en cuanto a rendimiento que me ha recordado porque no todo debe resolverse con interfaces […]

  11. […] theory you could open multiple WebSocket connections, one for every module. Although suboptimal (due to the need to handle multiple TCP/IP […]

  12. Suleiman says:

    why you are saying that websocket is stateful

  13. I think the big question I have is how to decide when to use them, and how much. I’m working on an app with wildfly where I can think of one piece where websockets might make sense, but just periodic polling (every 30s maybe) would probably be fine. But now I’m wondering if I used web sockets for that, should I use them for everything? do I even have a valid use case for that?

    I think people are little unfair to Websockets on the unstandardized protocol.. people will have there own proprietary protocol… and they don’t do that now? even with RESTful applications the whole thing is basically one proprietary payload after another, much of the HTTP protocol is either ignored by programmatic clients, or browsers, let me know when a browser supports a DELETE request in an HTML form.

  14. girish says:

    Nice one…………

  15. vlcvlc says:

    Arun, HI

    I confirm that Websocket implementation works in 8.0.0 Final.

    But I tried to deploy in 8.1.0 Final the same .war that I deployed in 8.0.0. and cannot connect from client. The context and endpoint are deployed and registered with success (I can see Console messages) but I cannot establish connection from different clients (JS, Java). Undertow is listening on, port 8080

    Thank you,

  16. arungupta says:


    All WildFly/WebSocket tests pass but somebody already filed this bug:

    Can you attach a reproducible test case ?

  17. vlcvlc says:

    Arun, Hi

    There is WildFly clustering integrated with websockets, I mean share sessions and so for (like on HTTP).

    Thank you,

  18. arungupta says:


    WebSocket is nothing HTTP :)

    What do you expect to happen from WebSocket clustering ?

Leave a Reply

Your email address will not be published. Required fields are marked *

8 × = seventy two

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>