Bird
Raised Fist0
Rest APIprogramming~5 mins

Retry-After header in Rest API - Cheat Sheet & Quick Revision

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is the purpose of the Retry-After header in HTTP?
The Retry-After header tells the client how long to wait before making another request. It helps manage server load and avoid repeated requests during downtime or rate limiting.
Click to reveal answer
beginner
What are the two formats allowed for the Retry-After header value?
The Retry-After header value can be either:
1. A number representing seconds to wait.
2. An HTTP-date indicating the exact time after which to retry.
Click to reveal answer
beginner
When is the Retry-After header typically used in HTTP responses?
It is commonly used with status codes 429 Too Many Requests and 503 Service Unavailable to tell clients when to retry their requests.
Click to reveal answer
beginner
Example: What does this header mean?
Retry-After: 120
It means the client should wait 120 seconds (2 minutes) before retrying the request.
Click to reveal answer
beginner
Example: What does this header mean?
Retry-After: Wed, 21 Oct 2024 07:28:00 GMT
It means the client should wait until the date and time Wed, 21 Oct 2024 07:28:00 GMT before retrying the request.
Click to reveal answer
What does the Retry-After header tell the client?
AThe type of content returned
BThe size of the response body
CHow long to wait before retrying a request
DThe server's IP address
Which HTTP status code commonly uses the Retry-After header?
A404 Not Found
B301 Moved Permanently
C200 OK
D429 Too Many Requests
Which of these is NOT a valid format for the Retry-After header value?
AA URL to retry
BHTTP-date format
CNumber of seconds to wait
DNone of the above
If a server responds with Retry-After: 60, what should the client do?
AWait 60 seconds before retrying
BRetry immediately
CIgnore the header
DRetry after 60 minutes
The Retry-After header helps to:
AIncrease the speed of requests
BReduce server overload by controlling retry timing
CChange the request method
DEncrypt the response
Explain what the Retry-After header is and when it is used.
Think about how servers tell clients to pause before retrying.
You got /3 concepts.
    Describe the two formats allowed for the Retry-After header value and give an example of each.
    One is a number, the other is a date string.
    You got /4 concepts.

      Practice

      (1/5)
      1.

      What is the main purpose of the Retry-After header in REST APIs?

      easy
      A. To provide the client's IP address to the server
      B. To specify the content type of the response
      C. To tell the client how long to wait before making another request
      D. To indicate the server's current time

      Solution

      1. Step 1: Understand the role of Retry-After header

        The Retry-After header is used by servers to tell clients when they can retry a request after being told to wait.
      2. Step 2: Match purpose with options

        To tell the client how long to wait before making another request correctly states that it tells the client how long to wait before retrying, which matches the header's purpose.
      3. Final Answer:

        To tell the client how long to wait before making another request -> Option C
      4. Quick Check:

        Retry-After = wait time before retry [OK]
      Hint: Retry-After tells when to retry, not server info [OK]
      Common Mistakes:
      • Confusing Retry-After with content type headers
      • Thinking Retry-After provides server time
      • Assuming Retry-After sends client info
      2.

      Which of the following is a correct example of the Retry-After header syntax?

      Retry-After: ?
      easy
      A. Wed, 21 Oct 2015 07:28:00 GMT
      B. "120 seconds"
      C. 120 seconds
      D. After 2 minutes

      Solution

      1. Step 1: Review Retry-After header formats

        Retry-After accepts either a number of seconds (integer) or a HTTP-date string.
      2. Step 2: Check each option

        120 seconds includes invalid text; "120 seconds" incorrectly quotes the number with text; Wed, 21 Oct 2015 07:28:00 GMT is a valid HTTP-date format; After 2 minutes is not a valid format.
      3. Final Answer:

        Wed, 21 Oct 2015 07:28:00 GMT -> Option A
      4. Quick Check:

        Retry-After = seconds or HTTP-date [OK]
      Hint: Retry-After uses seconds or HTTP-date format only [OK]
      Common Mistakes:
      • Adding quotes around seconds value
      • Using natural language like 'After 2 minutes'
      • Using invalid date formats
      3.

      Given the following HTTP response header:

      HTTP/1.1 503 Service Unavailable
      Retry-After: 60

      What should the client do?

      medium
      A. Wait 60 seconds before retrying the request
      B. Retry the request immediately
      C. Ignore the Retry-After header and retry after 5 seconds
      D. Abort the request permanently

      Solution

      1. Step 1: Interpret the Retry-After header value

        The header value '60' means the client should wait 60 seconds before retrying.
      2. Step 2: Match client action to header instruction

        Wait 60 seconds before retrying the request correctly instructs to wait 60 seconds before retrying, which follows the server's guidance.
      3. Final Answer:

        Wait 60 seconds before retrying the request -> Option A
      4. Quick Check:

        Retry-After: 60 means wait 60 seconds [OK]
      Hint: Retry-After number means wait that many seconds [OK]
      Common Mistakes:
      • Retrying immediately ignoring Retry-After
      • Assuming Retry-After is in milliseconds
      • Treating Retry-After as a permanent failure
      4.

      Identify the error in this HTTP response header snippet:

      HTTP/1.1 429 Too Many Requests
      Retry-After: "30 seconds"
      medium
      A. The header name should be lowercase
      B. Retry-After value should not be quoted or include text
      C. Retry-After header is missing
      D. Status code 429 is invalid

      Solution

      1. Step 1: Check Retry-After header format

        The Retry-After header must be either an integer number of seconds or a valid HTTP-date string without quotes or extra text.
      2. Step 2: Identify the error in the given header

        The value "30 seconds" is quoted and includes text, which is invalid syntax.
      3. Final Answer:

        Retry-After value should not be quoted or include text -> Option B
      4. Quick Check:

        Retry-After must be seconds or date, no quotes/text [OK]
      Hint: Retry-After value is raw seconds or date, no quotes [OK]
      Common Mistakes:
      • Adding quotes around Retry-After value
      • Including descriptive text in Retry-After
      • Confusing header case sensitivity
      5.

      A server wants to tell clients to retry after 2 minutes using the Retry-After header. Which is the best way to set this header to ensure compatibility?

      hard
      A. Retry-After: Wed, 21 Oct 2030 07:28:00 GMT (current time + 2 minutes)
      B. Retry-After: "120 seconds"
      C. Retry-After: After 2 minutes
      D. Retry-After: 120

      Solution

      1. Step 1: Understand Retry-After header formats

        Retry-After accepts either an integer number of seconds or a valid HTTP-date string.
      2. Step 2: Evaluate options for compatibility

        Retry-After: 120 uses integer seconds (120) which is simple and widely supported. Retry-After: "120 seconds" incorrectly quotes and adds text. Retry-After: Wed, 21 Oct 2030 07:28:00 GMT (current time + 2 minutes) uses a date but must be exact and updated dynamically, which is complex. Retry-After: After 2 minutes is invalid text.
      3. Final Answer:

        Retry-After: 120 -> Option D
      4. Quick Check:

        Use seconds as integer for simple Retry-After [OK]
      Hint: Use integer seconds for Retry-After to ensure compatibility [OK]
      Common Mistakes:
      • Adding quotes or text to seconds value
      • Using a fixed date without updating
      • Writing natural language instead of valid format