Anatomy Of Http Requests And Responses

The last post got you a real, open connection to the actual server behind a URL. Now you can finally write the letter.

HTTP, Hypertext Transfer Protocol, is just the agreed-upon format both sides use for that letter. It's a protocol in the same sense TCP and IP are: a rulebook two parties follow so a message written by one side means something predictable to the other.

The Anatomy of an HTTP Request

Every HTTP request has the same three parts, in the same order, whether it's your browser loading a page or your own code calling an API.

The start line comes first, and it's the envelope: which method this is, what resource on the server it's asking for, and which version of HTTP it's speaking.

Then come the headers, metadata about the request itself rather than its actual content: what browser sent it, what language the client prefers, what time it was sent, and dozens of other standard fields.

Finally, for requests that actually carry data, there's a body. A GET request has nothing to put there, you're only asking for something back. A request that submits an HTML form, on the other hand, carries that form's data in its body.

ExpandThe anatomy of an HTTP request and response: a start line, headers, and a body on both sides, the request asking for a resource and the response answering with a status and data.

The Four Verbs You'll Actually Use

The start line's method is one of a small handful of verbs, and each one tells the server what kind of action this request is:

• GET asks for data, without changing anything.
• POST sends new data to be created.
• PUT and PATCH both modify data that already exists.

An HTTP request isn't only for reading, it's the same mechanism for writing too. The target in that same start line, /countries/name/portugal here, tells the server exactly which resource this method should act on. Leave the target empty, just a bare /, and you're asking for the server's own root instead of anything specific underneath it.

Reading the Reply: the HTTP Response

Once the server has actually worked out what to do with your request, it writes back using the exact same three-part shape: a start line, headers, and a body.

The response's start line swaps the method and target for something more useful on the way back: an HTTP version, plus a status code and a short message.

That status code is the server telling you, in three digits, whether things went well. 200 means it worked. The one everyone already recognizes on sight, 404, means the resource you asked for doesn't exist, "not found." Both are just entries in the same status-code system, one of many the server can send back.

Response headers work the same way request headers do, metadata about the response itself: what kind of content is in the body, how long it is, and more. And the response body, when there is one, is usually the actual payload you were after: JSON data from an API, or the HTML of a page.

HTTPS Is the Same Letter, Sealed

HTTPS follows this exact same request/response shape. The only real difference is that everything is encrypted first, using protocols called TLS or SSL, so anyone intercepting the connection in between sees scrambled data instead of a readable letter. Once it's decrypted at the other end, it's the same start line, headers, and body as plain HTTP.

One API Call vs. Loading an Entire Page

Calling an API the way the last few posts did is one request and one response, start to finish. Loading an actual web page is a very different story.

The first response you get back for a page is just the raw HTML file. The browser then reads that HTML looking for everything else it references, CSS files, JavaScript files, images, fonts, and fires off a brand new request for each one individually. A page with a dozen linked files means a dozen more full request/response round trips, all using the exact same mechanics from this post and the last one.

Browsers do run a handful of these in parallel rather than one at a time, but only up to a limit, past a certain point more simultaneous connections just slows everything down instead of speeding it up. Only once every file the page depends on has actually arrived can the browser render the finished page from its HTML, CSS, and JavaScript.

The Essentials

1. An HTTP request has three parts: a start line (method, target, version), headers (metadata), and an optional body (actual data, for methods that send something).
2. The method says what kind of action this is: GET reads, POST creates, PUT/PATCH modify something that already exists.
3. An HTTP response has the same three-part shape, but its start line carries a status code instead of a method, 200 for success, 404 for a resource that doesn't exist.
4. HTTPS is identical to HTTP in structure, just encrypted with TLS/SSL so the contents can't be read in transit.
5. One API call is one request/response pair. Loading a full web page is many: one for the HTML, then a separate one for every CSS file, script, image, and font it references.