By the end of this session, you will be able to:

• Implement offset-based and cursor-based pagination in a .NET Web API
• Build reusable filter and sort query models that compose together
• Return pagination metadata correctly alongside response data
• Explain when cursor pagination is preferable over offset pagination
• Cap and whitelist user-supplied query parameters server-side to prevent abuse

• Server memory — materializing 1 million rows into a list allocates all of them in memory at once before the first byte is sent
• Database load — a query with no LIMIT locks table pages and competes with every other request for I/O
• Network bandwidth — a 50 MB JSON payload chokes mobile clients and slow connections entirely
• Client crash — browsers and mobile apps that try to render 100,000 list items freeze or crash
• Timeouts — long-running responses are killed by proxies, load balancers, and client timeout settings

public class PaginationParams
{
    private const int MaxPageSize = 100;
    private int _pageSize = 20;

    public int Page { get; set; } = 1;

    public int PageSize
    {
        get => _pageSize;
        set => _pageSize = value > MaxPageSize ? MaxPageSize : value;
    }
}

public class PagedResult<T>
{
    public IEnumerable<T> Data { get; set; } = [];
    public int Page { get; set; }
    public int PageSize { get; set; }
    public int TotalCount { get; set; }
    public int TotalPages => (int)Math.Ceiling((double)TotalCount / PageSize);
    public bool HasNextPage => Page < TotalPages;
    public bool HasPreviousPage => Page > 1;
}

Computed properties TotalPages, HasNextPage, and HasPreviousPage are derived — clients never need to calculate them themselves.

public PagedResult<TaskItem> GetAll(TaskFilterParams filters)
{
    var query = _tasks.AsQueryable();

    if (!string.IsNullOrWhiteSpace(filters.Search))
        query = query.Where(t => t.Title.Contains(filters.Search,
            StringComparison.OrdinalIgnoreCase));

    if (filters.IsCompleted.HasValue)
        query = query.Where(t => t.IsCompleted == filters.IsCompleted.Value);

    var totalCount = query.Count();
    var data = query.Skip((filters.Page - 1) * filters.PageSize)
                    .Take(filters.PageSize)
                    .ToList();

    return new PagedResult<TaskItem>
    {
        Data       = data,
        Page       = filters.Page,
        PageSize   = filters.PageSize,
        TotalCount = totalCount
    };
}

Count is taken before Skip/Take so TotalCount reflects the full filtered set, not just the current page.

public class TaskFilterParams : PaginationParams
{
    public string? Search { get; set; }
    public bool? IsCompleted { get; set; }
    public DateTime? CreatedAfter { get; set; }
    public DateTime? CreatedBefore { get; set; }
    public string? SortBy { get; set; } = "createdAt";
    public string? Order { get; set; } = "asc";
}

One model. All combinations work: ?search=meeting&isCompleted=false&page=1&pageSize=5&sortBy=title&order=asc

Enhance GET /api/tasks to support pagination, filtering, and sorting. All parameters must compose together.

• Pagination is mandatory — unbounded list responses are a correctness and performance failure waiting to happen
• Offset vs cursor — offset is simple and UI-friendly; cursor is stable with live data and the right choice for feeds and real-time endpoints
• PaginationParams enforces the server-side cap in a single model that every collection endpoint can inherit or compose
• PagedResult<T> standardizes the response shape — clients always know where to find data and navigation metadata
• TaskFilterParams extends PaginationParams so one model covers filtering, sorting, and paging in a single query-string binding
• Sort field whitelisting prevents injection and keeps the API surface explicit — unknown sort keys are silently defaulted or rejected

Session 08 — API Documentation & Swagger

• Now that your API returns paginated, filtered, and sorted responses, Session 08 covers how to document those query parameters so consumers do not have to read the source code
• You will integrate Swashbuckle (Swagger UI) into your .NET project and annotate endpoints with XML comments and response type attributes
• Swagger will automatically discover your TaskFilterParams query parameters and expose them as interactive form fields in the UI
• After Session 08, your Task API will have a living, testable API reference that stays in sync with the code

Extend the Task API with a fully composable paginated, filtered, and sorted GET endpoint.

What to build:

• Create PaginationParams, PagedResult<T>, and TaskFilterParams in a Models/ folder
• Update TaskService.GetAll to accept TaskFilterParams and return a PagedResult<TaskItem>
• Whitelist sort fields using a dictionary — reject (or default) any unknown sortBy value
• Update the controller action to bind the params with [FromQuery] and return the paged result

Acceptance criteria:

• Response always includes totalCount, totalPages, hasNextPage, and hasPreviousPage
• pageSize is capped at 100 regardless of what the client sends
• ?search=meeting&isCompleted=false&page=1&pageSize=5&sortBy=title returns correct results and correct metadata
• Passing an unknown sortBy value does not crash — it falls back to the default sort