REST vs WebSockets
“What is the difference between WebSockets and the REST API?” is a question I’m asked on a regular basis. In this post, I’ll try to clarify the jargon around both technologies and offer a basic explanation for their use. The essay is primarily written for non-technical readers who want to know whether WebSockets or REST are better for their data needs. Let’s first define WebSocket and REST API before diving into their applications.
What is a REST API?
REST is a set of restrictions or design rules for creating web services that use the HTTP protocol to interact between the client and the server, but only one way at a time. As a result, the REST API only responds to requests for data (or any other resource). It’s similar to getting anything from a vending machine: you’ll need to ask for the correct resource.
What is a WebSocket?
Websocket is a computer communication protocol, or more simply “a collection of rules” that allows two computer computers to interact with one another. It uses a TCP Socket to create bidirectional communication between two machines. Let’s look at how the WebSocket can aid with data delivery. In essence, a WebSocket provides a continuous two-way connection between the client (requesting data) and the server (sending data). A phone call, for example, allows for continuous two-way conversation once the call is connected.
What purposes is REST API used for?
When data needs are not constant and stateless, REST API is employed. For example, you may request current data when your application requires it, or you can request historical timeseries data to produce a chart. REST is a resource-based idea similar to our vending machine example, however Amazon.com is a better extension of that comparison because you can request your resource online and have it delivered.
What purposes is Websocket used for?
Websocket is commonly used for continuous (but not necessarily) and duplex data transfer, such as for low latency and high-frequency forex data feeds or Chat applications. Requesting 100s of rates per second through REST API will be resource-intensive, however the Websocket client can receive 100s of rates per second without being resource-intensive.
When to use Websocket and when to use REST?
Websockets vs REST is an issue of “what is more appropriate?” rather than “what is best?” REST is more adaptable and can supply practically all of the resources that we give. It is beneficial when data demands are ad hoc, but it is ineffective when data delivery has to be ultra rapid (more than 100 requests per second) and continuous, when every tick rate matters (in the case of forex data). WebSocket is suitable when no rates must be missed in delivery (such as when tick data analysis is necessary) and speed is critical. Websockets are appropriate for settings with heavy loads.
Conclusion
What is WebSockets and what is the REST API? In this essay, I’ll try to clarify the jargon around both technologies. In essence, a WebSocket provides a continuous two-way connection between the client (requesting data) and the server (sending data). A REST API only responds to requests for data (or any other resource). Websocket is commonly used for continuous (but not necessarily) and duplex data transfer.
When data needs are not constant and stateless, REST API is employed. Requesting 100s of rates per second through REST API will be resource-intensive. WebSocket is suitable when no rates must be missed in delivery.