- WebSockets Tutorial
- WebSockets – Home
- WebSockets Introduction
- WebSockets – Overview
- WebSockets - Duplex Communication
- WebSockets – Functionalities
- WebSockets – Implementation
- WebSockets Roles
- WebSockets – Events and Actions
- WebSockets – Opening Connections
- WebSockets – Handling Errors
- WebSockets - Send & Receive Msgs
- WebSockets – Closing a Connection
- JavaScript & WebSockets API
- WebSocket - Server Working
- WebSocket - API
- WebSockets – JavaScript Application
- WebSockets Implementation
- Communicating with Server
- WebSockets – Security
- WebSockets – Mobile APP
- WebSockets Useful Resources
- WebSockets – Quick Guide
- WebSockets – Useful Resources
- WebSockets – Discussion
WebSockets - API
API – Definition
API, an abbreviation of Application Program Interface, is a set of routines, protocols, and tools for building software applications.
Some important features are −
The API specifies how software components should interact and APIs should be used when programming graphical user interface (GUI) components.
A good API makes it easier to develop a program by providing all the building blocks.
REST, which typically runs over HTTP is often used in mobile applications, social websites, mashup tools, and automated business processes.
The REST style emphasizes that interactions between the clients and services is enhanced by having a limited number of operations (verbs).
Flexibility is provided by assigning resources; their own unique Universal Resource Identifiers (URIs).
REST avoids ambiguity because each verb has a specific meaning (GET, POST, PUT and DELETE)
Advantages of Web Socket
Web Socket solves a few issues with REST, or HTTP in general −
Bidirectional
HTTP is a unidirectional protocol where the client always initiates a request. The server processes and returns a response, and then the client consumes it. Web Socket is a bi-directional protocol where there are no predefined message patterns such as request/response. Either the client or the server can send a message to the other party.
Full Duplex
HTTP allows the request message to go from the client to the server and then the server sends a response message to the client. At a given time, either the client is talking to the server or the server is talking to the client. Web Socket allows the client and the server to talk independent of each other.
Single TCP Connection
Typically, a new TCP connection is initiated for an HTTP request and terminated after the response is received. A new TCP connection needs to be established for another HTTP request/response. For Web Socket, the HTTP connection is upgraded using standard HTTP upgrade mechanism and the client and the server communicate over that same TCP connection for the lifecycle of Web Socket connection.
The graph given below shows the time (in milliseconds) taken to process N messages for a constant payload size.
Here is the raw data that feeds this graph −
The graph and the table given above show 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 fulfil 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.
Conclusion
Web Socket is a low-level protocol. Everything, including a simple request/response design pattern, how to create/update/delete resources need, status codes etc. to be builds on top of it. All of these are well defined for HTTP.
Web Socket is a stateful protocol whereas HTTP is a stateless protocol. Web Socket connections can scale vertically on a single server whereas HTTP can scale horizontally. There are some proprietary solutions for Web Socket horizontal scaling, but they are not based on standards. HTTP comes with a lot of other goodies such as caching, routing, and multiplexing. All of these need to be defined on top of Web Socket.