Loading published curriculum…

12 · Spring Boot and the web request lifecycle / LESSON 57 OF 102

Bounded pagination and consistent error responses

Predictable response shapes and bounded work make an API easier to use and operate.

Before this lesson: DTOs, JSON serialization, and validation boundaries

Understand the topic

Cap page size, validate page indexes, and allowlist sort fields. Do not expose arbitrary persistence paths as sortable input. Decide how pagination behaves when data changes between requests and whether a cursor better fits the workload.

Use ProblemDetail for a consistent machine-readable failure contract and add safe validation details. Do not return stack traces, SQL, or credentials. Give clients a stable error code and a request ID they can use when reporting a failure.

EXAMPLE · JAVA

PagePolicy.java

public final class PagePolicy {
 private PagePolicy() {}
 public static int checkedSize(int size) {
  if (size < 1 || size > 100)
   throw new IllegalArgumentException("size must be between 1 and 100");
  return size;
 }
}

What to expect

Map invalid input to a documented 400 response at the HTTP boundary; the helper prevents an unbounded page request.

YOUR TURN

Put it into practice

  1. 01Add pagination with a maximum size of 100.
  2. 02Test zero, negative, maximum, and oversized input plus an unsupported sort field.
  3. 03Verify: Invalid requests return a consistent error shape and never trigger an unbounded query.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Predictable response shapes and bounded work make an API easier to use and operate.

  1. 01Cap page size, validate page indexes, and allowlist sort fields. Do not expose arbitrary persistence paths as sortable input. Decide how pagination behaves when data changes between requests and whether a cursor better fits the workload.
  2. 02Use ProblemDetail for a consistent machine-readable failure contract and add safe validation details. Do not return stack traces, SQL, or credentials. Give clients a stable error code and a request ID they can use when reporting a failure.
  3. 03Trace the example: Map invalid input to a documented 400 response at the HTTP boundary; the helper prevents an unbounded page request.

A mistake worth avoiding

A client requests millions of rows in one response.

DEBUGGING ROOM

Something broke. Where do you look?

A client requests millions of rows in one response.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Should SQL exception text be returned directly in a public error response?

Choose one answer

BUILD IT YOURSELF

Add pagination with a maximum size of 100.

  1. 1.Add pagination with a maximum size of 100.
  2. 2.Test zero, negative, maximum, and oversized input plus an unsupported sort field.
  3. 3.Reproduce this failure, then repair it: A client requests millions of rows in one response.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Should SQL exception text be returned directly in a public error response?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

Invalid requests return a consistent error shape and never trigger an unbounded query.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references