REST or websocket market data

REST polling and WebSocket subscriptions differ mechanistically. HTTP polling uses repeated request-response exchanges, so updates arrive only when the client asks for them. WebSockets begin with an HTTP Upgrade handshake and then keep a persistent connection open so the server can push messages continuously. That changes update timing, makes connection lifecycle and reconnection central for WebSockets, and leaves gap-recovery details to provider-specific protocols not included in the cited sources.

Market-data delivery over REST and over WebSockets differ first at the protocol level.

HTTP, as defined in RFC 7231, is a request-response application protocol: a client sends a request method to a target resource, and the server sends back a response message with a representation or status describing the result of that request. In a polling design, the client repeats that cycle on its own schedule, such as requesting the latest quote, trades, or order-book snapshot at intervals. Because each update requires a new client request, the client receives data as a series of discrete observations rather than as a continuously delivered stream. The timing of updates is therefore governed by when the client chooses to issue requests and what representation the server returns for each one. RFC 7231 supports the mechanism of polling by defining the semantics of methods such as GET for transferring a current representation of a resource; it does not define a standing subscription that continuously pushes future changes after the response is complete.

WebSockets use a different mechanism. RFC 6455 defines an opening handshake that begins as an HTTP-based Upgrade request and, if accepted, switches the connection to the WebSocket protocol. After that handshake, the same underlying TCP connection remains open and both endpoints can exchange data in WebSocket frames until the connection is closed. For market data, that persistent connection enables a subscription model: once the client has connected and sent any provider-required subscription message, the server can push subsequent updates over the open connection as messages arrive. Mechanically, this is not repeated request-response polling. It is a long-lived connection with frame-based message delivery.

That protocol difference changes update timing. With REST polling, there is no delivery unless the client asks again, so updates are observed at request boundaries. If multiple market changes occur between polls, a poll may only return the latest server representation available at the moment of the request, depending on the API design. With WebSockets, once the connection is established, messages can be delivered whenever the server sends them over the persistent channel. RFC 6455 describes the framing, message fragmentation rules, and control frames that make that continuous delivery possible. MDN's WebSocket API documentation reflects the same lifecycle at the browser API level: code reacts to an open event when the connection is established, receives pushed data through message events, and handles close and error conditions when the stream ends or fails.

The two mechanisms also imply different connection state models.

In REST polling, each request can be treated independently at the HTTP layer. A client issues a request, receives a response, and the application decides when to issue the next request. Even if HTTP transport connections are reused underneath, the polling logic is still organized as repeated request-response exchanges. State about "where the stream is now" is usually maintained by the client application, for example by remembering the last timestamp, identifier, or snapshot it processed, not by relying on an ongoing push session defined by RFC 7231.

In WebSockets, connection state matters directly. RFC 6455 defines the opening handshake, data transfer phase, and closing handshake, along with endpoint behavior for control frames such as Ping, Pong, and Close. MDN likewise describes a WebSocket object with a lifecycle that includes connection establishment, message receipt, and closure. For an ingestion pipeline, that means the client must actively manage a live session: connect, confirm the socket is open, subscribe if required by the provider protocol, process incoming messages in order as they arrive, and detect when the session has closed so it can re-establish it.

Reconnection behavior follows from that difference.

For REST polling, a failed request is usually handled by retrying another request later, because there is no standing stream to restore. The next successful request simply retrieves the current resource representation exposed by the endpoint. The main concern is deciding how the application resumes its polling schedule and whether it needs to compensate for time missed between successful requests.

For WebSockets, a disconnect interrupts an active delivery channel. RFC 6455 defines how connections are closed, but application recovery after closure is generally left to the application or the provider-specific protocol running over the socket. MDN documents that clients should listen for close events and can create a new WebSocket object to reconnect. In practice, reconnect logic for market data usually includes more than reopening the TCP/WebSocket session: the client often must resubscribe to channels and determine whether any updates were missed while the connection was unavailable.

Gap handling is application-specific.

The standards explain the transport mechanisms but do not prescribe a universal market-data recovery method such as sequence numbers, replay, or REST snapshot resynchronization.

Because REST polling returns discrete representations in response to explicit requests, a client that needs continuity must decide how to compare successive responses and determine what changed between them. Because WebSockets deliver an ongoing sequence of pushed messages over a persistent connection, a client must detect interruption of that sequence when the connection closes or errors and then restore the session. Specific techniques for proving continuity or repairing gaps depend on provider protocol specifications.

How to choose per workload follows directly from the mechanism, not from any unsupported performance claim.

REST polling fits workloads where the client wants periodic reads of a resource representation and can work in discrete request cycles. It is operationally simple because the client asks for data when needed and handles each response as a standalone fetch.

WebSocket subscriptions fit workloads where the client wants an ongoing feed of updates delivered over a persistent connection and is prepared to manage socket lifecycle events, subscription state, and recovery after disconnects.

In short: REST polling is repeated client-initiated retrieval of current representations through HTTP request-response exchanges. WebSocket market data is server-delivered messaging over a persistent connection established by an HTTP Upgrade handshake and then governed by the WebSocket protocol. That distinction drives how updates arrive, what state the client must maintain, and how recovery is approached when delivery is interrupted.

Drafted with AI assistance from cited sources. Reviewed and approved by Sonar Sciences Quant & Research Team.