Skip to main content

Module problem

Module problem 

Source
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§

ProblemDetails
Middleware turning error responses into application/problem+json