·
8 min
REST API Testing: Methods, Tools and Best Practices
Roman Kirchmeier - Autemos
REST APIs are the nervous system of modern software – and a rewarding target for both bugs and attackers. Salt Security reports that 95 percent of surveyed organisations experienced security problems in production APIs (Salt Security, 2024). REST API testing does not check the surface; it checks the protocol. You send a request and compare the response against a clear expectation. This guide walks you through the methods, the right assertions and a step-by-step workflow into CI/CD – including the status codes and HTTP methods every QA lead and test architect needs to know.
In short: REST API testing means validating every endpoint at the protocol level – status code, body, JSON Schema, headers and response time. Structured negative tests and automated CI/CD suites catch the failures that manual click-testing misses. With 95 percent of organisations affected (Salt Security, 2024), security belongs in every API test suite.
Figure 1: The six dimensions a complete REST API test checks.
What Is REST API Testing?
Figure 2: HTTP methods under test – purpose, idempotency and success status code.
Endpoint testing systematically verifies that a RESTful HTTP endpoint behaves correctly – at the protocol level, not through the UI. Demand is climbing fast: 82 percent of organisations are API-first in 2025, up from 74 percent a year earlier (Postman State of the API, 2025). You send a request and check the response against a defined expectation.
HTTP semantics form the foundation. The method you choose determines what the endpoint does – and which guarantees apply. Idempotency is central here: an idempotent method produces the same end state when called repeatedly. The table below summarises the five relevant methods, defined in the HTTP specification (RFC 9110, 2022) and extended for PATCH by (RFC 5789, 2010).
Method | Purpose | Idempotent | Success | Assertions |
|---|---|---|---|---|
GET | read | Yes | 200 | status, body schema, values, time |
POST | create | No | 201 (+Location) | status, new ID, Location header |
PUT | replace | Yes | 200/204 | status, same end state on repeat |
PATCH | partial update | No* | 200 | changed field verified, rest unchanged |
DELETE | delete | Yes | 204 | status 204, then GET → 404 |
Status Codes and Authentication
Status codes signal the outcome. They group into five families: 1xx (informational), 2xx (success), 3xx (redirect), 4xx (client error) and 5xx (server error). A simple rule of thumb applies for testing: 2xx confirms the happy path, 4xx is the expected result of your negative tests, and 5xx should almost never appear. If a 500 shows up, you have found a bug.
For authentication you will meet four schemes: API key in the header, bearer token or JWT, OAuth 2.0 (RFC 6749, 2012), and Basic Auth as the legacy option. Test each one both positively (valid token → access) and negatively (missing token → 401).
A concrete negative test makes this tangible. Send the same request once without and once with an invalid token, then check the reaction:
Request: `GET /api/v1/users/42` with no `Authorization` header
Expectation: status `401 Unauthorized`, body with an error code, no data leak
Variant: the same call with an expired token → also `401`, not `200`
If the endpoint returns a `200` or even user data here, you have found a serious gap – exactly the kind of failure a pure happy-path test never surfaces.
How Do You Test a REST API Step by Step?
Figure 3: The seven-step workflow for testing a REST API.
A reliable REST API test follows a fixed sequence from test case to CI pipeline. In client projects we regularly see teams without this structure skip negative tests and schema checks – exactly where production failures later emerge. The seven steps below close that gap and work with tools such as Postman, Newman or REST Assured.
1. Define test cases. Cover the happy path, boundary values, negative cases and auth. Align them with the story's acceptance criteria.
2. Set up the request. Specify method, URL, headers, token and body. Use variables instead of hardcoded values.
3. Add assertions. Check status, body, schema, headers and response time together – not just the status code.
4. Run negative tests. Invalid input, missing required fields and wrong or absent tokens must return a clean 4xx.
5. Test data-driven. CSV or JSON data sets in Postman, `ParameterizedTest` or DataProvider in REST Assured.
6. Verify idempotency. Call PUT and DELETE repeatedly and confirm the end state stays the same.
7. Automate in CI/CD. Wire Newman or REST Assured with Maven into GitHub Actions, GitLab CI or Jenkins, run it as a quality gate, and archive the reports.
How deep you automate depends on risk. For stable suites that grow with the product, it is worth examining the discipline of API test automation, which goes deeper into this CI/CD integration.
What Should You Check in a REST API?
Figure 4: API security in numbers – why security belongs in every test suite.
Beyond the status code, a strong API test checks five further dimensions – otherwise dangerous gaps remain. The risk is concrete: 80 percent of API attacks exploit at least one method from the OWASP API Security Top 10 (Salt Security, 2024). Checking only for 200 misses contract drift, data leaks and missing authorisation.
These aspects belong in every assertion suite:
Status code. Does the expected code match the case at hand?
Body and types. Are values, data types and required fields correct?
JSON Schema. Validate the structure against a schema (JSON Schema 2020-12). This catches contract drift before consumers break.
Response time. Does the endpoint meet its SLA?
Error handling. Do 4xx and 5xx return meaningful but not over-sharing bodies?
Security headers and authorisation. Is access enforced correctly, and do headers leak no sensitive data?
Authorisation deserves special attention. According to OWASP, the most common API vulnerability is Broken Object Level Authorization, or BOLA – user A reaching user B's data through manipulated IDs (OWASP API Security Top 10, 2023). A UI test almost never covers these cases; an API test using foreign object IDs does.
JSON Schema Validation in Practice
Why is a field-by-field check not enough? Because it is too coarse. A JSON Schema describes the complete contract of a response: which fields are required, what type they hold and which values are allowed (JSON Schema 2020-12). Validate every response against this schema and contract drift surfaces immediately – for example when the backend renames a field, switches a type from number to string, or drops a required field. These silent changes break consumers in production without any status-code check ever firing.
A practical example for a user response checks at least these points:
`id` – required, type integer, greater than 0
`email` – required, type string, format `email`
`created_at` – required, type string, format `date-time`
`role` – required, enum of `admin`, `editor`, `viewer`
no extra, undocumented fields (`additionalProperties: false`)
If any of these rules fails, the API has drifted from its contract – and your test stops it before a consumer does.
Best Practices and Common Mistakes
Effective interface testing follows a few principles applied consistently – and avoids a handful of typical traps. Gartner forecasts that by 2025 more than half of data theft will run through insecure APIs. Against that backdrop, every skipped security test carries weight. Practice condenses into two short lists.
What you should do:
Test against a production-like environment with realistic data.
Keep configuration and test data in version control.
Cover all endpoints including edge cases, not just the happy path.
Verify idempotency for PUT and DELETE explicitly.
Prioritise security assertions and include OWASP cases.
Automate in CI and document reports traceably.
What you should avoid:
Hardcoded test and auth data that breaks within days.
Missing negative tests – the most common blind spot.
Ignored schema that lets contract drift slip through unnoticed.
Flaky tests from shared or unreset state.
Skipped security checks.
Purely manual testing with no reproducible suite.
One final point from practice: treat API tests as regression protection, not one-off sign-offs. A stable suite that runs on every merge does not replace systematic regression testing, but complements it where the UI simply cannot reach.
FAQ
How do I test a REST API?
You send defined requests to an endpoint and check the response for status code, body, JSON Schema, headers and response time. Add negative tests for invalid input and missing tokens, which should return a 4xx. Then automate the suite in CI/CD so it runs on every merge.
Which tools are suitable for REST API testing?
Common choices are Postman with its CLI runner Newman for exploratory and automated endpoint checks, REST Assured for Java-based suites, and SoapUI for complex scenarios. JMeter handles performance, and curl serves quick checks. The right tool depends on your stack and degree of automation – not on popularity.
What is the difference between manual and automated API testing?
Manual testing suits exploratory checks and one-off investigations, for example in Postman. Automated testing runs the same cases reproducibly in CI/CD and catches regressions on every commit. In practice teams combine both: manual for exploration, automated as a quality gate. Our overview of the different types of software testing explains more.
Which HTTP status codes should I check?
Check 2xx for successful calls (200, 201, 204), 4xx as the expected result of your negative tests (400, 401, 403, 404, 422), and monitor 5xx. A 500 or 503 usually signals a server bug and should not appear in a normal test run (RFC 9110, 2022).
What do you check besides the status code?
Beyond the status code you check the response body with its values and data types, the structure via JSON Schema, the response time against the SLA, error handling, and security and response headers. These dimensions catch contract drift, performance problems and data leaks that a pure status-code check misses.
Conclusion
REST API testing means taking every endpoint seriously at the protocol level: the right HTTP method with its idempotency guarantees, the correct status code, a validated JSON Schema, checked headers and response times. Structured negative tests and an automated CI/CD suite catch the failures that manual click-testing overlooks – and with 95 percent of organisations affected (Salt Security, 2024), security belongs firmly in every suite. For the full picture, see our guide to API testing. If you want to bring your API tests robustly into the pipeline, book a demo and we will show you how Autemos lets your suite grow with the product.
