REST API
A request-and-response HTTP interface - the standard way to pull a defined range of history, as opposed to receiving records as they happen.
A REST API exposes resources over HTTP: the client asks for something with a URL and parameters, the server answers, and the connection closes. It is the right shape for bounded questions - a range of history, a backfill after downtime, a reproducible extract for a training run - because the client controls exactly what it receives and can ask for the same thing again and get the same answer.
It is the wrong shape for anything whose value decays in seconds. Polling a REST endpoint every few seconds adds half the polling interval to every record's delay on average, plus a round-trip time and a handshake on each call, which is delay a streaming API simply does not incur. Most teams use both against the same records: history through REST for research, the stream for production, so that what a backtest validated is what production consumes.
Real-time data, at edge speed.
A live evaluation measures EdgeOrigin against your coverage requirements: decision-ready real-time data, delivery latency into your systems, and record-level provenance.