This format helps APIs explain errors clearly and consistently. It makes it easier for clients to understand what went wrong.
Problem Details (RFC 7807) format in Rest API
Start learning this pattern below
Jump into concepts and practice - no test required
{
"type": "string (URI)",
"title": "string",
"status": "integer (HTTP status code)",
"detail": "string",
"instance": "string (URI)",
"additional_fields": "optional extra info"
}type is a URI that identifies the error type. It should be a URL but does not have to be reachable.
title is a short, human-readable summary of the problem.
{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"status": 403,
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/transactions/abc"
}{
"type": "https://example.com/probs/invalid-input",
"title": "Invalid input.",
"status": 400,
"detail": "The 'email' field must be a valid email address.",
"instance": "/users/5678"
}This Flask app returns a Problem Details JSON response with HTTP status 403 and the correct content type when you visit /error.
from flask import Flask, jsonify app = Flask(__name__) @app.route('/error') def error(): problem = { "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "status": 403, "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/transactions/abc" } response = jsonify(problem) response.status_code = problem["status"] response.headers["Content-Type"] = "application/problem+json" return response if __name__ == '__main__': app.run(debug=True)
Always set the HTTP status code to match the status field in the problem details.
Use the Content-Type header value application/problem+json to indicate this format.
You can add extra fields if needed, but keep the standard fields for compatibility.
Problem Details format standardizes error responses in APIs.
It uses a JSON object with fields like type, title, status, detail, and instance.
This helps clients understand and handle errors better.
Practice
Solution
Step 1: Understand the role of Problem Details format
The format is designed to provide a consistent way to report errors in APIs.Step 2: Identify the main benefit
It helps clients understand and handle errors better by standardizing error responses.Final Answer:
To standardize error responses so clients can understand errors better -> Option BQuick Check:
Purpose = Standardize error responses [OK]
- Confusing error format with data encryption
- Thinking it speeds up API responses
- Assuming it formats successful responses
Solution
Step 1: Recall required fields in RFC 7807
The RFC requires the "type" field to identify the error type URI.Step 2: Check other fields
Fields like "status", "detail", and "instance" are optional but recommended.Final Answer:
type -> Option AQuick Check:
Required field = type [OK]
- Assuming 'status' is required
- Confusing 'detail' as mandatory
- Thinking 'instance' is always needed
{"type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "status": 403, "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc"}What is the HTTP status code indicated?
Solution
Step 1: Locate the status field in JSON
The JSON has "status": 403, which indicates the HTTP status code.Step 2: Understand the meaning of 403
403 means Forbidden, matching the error about insufficient credit.Final Answer:
403 -> Option AQuick Check:
Status code = 403 [OK]
- Confusing status with 'detail' content
- Picking 200 as success code
- Ignoring the numeric status field
{"title": "Invalid input", "status": 400, "detail": "Missing required field 'name'"}What is missing that violates RFC 7807 requirements?
Solution
Step 1: Check required fields in the JSON
The 'type' field is required by RFC 7807 but is missing here.Step 2: Validate other fields
'status' is correctly a number, 'detail' and 'title' are valid types.Final Answer:
The 'type' field is missing -> Option DQuick Check:
Missing required field = type [OK]
- Thinking 'status' must be string
- Removing 'detail' field
- Assuming 'title' must be URL
Solution
Step 1: Check required fields and correct types
{"type": "https://example.com/probs/rate-limit", "title": "Rate limit exceeded", "status": 429, "detail": "You have sent too many requests in a short time.", "instance": "/api/v1/resource"} includes 'type' as a URI, 'title', numeric 'status' 429, 'detail', and 'instance' fields correctly.Step 2: Validate status code and clarity
Status 429 means Too Many Requests, matching the error. Other options have missing or wrong fields or wrong status codes.Final Answer:
{"type": "https://example.com/probs/rate-limit", "title": "Rate limit exceeded", "status": 429, "detail": "You have sent too many requests in a short time.", "instance": "/api/v1/resource"} -> Option CQuick Check:
Correct fields and status = {"type": "https://example.com/probs/rate-limit", "title": "Rate limit exceeded", "status": 429, "detail": "You have sent too many requests in a short time.", "instance": "/api/v1/resource"} [OK]
- Using string instead of number for status
- Missing 'type' or using non-URI string
- Wrong HTTP status code for error
