liveBook · Manning

Retry-After indicator

As explained in API Design Patterns

The Retry-After header is an HTTP response header that indicates how long a client should wait before making a subsequent request or the time at which it may retry.

The Retry-After HTTP response header tells a client how long to wait before a follow-up request or when it may retry. It lets an API provide more specific timing than a client's normal exponential back-off. section 29.3.3

Format the delay deliberately:

  • Use a duration in seconds, such as 120, as the usual choice. section 29.3.3
  • A date is also valid, but clock differences between server and client can produce substantially incorrect waits. section 29.3.3
  • Apply the header when the service knows when a transient failure is likely to succeed, while retaining retry limits and delay caps. section 29.6

Client honoring a dictated delay

A retrying client checks for Retry-After, converts a value such as 120 seconds to milliseconds, and waits that duration. Without the header, it uses exponential back-off with random jitter.

How API Design Patterns covers it

How deep it goes
Explains header semantics, date-versus-duration formatting, clock risks, and client handling, but not broader retry safety rules in detail.
Examples
Uses a 120-second duration, a timestamp example, and a TypeScript chat-room retry loop.
What it assumes
Assumes HTTP request-and-response familiarity and basic retry concepts such as exponential back-off and transient errors.
What you can do after
Operate/configure a retrying client that honors server delays and otherwise applies bounded, jittered exponential back-off.
How it connects
Connects HTTP retry behavior with exponential back-off, jitter, transient errors, HTTP 429, and HTTP 403.

Also explained in

Compare how 2 books explain Retry-After indicator →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.