Loading all records from a database table in a single query is impractical for large datasets – it consumes excessive memory, slows down the application, and degrades user experience. Spring Data JPA provides first‑class pagination and sorting support through the Pageable interface and Page return type – no manual SQL LIMIT/OFFSET needed. In this guide, we’ll walk through everything you need to know to implement efficient, production‑ready pagination in your Spring Boot applications.

The Key Classes

Spring Data JPA’s pagination API revolves around these core types:

Repository Setup

Extend JpaRepository (which already extends PagingAndSortingRepository) – pagination is inherited automatically:

import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;

public interface ProductRepository extends JpaRepository<Product, Long> {

    // findAll(Pageable) is inherited from PagingAndSortingRepository

    // Derived query method – also accepts Pageable
    Page<Product> findByCategory(String category, Pageable pageable);

    // Custom JPQL with pagination
    @Query("SELECT p FROM Product p WHERE p.price < :maxPrice")
    Page<Product> findAffordable(@Param("maxPrice") BigDecimal maxPrice, Pageable pageable);
}

Spring Data automatically generates the LIMIT/OFFSET SQL (or the equivalent for your database) and a count query for Page return types. You can also use @Query with native SQL if needed, but the JPQL version is database‑independent.

Creating a PageRequest

import org.springframework.data.domain.PageRequest;
import org.springframework.data.domain.Sort;

// Page 0 (first page), 10 results, no sort
Pageable pageable = PageRequest.of(0, 10);

// Page 2 (third page), 5 results, sorted by name ascending
Pageable sorted = PageRequest.of(2, 5, Sort.by("name"));

// Multiple sort fields
Pageable multiSort = PageRequest.of(0, 20,
    Sort.by(Sort.Direction.DESC, "createdAt")
        .and(Sort.by(Sort.Direction.ASC, "name")));

// Use the pageable to query the repository
Page<Product> page = productRepository.findAll(pageable);

Important: Page numbers are zero‑based: page 0 is the first page, page 1 is the second, and so on. This matches the convention used in Spring Data and most REST APIs.

What Page<T> Contains

Page<Product> page = productRepository.findAll(PageRequest.of(0, 10));

page.getContent();          // List<Product> – the actual data
page.getTotalElements();    // long – total records in database
page.getTotalPages();       // int – ceil(totalElements / pageSize)
page.getNumber();           // int – current page number (0-based)
page.getSize();             // int – page size requested
page.getNumberOfElements(); // int – actual elements in this page (may be less on last page)
page.isFirst();             // boolean
page.isLast();              // boolean
page.hasNext();             // boolean
page.hasPrevious();         // boolean

REST Controller with Pagination

Expose pagination as query parameters in your REST endpoint. Spring MVC can bind Pageable directly from request parameters when @EnableSpringDataWebSupport is active (enabled automatically with Spring Boot).

import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
import org.springframework.data.web.PageableDefault;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final ProductRepository repository;

    public ProductController(ProductRepository repository) {
        this.repository = repository;
    }

    @GetMapping
    public Page<Product> getProducts(
        // @PageableDefault sets fallback values if parameters are not provided
        @PageableDefault(size = 20, sort = "name") Pageable pageable
    ) {
        return repository.findAll(pageable);
    }

    @GetMapping("/category/{category}")
    public Page<Product> getByCategory(
        @PathVariable String category,
        @PageableDefault(size = 10) Pageable pageable
    ) {
        return repository.findByCategory(category, pageable);
    }
}

The endpoint now accepts these query parameters:

• page – page number (0‑based, default 0)
• size – page size (default from @PageableDefault)
• sort – sort field and direction, e.g. sort=name,desc

Example request: GET /api/products?page=1&size=10&sort=price,desc

You can also omit @PageableDefault and rely on global defaults by setting spring.data.web.pageable.default-page-size and spring.data.web.pageable.max-page-size in your application.properties.

JSON Response Structure

When you return Page<T> from a Spring MVC controller, it serializes to JSON with both content and metadata:

