HTTP
HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system.
The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols that share a generic interface, extensible semantics, and self-descriptive messages to enable flexible interaction with network-based hypertext information systems.
HTTP provides a uniform interface for interacting with a resource by sending messages that manipulate or transfer representations. Each message is either a request or a response.
A client constructs request messages that communicate its intentions and routes those to an identified origin server. A server listens for requests, parses each message received, interprets the message and responds to that request with one or more responses messages. The client examines received responses to see if its intentions were carried out, determining what to do next based on the status codes and content received. The interoperability between senders and recipients depends on shared expectations.
Resources
The target of an HTTP request is called a “resource”. HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Most resources are identified by a Uniform Resource Identifier (URI).
Representations
A “representation” is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol. A representation consists of a set of representation metadata and a potentially unbounded stream of representation data.
HTTP allows “information hiding” behind its uniform interface by defining communication with respect to a transferable representation of the resource state, rather than transferring the resource itself. This allows the resource identified by a URI to be anything, including temporal functions like “the current weather in Laguna Beach”, while potentially providing information that represents that resource at the time a message is generated.
Communication
HTTP is a client/server protocol that operates over a reliable transport- or session-layer “connection”.
An HTTP “client” is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP “server” is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
The terms client and server refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others.
HTTP is a stateless request/response protocol for exchanging “messages” across a connection. A Client sends requests to a server in the form of a “request” that might also contain header fields. A Server responds to a client’s request by sending one or more “response” messages, each including a status code. The response might also include header fields for server information.
Methods
The request method token is the primary source of request semantics. It indicates the purpose for which the client has made this request and what is expected by the client as a successful result.
| Method Name | Description |
|---|---|
| GET | Transfer a current representation of the target resource. |
| HEAD | Same as GET, but do not transfer the response content. |
| POST | Perform resource-specific processing on the request content. |
| PUT | Replace all current representations of the target resource with the request content. |
| DELETE | Remove all current representations of the target resource. |
| CONNECT | Establish a tunnel to the server identified by the target resource. |
| OPTIONS | Describe the communication options for the target resource. |
| TRACE | Perform a message loop-back test along the path to the target resource. |
All general-purpose servers must support the methods GET and HEAD. All other methods are optional.
GET, HEAD, OPTIONS and TRACE are defined to be safe methods because they are read-only, so the client does not request, and does not expect, any state change on the origin server as result.
PUT, DELETE and safe methods are considered idempotent, It means that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ. A client SHOULD NOT automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.
Status Codes
The status code of a response is a three-digit integer code that describes the result of the request and the semantics of the response, including whether the request and the semantics of the response, including whether the request was successful and what content is enclosed.
The first digit of the status code defines the class of response. The last two do not have any categorization role. There are five values for the first digit:
- 1xx (Informational): The request was received, continuing process
- 2xx (Successful): The request was successfully received, understood and accepted
- 3xx (Redirection): Further action needs to be taken in order 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
[!info] HTTP status codes are extensible. A client is not required to understand the meaning of all registered status codes, though such understanding is obviously desirable.
Consider reading at least section-9.3 and section-15 to understand more about methods and status code.
Cache
A “cache” is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A response is “cacheable” if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request.