PricingLoginStart free
Spring Boot 4 Complete Guide · レッスン

RFC 7807 Problem Detailレスポンス

SpringのProblemDetailとErrorResponseサポートを使い、機械可読なエラーペイロードを標準化します。

レッスン 4/413 ステップ

「RFC 7807 Problem Detailレスポンス」はCoddyKit上の無料Spring Boot 4 Complete Guideレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSpring Boot 4 Complete Guide学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Spring Boot 4 Complete Guideコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Standardize Error Responses?

When an API fails, clients need a predictable, machine-readable error body. Hand-rolled JSON like {"error": "bad"} varies per endpoint and breaks integrations.

RFC 7807 ("Problem Details for HTTP APIs") defines a single, standard shape for error payloads. Spring Boot has first-class support for it through the ProblemDetail class and the ErrorResponse contract.

  • Consistent across every endpoint
  • Self-documenting via a type URI
  • Extensible with custom properties

The RFC 7807 Media Type and Fields

A Problem Detail response uses the media type application/problem+json and contains these standard members:

  • type — a URI identifying the problem category (defaults to about:blank)
  • title — a short, human-readable summary
  • status — the HTTP status code (e.g. 404)
  • detail — a human-readable explanation specific to this occurrence
  • instance — a URI identifying the specific occurrence (often the request path)

You may also add custom extension members like errorCode or timestamp.

A Sample Problem+JSON Body

Here is what a client actually receives. Note the application/problem+json content type and the standard fields, plus an extension member errorCode.

{
  "type": "https://api.shop.com/problems/out-of-stock",
  "title": "Out of Stock",
  "status": 409,
  "detail": "Product 42 has only 3 units left, but 5 were requested.",
  "instance": "/api/orders",
  "errorCode": "INVENTORY_SHORTAGE"
}

Building a ProblemDetail Programmatically

Spring's ProblemDetail is a simple value object. Use the static factory forStatus() or forStatusAndDetail(), then enrich it with setters.

You can attach custom members via setProperty(name, value). This object serializes directly to application/problem+json.

ProblemDetail problem = ProblemDetail.forStatusAndDetail(
        HttpStatus.NOT_FOUND,
        "Product 42 was not found");
problem.setTitle("Product Not Found");
problem.setType(URI.create("https://api.shop.com/problems/not-found"));
problem.setInstance(URI.create("/api/products/42"));
problem.setProperty("errorCode", "PRODUCT_NOT_FOUND");

Returning ProblemDetail from a Controller

A controller method can return a ProblemDetail directly, or wrap it in a ResponseEntity for full control of headers. Spring sets the status from the ProblemDetail and serializes the body as problem+json.

@GetMapping("/products/{id}")
public ResponseEntity<ProblemDetail> getProduct(@PathVariable Long id) {
    return productRepo.findById(id)
        .map(p -> ResponseEntity.ok().<ProblemDetail>build())
        .orElseGet(() -> {
            ProblemDetail pd = ProblemDetail.forStatusAndDetail(
                HttpStatus.NOT_FOUND, "No product with id " + id);
            pd.setTitle("Product Not Found");
            return ResponseEntity.status(404).body(pd);
        });
}

The ErrorResponse Contract

Returning ProblemDetail manually works, but Spring prefers exceptions to carry their own problem detail. The ErrorResponse interface couples an HTTP status, headers, and a ProblemDetail body.

Spring MVC automatically renders any thrown exception that implements ErrorResponse as problem+json. The convenience class ErrorResponseException is a ready-made implementation you can throw directly.

ProblemDetail pd = ProblemDetail.forStatusAndDetail(
        HttpStatus.CONFLICT, "Email already registered");
pd.setTitle("Duplicate Email");
pd.setProperty("errorCode", "DUPLICATE_EMAIL");

throw new ErrorResponseException(HttpStatus.CONFLICT, pd, null);

Custom Exceptions Implementing ErrorResponse

For domain errors, implement ErrorResponse on your own exception. By extending ErrorResponseException, you inherit status, headers, and body handling, and just supply a configured ProblemDetail.

This keeps error definitions next to the domain logic and out of controllers.

public class OutOfStockException extends ErrorResponseException {

    public OutOfStockException(long productId, int available, int requested) {
        super(HttpStatus.CONFLICT, asProblemDetail(productId, available, requested), null);
    }

    private static ProblemDetail asProblemDetail(long id, int avail, int req) {
        ProblemDetail pd = ProblemDetail.forStatusAndDetail(
            HttpStatus.CONFLICT,
            "Product " + id + " has only " + avail + " left, but " + req + " requested.");
        pd.setType(URI.create("https://api.shop.com/problems/out-of-stock"));
        pd.setTitle("Out of Stock");
        pd.setProperty("errorCode", "INVENTORY_SHORTAGE");
        return pd;
    }
}

