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
{
"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
Ready to prove it?
Pass the test and this pattern moves unknown
