Partie Requests

Requests

A request carries the input for one query or command. The handler contract names its request type, and Providers and Parties use that same type to select matching operations.

Use a concrete class with an empty constructor accessible to the project that declares the routes. A class with no declared constructor has an implicit empty constructor. Generated request binding expects classes rather than records. Public data properties need a public getter, an accessible setter or init accessor, and one binding attribute. Inherited properties follow the same rules.

Query input

A course search can carry an ID and an optional academic year:

// CourseSearchQuery.cs
public sealed class CourseSearchQuery
{
    [FromPath]
    public required int CourseId { get; init; }

    [FromParams]
    public string? AcademicYear { get; init; }
}

The binding attributes describe input sources to the consuming framework's engine. ASP.NET Core request binding explains their HTTP behavior.

Command input

Put structured input in an operation-specific payload. The payload can be a record:

// CourseCreateCmd.cs
public sealed record CourseCreatePayload(string Title, int Capacity);

public sealed class CourseCreateCmd
{
    [FromPayload]
    public required CourseCreatePayload Body { get; init; }
}

The handler receives the outer command and reads command.Body.Title and command.Body.Capacity. Keep payloads specific to their operations so changing one command's input does not change another command's contract.

Empty requests

Use Unit as the request type when an operation takes no input. The handler still receives the request argument, but it carries no data.

Request families

A shared base class or interface lets generic Providers and Parties match a family of requests. Put the constraint on the step class; a concrete request in a step's contract matches only that exact request type. See Generic matching.

See Handlers for consuming input and Contexts for supplying dependencies separately.