GET Request

When you open a website, your browser sends a short message to the computer on which the page is stored. This message essentially says: Please send me this content. That is exactly what a GET request is. The word GET is English and means “fetch” or “get.” The addressed computer, the server, then responds with the desired content: a text, an image, a price list. The underlying basic rule is important here: a GET request should only read and change nothing.

Why fetching stays separate from changing

On the web there are several kinds of requests. Besides GET, there is, for example, POST, which is used to send data to the server, such as a filled-out form. This separation is not a mere formality. It determines which requests can be repeated safely.

A GET request is considered safe to repeat. If you reload a page ten times, nothing bad happens. It would be different with an order: ten clicks must not trigger ten packages. That’s why orders, payments, and password changes are never placed behind a GET request.

The separation has a second benefit. Because GET requests only read, their responses may be cached. An image that never changes doesn’t need to be transferred anew with every visit. This is exactly what the speed of the internet relies on.

What such a request actually contains

A GET request is plain text and surprisingly short. The first line states the method, i.e. GET, and the path to the requested resource. Below that are so-called headers, i.e. additional information. These state, for instance, which server is addressed, which browser is asking, and which language is preferred.

Unlike POST, a GET request has no body of its own. Everything the server needs to know is contained in the address. Additional information is therefore appended to the end of the address, separated by a question mark. In the address of a search results page, the search term is often visibly right there.

The server responds with a status code and the data. The code 200 means: everything is fine, here is the content. The well-known code 404 means: this path does not exist. A common misconception, by the way, is that data in the address is therefore secret. The opposite is true: it ends up in the browser’s history and in the server’s logs. Passwords therefore never belong in a GET request.

From page loads to AI interfaces

You trigger hundreds of GET requests every day without noticing. Every page load, every image that loads afterward, and every embedded video is one. If a page loads slowly, it’s often because the browser has to process a great many individual requests.

It gets more interesting with interfaces, known in technical jargon as APIs. These are access points through which programs fetch data from other programs. A weather app fetches the forecast via a GET request. A financial website fetches prices the same way. Anyone trying out such interfaces can simply type a GET request into the browser’s address bar.

You also encounter this principle in AI applications. When a chatbot looks something up online, it fetches pages via GET request. So-called crawlers, i.e. programs that automatically collect web pages, work the same way. In the news, the term therefore often comes up in the dispute over training data: when millions of automated requests hit a server, this costs the operators real money.