Vostra.Result.AspNetCore 1.2.1

Vostra.Result.AspNetCore

ASP.NET Core HTTP mapping for Vostra.Result: turn a Result/Result<T> into an HTTP response with one extension method. Works in minimal APIs and MVC controllers — no base class.

Install

dotnet add package Vostra.Result.AspNetCore

Setup (optional)

The whole point: your error kinds already know what they mean, so the HTTP layer shouldn't repeat that in a central switch. ToHttpResponse reads the status from the error itself and works with sensible defaults out of the box — call AddVostraResults only when you want to override the map:

builder.Services.AddVostraResults(o =>
{
    o.MapStatus(ErrorType.Conflict, 422);        // override a whole ErrorType
    o.MapStatusForCode("Order.Locked", 423);     // override one error code
});

Precedence: per-Code override → per-ErrorType map → built-in default.

A new ErrorBase subclass maps automatically through its ErrorType — no mapping edits.

Usage

Endpoints stay one line — return the Result and let the mapping pick the status, body, and pagination. Same call in minimal APIs and controllers, no base class:

// minimal API
app.MapGet("/orders/{id}", (int id, HttpContext http, IOrderService svc) =>
    svc.Get(id).ToHttpResponse(http));

// controller
[HttpGet("{id}")]
public async Task<IResult> Get(int id) =>
    (await _svc.Get(id)).ToHttpResponse(HttpContext);

// paginated list
app.MapGet("/orders", (HttpContext http, IOrderService svc) =>
    svc.List().ToHttpResponse(http, new Pagination(page: 1, pageSize: 20, totalCount: 137)));

Wire shapes

Success bodies stay thin (just a correlation id + your data); failures are standard ProblemDetails that keep the error's identity on the wire — which is exactly what lets the testing package reconstruct the typed error later.

Success (SuccessKind.Ok → 200, Created → 201):

{ "operationId": "00-abc…-01", "data": { "id": 42 } }

List:

{ "operationId": "…", "data": [ … ],
  "pagination": { "page": 1, "pageSize": 20, "totalCount": 137, "totalPages": 7 } }

Error — RFC 7807 application/problem+json, carrying code + errorType so a test client can assert on typed-error identity:

{ "type": "about:blank", "title": "Not Found", "status": 404,
  "detail": "Order 42 not found", "code": "Order.NotFound", "errorType": "NotFound",
  "operationId": "…" }

Validation errors (all ErrorType.Validation) render a field → messages map (field key = metadata["field"] if present, else the error Code):

{ "status": 400, "code": "General.Validation", "errorType": "Validation",
  "errors": { "Sku": ["required"], "Price": ["must be > 0"] }, "operationId": "…" }

Migration from a { status, operationId, data } envelope

• Success bodies drop status (read the HTTP status line); error bodies keep it (RFC 7807).
• operationId is a W3C trace id (Activity.Current?.Id ?? HttpContext.TraceIdentifier).
• Lists use ToHttpResponse(http, Pagination) with this package's Pagination record.