The Apache HTTP Client is a very robust library, suitable for both simple and advanced use cases when testing HTTP endpoints. Check out our guide covering basic request and response handling, as well as security, cookies, timeouts, and more:
Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Overview
The REST-assured library provides support for testing REST APIs, usually in JSON format.
From time to time it may be desirable, without analyzing the response in detail, to know first-off whether the JSON body conforms to a certain JSON format.
In this quick tutorial, weβll take a look at how we can validate a JSON response based on a predefined JSON schema.
2. Setup
The initial REST-assured setup is the same as our previous article.
In addition, we also need to include the json-schema-validator module in the pom.xml file:
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>json-schema-validator</artifactId>
<version>5.5.0</version>
<scope>test</scope>
</dependency>
To ensure you have the latest version, follow this link.
3. JSON Schema Validation
Letβs have a look at an example.
As a JSON schema, weβll use a JSON saved in a file called event_0.json, which is present in the classpath:
{
"id": "390",
"data": {
"leagueId": 35,
"homeTeam": "Norway",
"visitingTeam": "England",
},
"odds": [{
"price": "1.30",
"name": "1"
},
{
"price": "5.25",
"name": "X"
}]
}
Then assuming that this is the general format followed by all data returned by our REST API, we can then check a JSON response for conformance like so:
@Test
public void givenUrl_whenJsonResponseConformsToSchema_thenCorrect() {
get("/events?id=390").then().assertThat()
.body(matchesJsonSchemaInClasspath("event_0.json"));
}
Notice that weβll still statically import matchesJsonSchemaInClasspath from io.restassured.module.jsv.JsonSchemaValidator.
4. JSON Schema Validation Settings
4.1. Validate a Response
The json-schema-validator module of REST-assured gives us the power to perform fine-grained validation by defining our own custom configuration rules.
Say we want our validation to always use the JSON schema version 4:
@Test
public void givenUrl_whenValidatesResponseWithInstanceSettings_thenCorrect() {
JsonSchemaFactory jsonSchemaFactory = JsonSchemaFactory.newBuilder()
.setValidationConfiguration(
ValidationConfiguration.newBuilder()
.setDefaultVersion(SchemaVersion.DRAFTV4).freeze())
.freeze();
get("/events?id=390").then().assertThat()
.body(matchesJsonSchemaInClasspath("event_0.json")
.using(jsonSchemaFactory));
}
We would do this by using the JsonSchemaFactory and specify the version 4 SchemaVersion and assert that it is using that schema when a request is made.
4.2. Check Validations
By default, the json-schema-validator runs checked validations on the JSON response String. This means that if the schema defines odds as an array as in the following JSON:
{
"odds": [{
"price": "1.30",
"name": "1"
},
{
"price": "5.25",
"name": "X"
}]
}
then the validator will always be expecting an array as the value for odds, hence a response where odds is a String will fail validation. So, if we would like to be less strict with our responses, we can add a custom rule during validation by first making the following static import:
io.restassured.module.jsv.JsonSchemaValidatorSettings.settings;
then execute the test with the validation check set to false:
@Test
public void givenUrl_whenValidatesResponseWithStaticSettings_thenCorrect() {
get("/events?id=390").then().assertThat().body(matchesJsonSchemaInClasspath
("event_0.json").using(settings().with().checkedValidation(false)));
}
4.3. Global Validation Configuration
These customizations are very flexible, but with a large number of tests we would have to define a validation for each test, this is cumbersome and not very maintainable.
To avoid this, we have the freedom to define our configuration just once and let it apply to all tests.
Weβll configure the validation to be unchecked and to always use it against JSON schema version 3:
JsonSchemaFactory factory = JsonSchemaFactory.newBuilder()
.setValidationConfiguration(
ValidationConfiguration.newBuilder()
.setDefaultVersion(SchemaVersion.DRAFTV3)
.freeze()).freeze();
JsonSchemaValidator.settings = settings()
.with().jsonSchemaFactory(factory)
.and().with().checkedValidation(false);
then to remove this configuration call the reset method:
JsonSchemaValidator.reset();
5. Conclusion
In this article, weβve shown how we can validate a JSON response against a schema when using REST-assured.
