HTTP Fundamentals
HTTP is the application protocol that clients and servers use to exchange requests and responses for resources. It gives browsers, APIs, proxies, and other systems a shared set of methods, fields, status codes, and message semantics.
itNetworking | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
HTTP Fundamentals
HTTP is a family of stateless, application-level request and response protocols. A client sends a request about a resource. A server returns a response that reports the outcome and can carry a representation of that resource.
That small pattern supports web pages, APIs, file transfers, media delivery, and communication between services. The same semantics also let browsers, command-line clients, origin servers, proxies, gateways, and caches cooperate.
HTTP gives these systems a uniform interface. The client does not need to know how the server stores or computes a resource. The server does not need to know why the client wants it. Both sides agree on a request method, a target, fields, content, and a response status.
Start with resources and representations
A resource is the target of a request. A resource can represent a document, an image, a customer record, a search operation, or something else a server exposes. Its Uniform Resource Identifier, or URI, identifies it.
A resource is not the bytes sent across the network. A representation is information that reflects the current or intended state of a resource. One resource might have an HTML representation for a browser and a JSON representation for a program.
HTTP separates resource identification from request semantics. The URI identifies the target. The request method states what the client intends to do with that target.
One exchange has two messages
An HTTP request communicates the client's intent. Its main parts are:
- a method, such as
GETorPOST; - a target URI;
- fields that carry metadata or modify the request;
- optional content.
An HTTP response communicates the result. Its main parts are:
- a status code;
- fields that describe the response or its content;
- optional content.
In HTTP/1.1, you can see this structure as text:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.rfc-editor.org/rfc/rfc9110.html
Supports
- HTTP as a stateless application-level request and response protocol
- Resources, representations, clients, servers, messages, intermediaries, and origins
- URI schemes, HTTPS connection requirements, methods, method properties, fields, content, and content negotiation
- Status classes and individual status-code semantics
- Conditional requests, entity tags, authentication challenges, and shared semantics across HTTP versions
- https://www.rfc-editor.org/rfc/rfc9111.html
Supports
- HTTP cache storage, freshness, validation, and response reuse
- Cache-Control directives and shared versus private cache behavior
- Conditional validation and handling of 304 Not Modified
- https://www.rfc-editor.org/rfc/rfc9112.html
Supports
- HTTP/1.1 textual message syntax, request lines, status lines, fields, framing, and connection management
- Host routing requirements and message-body determination
- HTTP/1.1 security and interoperability boundaries
- https://www.rfc-editor.org/rfc/rfc9113.html
Supports
- HTTP/2 binary framing, streams, multiplexing, and field compression
- Mapping shared HTTP request and response semantics onto HTTP/2
- Per-hop protocol behavior through intermediaries
- https://www.rfc-editor.org/rfc/rfc9114.html
Supports
- Mapping HTTP semantics onto QUIC
- HTTP/3 request streams, control streams, and field sections
- Independent stream behavior and version boundaries
- https://www.rfc-editor.org/rfc/rfc8446.html
Supports
- TLS confidentiality, integrity, and endpoint authentication goals
- The security boundary between protected transport and application authorization
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
Supports
- Learner-oriented diagrams and examples of requests, responses, clients, servers, and proxies
- Browser-facing HTTP message anatomy and common web uses
- Scope and progression stated in the MDN reference-link rationale
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference
Supports
- Indexed reference sections for methods, status codes, fields, caching, media types, and security
- Scope and progression stated in the MDN reference-link rationale
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the curated Awesome REST list from the canonical awesome-list index
- https://github.com/marmelab/awesome-rest
Supports
- Curated discovery of HTTPie, httpbin, mitmproxy, and Mockoon as relevant HTTP and REST testing tools
- Categories covering request querying, mocking, and debugging proxies
- https://httpie.io/docs/cli
Supports
- HTTPie as a command-line HTTP client for testing, debugging, and interacting with HTTP servers
- Arbitrary requests, readable output, JSON, authentication, fields, sessions, uploads, and downloads
- HTTPie Awesome Links rationale
- https://httpbin.org/
Supports
- httpbin as an HTTP request and response service
- Endpoints for methods, authentication, status codes, request and response inspection, cookies, redirects, and formats
- httpbin Awesome Links rationale
- https://docs.mitmproxy.org/stable/
Supports
- mitmproxy as an interactive intercepting proxy for HTTP and HTTPS traffic
- Inspection, modification, saving, replay, and multiple user interfaces
- mitmproxy Awesome Links rationale
- https://mockoon.com/docs/latest/
Supports
- Mockoon support for configurable mock HTTP routes
- Response status, fields, content, rules, local applications, command-line use, and serverless use
- Mockoon Awesome Links rationale