{
  "content": [
    { "id": 11, "name": "Keyboard", "price": 49.99 },
    { "id": 12, "name": "Mouse", "price": 29.99 }
  ],
  "pageable": {
    "sort": { "sorted": true, "unsorted": false },
    "pageNumber": 1,
    "pageSize": 10,
    "offset": 10
  },
  "totalPages": 5,
  "totalElements": 47,
  "last": false,
  "first": false,
  "numberOfElements": 10,
  "size": 10,
  "number": 1,
  "empty": false
}

This structure is compatible with most front‑end pagination components (e.g., Angular Material, React Table).

Page vs Slice

Spring Data JPA offers two main return types for paginated queries. Here’s how they compare:

For large tables, the COUNT(*) query that Page requires can be expensive. If you're building an infinite scroll UI where you only need to know if there are more results, Slice is more efficient. To use Slice, simply change your repository method return type to Slice<T> – Spring Data will automatically generate the appropriate query without the count.

Sorting Without Pagination

You can also use Sort independently of Pageable when you need sorted results but don't need pagination:

// Repository method with Sort parameter
List<Product> findByCategory(String category, Sort sort);

// Usage:
Sort sort = Sort.by(Sort.Direction.ASC, "name");
List<Product> products = repository.findByCategory("Electronics", sort);

Performance Considerations

• Large offsets: When you request a high page number (e.g., page 1000 with size 20), the generated SQL uses OFFSET 20000. This can be slow on large tables because the database still has to scan rows up to that offset. Consider using keyset pagination (also called “seek method”) if you need to navigate deeply. Spring Data doesn't support keyset pagination out‑of‑the‑box, but you can implement it with custom queries using WHERE id > :lastId.
• Count queries: The COUNT(*) query for Page can become expensive on tables with millions of rows. If you have a very large table and don't need exact total counts, use Slice instead.
• Sorting on unindexed columns: Sorting on columns without database indexes will force a full table scan. Always ensure that the columns you sort on are indexed, especially for large datasets.
• Default page size: Set a reasonable default page size (e.g., 20 or 50) to avoid accidentally loading too many records at once. Use @PageableDefault or global properties to enforce a maximum size.

Sorting with Multiple Fields and Null Handling

You can control how null values are sorted using the Sort.Order class:

Sort sort = Sort.by(
    Sort.Order.asc("name").nullsFirst(),
    Sort.Order.desc("createdAt").nullsLast()
);
Pageable pageable = PageRequest.of(0, 10, sort);

This is useful when you want to place nulls at the beginning or end of the result set.

Using Pagination with Projections (DTOs)

If you want to fetch only a subset of columns (e.g., for performance), you can use DTO projections with pagination:

public interface ProductSummary {
    String getName();
    BigDecimal getPrice();
}

// Repository method
Page<ProductSummary> findByCategory(String category, Pageable pageable);

Spring Data will generate a query that selects only the needed columns, and the pagination works the same way as with entities.

Best Practices

• Always set a maximum page size – use @PageableDefault with maxPageSize or configure spring.data.web.pageable.max-page-size to prevent clients from requesting huge pages that could overload your database.
• Use Slice for infinite scroll – avoid the count query cost when you don’t need total page numbers.
• Index your sort columns – ensure that all columns used in Sort.by() have database indexes.
• Validate sort parameters – to prevent malicious sort fields, consider whitelisting allowed sort properties (e.g., by checking the field name against a set of known column names).
• Prefer default values – always specify defaults for page, size, and sort so that your API works without any parameters.
• Use @PageableDefault with sort and direction for a clean and consistent API.

Common Pitfalls and Troubleshooting

• Page is 0‑based – many developers expect 1‑based pages. Make sure your front‑end sends page=0 for the first page, or you can create a custom Pageable resolver to convert from 1‑based.
• Missing @EnableSpringDataWebSupport – in Spring Boot, it’s auto‑configured. In plain Spring MVC, you need to add it to a configuration class.
• Sort parameter format – the query parameter should be like sort=name,desc (note: comma, not space). Multiple sorts: sort=name,desc&sort=id,asc.
• Large offset performance – if you're experiencing slow queries on large offsets, consider implementing keyset pagination or using @Query with a native WHERE clause that uses the last retrieved ID.
• Count query fails – when using complex joins or distinct queries, the count query may fail. You can provide a custom count query with @Query(countQuery = "...").

