RFC 7807 Quiz

**Explanation:** **Terms:** media type, Problem Details **Correct (B):** The specification defines a dedicated media type to signal the semantics of the payload **Options:** - A (incorrect): It can work but does not convey the Problem Details semantics - B (correct): Standard for JSON problem details - C (incorrect): Not defined **Related:** There is also application/problem+xml for XML

**Explanation:** **Terms:** members, extensibility **Correct (A,B,C,D,E):** These are the defined standard members **Options:** - F (incorrect): Not a standard member, and is often unsafe to expose **Related:** You can add extension members, but keep them stable and documented

**Explanation:** **Terms:** URI reference, problem type **Correct (C):** type is an identifier, often a documentation URL or about:blank **Options:** - A (incorrect): status is the HTTP status code - B (incorrect): host is not the meaning of type - C (correct): This enables stable categorization of errors **Related:** about:blank means the problem type is implied by the HTTP status

**Explanation:** **Terms:** status member **Correct (A):** It is a convenience for clients, not a separate status channel **Options:** - A (correct): Keep it consistent with the HTTP status line - B (incorrect): status is numeric in the standard members - C (incorrect): Problem details is for error conditions, not success **Related:** If intermediaries rewrite status codes, be careful about consistency

**Explanation:** **Correct:** title **Related:** detail is for a longer explanation specific to this occurrence

**Explanation:** **Terms:** interoperability, client UX **Correct (B):** A predictable schema reduces boilerplate and improves observability **Options:** - A (incorrect): Not related - B (correct): This is the main benefit - C (incorrect): It does not prevent errors **Related:** Avoid leaking sensitive internal details in detail and extensions