Centralizing with @ControllerAdvice

The cleanest pattern: throw plain domain exceptions, then convert them to ProblemDetail in one place using @RestControllerAdvice and @ExceptionHandler.

The handler returns a ProblemDetail; Spring applies the status and problem+json content type automatically.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ProductNotFoundException.class)
    public ProblemDetail handleNotFound(ProductNotFoundException ex) {
        ProblemDetail pd = ProblemDetail.forStatusAndDetail(
            HttpStatus.NOT_FOUND, ex.getMessage());
        pd.setTitle("Product Not Found");
        pd.setType(URI.create("https://api.shop.com/problems/not-found"));
        pd.setProperty("errorCode", "PRODUCT_NOT_FOUND");
        return pd;
    }
}

Extending ResponseEntityExceptionHandler

Spring's built-in exceptions (validation failures, unreadable bodies, missing parameters) are handled by ResponseEntityExceptionHandler. Since Spring Boot 3, these already produce ProblemDetail bodies.

Extend it in your advice to override or enrich the defaults while keeping framework error handling consistent.

@RestControllerAdvice
public class ApiExceptionHandler extends ResponseEntityExceptionHandler {

    @Override
    protected ResponseEntity<Object> handleMethodArgumentNotValid(
            MethodArgumentNotValidException ex, HttpHeaders headers,
            HttpStatusCode status, WebRequest request) {

        ProblemDetail pd = ex.getBody();
        pd.setTitle("Validation Failed");
        pd.setProperty("errorCode", "VALIDATION_ERROR");
        return handleExceptionInternal(ex, pd, headers, status, request);
    }
}

Adding Standard Extension Properties

Common extensions include a timestamp and a traceId for log correlation. Add them in one place so every error carries them.

Use setProperty with serializable values; Instant serializes to an ISO-8601 string by default.

ProblemDetail pd = ProblemDetail.forStatusAndDetail(
        HttpStatus.BAD_REQUEST, "Quantity must be positive");
pd.setTitle("Invalid Quantity");
pd.setProperty("timestamp", Instant.now());
pd.setProperty("traceId", MDC.get("traceId"));
pd.setProperty("errorCode", "INVALID_QUANTITY");

Configuring Defaults in application.yml

Spring can include extra context automatically. Enabling these properties makes the framework attach standard details without code changes.

  • spring.mvc.problemdetails.enabled=true turns on problem+json for built-in exceptions (default in Boot 3+)
  • server.error.include-message and include-binding-errors control how much detail is exposed

Keep sensitive details out of production responses by tuning these flags.

spring:
  mvc:
    problemdetails:
      enabled: true
server:
  error:
    include-message: on_param
    include-binding-errors: on_param
    include-stacktrace: never

Quick Check: Choosing the Right Pattern

You have several domain exceptions (not-found, conflict, forbidden) and want every error across all controllers to emit consistent application/problem+json with shared extensions like traceId. What is the recommended Spring approach?

対話的なレッスンで答える

Recap: RFC 7807 in Spring Boot

You learned how to standardize error payloads with RFC 7807:

  • ProblemDetail is the value object for application/problem+json, with type, title, status, detail, instance plus custom properties.
  • ErrorResponse / ErrorResponseException let exceptions carry their own problem detail.
  • @RestControllerAdvice centralizes conversion of domain exceptions into ProblemDetail.
  • ResponseEntityExceptionHandler already renders Spring's built-in exceptions as problem+json, and can be extended.
  • Add extensions like errorCode, timestamp, and traceId, and tune exposure via application.yml.

The result: a single, predictable, machine-readable error contract across your whole API.

無料で開始

AI チューターと学ぶ Java — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース
21
レッスン
84
無料で学習を始めるコース全体を表示

よくある質問

「RFC 7807 Problem Detailレスポンス」レッスンは無料ですか？

はい。「RFC 7807 Problem Detailレスポンス」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Spring Boot 4 Complete Guideコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Spring Boot 4 Complete Guideコースには全4レッスンが含まれています。

「RFC 7807 Problem Detailレスポンス」で何を学びますか？

SpringのProblemDetailとErrorResponseサポートを使い、機械可読なエラーペイロードを標準化します。 ブラウザで直接実行するハンズオンコードでSpring Boot 4 Complete Guideを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Spring Boot 4 Complete Guideを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSpring Boot 4 Complete Guideは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「RFC 7807 Problem Detailレスポンス」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSpring Boot 4 Complete Guideレッスンでコードを書いて実行できますか？

はい。すべてのSpring Boot 4 Complete Guideレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. Bean Validation制約と制約グループ
  2. カスタム制約アノテーションの構築
  3. @ControllerAdviceによるグローバル例外処理
  4. RFC 7807 Problem Detailレスポンス
← Spring Boot 4 Complete Guideに戻る