| Level Navigation: 1 | 2 | 3 | (4ℹ️) | (5ℹ️) | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14⚡ | 15⚡ | (16ℹ️) | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26⚡ | 27⚡ | 28⚡ | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39⚡ | 40⚡ |
At the core sits the web server: a program that listens for incoming HTTP requests, processes them, and sends back responses. Requests are structured messages that include a verb (like GET or POST), a path, headers, and optionally a body 1. The server examines those pieces, decides what work to perform, and then constructs a response containing a status line, headers, and a body.
Status codes communicate the outcome of each request—200 means “OK”, 201 indicates a resource was created, 400 flags invalid input, and 500 signals something went wrong on the server. Matching the right status to each scenario helps clients understand what happened without reading the full payload, and resources like http.cat make the full catalog easy (and fun) to scan.
The response body can take many forms, but two you’ll use often are HTML and JSON. HTML (text/html) is perfect for returning full web pages that a browser can render. JSON (application/json) shines when you want to send structured data to another program or frontend. These formats are part of the broader MIME (Multipurpose Internet Mail Extensions) type system, which labels response payloads so clients know how to parse them 2. Choosing the correct MIME type—communicated through the Content-Type header—is critical for interoperability as your API evolves.