Expand description
RFC 9457 problem details for error responses
By default errors are {"error": "...", "status": 404}. Add
ProblemDetails to answer in the standard format instead, which API
clients and gateways understand without knowing your conventions:
{
"type": "https://api.example.com/problems/not-found",
"title": "Not Found",
"status": 404,
"detail": "Order 17 does not exist",
"instance": "/orders/17",
"errors": { "quantity": ["must be 1-50"] }
}sent as application/problem+json. Validation failures (422) list their
fields under errors.
use ullun::prelude::*;
use ullun::problem::ProblemDetails;
App::new()
.middleware(ProblemDetails::new().type_base("https://api.example.com/problems/"))
.get("/orders/{id}", |_req: Request| async {
Err::<Response, _>(Error::not_found("Order does not exist"))
})
.run("127.0.0.1:3000")
.await
.unwrap();Only the framework’s own error bodies are converted (a JSON object with
exactly error and status, plus fields for validation); responses your
handlers build themselves are left alone. Without
type_base the type is about:blank, as the RFC
allows for plain HTTP status problems.
Structs§
- Problem
Details - Middleware turning error responses into
application/problem+json