Extension: Validation Responses & Pagination

Before you start

This page contains content that was deferred from Week 5. It must be completed before starting the capstone project.

If you completed the full Week 5 including the extension section, you do not need this page — you have already covered this material.

When to work through this

After Week 7 (Testing) and before the capstone, or at any point where you have spare time between weeks.

Goal

Return structured validation error responses from your endpoints, and implement pagination so list endpoints do not return all records at once.

Part 1: Validation error responses

Core skills

• Return structured validation error messages from endpoints
• Use Results.ValidationProblem() for a consistent error format
• Understand the difference between a generic 400 and a field-level validation error response

Key resources

• Model Validation
• Data Annotations Reference
• REST API Design Best Practices

LLM prompts

“Show me how to check if a Book is valid in my POST endpoint and return a structured BadRequest response with field-level error messages using Results.ValidationProblem().”

“What is the difference between Results.BadRequest() and Results.ValidationProblem()? When should I use each?”

Learning activities

1. Update POST /books to return Results.ValidationProblem() when validation fails
2. Test in Swagger — confirm the 400 response body lists which fields failed and why
3. Repeat for POST /authors
4. Try submitting a book with a title that is too long and confirm the max length error appears

Key concepts

• Results.ValidationProblem() returns a standardised Problem Details response (RFC 7807)
• Field-level error messages tell the caller exactly what to fix, unlike a generic 400
• Validation runs automatically against Data Annotations before your endpoint body executes

Part 2: Pagination

Core skills

• Accept page and pageSize query parameters on list endpoints
• Use .Skip() and .Take() to retrieve a subset of database results
• Return total count alongside the current page so clients can calculate total pages

Key resources

• REST API Design Best Practices
• Model Binding

LLM prompts

“Implement simple pagination for GET /books. Accept page and pageSize query parameters with defaults, use Skip() and Take(), and return both the results and the total count.”

“Show me how to return a paginated response object that includes the items, total count, current page, and page size.”

Learning activities

1. Add page and pageSize query parameters to GET /books (defaults: page=1, pageSize=10)
2. Implement .Skip((page - 1) * pageSize).Take(pageSize) in the database query
3. Return total count alongside the paged results
4. Seed 15+ books into the database
5. Test fetching page 1 and page 2 in Swagger and confirm results differ
6. Test that requesting a page beyond the last page returns an empty list, not an error

Key concepts

• .Skip() and .Take() are the core of offset-based pagination
• Always run the count query on the unfiltered set before applying Skip/Take
• Returning total count lets clients display “Page 2 of 5” without additional requests

Optional

• Simple title search using .Contains()
• Filter books by author name
• Sorting by title or year

Deliverable

Before moving to the capstone, confirm:

• POST /books and POST /authors return field-level error messages on invalid input
• GET /books accepts page and pageSize parameters and returns paginated results with a total count

---

Back to Week 5 | Back to Overview | Capstone Project