Wolverine | Wolverine

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());
        httpChain.WithTags("wolverine");
    });
    
    // 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());
        httpChain.WithTags("wolverine");
    });
    
    // more configuration for HTTP...
    
    // Opting into the Fluent Validation middleware from
    // Wolverine.Http.FluentValidation
    opts.UseFluentValidationProblemDetailMiddleware();

^{snippet source | anchor}

HTTP Policies #

HTTP Policies