A valid API request can still take down a service.
API abuse is not always malicious. Retry storms, broken integrations, excessive polling, misconfigured automation, and large data requests can generate enough traffic to exhaust shared resources. Each request may be valid on its own, but the combined effect can increase latency, consume database connections, and reduce availability for every other consumer.
Every API should defend itself against excessive resource consumption. API testing should cover rate limits, quotas, expensive operations, concurrent requests, large-volume retrieval, retry behavior, resource exhaustion, and fair allocation between consumers.
For example, an expensive search or report endpoint may work correctly under normal traffic but become a serious reliability problem when a client repeatedly calls it hundreds of times per second. The same applies to endpoints that return large collections or allow aggressive polling without meaningful restrictions.
Protection may be implemented in the application, API gateway, infrastructure, or a combination of these layers. What matters is the observable result: one consumer must not be able to significantly degrade availability for everyone else.
Testing should verify not only that limits exist, but also that the API responds predictably when those limits are exceeded. Clients should receive clear failure responses, while the service remains stable and available.
An API that assumes all consumers will behave correctly is an API that has not been fully tested.
This is Rule 8 of The Power of Ten Rules for Testing HTTP APIs. Read the complete research article for the full explanation and testing guidance: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html
Rentgen is an API discovery tool built to reveal behavior beyond normal usage assumptions and expose reliability risks before they become production incidents.
Automation Before Automation.
Top comments (0)