속도 제한 초과 처리
HTTP 429 상태 코드와 재시도-대기 헤더를 포함하여 속도 제한 위반에 대응하는 모범 사례를 살펴봅니다.
속도 제한 초과 처리은(는) CoddyKit의 무료 API Rate Limiting & Scalability Patterns 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 API Rate Limiting & Scalability Patterns 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. API Rate Limiting & Scalability Patterns 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
What Happens When You Hit a Limit?
Imagine an API as a busy service counter. If too many people (requests) try to get help at once, the counter gets overwhelmed.
Rate limiting helps manage this traffic. But what happens when you, as an API client, send too many requests and hit that limit?
The API needs a way to tell you to slow down, and you need to know how to respond gracefully.
HTTP 429: Too Many Requests
The standard way for an API to signal that you've exceeded a rate limit is by returning an HTTP 429 Too Many Requests status code.
- It's a clear, machine-readable signal.
- It tells your application, "Hey, you've sent too many requests in a given time period."
- It's crucial for both server stability and client guidance.
Guiding Retries with Retry-After
Just saying "429 Too Many Requests" isn't enough. Clients need to know when they can try again. That's where the Retry-After HTTP header comes in.
This header tells the client how long to wait before making another request. It can be:
- A number of seconds (e.g.,
Retry-After: 60for 60 seconds). - A specific date and time (e.g.,
Retry-After: Tue, 01 Mar 2024 10:00:00 GMT).
Server: Sending a 429 Response
As an API provider, you need to implement logic to detect rate limit violations and respond correctly. Here's a conceptual Java example of how a server might simulate sending a 429 response with a Retry-After header.
public class Main {
public static void main(String[] args) {
int requestsMade = 5;
int limit = 3;
System.out.println("Simulating a server response...");
if (requestsMade > limit) {
System.out.println("HTTP/1.1 429 Too Many Requests");
System.out.println("Content-Type: text/plain");
System.out.println("Retry-After: 60"); // Wait 60 seconds
System.out.println("\nBody: You have exceeded your rate limit.");
} else {
System.out.println("HTTP/1.1 200 OK");
System.out.println("Content-Type: text/plain");
System.out.println("\nBody: Request successful!");
}
}
}Client: Understanding When to Retry
When your client application receives a 429 response, it should parse the Retry-After header. This is critical for smart retrying.
- If the value is a number, convert it to milliseconds and wait.
- If it's a date, calculate the difference to determine the wait time.
Ignoring this header can lead to continued rate limit violations or even getting blocked.
Smart Retries: Exponential Backoff
What if the API doesn't send a Retry-After header, or you need a general strategy? Exponential backoff is a common and effective pattern.
Instead of retrying immediately, you wait for an increasingly longer period after each failed attempt. This reduces the load on the server and gives it time to recover.
- Start with a small initial delay (e.g., 1 second).
- Double the delay after each consecutive failure (1s, 2s, 4s, 8s...).
- Set a maximum number of retries or a maximum delay.
Client: Exponential Backoff Example
Here's how you might implement a simple exponential backoff strategy in Java. This example simulates an API call that initially fails, then succeeds after a delay.
public class Main {
public static void main(String[] args) {
int maxRetries = 3;
long delay = 1000; // Start with 1 second (1000 ms)
boolean apiCallSuccessful = false;
for (int i = 0; i < maxRetries; i++) {
System.out.println("Attempt " + (i + 1) + ": Making API call...");
// Simulate API call failure on first attempt, success after
boolean rateLimited = (i == 0);
if (rateLimited) {
System.out.println("API call failed (429). Retrying in " + (delay / 1000) + "s...");
try {
Thread.sleep(delay);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
System.out.println("Retry interrupted.");
break;
}
delay *= 2; // Double the delay for the next attempt
} else {
System.out.println("API call successful!");
apiCallSuccessful = true;
break; // Exit loop on success
}
}
if (!apiCallSuccessful) {
System.out.println("Max retries reached. Giving up.");
}
}
}Preventing Thundering Herd with Jitter
When many clients use exponential backoff, they might all retry at roughly the same time, causing a "thundering herd" problem.
To avoid this, add a small, random amount of jitter (randomness) to your calculated delay. This spreads out the retries, further reducing the server load.
import java.util.Random;
public class Main {
public static void main(String[] args) {
int maxRetries = 3;
long baseDelay = 1000; // Start with 1 second (1000 ms)
Random random = new Random();
boolean apiCallSuccessful = false;
for (int i = 0; i < maxRetries; i++) {
System.out.println("Attempt " + (i + 1) + ": Making API call...");
boolean rateLimited = (i == 0); // Simulate 429 on first try
if (rateLimited) {
long currentExpDelay = baseDelay * (long) Math.pow(2, i); // Exponential part
long jitter = random.nextInt((int) (currentExpDelay / 2) + 1); // Add up to 50% random delay
long totalDelay = currentExpDelay + jitter;
System.out.println("API call failed (429). Retrying in " + (totalDelay / 1000) + "s (base: " + (currentExpDelay/1000) + "s, jitter: " + (jitter/1000) + "s)...");
try {
Thread.sleep(totalDelay);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
System.out.println("Retry interrupted.");
break;
}
} else {
System.out.println("API call successful!");
apiCallSuccessful = true;
break;
}
}
if (!apiCallSuccessful) {
System.out.println("Max retries reached. Giving up.");
}
}
}Graceful Degradation: When Retries Aren't Enough
Sometimes, even with smart retries, an API might remain unavailable or your application can't afford to wait. This is where graceful degradation comes in.
Instead of showing a full error, your application can provide reduced functionality or cached data to the user.
- Display older, cached data instead of real-time.
- Temporarily disable non-critical features.
- Prompt the user to try again later, explaining the situation.
Rate Limit Response Check
You've learned how APIs signal rate limit exceedance and how clients should respond. Let's check your understanding.
Summary: Handling Rate Limits
In this lesson, we explored how to effectively handle rate limit exceedance from both the server and client perspectives.
- APIs use HTTP 429 Too Many Requests and the
Retry-Afterheader to communicate limits. - Clients should parse
Retry-Afteror use exponential backoff. - Adding jitter prevents the "thundering herd" problem.
- Graceful degradation ensures a better user experience when retries aren't viable.
Mastering these techniques leads to more robust and resilient API integrations.
AI 튜터와 함께 API Rate Limiting & Scalability Patterns을(를) 배우세요 — 무료
브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.
- 코스
- 12
- 레슨
- 48
자주 묻는 질문
“속도 제한 초과 처리” 강의는 무료인가요?
네 — “속도 제한 초과 처리” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 API Rate Limiting & Scalability Patterns 강의 전체를 잠금 해제할 수 있습니다. API Rate Limiting & Scalability Patterns 강의에는 총 4개의 강의가 포함되어 있습니다.
“속도 제한 초과 처리”에서 뭘 배우나요?
HTTP 429 상태 코드와 재시도-대기 헤더를 포함하여 속도 제한 위반에 대응하는 모범 사례를 살펴봅니다. 브라우저에서 직접 실행하는 실습 코드로 API Rate Limiting & Scalability Patterns을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
API Rate Limiting & Scalability Patterns을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 API Rate Limiting & Scalability Patterns은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.
“속도 제한 초과 처리” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 API Rate Limiting & Scalability Patterns 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 API Rate Limiting & Scalability Patterns 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.