HTTP and HTTPS

Analogy categoryAnalogies

Introduction

HTTP (HyperText Transfer Protocol) is the application layer protocol that powers the web: it defines how browsers and other clients request resources from servers, and how servers respond. HTTPS is HTTP layered on top of TLS (Transport Layer Security), adding encryption and server authentication so that data exchanged between client and server cannot be easily eavesdropped on or tampered with in transit.

🏏

Cricket analogy: HTTP is like a batsman calling for a run and the non-striker responding, a basic request-response exchange, while HTTPS is that same call wrapped in a trusted third umpire's review (TLS) so no one can fake the call or eavesdrop on the signal.

Explanation

HTTP is a stateless, text-based (in HTTP/1.1) request/response protocol running over TCP, using port 80 by default. A client sends a request specifying a method, a resource path, headers, and optionally a body; the server replies with a status code, headers, and optionally a body. The main HTTP methods are GET (retrieve a resource, should not change server state, and is idempotent — repeating it has the same effect as doing it once), POST (submit data to create a new resource or trigger a non-idempotent action, such as placing an order), PUT (replace a resource entirely with the supplied data; idempotent, since sending the same PUT twice leaves the resource in the same state), DELETE (remove a resource; idempotent, since deleting an already-deleted resource has no further effect), and PATCH (apply a partial update to a resource; not guaranteed to be idempotent, since repeated partial updates can produce different results depending on the operation).

🏏

Cricket analogy: GET is like checking the live scoreboard as often as you want without changing the match, idempotent and safe, while POST is like actually bowling a delivery, an action that changes the game state and can't be undone by repeating it; PUT is like replacing the entire batting lineup with a new one, DELETE is like retiring a player from the squad list, and PATCH is like adjusting just one player's batting position.

HTTPS wraps HTTP inside a TLS session, defaulting to port 443. Before any HTTP data is exchanged, the client and server perform a TLS handshake: the server presents a digital certificate (issued by a trusted certificate authority) proving its identity, the two sides use asymmetric cryptography to safely agree on a shared symmetric session key, and from that point on all HTTP traffic is encrypted with that session key. This gives HTTPS three properties HTTP lacks on its own: confidentiality (traffic is encrypted so eavesdroppers cannot read it), integrity (tampering with data in transit is detectable), and authentication (the client can verify it is really talking to the legitimate server, not an impostor).

🏏

Cricket analogy: HTTPS is like a match only starting after the third umpire verifies both captains' identities via credentials (the TLS handshake with a CA-issued certificate), after which every ball bowled is recorded on a tamper-evident, encrypted scorecard that spectators can trust.

Example

python

import requests

# GET: retrieve a resource (safe, idempotent)
resp = requests.get("https://api.example.com/users/42")
print(resp.status_code, resp.json())

# POST: create a new resource (not idempotent)
resp = requests.post("https://api.example.com/users", json={"name": "Ada"})
print(resp.status_code, resp.json())

# PUT: replace a resource entirely (idempotent)
resp = requests.put("https://api.example.com/users/42", json={"name": "Ada Lovelace"})

# PATCH: partially update a resource
resp = requests.patch("https://api.example.com/users/42", json={"name": "A. Lovelace"})

# DELETE: remove a resource (idempotent)
resp = requests.delete("https://api.example.com/users/42")
print(resp.status_code)

Analysis

The idempotency distinction matters in practice: a client or proxy can safely retry a GET, PUT, or DELETE after a network timeout without worrying about duplicate side effects, but retrying a POST blindly could create two orders instead of one. This is why well-designed APIs sometimes add idempotency keys to POST requests. On the transport security side, using the requests library against an https:// URL automatically performs the TLS handshake and certificate validation shown conceptually above — if the certificate is invalid or untrusted, the request fails rather than silently sending data insecurely, which is exactly the authentication guarantee HTTPS is meant to provide.

🏏

Cricket analogy: A rain-delayed appeal for a review (GET) can be safely repeated without consequence, and a request to reverse a wicket decision (DELETE) has no extra effect if repeated, but re-submitting a request to add an extra run (POST) blindly could double-count it, which is why scorers use a unique ball-by-ball ID as an idempotency key.

Key Takeaways

HTTP methods: GET (idempotent, retrieve), POST (not idempotent, create/trigger), PUT (idempotent, full replace), DELETE (idempotent, remove), PATCH (not guaranteed idempotent, partial update).
HTTP's default port is 80; HTTPS's default port is 443.
HTTPS = HTTP + TLS: it adds encryption (confidentiality), tamper detection (integrity), and certificate-based server authentication.
The TLS handshake establishes a shared session key and verifies the server's certificate before any HTTP data is exchanged.
HTTP itself is stateless — each request is independent unless state is layered on top via cookies, tokens, or sessions.

Practice what you learned

1. Which HTTP method is used to completely replace a resource and is idempotent?

2. Why is POST generally considered non-idempotent?

3. What is the primary role of the TLS handshake in HTTPS?

4. What are the default ports for HTTP and HTTPS respectively?

5. Which HTTP method is designed for partial updates to a resource?

Was this page helpful?

DNS: The Domain Name System

FTP and Email Protocols

Topics covered

#Python#ComputerNetworksStudyNotes#ComputerNetworks#HTTPAndHTTPS#HTTP#HTTPS#Explanation#Example#Networking#StudyNotes#SkillVeris