API testing, explained
Because APIs have no screen, tests call them directly and assert on the result. Different kinds of tests answer different questions:
- Functional tests: does each endpoint return the right data and status code for valid and invalid input?
- Contract tests: do provider and consumers still agree on requests and responses? See contract testing.
- Integration and end-to-end tests: does a real workflow across several services succeed?
- Performance and load tests: does latency hold under expected and peak traffic?
- Security tests: are authorization checks enforced on every object?
Common tools include Postman, REST Assured, pytest with an HTTP client, k6 for load, and Pact for contracts, with mocks standing in for dependencies.
The gap in most suites is coverage of real usage. Hand-written tests cover the cases developers thought of, while production clients rely on combinations nobody wrote down. Traffic replay testing closes that gap by replaying recorded requests against a new version and diffing responses, catching behavioral breaking changes before release.
Related terms
- Contract testing: Contract testing verifies that an API provider and its consumers agree on the requests and responses they exchange, so either side can change without silently breaking the other.
- API mocking: API mocking replaces a real API with a simulated one that returns predefined responses, so teams can build and test clients without the real service.
- API monitoring: API monitoring continuously checks that an API is available, fast and returning correct responses in production, and alerts teams when it stops doing so.