liveBook · Manning

Polling

As explained in The Design of Web APIs, Second Edition

A polling strategy repeatedly sends requests to check the current state or result of an asynchronously running operation.

Polling repeatedly sends requests to check the status of an asynchronous operation. It avoids keeping a connection open for work that may last minutes or hours, reducing timeout and scalability risks. section 14.7 section 14.7.1

Monitoring a stress test

A dashboard starts a stock-market simulation with POST /simulations. The API returns 202 Accepted, current status, and Location: /simulations/12345. The dashboard then calls GET /simulations/12345 until the status changes from IN_PROGRESS to DONE. section 14.7.1

Make polling more efficient by:

  • Returning progressPercentage, progressPercentagePerMinute, or estimatedEnd so consumers can adjust request frequency. section 14.7.1
  • Returning Retry-After with an estimated completion time when another wait is appropriate. section 14.7.1
  • Considering callbacks or webhooks as alternatives, while retaining retrieval for consumers that cannot implement them. section 14.7 section 14.9

How The Design of Web APIs, Second Edition covers it

How deep it goes
Explains the request sequence and optimization metadata, but does not detail client scheduling algorithms.
Examples
Uses an on-demand bank stock-market stress test lasting up to an hour.
What it assumes
Assumes familiarity with HTTP API requests, resource URLs, status codes, and response headers.
What you can do after
Apply it via HTTP by starting an operation, following its status URL, and adapting request timing.
How it connects
Connects asynchronous operations with HTTP status codes, Location, Retry-After, callbacks, and webhooks.

Also explained in

Compare how 9 books explain polling →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of The Design of Web APIs, Second Edition. The section links point to the parts of the book it draws on.