HTTP Policies

Custom policies can be created for HTTP endpoints through either creating your own implementation of IHttpPolicy shown below:

/// <summary>
///     Use to apply your own conventions or policies to HTTP endpoint handlers
/// </summary>
public interface IHttpPolicy
{
    /// <summary>
    ///     Called during bootstrapping to alter how the message handlers are configured
    /// </summary>
    /// <param name="chains"></param>
    /// <param name="rules"></param>
    /// <param name="container">The application's underlying Lamar Container</param>
    void Apply(IReadOnlyList<HttpChain> chains, GenerationRules rules, IContainer container);
}

^{snippet source | anchor}

And then adding a policy to the WolverineHttpOptions like this code from the Fluent Validation extension for HTTP:

/// <summary>
///     Apply Fluent Validation middleware to all Wolverine HTTP endpoints with a known Fluent Validation
///     validator for the request type
/// </summary>
/// <param name="httpOptions"></param>
public static void UseFluentValidationProblemDetailMiddleware(this WolverineHttpOptions httpOptions)
{
    httpOptions.AddPolicy<HttpChainFluentValidationPolicy>();
}

^{snippet source | anchor}

Or lastly through lambdas (which creates an IHttpPolicy object behind the scenes):

app.MapWolverineEndpoints(opts =>
{
    // This is strictly to test the endpoint policy

    opts.ConfigureEndpoints(httpChain =>
    {
        // The HttpChain model is a configuration time
        // model of how the HTTP endpoint handles requests

        // This adds metadata for OpenAPI
        httpChain.WithMetadata(new CustomMetadata());
    });
    
    // more configuration for HTTP...
    
    // Opting into the Fluent Validation middleware from
    // Wolverine.Http.FluentValidation
    opts.UseFluentValidationProblemDetailMiddleware();

^{snippet source | anchor}

The HttpChain model is a configuration time structure that Wolverine.Http will use at runtime to create the full HTTP handler (RequestDelegate and RoutePattern for ASP.Net Core). But at bootstrapping / configuration time, we have the option to add -- or remove -- any number of middleware, post processors, and custom metadata (OpenAPI or otherwise) for the endpoint.

Here's an example from the Wolverine.Http tests of using a policy to add custom metadata:

app.MapWolverineEndpoints(opts =>
{
    // This is strictly to test the endpoint policy

    opts.ConfigureEndpoints(httpChain =>
    {
        // The HttpChain model is a configuration time
        // model of how the HTTP endpoint handles requests

        // This adds metadata for OpenAPI
        httpChain.WithMetadata(new CustomMetadata());
    });
    
    // more configuration for HTTP...
    
    // Opting into the Fluent Validation middleware from
    // Wolverine.Http.FluentValidation
    opts.UseFluentValidationProblemDetailMiddleware();

^{snippet source | anchor}

Resource Writer Policies

Wolverine has an additional type of policy that deals with how an endpoints primary result is handled.

/// <summary>
///    Use to apply custom handling to the primary result of an HTTP endpoint handler
/// </summary>
public interface IResourceWriterPolicy
{
    /// <summary>
    ///  Called during bootstrapping to see whether this policy can handle the chain. If yes no further policies are tried.
    /// </summary>
    /// <param name="chain"> The chain to test against</param>
    /// <returns>True if it applies to the chain, false otherwise</returns>
    bool TryApply(HttpChain chain);
}

^{snippet source | anchor}

Only one of these so called resource writer policies can apply to each endpoint and there are a couple of built in policies already.

If you need special handling of a primary return type you can implement IResourceWriterPolicy and register it in WolverineHttpOptions

opts.AddResourceWriterPolicy<CustomResourceWriterPolicy>();

^{snippet source | anchor}

Resource writer policies registered this way will be applied in order before all built in policies.