Key takeaways
- REST Assured is an open-source Java library for functional tests of REST APIs: send a request, assert on the status, headers and body. It runs inside JUnit or TestNG, so it fits any Java build and CI pipeline.
- The current release is 6.2.0 (Maven Central, October 2026). Since 6.0 it needs Java 17 or later.
- It is not a load testing tool. It checks that an API is correct for one request at a time. For concurrency and response-time percentiles, use JMeter or k6, which LoadFocus runs from the cloud.
What is REST Assured?
REST Assured is a Java library that lets you write API tests as a readable chain: given a request setup, when you call an endpoint, then assert on the response. The project describes itself as an open-source library for testing and validating REST services in Java (rest-assured.io, October 2026). You add it as a test dependency, write ordinary JUnit or TestNG test methods and run them with Maven or Gradle.
It checks correctness: does GET /users/123 return 200, the right JSON and the right headers? It does not measure how the API behaves with 500 users at once. That distinction is the main thing to take from this article.
What do you need to run REST Assured 6?
I checked this on 2026-10-23.
- Version:
io.rest-assured:rest-assured6.2.0 is the latest on Maven Central (published 2026-10-16). The 5.5.x line is still available. - Java: the 6.0.0 release notes state that Java 17 or later is required (github.com/rest-assured/rest-assured wiki, Release Notes 6.0). The 5.x line is the one to stay on if your build is on an older JDK.
- Groovy: 6.0 moved to Groovy 5.x internally, and the 6.2.0 notes say the core module is now written entirely in Java and no longer depends on Groovy directly (rest-assured.io). You do not need to install Groovy.
- Test framework: any. The example below uses JUnit 5.
Step by step: your first REST Assured tests
The tests below target httpbin.org, a public HTTP request and response service, so you can run them with no backend of your own. I compiled and ran them with Maven, JDK 17, REST Assured 6.2.0 and JUnit Jupiter 5.11.4: four tests, four passes.
Step 1: Add the dependencies
<properties>
<maven.compiler.release>17</maven.compiler.release>
</properties>
<dependencies>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>6.2.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.11.4</version>
<scope>test</scope>
</dependency>
</dependencies>
Hamcrest, which supplies matchers like equalTo, comes in with REST Assured. Use a current Surefire plugin (3.x) so Maven discovers JUnit 5 tests.
Step 2: Write a GET test
package demo;
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;
import static org.hamcrest.Matchers.lessThan;
import io.restassured.RestAssured;
import io.restassured.http.ContentType;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
class HttpbinTest {
@BeforeAll
static void setUp() {
RestAssured.baseURI = "https://httpbin.org";
}
@Test
void getWithQueryParam() {
given()
.queryParam("userId", 123)
.when()
.get("/get")
.then()
.statusCode(200)
.contentType(ContentType.JSON)
.body("args.userId", equalTo("123"))
.time(lessThan(5000L));
}
}
The body("args.userId", ...) string is a path into the JSON response. Note time(lessThan(5000L)): it asserts that this single request answered in under five seconds. It is a sanity check, not a performance test.
Step 3: Send a JSON body
@Test
void postJson() {
given()
.contentType(ContentType.JSON)
.body("""
{"name": "Alice", "email": "alice@example.com"}
""")
.when()
.post("/post")
.then()
.statusCode(200)
.body("json.name", equalTo("Alice"));
}
I passed the body as a string on purpose. If you pass a Java Map or an object instead, REST Assured has to serialize it, and it fails with “no JSON serializer found in classpath” unless Jackson, Gson, Johnzon or Yasson is on the test classpath. I hit that error when I tried a Map first. Add jackson-databind as a test dependency if you want to send objects.
Step 4: Authentication and a reusable specification
@Test
void bearerToken() {
given()
.auth().oauth2("my-token")
.when()
.get("/bearer")
.then()
.statusCode(200)
.body("authenticated", equalTo(true))
.body("token", equalTo("my-token"));
}
@Test
void reusableSpec() {
var spec = new io.restassured.builder.RequestSpecBuilder()
.setBaseUri("https://httpbin.org")
.addHeader("Accept", "application/json")
.build();
String ua = given().spec(spec).header("User-Agent", "demo")
.when().get("/user-agent")
.then().statusCode(200)
.extract().path("'user-agent'");
org.junit.jupiter.api.Assertions.assertEquals("demo", ua);
}
A RequestSpecBuilder holds the base URI, headers and authentication once, so each test only states what is different. extract() pulls a value out of a response so you can reuse it in the next request, for example a token from a login call.
Run everything with mvn test. In CI, the same command works unchanged, and Surefire writes JUnit XML reports that Jenkins, GitHub Actions and most other CI systems can display.
When REST Assured fits, and when it does not
It fits when your backend is Java or Kotlin, you want API tests in the same repository and review process as the code, and you need precise control over requests and assertions. It also validates against JSON Schema (6.1.0 added drafts 6, 7, 2019-09 and 2020-12) and supports client certificate authentication for mutual TLS (6.2.0), per the release notes on rest-assured.io.
It fits less well when the people writing tests do not write Java, when you want a visual interface and shared collections, or when the main question is how the API behaves under volume.
REST Assured vs load testing tools
REST Assured, JMeter and k6 answer different questions:
| Question | Tool type | Examples |
|---|---|---|
| Does this endpoint return the right thing? | Functional API test library | REST Assured |
| How does it respond with hundreds of concurrent users? | Load testing tool | Apache JMeter, k6 |
| Is it still up and fast, every few minutes? | Monitoring | LoadFocus API monitoring |
Technically you can put REST Assured calls in a loop or a thread pool. You would then have to build the ramp-up, the distribution across machines, the percentile reporting and the pass/fail thresholds yourself, and the JVM test runner is not designed for it. A tool built for the job already does that. If your team has JMeter or k6 skills, see k6 vs JMeter for choosing between them, and scripted vs codeless API load testing for the trade-off with no-code tools.
How REST Assured relates to LoadFocus
LoadFocus runs cloud load tests for websites and APIs, and runs JMeter and k6 scripts from 25+ regions (loadfocus.com/index.md, October 2026). I found no statement on its pages that it executes JUnit or REST Assured suites, so do not plan on uploading one.
A workable split: REST Assured in your CI pipeline guards correctness on every commit. Once an endpoint is correct, you load test the API with LoadFocus, reusing the same requests by importing them as described in importing cURL, HAR, Postman and OpenAPI into load tests. After release, LoadFocus API monitoring runs scheduled checks that assert on status code, body, headers and response time. For the load side in depth, see API performance testing challenges and solutions.
Frequently Asked Questions
What is REST Assured used for?
It is used to write automated functional tests for REST APIs in Java. You send requests and assert on status codes, headers and response bodies, usually inside JUnit or TestNG tests that run in your CI pipeline.
Which Java version does REST Assured need?
Version 6.0 and later require Java 17 or later, per the 6.0.0 release notes. If your project is on an older JDK, use the 5.x line, for example 5.5.7, which is on Maven Central.
Can REST Assured do load testing?
Not in a practical sense. It sends requests and asserts on responses, but it has no built-in load model, distributed generators or percentile reporting. Use JMeter or k6 for load, and keep REST Assured for correctness.
Does REST Assured work with Postman collections?
No. REST Assured tests are Java code and do not read Postman collections. Teams that want a visual tool and code-based tests often keep both and use each for what it does well.
Do I need to know Groovy?
No. Older versions leaned on Groovy internally. The 6.2.0 release notes say the core module is now written entirely in Java, and you write tests in plain Java.
Sources
- REST Assured project page and release notes (October 2026)
- REST Assured 6.0 release notes (October 2026)
- Maven Central metadata for io.rest-assured:rest-assured (6.2.0, last updated 2026-10-16)
- LoadFocus overview (loadfocus.com/index.md) and API monitoring page (October 2026)