What is HTTP?

HTTP is the protocol the web speaks. Every time your browser fetches a page, every time a mobile app calls an API, every time curl pulls a JSON response, HTTP is doing the work underneath. It has been the base of the web since Tim Berners-Lee published the first specification in 1991. The version numbers have changed (1.0, 1.1, 2, 3); the basic idea has not.

The basic idea

HTTP is a request/response protocol. The client sends a request to a server. The server sends back a response. That is it. Both sides hang up. The next request starts a fresh conversation.

This stateless property is critical. The server does not remember you between requests. If you need to be identified, you have to identify yourself on every call; hence cookies and bearer tokens. Statelessness is also why HTTP is easy to scale: any server can handle any request because there is no per-client memory to coordinate.

What a request looks like

An HTTP request has four parts: a method, a URL, headers, and (optionally) a body.

GET /public/v2/users HTTP/1.1
Host: gorest.co.in
Authorization: Bearer abc...123
Accept: application/json

Method: GET. Tells the server what to do.
URL: /public/v2/users. The thing being acted on.
Headers: Host, Authorization, Accept. Metadata.
Body: empty here. For POST / PUT / PATCH it carries the payload (typically JSON).

What a response looks like

HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Remaining: 29

[{"id":1,"name":"Avani"}]

Three parts: a status code (200), headers (Content-Type, X-RateLimit-Remaining), and a body (the JSON list). The status code is the most important number on the page; it tells your code at a glance whether the request succeeded.

Methods

The eight HTTP methods, in rough order of how often you will see them:

GET reads a resource. Should not change anything on the server.
POST creates a new resource (or triggers an action that does not fit the others).
PUT replaces a resource entirely.
PATCH partially updates a resource.
DELETE removes a resource.
HEAD is the same as GET but with no body in the response. Used to check if a resource exists.
OPTIONS asks what methods are supported. Used by browsers for CORS pre-flight.
CONNECT establishes a tunnel (for HTTPS proxies).

Most APIs use the first five and ignore the rest.

Status codes

Status codes are three digits in five buckets:

1xx (informational). Rare in practice. 100 Continue is the most you will see.
2xx (success). 200 OK, 201 Created, 204 No Content. Read the body (or do not, if 204).
3xx (redirect). 301 Moved Permanently, 304 Not Modified. The Location header tells you where to go.
4xx (client error). The request was wrong. 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity, 429 Too Many Requests.
5xx (server error). The server made a mistake. 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Branch on the bucket first, the specific code second. 4xx is your bug; 5xx is theirs. See the dedicated status codes guide for the full list with example bodies.

Headers

Headers carry metadata: who you are, what you accept, what you are sending. Common request headers:

Authorization carries your credentials (typically Bearer <token>).
Accept lists the formats you can read (application/json).
Content-Type declares the format of the body you are sending.
User-Agent identifies the client software.

Common response headers:

Content-Type declares the format of the response body.
Cache-Control says how long the client may cache.
Set-Cookie asks the client to store a cookie.
Location points where to go next on a 201 or 3xx.

See the HTTP headers reference for a complete list of headers GoRest sends and the standards they come from.

HTTP versions

HTTP/1.0. One connection per request. Slow.
HTTP/1.1. Keep-alive (multiple requests per connection), pipelining (rarely used). Still the main version on many servers.
HTTP/2. One connection, multiple streams in parallel. Binary framing. Header compression.
HTTP/3. HTTP/2 semantics over QUIC (UDP) instead of TCP. Faster on lossy networks.

The semantics (methods, status codes, headers) are the same across all versions; only the wire format changes. As an API consumer, you almost never need to care which version you are using; the client library and server negotiate it.

HTTP vs HTTPS

HTTPS is HTTP wrapped in TLS: encrypted, authenticated, and tamper-evident. Modern browsers refuse plain HTTP for almost everything. Public APIs should be HTTPS-only, and GoRest is. See HTTP vs HTTPS for the differences in detail.

The smallest useful HTTP knowledge

If you remember three things about HTTP, make them: every request has a method and URL, every response has a status code, and metadata travels in headers. That alone gets you through 90% of API work.