From a URL to a response
What HTTP does
Understand the simple request and response convention that lets browsers, servers, command-line tools, and APIs communicate.
HTTP is the language clients and servers use to exchange messages on the Web.
A client sends a request. A server handles it and sends a response.
client -- request --> server
client <-- response -- server
Your browser is an HTTP client, but it is not the only one. curl, mobile apps, search-engine crawlers, and backend services all speak HTTP too. When I debug an API, I often reach for curl before opening a browser. Same protocol, different tool.
HTTP does not decide how a server builds its response. The server might read a file from disk, query a database, call another API, or compute a value on the fly. HTTP only defines the message format both sides agree on.
That separation matters. You can swap the browser, rewrite the server in another language, or move the database, and the basic request/response cycle stays the same.
Let’s see a real exchange. Run this in your terminal:
curl -i https://flaviocopes.com/
You get back a block of headers, then HTML. The first line is the status line (HTTP/2 200 or similar). Below that come response headers like content-type. After a blank line, the body starts. That whole package is one HTTP response to the GET request curl sent.
Notice you did not need a browser. Any HTTP client that can open a connection and format a request gets the same kind of answer back.
Try this on your own project: pick any public URL you control and run curl -i against it. Read the status line first, then scan the headers. That habit makes every later lesson in this course easier to follow.
Lesson completed