Summary

Spring Data JPA's pagination is built around three components: PageRequest.of(page, size, sort) to specify what you want, repository methods that accept Pageable and return Page<T>, and the Page object that carries both the data and metadata (total elements, total pages, current page). In a REST controller, declare Pageable as a method parameter and Spring MVC automatically binds it from page, size, and sort query parameters. Use Slice<T> instead of Page<T> when you want to avoid the count query on very large tables, and always protect your endpoints with sensible defaults and maximum page sizes.

With these tools, you can build efficient, user‑friendly APIs that handle large datasets gracefully.

Happy coding!

Most Spring Boot tutorials focus on building REST APIs. But in practice, most applications also need to consume them — calling third‑party services, microservices in your own stack, or internal APIs. Spring's RestTemplate is the traditional way to do this, and while Spring 5 introduced the reactive WebClient, RestTemplate is still widely used and the right choice for blocking, synchronous HTTP calls in servlet‑based applications.

Setup

No extra dependency needed for RestTemplate — it's part of spring-boot-starter-web. The typical setup uses RestTemplateBuilder, which Spring Boot auto‑configures and injects:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

The examples here also use Jackson's JsonNode to work with JSON responses generically, which is already included through the web starter.

Example 1: Fetching GitHub API Endpoints

GitHub's root API endpoint returns a map of all available API URLs. This makes a good first example because it returns structured JSON with no authentication required:

import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.web.client.RestTemplateBuilder;
import org.springframework.core.annotation.Order;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestTemplate;
import com.fasterxml.jackson.databind.JsonNode;
import java.util.Iterator;
import java.util.Map;

@Component
@Order(1)
public class GithubEndpointLoader implements CommandLineRunner {

    private final RestTemplate restTemplate;

    public GithubEndpointLoader(RestTemplateBuilder builder) {
        this.restTemplate = builder.build();
    }

    @Override
    public void run(String... args) {
        String url = "https://api.github.com";
        ResponseEntity<JsonNode> response =
            restTemplate.getForEntity(url, JsonNode.class);

        System.out.println("GitHub API Endpoints:");
        Iterator<Map.Entry<String, JsonNode>> fields = response.getBody().fields();
        while (fields.hasNext()) {
            Map.Entry<String, JsonNode> entry = fields.next();
            System.out.println("  " + entry.getKey() + " -> " + entry.getValue().asText());
        }
    }
}

getForEntity(url, responseType) makes a GET request and wraps the response in a ResponseEntity, giving you access to the status code, headers, and body. Using JsonNode.class as the response type tells Jackson to parse the JSON into a generic tree structure — useful when you don't want to create a specific class just to parse a response.

Example 2: Fetching User Repositories

A more realistic example — fetching a list of repositories for a specific GitHub user. The response is a JSON array, so you need to check before iterating:

@Component
@Order(2)
public class GithubRepoLoader implements CommandLineRunner {

    private final RestTemplate restTemplate;

    public GithubRepoLoader(RestTemplateBuilder builder) {
        this.restTemplate = builder.build();
    }

    @Override
    public void run(String... args) {
        String url = "https://api.github.com/users/bootng/repos";
        ResponseEntity<JsonNode> response =
            restTemplate.getForEntity(url, JsonNode.class);

        JsonNode body = response.getBody();
        System.out.println("Repositories:");

        if (body != null && body.isArray()) {
            for (JsonNode repo : body) {
                System.out.println("  " + repo.get("name").asText()
                    + " — " + repo.get("description").asText());
            }
        }
    }
}

The @Order annotations on both classes control which CommandLineRunner executes first. Order 1 runs before Order 2.

Deserializing into a POJO Instead

For responses with a known structure, mapping to a POJO is cleaner than working with JsonNode:

public class GithubRepo {
    private String name;
    private String description;
    private int stargazersCount;

