Problem Details and error contracts

Return understandable, safe errors.

UnderstandStudy an examplePractise

Understand the concept

Problem Details is a standard error representation. type identifies the problem kind, title is short, status matches HTTP, detail provides a safe occurrence-specific explanation, and instance can identify the occurrence. Extensions can carry validation or correlation fields.

Keep HTTP and body status consistent. Do not expose traces, SQL or secrets. Correlate public identifiers with protected server logs.

Clients should use stable type/code contracts rather than matching English title text. Distinguish actionable validation and access failures within the security boundary. A central exception pipeline can produce consistent errors; this course illustrates the design without changing existing middleware.

WHEN TO USE IT

Connect frontend handling with backend observability.

COMMON PITFALL

Returning a stack trace as public error detail.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

Content-Type: application/problem+json

Problem representation media type.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Should client logic depend on an exact English title?

Show the solution and explanation

Worked solution

Stable type/code → localised message

No; separate stable identifiers from localised copy.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.