5 intermediate exercises — use RFC 2119 keywords correctly in API specifications, security requirements, coding standards, and system design documents.
MUST NOT / SHALL NOT — absolute prohibition; this behaviour is forbidden
SHOULD / RECOMMENDED — strong recommendation; valid exceptions exist but must be weighed carefully
SHOULD NOT / NOT RECOMMENDED — strong discouragement; valid reasons to permit it may exist
MAY / OPTIONAL — truly optional; implementations may include or omit with no conformance impact
Enforcement test: If ignoring this causes a 4xx/5xx error → MUST. If it's best practice → SHOULD. If there's no enforcement → MAY.
0 / 5 completed
1 / 5
An API specification states: "All requests to the /payments endpoint _____ include an Authorization header. Requests without a valid token will be rejected with a 401 Unauthorized response." Which RFC 2119 keyword correctly signals an absolute requirement?
MUST (equivalents: REQUIRED, SHALL) is the RFC 2119 keyword for an absolute requirement. If a conforming implementation does not satisfy a MUST requirement, it is non-compliant. The sentence confirms this: the second sentence describes the consequence of not sending the header ("will be rejected"), which is consistent with a MUST. RFC 2119 keyword hierarchy: MUST → no exceptions; SHOULD → strong recommendation, valid exceptions exist; MAY → optional feature. The keyword MUST NOT prohibits something absolutely. Example from the real world (RFC 9110, HTTP Semantics): "A client MUST send a Host header field in all HTTP/1.1 request messages." Practical tip: when writing API specs, use MUST only for things you will actually enforce with a 4xx or 5xx error — not for best practices.
2 / 5
A coding standards document reads: "Service handlers _____ log unhandled exceptions to the centralised logging platform. Developers may choose to also log to local files during development, but this is not required." Which RFC 2119 keyword signals a strong recommendation with valid exceptions?
SHOULD (equivalent: RECOMMENDED) signals a strong recommendation: there may be valid reasons to ignore it in particular circumstances, but the full implications must be understood before choosing a different approach. The sentence hints at this with "developers may choose to also log to local files during development" — the core expectation is centralised logging, but there's acknowledged flexibility. When to use SHOULD vs. MUST in coding standards: use MUST for security controls, API contracts, and legal/compliance items; use SHOULD for best practices, architectural guidance, and performance recommendations. RFC 2119 exact wording: "SHOULD: This word… means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Also: SHOULD NOT = strong discouragement but not absolute prohibition.
3 / 5
A system requirements document states: "The API client _____ include a User-Agent header in requests to aid in debugging and traffic analysis. This header is not validated by the server." Which RFC 2119 keyword signals an optional feature?
MAY (equivalents: OPTIONAL) signals that the item is genuinely optional — an implementation may or may not include this feature and remain fully conformant. The sentence confirms this: "This header is not validated by the server" means there is no enforcement and no consequence for omitting it. RFC 2119 exact wording: "MAY: This word… means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item." Common mistakes: using SHOULD when you mean MAY (overstating the recommendation) or MUST when you mean SHOULD (creating false absolutes that are then routinely ignored, undermining the spec's credibility). Synonyms in specs: "is OPTIONAL", "is permitted", "is allowed", "clients are free to include".
4 / 5
An API security spec reads: "Tokens _____ be transmitted in URL query parameters. They MUST only be sent in the Authorization header or as an HttpOnly cookie to prevent exposure in server logs and browser history." Which RFC 2119 keyword creates an absolute prohibition?
MUST NOT (equivalent: SHALL NOT) is the RFC 2119 keyword for an absolute prohibition — the specification forbids this behaviour entirely. Any compliant implementation that transmits tokens in URL parameters violates the specification. The context confirms this: the next sentence ("They MUST only be sent in…") pairs the prohibition with a mandatory alternative, which is the classic security spec pattern. Why not SHOULD NOT? SHOULD NOT means the behaviour is strongly discouraged but may be acceptable in specific circumstances — far too weak for a security control where the risk (token exposure in logs, referrer headers, browser history) is high and unambiguous. In OAuth 2.0 (RFC 6749), you will find exactly this prohibition: "Clients MUST NOT use the query parameter for access tokens." When writing security specs, always escalate SHOULD NOT to MUST NOT for controls that prevent known attack vectors.
5 / 5
A REST API style guide reads: "Endpoints _____ support both JSON and XML response formats. However, JSON _____ be the default content type returned when no Accept header is specified." Which combination of RFC 2119 keywords is correct?
The correct combination is MAY… SHOULD. Breaking down the logic: (1) Supporting both JSON and XML is optional — not every endpoint needs to offer XML. MAY is correct: "implementations are permitted to support both formats but are not required to." (2) When a client sends no Accept header, returning JSON is a strong best practice (it's what API consumers expect), but it's not an absolute requirement that would break conformance. SHOULD is correct: "the default SHOULD be JSON — there may be valid reasons to default to another format in specific contexts." This two-keyword pattern is common in style guides: the optional feature (MAY) paired with a recommended default behaviour (SHOULD). Compare with a stricter alternative: "Endpoints MUST accept both formats. JSON MUST be the default." — this would be appropriate if the API contract explicitly guarantees content negotiation support. Always pair your keywords with the enforcement mechanism: MUST → server enforces (4xx); SHOULD → documented best practice; MAY → no enforcement.