Playwright is best known for driving browsers, but it also ships a first class API testing client, and it is available for Java. The same library that automates a web page can send HTTP requests through an APIRequestContext and read the response through an APIResponse. That means a Java team can use one tool for both user interface tests and API tests, which keeps the toolbox small. In this project the runner is TestNG.
How it works
You create a Playwright instance, build a request context with a base URL, then call methods like get and post on it. The response gives you the status and the raw text, which you parse with a JSON library such as Gson. Assertions use plain TestNG checks:
@Test
public void testShouldRetrieveAtLeastTwoBrands() {
APIResponse response = request.get("/brands");
Assert.assertEquals(response.status(), 200, "Unexpected status code");
String responseBody = response.text();
JsonArray data = JsonParser.parseString(responseBody).getAsJsonArray();
Assert.assertTrue(data.size() >= 2, "Expected at least 2 brands, but got " + data.size());
}
The request context is created in a TestNG @BeforeClass and disposed in an @AfterClass, so each test class manages its own lifecycle. For authenticated calls a test logs in first, pulls the access_token out of the login response, and sends it as an Authorization: Bearer header on the protected request. The build runs through Maven with mvn test.
Benefits
The big draw is one tool for two jobs. If your team already uses Playwright for browser tests, adding API tests costs almost nothing in new dependencies or new concepts. The request context is fast and modern, it handles cookies and headers cleanly, and it comes from a well maintained project with strong documentation. Because the tests are ordinary Java on TestNG, you keep all the structure, reuse and IDE support you expect from a real language.
Downsides
Playwright does not parse JSON or assert on it for you the way a dedicated API library does, so you bring your own JSON handling and write more lines for each check. Compared with REST Assured the body assertions are more manual. You also pull in the full Playwright dependency and its browser tooling even when you only want the HTTP client, which is heavier than a plain request library. For a pure API suite with no browser tests, a lighter option may fit better.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-java-testng-playwright tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used throughout this series. The base URL is set on the request context and can be overridden with a system property.
Three scenarios are covered. A login test posts credentials to /users/login and asserts a 200 with an access_token. A brands test calls GET /brands, parses the array and checks for at least two entries. A protected invoices test logs in during class setup, extracts the token, sends it as a Bearer header to GET /invoices, and asserts a healthy list of invoices. A GitHub Actions workflow runs mvn test on push and on a weekly cron. The scenarios match the other Java examples, so you can compare Playwright against REST Assured and Karate on the same ground.