Stock API: REST or WebSocket?

Stock API: A Poster Child of Disruptive Innovation

In his landmark research on disruptive innovation, the great management thinker Dr. Clayton Christensen observed:

Once a product or service reliably delivers for customers, individual parts and their interactions become standardized. This creates a state of modularity where many suppliers can compete to deliver one or more modules more cheaply and quickly. Interdependence and modularity are not binary notions; they are part of a continuum. It’s worth reiterating that the implementation of either modularity or interdependence does not determine whether a product is adopted, but predicts how quickly adoption will occur. (source)

Indeed, since the invention of the Internet in the 1960s, the financial industry has evolved to a stage where market data is more or less standardized, with a broad spectrum of suppliers offering predictable, modular interfaces for the ingestion and consumption of financial market data. A stock API is a prominent example of such modular interfaces.

With stock APIs, a portfolio manager no longer needs to call NASDAQ or NYSE and say “please give me data.” Instead, they can simply use a modular, pre-packaged API to get clean and standardized market data. Take Harvard University as an example. In 2020, Harvard Business School launched the COVID-19 Business Impact Center, a key component of which is a Global Policy Tracker that aggregates key economic policies (e.g., fiscal, monetary) implemented as a response to the Covid-19 pandemic around the world. When tracking the global foreign exchange rates as part of the initiative, Harvard Business School didn’t go to the central banks and say “please give me forex data.” Instead, the project team used a stock API called Alpha Vantage to query realtime and historical forex data for its economic analysis.

In this article, we will examine a key design choice faced by users working with APIs: when integrating an API into my application, should I use REST or WebSocket?

Pulling Data vs. Pushing Data: Making the Right Design Choice

When integrating a stock API into your application – trading algorithm, iOS/Android app, personal finance dashboard, just to name a few – you often face an immediate design choice: REST endpoints vs. WebSockets. At the time of writing this article, some of the popular stock APIs in the market support at least the REST option, with a majority of them supporting WebSocket as well. However, it can still be quite confusing to an end user as to “when to use what.” In reality, the REST-vs-WebSocket choice is not something to be made lightly via a coin flip – making the right design choice would go a long way toward building a scalable software application. Let’s unravel the puzzle!

REST Endpoint as a Pull Mechanism

According to Wikipedia:

Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services, provide interoperability between computer systems on the internet. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations. (source)

In layman terms, a REST endpoint is like a menu when you visit a restaurant. It is a standardized communication vehicle between you and the restaurant. As long as you order a dish that is listed on the menu, the restaurant will make the gourmet for you. Similarly, you can “order” financial market data via another kind of “menu” – a REST stock API.

The REST API is passive and on-demand by nature. It won’t automatically “push” data to you; rather, you would need to “pull” the data the moment you need it (just like most restaurants that make dishes only after a customer has placed their order.) If you need to pull the close prices of all S&P 500 stocks daily at 8pm ET, a REST mechanism will be the perfect solution. However, if you would like to stream live stock price movements to capture all the trading actions at the exchanges, a passive pulling mechanism might pale in scalability and you will need a more robust solution that can proactively “push” live data to you – this is where a WebSocket comes in.

WebSocket as a Push Mechanism

According to Wikipedia:

The WebSocket protocol enables interaction between a web browser (or other client application) […], facilitating real-time data transfer from and to the server. This is made possible by providing a standardized way for the server to send content to the client without being first requested by the client, and allowing messages to be passed back and forth while keeping the connection open.

In other words, a WebSocket is like a rotating sushi bar that brings all the available dishes in front of you. You don’t need to proactively order anything – all you need to do is to find a seat near the revolving belt. In the financial data domain, a WebSocket is best suited for processing data on a continuous, streaming basis – e.g., live stock prices, market news, etc. Given its high information density and continuous delivery mechanism, WebSockets are sometime called “information firehoses,” a fitting description.

In Summary

Stock APIs are modular interfaces with attributes that almost perfectly fit the Modularity Theory (part of the Disruptive Innovation framework) by Professor Clayton Christensen – specifically:

  • Standardized components
  • Optimized for price, speed
  • Often outsourced (i.e., accessed via third-party)
  • Rapid adoption
  • Expands industries

When designing the integration logic with these modular interfaces, there are no one-size-fits-all rules that stipulate the exact business scenarios that merit the use of REST endpoints vs. WebSocket. As we have surveyed in this article, however, the financial market data domain does have some empirical boundaries when it comes to the data consumption mechanisms of stock market APIs. You may refer to the following table as a starting point as you design the data integration pipeline for your own software and investment applications. The REST vs. WebSocket dichotomy is a developing subject matter, and we will update this article based on the latest technological trends and software design patterns.

Use REST endpoints for… Use WebSocket for…
Pulling market data at pre-determined schedule Streaming financial data continuously
Data with low or medium refresh frequency Data with high refresh frequency
Structured data with server-side caching Data with no server-side storage requirements
Prototyping applications with static data Prototyping applications with streaming data

Content Permalink

1 Comment »

  1. James Harding

    August 12, 2020 @ 6:31 pm

    1

    Very interesting topic. Loved the use of Menu vs Sushi bar as a way of explaining the fundamental logical differences between the structures of REST vs WebSocket. Thanks for sharing.

Leave a Comment

Log in