REST vs WebSocket Comparison and Benchmarks

java, javaee, ,

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.
    And the response headers received from WildFly 8:
    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.

websocket-rest-messages

Here is the raw data that feeds this graph:

websocket-rest-constant-payload

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.

websocket-rest-payload

Here is the raw data that feeds this graph:

websocket-rest-constant-messages

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!
  • Tweet
Related posts:
  1. Securing WebSocket using wss and HTTPS/TLS (Tech Tip #50)
  2. Securing WebSockets using Username/Password and Servlet Security (Tech Tip #49)
  3. STOMP over WebSocket (Tech Tip #53)
  4. Slides from Nuts and Bolts of WebSocket at #Devoxx 2014
  5. WebSocket Chat on WildFly and OpenShift (Tech Tip #51)

45 thoughts on “REST vs WebSocket Comparison and Benchmarks”

  1. 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.

  3. 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. Sumit,

    Any such architecture would need to be built on top of WebSocket. There are a few WebSocket subprotocols registered at: https://www.iana.org/assignments/websocket/websocket.xml but no clear REST API as such.

  8. Arun,

    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… :-)

    Regards
    -Markus

  9. Markus,

    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. Pingback: REST vs WebSockets: comparando rendimiento y otras consideraciones | Un poco de Java
  11. Pingback: Multiplexing and WebSockets | Tales from a Trading Desk

  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.

  15. 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 0.0.0.0, port 8080

    Thank you,
    Cris

  16. Cris,

    All WildFly/WebSocket tests pass but somebody already filed this bug: https://issues.jboss.org/browse/WFLY-3439

    Can you attach a reproducible test case ?

  17. Arun, Hi

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

    Thank you,
    Cris

  20. Pingback: REST vs WebSocket Comparison and Benchmarks | Rahul Sethi | PHP Programmer | Software Developer | India
  22. Pingback: Adding WebSocket endpoints on the fly with JRebel and Spring Boot | zeroturnaround.com

  23. “This graph and the table shows that the REST overhead increases with the number of messages. This is true because…” I draw a different conclusion. Your graph shows the ratio of websockets to HTTP “time to process”, which is relatively constant for the HTTP case but decreases by a factor of 10 for the websockets case. What your data actually shows IMO is a 10X DECREASE in websocket overhead, not a 10X increase in http overhead.

    What is “time to process” actually measuring? Is it time spent on the server? Why is this important in the context of all of the other work the server needs to do?

    Of course HTTP takes more “time to process” than websockets. HTTP is an application protocol and websockets is barely more than a transport protocol. A relevant and even valid comparison would be to implement an application protocol on top of websockets and compare that.

  24. REST if implemented correctly has no application state on the server side and can disconnect the connection.

    From what I understand with WebSockets it does not close the connection. Give that it looks like we would hit a user limit if we use WebSockets faster than REST.

  25. HTTP/1.1 is not uni-directional, there’s streaming and pipelining support. Also note that HTTP2 has similar characteristics to WebSockets, like low overhead, low latency, multiple streams through a single TCP connection… See e.g. http://stackoverflow.com/questions/14703627/websockets-protocol-vs-http

  26. Oh, and I wouldn’t say that an HTTP connection is typically closed after a request – the example even uses Connection: keep-alive! So it certainly doesn’t there.

  27. Hi Arun,

    Your article gives a good overview of RESTful HTTP vs websockets. Do you think there could be software architectures where people would use REST APIs for fetching relatively static data and websockets for ever-changing data (live values) or would that be an overkill

    Regards,
    DJ

  28. DJ,

    Thanks!

    That is one way to use REST vs WebSockets. But you should also think about how often that static data is changing and if the server needs to inform the client about it.

  29. Thanks for this benchmark,

    I have a chat application using Websocket, and by keeping more javax.websocket.Session objects my server will crash one day… so i want to prevent this by scaling out ?

    I want, please more detail about WebSocket horizontal scaling !

    thank you in advance, for your help.

  30. Pingback: Creating a WebSocket with Java and AngularJS – kertpjatkin.eu

  31. Hey ,

    I want to run your Websocket vs REST Test for myself can u help me to install it ? I have no Idea how to run this Test ? Would appreciate this a lot. And good work u did there 😉

    kinds regard

  33. Pingback: php restful api framework comparison - دسرا

  35. Hi Arun,

    I agree with you that replacing RESTful HTTP with WebSockets will not be always beneficial. However, for applications with large number of users, high frequency of requests, and/or requiring low-latency communication, such replacement could be appropriate using a WebSocket-based technology which solves a number of issues you mentioned (e.g. easy-to-use API, horizontal scalability, etc).

    In a recent post, I show how such an application – search box autocomplete – could benefit from replacing RESTful HTTP with a scalable WebSocket-based messaging solution. Here is the post and it also includes a benchmark:

    http://highscalability.com/blog/2016/12/13/a-scalable-alternative-to-restful-communication-mimicking-go.html

    Cheers,
    Mihai

  36. REST is architectural pattern – one step higher in the layer whereas Web socket is communication protocol a step lower in the layer. Article is nice and largely focused on comparing HTTP vs Web socket. But the name of the article REST Vs Web socket… is confusing to viewers.

  37. Would the ideal solution depend a lot on whether you expect lots of clients to connect infrequently, or few clients to connect frequently? A websocket needs to be maintained, which takes resources.

    Mihai’s search box autocomplete scenario is interesting though, lots of clients making frequent requests but only or a short part of their lifecycles. So hold a websocket during that interaction and revert to REST afterwards?

  38. Loved your comparison. I am trying to use strophejs and it support both HTTP and WebSockete for eJabber

    What should I consider for creating Chat application HTTP / WebSocket?

    Thanks,
    Iris
    https://jsonformatter.org

  39. Pingback: HTTP and Websockets: Understanding the capabilities of today’s web communication technologies - Platform Engineer
  41. Pingback: HTTP and Websockets: Understanding the capabilities of today’s web communication technologies | Platform Engineer

  42. I have created a solution, which uses Socket.IO, on GitHub you can check it out at https://p3x.redis.patrikx3.com

    Do you think for big responses from Socket.IO actually slows down the app and I should use rest instead? There is no rest in this program at all. It is pure socket.io totally.

    What do you think?

  43. Sockets are a paradigm for handling networking, and the concept has been around for decades. Sockets were once a way to standardize networking input and output, much like an API does, so that regardless of the particulars of the hardware, applications could program to “sockets”

  44. I have created a Redis UI app, and is not using rest at all, but for me (using Socket.IO), there must be weird, because it is not as fast as I expected, check it out: https://p3x.redis.patrikx3.com

  45. Wow! This is such a great post. Now getting clear idea about REST vs WebSocket Comparison and Benchmarks

Leave a Reply

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