REST vs WebSocket

Every dataset is available over both REST and WebSocket. They're not alternatives — they solve different problems and most production apps use both.

TL;DR

  • Use REST when you ask a question.
  • Use WebSocket when you want to be told.

REST polling

Right when:

  • You need a snapshot — e.g. final box score, current standings, today's schedule
  • You're building on serverless and can't hold connections
  • The data doesn't change often — schedule, season totals, historical archives
  • You need pagination or complex filtering

WebSocket push

Right when:

  • You want sub-second updates pushed to your app
  • You're rendering live scores to clients (browsers, mobile apps)
  • You'd otherwise be polling every 1–2 seconds
  • You need to react to discrete events: goals, penalties, injury news
💡
WebSocket consumption doesn't count against your REST rate limit. Connection count and message rate have separate limits per plan.

When to use both

Most production apps look like this:

  • On page load / app start: REST call to get current state
  • While the user is watching: WebSocket subscribe to push deltas
  • On reconnect: REST call again to catch up, then resume subscription

This pattern handles network blips, mobile-app backgrounding, and stale tabs gracefully. See the reconnection guide for production-ready code.

← Previous
Data Freshness