Selenium + API Testing means combining browser-based UI automation with API-level testing in the same automation framework. Selenium WebDriver is used to automate web applications through the browser, while API testing tools such as REST Assured are used to send HTTP requests and validate API responses.
This combination is especially useful for end-to-end testing because APIs can be used to prepare test data, validate backend responses, create or delete records, and verify application behavior before or after performing UI actions. A hybrid UI + API framework can therefore test both the user interface and the underlying services.
In a Java automation framework, Selenium WebDriver, REST Assured, TestNG, Maven, and supporting utilities can work together to create a reusable UI and API automation architecture.
Course Resource: Selenium Training | Register for Course Demo
API Testing is the process of validating application programming interfaces to verify that they work correctly, return expected responses, enforce required rules, and handle valid and invalid requests properly.
Unlike UI testing, API testing does not require interacting with the application's graphical interface. Tests communicate directly with API endpoints using HTTP methods such as GET, POST, PUT, PATCH, and DELETE.
API testing commonly validates:
Selenium is an open-source framework used to automate web browsers. Selenium WebDriver allows automation scripts to interact with web elements such as text fields, buttons, links, dropdowns, tables, and forms.
Selenium is primarily used for UI automation rather than directly testing REST APIs.
Java Test
|
v
Selenium WebDriver
|
v
Browser
|
v
Web Application
REST, or Representational State Transfer, is an architectural style commonly used for building web APIs. REST APIs generally use HTTP methods to perform operations on resources.
| HTTP Method | Typical Purpose | Example |
|---|---|---|
| GET | Retrieve data | Get user details |
| POST | Create data | Create a user |
| PUT | Replace/update data | Update a user |
| PATCH | Partially update data | Update user email |
| DELETE | Delete data | Delete a user |
Selenium and API testing solve different testing problems. Selenium validates what users see and interact with, while API testing validates communication between application components and backend services.
Combining them allows a framework to validate an end-to-end business flow at multiple layers.
| Feature | Selenium UI Testing | API Testing |
|---|---|---|
| Layer | Presentation/UI layer | Service/API layer |
| Browser Required | Usually yes | No |
| Speed | Generally slower | Generally faster |
| Main Tool | Selenium WebDriver | REST Assured or similar API client |
| Validation | UI elements and user flows | Status, headers, body, schema, business rules |
| Typical Data | Form fields and UI values | JSON/XML request and response |
| Best Use | Browser workflows | Service/API validation |
REST Assured is a Java library designed to simplify testing and validating REST APIs. It provides a readable syntax for constructing HTTP requests and validating responses.
REST Assured can be combined with TestNG to create structured API automation suites. A common BDD-style flow is:
given()
|
v
Request Configuration
|
v
when()
|
v
HTTP Request
|
v
then()
|
v
Response Validation
Automation Framework
|
+-------------+-------------+
| |
v v
UI Automation API Automation
| |
v v
Selenium WebDriver REST Assured
| |
v v
Browser API Server
| |
+-------------+-------------+
|
v
TestNG Assertions
|
v
Reports
Modern automation frameworks can keep UI and API tests in separate layers while sharing common configuration, test data, utilities, logging, reporting, and execution infrastructure.
A Java Maven project can include Selenium, REST Assured, and TestNG dependencies. Version numbers should be selected according to the project's compatibility and dependency-management strategy.
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>YOUR_SELENIUM_VERSION</version>
</dependency>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>YOUR_REST_ASSURED_VERSION</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>YOUR_TESTNG_VERSION</version>
<scope>test</scope>
</dependency>
</dependencies>
A GET request is commonly used to retrieve information from an API.
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import org.testng.annotations.Test;
public class ApiGetTest {
@Test
public void getUserTest() {
given()
.when()
.get("https://example.com/api/users/1")
.then()
.statusCode(200);
}
}
The test sends a GET request and verifies that the server returns the expected HTTP status code.
API testing should not stop at status-code validation. The response body should also be checked when appropriate.
given()
.when()
.get("https://example.com/api/users/1")
.then()
.statusCode(200)
.body("id", equalTo(1));
This verifies both the response status and a value in the response body.
A response can be stored in a REST Assured Response object for further validation or for passing data to subsequent operations.
import io.restassured.response.Response;
import static io.restassured.RestAssured.*;
Response response =
given()
.when()
.get("https://example.com/api/users/1");
System.out.println(response.getStatusCode());
System.out.println(response.asPrettyString());
A POST request is generally used to create a new resource.
String requestBody = """
{
"name": "John",
"job": "Tester"
}
""";
given()
.contentType("application/json")
.body(requestBody)
.when()
.post("https://example.com/api/users")
.then()
.statusCode(201);
The exact status code depends on the API contract. A successful resource-creation operation commonly returns 201 Created, but the API documentation should be treated as the source of truth.
PUT is commonly used to replace or update an existing resource.
String requestBody = """
{
"name": "John Updated",
"job": "Senior Tester"
}
""";
given()
.contentType("application/json")
.body(requestBody)
.when()
.put("https://example.com/api/users/1")
.then()
.statusCode(200);
PATCH is commonly used when only part of a resource needs to be updated.
String requestBody = """
{
"job": "Automation Engineer"
}
""";
given()
.contentType("application/json")
.body(requestBody)
.when()
.patch("https://example.com/api/users/1")
.then()
.statusCode(200);
DELETE is used to remove a resource when the API supports deletion.
given()
.when()
.delete("https://example.com/api/users/1")
.then()
.statusCode(204);
The expected status code depends on the API contract. Some APIs return 200, 202, or 204 after a successful deletion.
HTTP headers provide additional information about a request or response. Common API headers include Content-Type, Accept, and authorization-related headers.
given()
.header("Accept", "application/json")
.when()
.get("https://example.com/api/users")
.then()
.statusCode(200);
The Content-Type header indicates the format of the request body being sent to the server.
given()
.contentType("application/json")
.body("{\"name\":\"John\"}")
.when()
.post("https://example.com/api/users")
.then()
.statusCode(201);
Query parameters are commonly used to filter, search, sort, or control API responses.
given()
.queryParam("page", 2)
.queryParam("limit", 10)
.when()
.get("https://example.com/api/users")
.then()
.statusCode(200);
The resulting request conceptually contains parameters such as ?page=2&limit=10.
Path parameters identify a specific resource within the URL path.
given()
.pathParam("id", 10)
.when()
.get("https://example.com/api/users/{id}")
.then()
.statusCode(200);
Many APIs require authentication. Common mechanisms include API keys, Basic Authentication, Bearer tokens, OAuth-based authentication, and session-based authentication.
A bearer token can be supplied using an Authorization header.
String token = "YOUR_TOKEN";
given()
.header("Authorization", "Bearer " + token)
.when()
.get("https://example.com/api/profile")
.then()
.statusCode(200);
Sensitive tokens should be supplied through secure configuration or secret-management mechanisms rather than committed as plain text in source code.
JSON is commonly used for REST API request and response bodies. REST Assured provides mechanisms for validating JSON fields.
given()
.when()
.get("https://example.com/api/users/1")
.then()
.statusCode(200)
.body("name", equalTo("John"))
.body("active", equalTo(true));
API response values can be extracted and used in later steps.
String userId =
given()
.when()
.get("https://example.com/api/users/1")
.then()
.statusCode(200)
.extract()
.path("id");
System.out.println("User ID: " + userId);
API chaining means using data returned by one API request in another API request.
For example:
Create User API
|
v
Capture User ID
|
v
Get User API
|
v
Update User API
|
v
Delete User API
This approach is useful for end-to-end service workflows where one operation depends on the output of another.
int userId =
given()
.contentType("application/json")
.body("{\"name\":\"John\"}")
.when()
.post("https://example.com/api/users")
.then()
.statusCode(201)
.extract()
.path("id");
System.out.println("Created User ID: " + userId);
TestNG can be used as the test execution framework for REST Assured tests.
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import org.testng.annotations.Test;
public class UserApiTest {
@Test
public void verifyUser() {
given()
.when()
.get("https://example.com/api/users/1")
.then()
.statusCode(200)
.body("id", equalTo(1));
}
}
TestNG provides annotations, assertions, groups, dependencies, Data Providers, listeners, suite execution, and other features useful for organizing API automation.
A hybrid test can use an API to prepare data and Selenium to validate the corresponding UI behavior.
API: Create Test User
|
v
Capture User ID
|
v
Open Application with Selenium
|
v
Login Through UI
|
v
Navigate to User Profile
|
v
Validate UI Information
|
v
API: Verify Backend Data
|
v
API: Delete Test User
Creating test data through the UI can be time-consuming. If the application provides suitable APIs, an API call can create the required test data before the UI test starts.
API
|
+-- Create Customer
|
+-- Create Product
|
+-- Create Order
|
v
Selenium UI Test
This can reduce the number of UI steps required for test setup while keeping the actual user workflow under UI validation.
Suppose a test needs a new user account. Instead of navigating through the registration UI every time, an API can create the account first, and Selenium can then validate the login workflow.
API
|
v
Create User
|
v
User Credentials
|
v
Selenium Login Page
|
v
Enter Credentials
|
v
Click Login
|
v
Validate Dashboard
An API can create or update a resource, after which Selenium can open the corresponding UI page and verify that the change is displayed correctly.
API Update
|
v
Backend Data Changed
|
v
Open Web Application
|
v
Navigate to Resource
|
v
Validate UI
|
v
Compare Expected vs Actual
The reverse approach is also useful. Selenium can perform a user action and the API can then verify that the expected backend change occurred.
Selenium UI
|
v
User Creates Order
|
v
Application Processes Request
|
v
API GET Order
|
v
Validate Order Status
|
v
Test Result
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
public class HybridUiApiTest {
private WebDriver driver;
@BeforeMethod
public void setup() {
driver = new ChromeDriver();
driver.manage().window().maximize();
}
@Test
public void verifyUserThroughUiAndApi() {
given()
.when()
.get("https://example.com/api/users/1")
.then()
.statusCode(200)
.body("id", equalTo(1));
driver.get("https://example.com/login");
driver.findElement(By.id("username"))
.sendKeys("testUser");
driver.findElement(By.id("password"))
.sendKeys("testPassword");
driver.findElement(By.id("loginButton"))
.click();
System.out.println("UI validation completed.");
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
This is a simplified example. In a production framework, UI actions, API clients, configuration, test data, assertions, and reporting should generally be separated into reusable components.
Instead of writing REST Assured request logic repeatedly, common API operations can be moved into reusable utility or client classes.
public class ApiClient {
public static Response get(String endpoint) {
return given()
.when()
.get(endpoint);
}
public static Response post(String endpoint, String body) {
return given()
.contentType("application/json")
.body(body)
.when()
.post(endpoint);
}
public static Response delete(String endpoint) {
return given()
.when()
.delete(endpoint);
}
}
Reusable API clients help keep test classes focused on test scenarios instead of low-level request construction.
Common API configuration such as the base URI can be centralized.
import io.restassured.RestAssured;
public class ApiConfig {
public static void setup() {
RestAssured.baseURI = "https://example.com";
}
}
A more scalable framework can load the base URI from environment-specific configuration rather than hard-coding it.
REST Assured supports reusable request and response specifications. These can centralize common headers, base paths, content types, and validation rules.
RequestSpecification requestSpec =
new RequestSpecBuilder()
.setBaseUri("https://example.com")
.setContentType("application/json")
.build();
Reusable specifications reduce duplication across API test classes.
ResponseSpecification responseSpec =
new ResponseSpecBuilder()
.expectContentType("application/json")
.build();
Response specifications can be used when multiple tests share common response expectations.
API requests often require JSON payloads.
String body = """
{
"username": "john",
"email": "[email protected]",
"role": "customer"
}
""";
given()
.contentType("application/json")
.body(body)
.when()
.post("https://example.com/api/users")
.then()
.statusCode(201);
API automation should also verify how an API behaves when invalid input is provided.
Examples include:
given()
.header("Authorization", "Bearer invalid-token")
.when()
.get("https://example.com/api/profile")
.then()
.statusCode(401);
| Status Code | Meaning | Typical Testing Purpose |
|---|---|---|
| 200 | OK | Successful request |
| 201 | Created | Successful resource creation |
| 202 | Accepted | Request accepted for processing |
| 204 | No Content | Successful operation without response body |
| 400 | Bad Request | Invalid request data |
| 401 | Unauthorized | Authentication failure/missing credentials |
| 403 | Forbidden | Insufficient permissions |
| 404 | Not Found | Resource does not exist |
| 500 | Internal Server Error | Server-side failure |
The expected status code should always be determined from the API contract and application behavior.
Response time can be measured as part of functional API checks, although dedicated performance testing requires more specialized approaches.
given()
.when()
.get("https://example.com/api/users")
.then()
.statusCode(200)
.time(lessThan(3000L));
The threshold should be based on the application's agreed requirements rather than an arbitrary value.
A login API may return an authentication token that can be used by subsequent API requests.
String token =
given()
.contentType("application/json")
.body("""
{
"username": "testUser",
"password": "testPassword"
}
""")
.when()
.post("https://example.com/api/login")
.then()
.statusCode(200)
.extract()
.path("token");
System.out.println("Token received.");
Do not print real authentication tokens in production logs or reports.
An API token can sometimes be used to prepare or authenticate backend operations before a UI test. The exact mechanism depends on the application architecture.
Login API
|
v
Authentication Token
|
v
Create Required Test Data
|
v
Selenium UI Test
|
v
Validate User Workflow
One of the practical benefits of API integration is fast test-data cleanup.
Test Execution
|
v
Create Test Data
|
v
Run UI Test
|
v
Validate Result
|
v
Delete Test Data Through API
|
v
Clean Environment
This approach can help keep test environments cleaner when the application's APIs provide appropriate operations for test data management.
TestNG Data Providers can supply multiple combinations of UI and API test data.
@DataProvider(name = "users")
public Object[][] users() {
return new Object[][] {
{"user1", "pass1"},
{"user2", "pass2"},
{"user3", "pass3"}
};
}
@Test(dataProvider = "users")
public void hybridTest(String username, String password) {
System.out.println(
"Testing user: " + username
);
// API setup and Selenium UI validation
}
This allows the same hybrid workflow to execute against multiple test-data combinations.
The Page Object Model can be combined with API client classes. Page classes manage UI interactions while API classes manage service interactions.
Test Class
|
+-- LoginPage
| |
| +-- Selenium UI actions
|
+-- UserApiClient
|
+-- REST API actions
This separation improves maintainability and makes the framework easier to extend.
src
|-- main
| |-- java
| |-- pages
| | |-- LoginPage.java
| | |-- DashboardPage.java
| |
| |-- api
| | |-- UserApiClient.java
| | |-- AuthApiClient.java
| |
| |-- utilities
| |-- DriverFactory.java
| |-- ConfigReader.java
| |-- ApiUtils.java
|
|-- test
|-- java
|-- tests
| |-- LoginTest.java
| |-- UserTest.java
| |-- HybridTest.java
|
|-- data
|-- TestDataProvider.java
| Component | Responsibility |
|---|---|
| Page Classes | Web UI interaction |
| API Client | HTTP request and response handling |
| Data Provider | Test data |
| Driver Factory | WebDriver creation and management |
| Config Reader | Environment configuration |
| Assertions | Expected vs actual validation |
| Reports | Test execution results |
| Test Classes | Business-level test scenarios |
Consider an e-commerce checkout scenario.
Selenium
|
v
Login
|
v
Search Product
|
v
Add Product to Cart
|
v
Checkout
|
v
Place Order
|
v
API GET Order
|
v
Validate Order Status
|
v
Test Result
The UI validates the user workflow while the API validates the backend order information.
The opposite workflow can also be implemented.
POST Product API
|
v
Product Created
|
v
Open Website
|
v
Search Product
|
v
Validate Product Details
|
v
Delete Product API
Assertions should be placed at the appropriate testing layer.
API Assertions
|
+-- Status Code
+-- Response Body
+-- Headers
+-- Schema
+-- Business Rules
UI Assertions
|
+-- Page Title
+-- Element Visibility
+-- Text
+-- URL
+-- User Workflow Result
A realistic hybrid test could follow the following sequence:
Hybrid frameworks can report UI and API test results in a unified reporting system. Each test should provide enough information to identify whether the failure occurred during API preparation, UI execution, API validation, or cleanup.
Hybrid Test
|
+-- API Setup PASS
|
+-- Selenium UI PASS
|
+-- API Validation PASS
|
+-- Cleanup PASS
|
v
Test Report
Frameworks can integrate reporting tools such as Allure or Extent Reports to provide richer execution information. :contentReference[oaicite:0]{index=0}
Logging is useful for debugging API failures, but sensitive information should be protected.
Useful information may include:
Passwords, access tokens, API keys, session cookies, and other secrets should be masked or excluded from logs.
Hybrid UI/API suites can be executed through Maven-based CI/CD pipelines.
Developer Commit
|
v
CI/CD Pipeline
|
v
Maven Build
|
+----------------+
| |
v v
API Tests UI Tests
| |
v v
REST Assured Selenium
| |
+-------+--------+
|
v
Test Results
|
v
Report
Hybrid automation projects commonly use Maven and TestNG for execution and can integrate with CI systems such as Jenkins. :contentReference[oaicite:1]{index=1}
A Maven project can execute the test suite using the Maven test lifecycle.
mvn clean testSpecific TestNG suite files can also be configured through Maven Surefire depending on the project setup.
Different environments may have different API base URLs.
| Environment | Example Base URL |
|---|---|
| Development | https://dev.example.com |
| QA | https://qa.example.com |
| Staging | https://stage.example.com |
| Production | https://www.example.com |
Actual environment URLs should be stored in configuration rather than scattered throughout test classes.
Environment Configuration
|
+-- UI Base URL
|
+-- API Base URL
|
+-- Browser
|
+-- Authentication
|
v
Test Framework
|
+----+----+
| |
v v
Selenium REST Assured
| Aspect | UI-Only Approach | Hybrid UI + API Approach |
|---|---|---|
| Test Data Setup | Often through UI | Can use API where appropriate |
| Backend Validation | Indirect | Direct API validation possible |
| Execution Speed | More UI operations | Can reduce unnecessary UI setup |
| Coverage | Primarily UI behavior | UI and service layers |
| Architecture | Primarily page objects | Page objects + API clients |
| Data Cleanup | May require UI | Can use APIs where supported |
automation-framework/
|
|-- pom.xml
|-- testng.xml
|
|-- src/
| |-- main/
| | |-- java/
| | |-- pages/
| | | |-- LoginPage.java
| | | |-- DashboardPage.java
| | |
| | |-- api/
| | | |-- UserApiClient.java
| | | |-- OrderApiClient.java
| | |
| | |-- utilities/
| | |-- DriverFactory.java
| | |-- ConfigReader.java
| | |-- ApiUtils.java
| |
| |-- test/
| |-- java/
| |-- tests/
| | |-- LoginTest.java
| | |-- OrderTest.java
| | |-- HybridOrderTest.java
| |
| |-- data/
| |-- TestDataProvider.java
|
|-- resources/
| |-- config.properties
| |-- testdata.json
TestNG
|
v
Test Data
|
+-----------------------+
| |
v v
API Setup Selenium Setup
| |
v v
Create Data Open Browser
| |
v v
Capture ID Login
| |
+-----------+-----------+
|
v
UI Workflow
|
v
Business Action
|
v
API Validation
|
v
Assertions
|
v
Cleanup
|
v
Report
Consider an e-commerce application with customer, product, cart, and order APIs.
API: Create Customer
|
v
API: Create Product
|
v
Selenium: Login
|
v
Selenium: Search Product
|
v
Selenium: Add to Cart
|
v
Selenium: Checkout
|
v
API: Get Order
|
v
Validate Order
|
v
API: Cleanup Data
This architecture allows the UI layer to focus on user-facing workflows while APIs support setup, validation, and cleanup.
Not every API test needs Selenium, and not every Selenium test needs an API call. The purpose of a hybrid framework is to use each layer where it provides meaningful coverage.
Selenium is designed primarily for browser automation. REST APIs are generally tested using API clients or libraries such as REST Assured.
The combination allows a framework to validate both user-facing browser workflows and backend service behavior.
REST Assured is a Java library commonly used to automate and validate REST APIs.
Yes. REST Assured tests can be organized and executed using TestNG.
Yes. When suitable APIs are available, they can be used to create test data before Selenium executes the UI workflow.
Yes. A UI action can be followed by an API request that verifies the corresponding backend state.
API chaining means using output from one API request as input to another API request.
API-based cleanup can be faster and less dependent on UI workflows when appropriate delete or reset endpoints are available.
GET, POST, PUT, PATCH, and DELETE are commonly tested in REST API automation.
Depending on the API contract, validation may include status code, response body, headers, schema, business rules, and response time.
Authentication may involve API keys, Basic Authentication, bearer tokens, OAuth-based mechanisms, or other application-specific approaches.
Data can be passed through test utilities, Data Providers, context objects, configuration objects, or dedicated test-data classes.
A hybrid automation framework combines multiple automation layers or techniques, such as Selenium UI automation and REST API automation, under a common framework architecture.
Yes. UI and API test classes can be organized in the same TestNG project and suite configuration.
It can reduce unnecessary UI setup steps and allow tests to start with the required backend state.
POM separates Selenium page interactions from test logic, while API client classes can separately manage API operations.
No. API tests can run independently when browser behavior is not relevant.
No. API calls should be used when they provide useful setup, validation, cleanup, or business-flow coverage.
Maven and TestNG can execute UI and API test suites in CI/CD pipelines, with reports generated after execution.
The goal is to efficiently validate complete application behavior by testing appropriate UI and service-level scenarios through a maintainable automation framework.
| Concept | Description |
|---|---|
| Selenium | Browser automation framework |
| WebDriver | API for controlling browsers |
| REST Assured | Java library for REST API automation |
| GET | Retrieve a resource |
| POST | Create a resource |
| PUT | Replace/update a resource |
| PATCH | Partially update a resource |
| DELETE | Delete a resource |
| TestNG | Test execution and organization framework |
| DataProvider | Supplies multiple test-data sets |
| API Chaining | Uses output from one API in another API |
| API Setup | Creates or prepares test data |
| API Validation | Verifies backend state after UI actions |
| POM | Separates UI page interaction logic |
| Maven | Build and dependency management |
TestNG Test Suite
|
+-------------+-------------+
| |
v v
API Test Layer UI Test Layer
| |
v v
REST Assured Selenium WebDriver
| |
v v
API Services Browser
| |
+-------------+-------------+
|
v
Shared Utilities
|
+----------------+----------------+
| | |
v v v
Config Test Data Reporting
| | |
+----------------+----------------+
|
v
Maven
|
v
CI/CD
Selenium + API Testing combines browser automation with direct service-level validation. Selenium WebDriver is responsible for testing web application behavior through the browser, while REST Assured can be used to automate REST API requests and validate their responses.
A hybrid framework can use APIs to prepare test data, Selenium to execute user workflows, and APIs again to validate backend results or clean up data. This approach can reduce unnecessary UI operations and provide broader coverage across application layers.
TestNG can coordinate both API and UI tests, while Data Providers can supply multiple test scenarios. Page Object Model can organize Selenium interactions, API client classes can encapsulate service operations, and Maven can manage dependencies and execution.
For larger projects, configuration management, secure credentials, reusable utilities, logging, reporting, parallel execution, and CI/CD integration should be designed as separate framework concerns.
Learn more about Selenium automation and related testing concepts:
Final Takeaway: Selenium and API testing complement each other. Selenium validates the application from the user's perspective, while API automation validates service behavior directly. When combined with TestNG, Page Object Model, Data Providers, reusable API clients, Maven, reporting, and CI/CD, they can form a structured hybrid automation framework for end-to-end testing.
