What are WebSockets?
WebSockets are really just an extension of the socket idea. While HTTP was invented for the World Wide Web, and has been used by browsers since then, it had limitations. It was a particular protocol that worked in a particular way, and wasn’t well suited for every need. In particular was how HTTP handled connections. Whenever you made a request, say to download html, or an image, a port/socket was opened, data was transferred, and then it was closed.
The opening and closing creates overhead, and for certain applications, especially those that want rapid responses or real time interactions or display streams of data, this just doesn’t work.
The other limitation with HTTP was that it was a “pull” paradigm. The browser would request or pull information from servers, but the server couldn’t push data to the browser when it wanted to. This means that browsers would have to poll the server for new information by repeating requests every so many seconds or minutes to see if there was anything new. In the late 2000’s, a movement to add Sockets to browsers was mounting.
In 2011, the WebSocket was standardized, and this allowed people to use the WebSocket protocol, which was very flexible, for transferring data to and from servers from the browser, as well as Peer-to-Peer (P2P), or direct communication between browsers. Unlike HTTP, the socket that is connected to the server stays “open” for communication. That means data can be “pushed” to the browser in realtime on demand.
What is REST architecture?
REST stands for REpresentational State Transfer. REST is web standards based architecture and uses HTTP Protocol. It revolves around resource where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. REST was first introduced by Roy Fielding in 2000.
A REST Server simply provides access to resources and REST client accesses and modifies the resources using HTTP protocol. Here each resource is identified by URIs/ global IDs. REST uses various representation to represent a resource like text, JSON, XML but JSON is the most popular one.
RESTful Web Services
A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., communication between Java and Python, or Windows and Linux applications) is due to the use of open standards.
Web services based on REST Architecture are known as RESTful web services. These webservices uses HTTP methods to implement the concept of REST architecture. A RESTful web service usually defines a URI, Uniform Resource Identifier a service, which provides resource representation such as JSON and set of HTTP Methods.
For more real time interaction, or real time transfer or streaming of data, HTTP and REST aren’t the best suited protocol and abstraction combination. This is where Sockets and WebSockets shine.
WebSockets vs REST: A Comparison of Performance
The overhead of opening and closing connections is very real. The performance of being able to send and receive data and the number of concurrent devices that can do so is a significant consideration. The use of polling versus pushing is also a very real burden on servers.
REST Performance
Metaphorically, we could think of this as an army with a chain of command. Let’s make the server the General, and all the browsers the soldiers on the ground waiting for orders. Using HTTP/REST, if every soldier has to ask the General if there are any new orders, it burdens the General tremendously, particularly when there isn’t anything new. That means the General is saying “no, nothing new” most of the time.
If your servers are the General, their resources are being wasted mostly saying that there is nothing new. Furthermore, because the General can only answer so many soldiers at a time, it takes a long time to say “nothing new” to every soldier even once, there is a time delay where the last soldiers in line hear the “nothing new” far later than the first soldier who asked.
WebSockets Performance
Using the same metaphor, sockets being connected are like each soldier having a radio, and when the General has a new order, he can send that order into the radio and all the soldiers can receive it at the same time. It could be all the soldiers hear the same order, and, of course we can have different bands on the radio, and the General can speak order to particular groups listening on different bands.
The efficiency here is on both sides.
The General no longer needs to be burdened with unnecessary work, so you need fewer servers to service your clients. The clients also don’t need to waste networking and resources for polling and making requests. Far more efficient on both sides.
There are a number of WebSocket frameworks and Socket.IO is likely the most popular and widely known.
It’s a great way to become familiar with Socket style programming and how the paradigm works. However, actually using it in production has a bigger story.
When using Socket.IO, just like any other server, you have to dedicate time and resources to setting it up, configuring, monitoring, managing, and scaling. All of these take time, people and machines, all of which cost money. Throw in learning from mistakes and anomalies when things go awry, which they always will. Every time there is a lesson learned, the value is the lesson, but the cost is downtime for the application relying everything working, and likely losing customers.
Reference
- API
- Socket API
- Select Websocket
- Rest Sample Php
- Proxy A proxy is “something” that acts on behalf of one other.
- Websocket 101
- Information
- REST Api Nodejs