    // getters and setters
}

// Use an array type as the response type
ResponseEntity<GithubRepo[]> response =
    restTemplate.getForEntity(url, GithubRepo[].class);

GithubRepo[] repos = response.getBody();
for (GithubRepo repo : repos) {
    System.out.println(repo.getName());
}

Jackson maps JSON field names to Java field names. If the JSON uses snake_case (stargazers_count) and your Java uses camelCase (stargazersCount), add @JsonProperty("stargazers_count") to the field or configure an object mapper with MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES.

POST, PUT, DELETE

RestTemplate supports all HTTP methods:

// POST — send a request body, receive a response body
ResponseEntity<Blog> created =
    restTemplate.postForEntity("/api/blogs", newBlog, Blog.class);

// PUT — update a resource
restTemplate.put("/api/blogs/{id}", updatedBlog, blogId);

// DELETE — remove a resource
restTemplate.delete("/api/blogs/{id}", blogId);

Error Handling

By default, RestTemplate throws HttpClientErrorException (4xx responses) and HttpServerErrorException (5xx responses). You can handle them explicitly:

try {
    ResponseEntity<Blog> response =
        restTemplate.getForEntity("/api/blogs/nonexistent", Blog.class);
} catch (HttpClientErrorException.NotFound e) {
    System.out.println("Blog not found: " + e.getStatusCode());
} catch (HttpServerErrorException e) {
    System.out.println("Server error: " + e.getStatusCode());
}

For more control, implement a custom ResponseErrorHandler and set it on the RestTemplate instance.

Running the Application

mvn clean install
mvn spring-boot:run

The console output shows the GitHub API endpoints (from the first runner) followed by the repository list (from the second runner), ordered by the @Order annotations.

RestTemplate vs WebClient

Spring 5 introduced WebClient as the modern, non‑blocking alternative. RestTemplate is still maintained but no longer actively developed with new features. For most existing Spring MVC applications, RestTemplate is perfectly fine. Switch to WebClient if you're building reactive applications with Spring WebFlux or need non‑blocking I/O for performance reasons.

Summary

Spring Boot's RestTemplate provides a straightforward API for making HTTP requests from Java. Inject RestTemplateBuilder, call build() to get an instance, then use methods like getForEntity() to make requests. The response comes back as a ResponseEntity containing status, headers, and body. Use JsonNode.class as the response type for flexible generic JSON parsing, or map to a POJO for known response structures. For sequenced startup operations, implement CommandLineRunner with @Order to control execution sequence.

Happy coding!

Without centralized exception handling, every controller method ends up with try‑catch blocks, and every new exception type requires updating every controller that might throw it. @ControllerAdvice solves this by letting you define exception handling logic once, in one place, and have it apply across your entire application. It's one of those Spring features that pays off quickly once you have more than a handful of endpoints.

The Problem Without @ControllerAdvice

Here's what controller code looks like when exception handling is inline:

@GetMapping("/blogs/{id}")
public ResponseEntity<BlogStory> getBlog(@PathVariable String id) {
    try {
        BlogStory blog = blogService.findById(id);
        return ResponseEntity.ok(blog);
    } catch (NotFoundException e) {
        return ResponseEntity.notFound().build();
    } catch (AppException e) {
        return ResponseEntity.internalServerError().build();
    }
}

@PostMapping("/blogs")
public ResponseEntity<BlogStory> createBlog(@RequestBody BlogStory blog) {
    try {
        BlogStory created = blogService.create(blog);
        return ResponseEntity.status(201).body(created);
    } catch (AppException e) {  // same handler copied again
        return ResponseEntity.internalServerError().build();
    }
}

Every method that can throw AppException needs the same catch block. Add a new exception type and you're touching every controller. This is the problem @ControllerAdvice was designed to eliminate.

Custom Exception Classes

First, define the application‑specific exceptions:

public class NotFoundException extends RuntimeException {
    public NotFoundException(String message) {
        super(message);
    }
}

public class AppException extends RuntimeException {
    public AppException(String message) {
        super(message);
    }

