T
http rfc9110 rest web-architecture standards

HTTP Semantics Explained: Master RFC 9110 for Modern Web Dev

Understand the core of the web. A guide to RFC 9110, covering HTTP methods, status codes, and header semantics in the modern era.

2026-04-11

HTTP Semantics Explained: Master RFC 9110 for Modern Web Dev

In 2022, the IETF published RFC 9110, a monumental document that obsoleted several older RFCs (like RFC 7231) to become the definitive authority on HTTP Semantics. While HTTP/2 and HTTP/3 changed how data is framed and transported, the semantics—the meaning of methods, status codes, and headers—remain the foundation of the web.

What is RFC 9110 (HTTP Semantics)?

RFC 9110 defines the common architecture of the Hypertext Transfer Protocol (HTTP). It is independent of the protocol version (HTTP/1.1, HTTP/2, or HTTP/3). If you want to know what a 403 Forbidden really means or how a POST request should behave compared to a PUT, RFC 9110 is the source of truth.

It provides a consistent vocabulary for:

  • Resources and Uniform Resource Identifiers (URIs).
  • Messages (Requests and Responses).
  • Methods (GET, POST, etc.).
  • Status Codes (200, 404, etc.).
  • Header Fields.

Core Principles of HTTP Semantics

1. Request Methods and Idempotency

One of the most important concepts in RFC 9110 is the distinction between Safe and Idempotent methods.

Method Safe Idempotent Description
GET Yes Yes Retrieves data without side effects.
HEAD Yes Yes Same as GET but returns no body.
PUT No Yes Replaces a resource; repeating it has no further effect.
DELETE No Yes Removes a resource.
POST No No Processes data; multiple requests may create multiple resources.

2. Status Code Classes

RFC 9110 organizes status codes into five classes:

  • 1xx (Informational): Request received, continuing process.
  • 2xx (Successful): The action was successfully received, understood, and accepted.
  • 3xx (Redirection): Further action needs to be taken to complete the request.
  • 4xx (Client Error): The request contains bad syntax or cannot be fulfilled.
  • 5xx (Server Error): The server failed to fulfill an apparently valid request.

Practical Application Scenarios

Designing RESTful APIs

Following RFC 9110 ensures your API is "discoverable" and behaves as expected by standard HTTP clients and caches. For example, using 201 Created after a successful POST instead of a generic 200 OK.

Cache Optimization

RFC 9110 defines how Vary, ETag, and Last-Modified headers work. Correct implementation allows CDNs and browsers to cache data efficiently, reducing server load.

Content Negotiation

The protocol allows a client to request a specific format (e.g., Accept: application/json) and the server to respond with the best available representation.

Comparison: RFC 7231 vs. RFC 9110

RFC 9110 didn't fundamentally change how HTTP works, but it improved the documentation significantly:

  • Consolidation: It merged semantics from multiple documents into one.
  • Clarity: It clarified ambiguous points regarding partial content (Range requests) and authentication.
  • Versioning: It explicitly separates the "what" (Semantics) from the "how" (HTTP/1.1 vs HTTP/3).

FAQ

Q: Is RFC 9110 only for HTTP/1.1?
A: No. RFC 9110 defines the semantics that apply to all versions of HTTP, including HTTP/2 and HTTP/3.

Q: What is the difference between POST and PUT?
A: According to RFC 9110, PUT is idempotent (replaces the resource at a specific URI), while POST is not (it submits data to be processed by the resource).

Q: When should I use a 403 vs. a 401?
A: Use 401 Unauthorized when authentication is required and has failed or hasn't been provided. Use 403 Forbidden when the server understands the request but refuses to authorize it (even with valid credentials).

Related Tools

  • JSON Formatter - Perfect for inspecting JSON responses from your HTTP APIs.
  • URL Encoder/Decoder - Essential for preparing valid URIs according to HTTP standards.
  • JWT Decoder - Decode tokens often carried in the Authorization header.
Back to Blog