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 timecurl pulls a JSON response, HTTP is doing the work underneath. It has been the foundation 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. ForPOST /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 screwed up. 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 dedicatedstatus 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 (typicallyBearer ).
• 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 theHTTP headers reference for a complete list of headers Go REST 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 workhorse 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 Go REST is. SeeHTTP 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.