    public AppException(String message, Throwable cause) {
        super(message, cause);
    }
}

The Global Exception Handler

import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(NotFoundException.class)
    public ResponseEntity<String> handleNotFound(NotFoundException ex) {
        return ResponseEntity
            .status(HttpStatus.NOT_FOUND)
            .body(ex.getMessage());
    }

    @ExceptionHandler(AppException.class)
    public ResponseEntity<String> handleAppException(AppException ex) {
        return ResponseEntity
            .status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body("Something went wrong: " + ex.getMessage());
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleGeneral(Exception ex) {
        return ResponseEntity
            .status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body("Unexpected error occurred");
    }
}

Each @ExceptionHandler method handles one (or more) exception types. When a controller throws NotFoundException, Spring intercepts it and routes it to handleNotFound() instead of propagating. The controller never sees the exception — it only throws it.

Clean Controllers After @ControllerAdvice

The same controller methods from before, now without any error handling code:

@RestController
@RequestMapping("/blogs")
public class BlogAPIController {

    private final BlogService blogService;

    public BlogAPIController(BlogService blogService) {
        this.blogService = blogService;
    }

    @GetMapping("/{id}")
    public BlogStory getBlog(@PathVariable String id) {
        return blogService.findById(id);  // throws NotFoundException — handled globally
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public BlogStory createBlog(@RequestBody BlogStory blog) {
        return blogService.create(blog);  // throws AppException — handled globally
    }
}

The controller is now purely about orchestration — take the request, call the service, return the result. Exception handling is a cross‑cutting concern that belongs elsewhere, and @ControllerAdvice is that elsewhere.

Returning Structured Error Responses

Returning a plain string as the error body is functional but not ideal for API clients. A structured error response is more useful:

public class ErrorResponse {
    private int status;
    private String message;
    private long timestamp;

    public ErrorResponse(int status, String message) {
        this.status = status;
        this.message = message;
        this.timestamp = System.currentTimeMillis();
    }

    // getters
}

@ExceptionHandler(NotFoundException.class)
public ResponseEntity<ErrorResponse> handleNotFound(NotFoundException ex) {
    ErrorResponse error = new ErrorResponse(404, ex.getMessage());
    return ResponseEntity.status(HttpStatus.NOT_FOUND).body(error);
}

The JSON response now looks like:

{
  "status": 404,
  "message": "Blog with id 'xyz' not found",
  "timestamp": 1718123456789
}

Scoping @ControllerAdvice

By default, @ControllerAdvice applies to all controllers in the application. You can narrow its scope:

// Only applies to controllers in this package
@ControllerAdvice("com.example.api")

// Only applies to controllers annotated with @RestController
@ControllerAdvice(annotations = RestController.class)

// Only applies to these specific controller classes
@ControllerAdvice(assignableTypes = {BlogAPIController.class, UserController.class})

In most cases, a single application‑wide advice class is the right approach. Multiple scoped advice classes can be useful in modular applications where different modules have different error response formats.

@RestControllerAdvice

If all your handler methods return response bodies (as in a REST API), use @RestControllerAdvice instead of @ControllerAdvice. It's the equivalent of combining @ControllerAdvice with @ResponseBody — the same way @RestController combines @Controller with @ResponseBody:

@RestControllerAdvice
public class GlobalExceptionHandler {
    // no need to wrap returns in ResponseEntity if you're always returning bodies

    @ExceptionHandler(NotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public ErrorResponse handleNotFound(NotFoundException ex) {
        return new ErrorResponse(404, ex.getMessage());
    }
}

Summary

@ControllerAdvice is Spring's mechanism for defining global exception handling logic that applies across all controllers. Instead of writing try‑catch blocks in every controller method, you define @ExceptionHandler methods in a single @ControllerAdvice class. Spring intercepts exceptions thrown by any controller and routes them to the appropriate handler. The result is cleaner controllers focused on business logic, consistent error responses across the API, and a single place to update when you add new exception types. Use @RestControllerAdvice for REST APIs where all responses serialise to JSON.

Happy coding!