In more detail
Typical limits are "100 requests per minute per IP address" or per API key. When the limit is hit, the server replies with status 429 Too Many Requests and often a Retry-After header. Common algorithms are the fixed window (count per calendar minute), the sliding window (count over the last 60 seconds) and the token bucket, which refills at a steady rate and allows short bursts up to the bucket's size. Rate limits slow down password guessing and scraping and keep one noisy client from starving the others.
Why it matters
Clients should treat 429 as "wait", honour Retry-After and back off exponentially instead of retrying at once, which only makes things worse. Limits keyed on IP address can hit innocent users who share one address behind NAT, such as a whole office or a mobile carrier.
Example
A token bucket holds 10 tokens and refills at 100 per minute, one every 0.6 seconds. A client can fire 10 requests at once, then sustain one every 0.6 s. An eleventh immediate request gets:
HTTP/1.1 429 Too Many Requests
Retry-After: 1
See HTTP Status Codes Cheat Sheet for related responses.