429 Too Many Requests in Rest API - Mini Project: Build & Apply

Handling 429 Too Many Requests in REST API

📖 Scenario: You are building a simple REST API client that calls a web service. Sometimes, the server limits how many requests you can send in a short time. When you send too many requests, the server responds with a 429 Too Many Requests status code. Your task is to handle this response properly by waiting and retrying the request.

🎯 Goal: Create a Python program that makes a request to a web API. If the server responds with 429 Too Many Requests, the program should wait for a specified time and then retry the request once.

📋 What You'll Learn

Create a variable called url with the API endpoint string 'https://api.example.com/data'.

Create a variable called retry_wait with the integer value 5 representing seconds to wait before retry.

Write code to send a GET request to url using the requests library.

If the response status code is 429, wait for retry_wait seconds and send the request again.

Print 'Success' if the final response status code is 200, otherwise print 'Failed with status code: X' where X is the status code.

💡 Why This Matters

🌍 Real World

Many web APIs limit how often you can send requests to prevent overload. Handling 429 responses properly helps your program be polite and avoid being blocked.

💼 Career

Understanding how to handle rate limits and retry logic is important for backend developers, API consumers, and anyone working with web services.

1

Set up the API endpoint URL

Create a variable called url and set it to the string 'https://api.example.com/data'.

Rest API

# Create the API endpoint URL
# Your code here

Hint

Use a simple assignment statement to create the url variable.

2

Set the retry wait time

Create a variable called retry_wait and set it to the integer 5 to represent seconds to wait before retrying.

Rest API

url = 'https://api.example.com/data'
# Set the retry wait time in seconds
# Your code here

Hint

Use a simple assignment statement to create the retry_wait variable.

3

Send the request and handle 429 status

Import the requests and time modules. Send a GET request to url and store the response in a variable called response. If response.status_code is 429, use time.sleep(retry_wait) to wait, then send the GET request again and update response.

Rest API

url = 'https://api.example.com/data'
retry_wait = 5
# Import requests and time modules
# Send GET request and handle 429 status
# Your code here

Hint

Use requests.get(url) to send the request. Use an if statement to check the status code. Use time.sleep() to wait.

4

Print the final result

Write an if statement to check if response.status_code is 200. If yes, print 'Success'. Otherwise, print 'Failed with status code: ' followed by the actual status code.

Rest API

import requests
import time

url = 'https://api.example.com/data'
retry_wait = 5

response = requests.get(url)
if response.status_code == 429:
    time.sleep(retry_wait)
    response = requests.get(url)

# Print success or failure message
# Your code here

Hint

Use print() with an if statement to show the correct message.

Practice

1.

What does the HTTP status code 429 Too Many Requests mean?

easy

A. Your request is missing required authentication credentials.

B. The server could not find the requested resource.

C. You have sent too many requests in a short time and should wait before retrying.

D. The server encountered an unexpected error.

Solution

1. Step 1: Understand HTTP status codes

   HTTP status codes communicate the result of a request. 429 specifically signals rate limiting.

2. Step 2: Interpret 429 meaning

   429 means the client sent too many requests too quickly and must wait before sending more.

3. Final Answer:

   You have sent too many requests in a short time and should wait before retrying. -> Option C

4. Quick Check:

   429 = Too Many Requests [OK]

Hint: 429 means slow down your requests and try again later [OK]

Common Mistakes:

• Confusing 429 with 404 Not Found
• Thinking 429 means authentication error
• Ignoring the need to wait before retrying

2.

Which HTTP header is commonly used by servers to tell clients how long to wait before retrying after a 429 Too Many Requests response?

easy

A. Content-Type

B. Retry-After

C. Authorization

D. User-Agent

Solution

1. Step 1: Identify headers related to retrying

   When a server limits requests, it often tells clients how long to wait using a specific header.

2. Step 2: Match header to purpose

   The Retry-After header indicates the wait time before retrying after 429.

3. Final Answer:

   Retry-After -> Option B

4. Quick Check:

   Retry-After header = wait time [OK]

Hint: Retry-After tells you when to try again after 429 [OK]

Common Mistakes:

• Choosing Content-Type which describes data format
• Confusing Authorization with retry timing
• Selecting User-Agent which identifies client software

3.

Consider this server response to a client request:

{
  "status": 429,
  "headers": {"Retry-After": "10"},
  "body": "Too many requests, please wait."
}

If the client immediately retries the request after 5 seconds, what is the likely result?

medium

A. The server will respond with another 429 status, indicating to wait longer.

B. The server will accept the request and respond normally.

C. The server will respond with a 404 Not Found error.

D. The server will close the connection without response.

Solution

1. Step 1: Analyze Retry-After header value

   The server asks the client to wait 10 seconds before retrying.

2. Step 2: Evaluate client retry timing

   The client retries after only 5 seconds, which is less than 10 seconds.

3. Step 3: Predict server response

   The server will reject the early retry and respond with 429 again.

4. Final Answer:

   The server will respond with another 429 status, indicating to wait longer. -> Option A

5. Quick Check:

   Retry before 10s = 429 again [OK]

Hint: Retry only after Retry-After seconds to avoid repeated 429 [OK]

Common Mistakes:

• Assuming server accepts early retries
• Confusing 429 with 404 errors
• Thinking server silently drops requests

4.

Given this snippet of server-side pseudocode handling API requests:

if request_count > limit:
    return 429, {"Retry-After": "30"}, "Too many requests"
else:
    process_request()

What is a likely bug if clients keep getting 429 responses even after waiting 30 seconds?

medium

A. The server is processing requests without any limit.

B. The Retry-After header is missing from the response.

C. The server is not checking request_count at all.

D. The server does not reset request_count after the wait period.

Solution

1. Step 1: Understand rate limiting logic

   The server limits requests by counting them and returning 429 if over limit.

2. Step 2: Identify why 429 repeats after wait

   If request_count never resets, the server always thinks limit is exceeded.

3. Step 3: Confirm bug cause

   Not resetting request_count after wait causes repeated 429 responses.

4. Final Answer:

   The server does not reset request_count after the wait period. -> Option D

5. Quick Check:

   Persistent 429 means counter not reset [OK]

Hint: Reset request count after wait to avoid repeated 429 [OK]

Common Mistakes:

• Ignoring the need to reset counters
• Assuming Retry-After header alone fixes issue
• Thinking server ignores request limits

5.

You are designing a client application that calls a public API which may respond with 429 Too Many Requests. How should your client handle this to avoid errors and respect the server?

hard

A. Read the Retry-After header and wait that many seconds before retrying.

B. Stop all requests permanently after the first 429 response.

C. Ignore the 429 response and retry immediately until successful.

D. Send multiple requests in parallel to speed up retries.

Solution

1. Step 1: Understand respectful client behavior

   Clients should avoid overwhelming servers by respecting rate limits.

2. Step 2: Use Retry-After header properly

   The server provides Retry-After to tell clients how long to wait before retrying.

3. Step 3: Implement waiting before retry

   Client should pause for the specified time, then retry to avoid repeated 429 errors.

4. Final Answer:

   Read the Retry-After header and wait that many seconds before retrying. -> Option A

5. Quick Check:

   Respect Retry-After to avoid 429 [OK]

Hint: Always wait Retry-After seconds before retrying after 429 [OK]

Common Mistakes:

• Retrying immediately ignoring Retry-After
• Stopping requests forever after one 429
• Sending many parallel requests causing more 429s