Karate is an API testing framework that gives you a full toolkit in one place. It uses a Gherkin style syntax, so tests read as Given, When, Then scenarios, but unlike other Gherkin tools it does not ask you to write step definitions in Java. The HTTP client, the JSON matching and the assertions are all built in. You write the feature file and Karate does the rest.
How it works
A test lives in a .feature file. You set a URL, add headers, choose a method, then assert on the status and the body. Karate has a powerful match keyword that compares JSON against a shape, including markers like #[] for an array and #notnull for a value that must be present. Feature files can call other feature files, which is how you share a login step:
Scenario: Should retrieve invoices with valid token
* def loginResponse = call read('common/login.feature')
* def token = loginResponse.token
Given url baseUrl + '/invoices'
And header Authorization = 'Bearer ' + token
When method GET
Then status 200
And match response.data == '#[]'
And assert response.data.length >= 15
The base URL is configured in karate-config.js, which can also switch values per environment. A JUnit 5 runner executes the features, and it can run them in parallel for speed. The build is Maven based, so mvn test runs the whole suite.
Benefits
Karate is approachable because the syntax is close to plain English, yet it is powerful enough for real work. You do not need to write glue code, which removes the biggest friction of other BDD tools. The match keyword makes structural assertions on JSON concise, and calling one feature from another gives you reuse without a lot of ceremony. Parallel execution is built in, and the same framework can also handle mocking and performance checks.
Downsides
The Gherkin plus JavaScript expression style is its own dialect, so there is a learning curve even for experienced Java developers, and it does not map onto how you write ordinary Java tests. For very complex logic the feature file can become awkward, and you may find yourself pushing code into JavaScript blocks or Java helpers anyway. Teams that want their API tests to look like the rest of their Java code sometimes prefer a library such as REST Assured instead.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-java-karate tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used across this series. The baseUrl is set in karate-config.js.
Three scenarios are covered, one feature file each. The brands feature calls GET /brands and checks that the response is an array with at least two entries. The login feature posts credentials to /users/login and asserts that access_token is not null. The protected invoices feature calls a shared common/login.feature to get a token, sends it as a Bearer header to GET /invoices, and matches the returned data as an array with a healthy length. A runner executes the features in parallel and asserts zero failures, and a GitHub Actions workflow runs mvn test on push and on a weekly cron. The scenarios line up with the REST Assured example, so you can compare the two Java approaches directly.