|
| 1 | +# API Rate Limiting on a Hosting Service |
| 2 | + |
| 3 | +Rate limiting is a mechanism used to control the amount of requests a client can make to an API within a specified time frame. On our hosting platform, rate limiting ensures fair usage, prevents abuse, and protects our servers from overload. |
| 4 | + |
| 5 | + |
| 6 | +## API Endpoints Rate Limiting |
| 7 | + |
| 8 | +Each API endpoint has a defined limit of requests per minute. When a client exceeds this limit, the server responds with an HTTP `429 Too Many Requests` error. |
| 9 | + |
| 10 | +### Example Limits |
| 11 | + |
| 12 | +| Endpoint | Limit | Time Window | |
| 13 | +|----------------------------|----------------|-------------| |
| 14 | +| `GET /api/events` | 60 requests | 1 minute | |
| 15 | +| `POST /api/events` | 30 requests | 1 minute | |
| 16 | +| `GET /api/venues` | 100 requests | 1 minute | |
| 17 | +| `PUT /api/venues/:id` | 20 requests | 1 minute | |
| 18 | + |
| 19 | +### Response on Exceeding Limits |
| 20 | + |
| 21 | +When a client exceeds the allowed limit: |
| 22 | + |
| 23 | +```http |
| 24 | +HTTP/1.1 429 Too Many Requests |
| 25 | +Content-Type: application/json |
| 26 | +
|
| 27 | +{ |
| 28 | + "error": "Rate limit exceeded", |
| 29 | + "retry_after": 45 |
| 30 | +} |
| 31 | +``` |
| 32 | + |
| 33 | +retry_after indicates the number of seconds the client should wait before retrying. |
| 34 | + |
| 35 | + |
| 36 | +### Login / Authentication Rate Limiting |
| 37 | + |
| 38 | +Login endpoints have stricter rate limits to protect against brute-force attacks. |
| 39 | + |
| 40 | + |
| 41 | +| Endpoint | Limit | Time Window | |
| 42 | +|-----------------------|-------------|-------------| |
| 43 | +| `POST /api/login` | 5 attempts | 5 minutes | |
| 44 | +| `POST /api/signup` | 10 requests | 10 minutes | |
| 45 | + |
| 46 | +Important Notes: |
| 47 | +- Exceeding the login limit may temporarily lock the account or IP address. |
| 48 | + -Always implement retry logic with exponential backoff to avoid unnecessary lockouts. |
| 49 | + |
| 50 | +## Best Practices |
| 51 | +1. Use Caching: Cache frequent GET requests to reduce repeated hits to the API. |
| 52 | +2. Implement Backoff: When receiving a 429 response, wait for the retry_after duration before retrying. |
| 53 | +3. Distribute Requests: Spread API calls over time instead of sending bursts. |
| 54 | +4. Monitor Usage: Track your request usage to avoid hitting limits unexpectedly. |
| 55 | +5. Use API Keys: API keys help monitor usage and provide higher limits for trusted clients. |
0 commit comments