HTTP, HTTPS & Request Methods

Scenario

You type an address into your browser, hit Enter, and instantly see a web page. Behind the scenes, your browser and a server are speaking a highly structured language to trade documents.

How exactly does the browser ask for data versus submit it securely?

Mental model

HTTP is a restaurant menu, and methods are your instructions to the waiter.

Just as you can ask a waiter to fetch a dish (GET), add a new dish to your order (POST), or replace a dish (PUT), HTTP methods tell the web server exactly what you want to do with a resource.

Explanation

HyperText Transfer Protocol (HTTP) is the foundational language of the World Wide Web. It is a 'stateless' protocol operating at the Application Layer (Layer 7). Think of it as a set of rules for how browsers (clients) ask for information and how servers return that information. When you request a webpage, your browser sends an HTTP request message containing a URL, a specific method, and headers (metadata like your browser type). The server processes this and replies with an HTTP response containing a status code (like 200 OK or 404 Not Found) and the requested payload.

The core of HTTP revolves around its methods, which are verbs indicating the desired action. The most common is **GET**, used exclusively to fetch data without modifying anything on the server. When you submit a form or upload a file, you use **POST**, which sends data to the server to create a new resource. If you want to update an existing resource completely, you use **PUT**, whereas **PATCH** is used for partial updates. Finally, **DELETE** instructs the server to remove a resource. These methods map cleanly to the CRUD operations (Create, Read, Update, Delete) used in databases.

HTTP was originally designed to transmit data in plain text. This meant anyone sitting between your computer and the server—like a hacker on public Wi-Fi—could intercept and read your passwords or credit card numbers. To fix this, HTTPS (HTTP Secure) was introduced. HTTPS is exactly the same protocol as HTTP, but wrapped inside a secure, encrypted tunnel called TLS (Transport Layer Security).

When using HTTPS, before any actual data is exchanged, the client and server perform a 'handshake' to establish encrypted communication. The server provides a digital certificate proving its identity, preventing attackers from impersonating the website. Once the secure connection is established, standard HTTP requests and responses are sent back and forth, but they look like gibberish to anyone trying to eavesdrop.

Understanding HTTP and its methods is crucial for building and interacting with RESTful APIs, which rely heavily on these standard verbs to manipulate data predictably. Knowing the difference between HTTP and HTTPS is equally vital, as modern browsers penalise non-secure HTTP sites, and secure data transmission is an absolute baseline requirement for any application.

Key points

• GET: Retrieves data from the server. It should be safe and 'idempotent'—calling it multiple times has the same effect as calling it once.
• POST: Sends data to the server to create a new resource. It is not idempotent (calling it twice creates two resources).
• PUT: Replaces an entire resource with the uploaded content. It is idempotent.
• PATCH: Applies partial modifications to a resource.
• DELETE: Removes the specified resource from the server.
• HTTPS: HTTP over TLS/SSL. Provides encryption (privacy), data integrity, and authentication.

Common mistakes

• Confusing PUT and POST: Many confuse these two. Remember: POST is for creating a *new* resource, while PUT is for *replacing* a specific existing resource. PUT is idempotent; POST is not.
• Assuming GET requests are completely safe: While GET shouldn't change data according to HTTP standards, a poorly written backend might alter a database on a GET request. This is a bad practice and violates REST principles.

Glossary

stateless

A design where a system treats every single request as completely new and independent, refusing to remember anything about previous interactions.

Application Layer

The top layer of network communication where human-facing software programs, like web browsers and email clients, actually operate.

HTTP request message

A properly formatted message sent from your browser to a web server asking it to perform an action, like fetching a webpage or saving a form.

Recall questions

• Which HTTP method should be used to completely replace an existing user profile?
• Why is POST considered non-idempotent?
• What is the primary difference between HTTP and HTTPS?

Questions & answers

Which of the following HTTP methods is NOT idempotent?

POST

Approach: Idempotent means calling the method multiple times has the same outcome as calling it once. GET, PUT, and DELETE are idempotent. POST is not, because multiple POST requests create multiple resources.

In an e-commerce application, which HTTP method is most appropriate for submitting credit card details during checkout?

POST over HTTPS

Approach: POST is used to send sensitive data to the server for processing (creating an order). It must be sent over HTTPS to encrypt the sensitive payload in transit.

Continue learning

Next: SSL/TLS & Firewalls

Return to Core CS Roadmap