HTTP Methods - GET, POST, PUT, PATCH, DELETE & Idempotency

▶

Steps

setup

Client prepares GET request

The client constructs an HTTP GET request packet to retrieve data from the server.

💡 This step shows how a simple GET request is formed before sending, establishing the starting point of communication.

Line:

request = HTTPRequest(method='GET', url='/resource')

💡 Understanding the initial request setup is crucial to follow the packet flow.

traverse

Client sends GET request to server

The client sends the GET request packet to the server over the network.

💡 This step shows the packet leaving the client and traveling to the server, illustrating the request flow.

Line:

network.send(request_packet)

💡 Packet transmission is the core of client-server communication.

processing

Server receives and processes GET request

The server receives the GET request and begins processing it to retrieve the requested resource.

💡 This step highlights the server's role in handling incoming requests.

Line:

response = server.handle_request(request)

💡 Server processing is where the request method determines the action taken.

traverse

Server sends response to GET request

The server sends back the requested resource in an HTTP response packet to the client.

💡 This step completes the GET request cycle by returning data to the client.

Line:

network.send(response_packet)

💡 Response packets carry requested data back to the client.

processing

Client receives response to GET request

The client receives the server's response and processes the returned data.

💡 This step shows the client completing the GET request cycle by handling the response.

Line:

client.process_response(response_packet)

💡 Client processes data after successful GET response.

setup

Client prepares POST request

The client constructs an HTTP POST request to submit new data to the server.

💡 POST differs from GET by sending data to the server, so this step shows the request setup.

Line:

request = HTTPRequest(method='POST', url='/resource', body='new data')

💡 POST requests modify server state and are not idempotent.

traverse

Client sends POST request to server

The client sends the POST request packet containing new data to the server.

💡 This step shows data submission from client to server.

Line:

network.send(request_packet)

💡 POST requests change server state and are not idempotent, so each request matters.

processing

Server receives and processes POST request

The server receives the POST request and updates its state with the new data.

💡 This step shows how POST modifies server resources.

Line:

response = server.handle_request(request)

💡 POST is not idempotent; repeated requests create multiple changes.

traverse

Server sends response to POST request

The server sends a confirmation response back to the client after processing the POST request.

💡 This step confirms the server has accepted and processed the POST data.

Line:

network.send(response_packet)

💡 Server responses confirm request success or failure.

processing

Client receives response to POST request

The client receives the server's confirmation and processes the POST response.

💡 This step completes the POST request cycle by acknowledging server acceptance.

Line:

client.process_response(response_packet)

💡 Client confirms that POST data was successfully stored.

setup

Client prepares PUT request

The client constructs an HTTP PUT request to update an existing resource on the server.

💡 PUT replaces the resource entirely and is idempotent, so this step shows the update request setup.

Line:

request = HTTPRequest(method='PUT', url='/resource', body='updated data')

💡 PUT requests overwrite resources and repeated identical requests have the same effect.

traverse

Client sends PUT request to server

The client sends the PUT request packet to update the resource on the server.

💡 This step shows the update request traveling to the server.

Line:

network.send(request_packet)

💡 PUT requests are idempotent; sending the same request multiple times results in the same server state.

processing

Server receives and processes PUT request

The server receives the PUT request and replaces the existing resource with the new data.

💡 This step shows how PUT updates resources idempotently.

Line:

response = server.handle_request(request)

💡 PUT ensures the resource state is consistent after repeated identical requests.

traverse

Server sends response to PUT request

The server sends a confirmation response back to the client after processing the PUT request.

💡 This step confirms the server has updated the resource.

Line:

network.send(response_packet)

💡 Server responses confirm successful resource replacement.

processing

Client receives response to PUT request

The client receives the server's confirmation and processes the PUT response.

💡 This step completes the PUT request cycle by acknowledging server acceptance.

Line:

client.process_response(response_packet)

💡 Client confirms that the resource was successfully updated.

setup

Client prepares DELETE request

The client constructs an HTTP DELETE request to remove a resource from the server.

💡 DELETE requests remove resources and are idempotent; this step shows the request setup.

Line:

request = HTTPRequest(method='DELETE', url='/resource')

💡 DELETE requests remove resources and repeated identical requests have the same effect.

traverse

Client sends DELETE request to server

The client sends the DELETE request packet to remove the resource on the server.

💡 This step shows the delete request traveling to the server.

Line:

network.send(request_packet)

💡 DELETE requests are idempotent; repeated deletes have the same effect as one.

processing

Server receives and processes DELETE request

The server receives the DELETE request and removes the specified resource.

💡 This step shows how DELETE removes resources idempotently.

Line:

response = server.handle_request(request)

💡 DELETE ensures resource removal; repeated deletes do not cause errors.

traverse

Server sends response to DELETE request

The server sends a confirmation response back to the client after processing the DELETE request.

💡 This step confirms the server has deleted the resource.

Line:

network.send(response_packet)

💡 Server responses confirm successful resource deletion.

processing

Client receives response to DELETE request

The client receives the server's confirmation and processes the DELETE response.

💡 This step completes the DELETE request cycle by acknowledging server acceptance.

Line:

client.process_response(response_packet)

💡 Client confirms that the resource was successfully deleted.

class HTTPRequest:
    def __init__(self, method, url, body=None):
        self.method = method  # STEP 1,6,11,16
        self.url = url
        self.body = body

class Network:
    def send(self, packet):
        pass  # STEP 2,7,12,17

class Server:
    def handle_request(self, request):
        if request.method == 'GET':
            # STEP 3
            return '200 OK', 'resource data'
        elif request.method == 'POST':
            # STEP 8
            return '201 Created', None
        elif request.method == 'PUT':
            # STEP 13
            return '200 OK', None
        elif request.method == 'DELETE':
            # STEP 18
            return '200 OK', None

class Client:
    def process_response(self, response):
        pass  # STEP 5,10,15,20

# Example usage:
client = Client()
server = Server()
network = Network()

# Steps 1-5: GET
request = HTTPRequest('GET', '/resource')  # STEP 1
network.send(request)  # STEP 2
response = server.handle_request(request)  # STEP 3
network.send(response)  # STEP 4
client.process_response(response)  # STEP 5

# Steps 6-10: POST
request = HTTPRequest('POST', '/resource', 'new data')  # STEP 6
network.send(request)  # STEP 7
response = server.handle_request(request)  # STEP 8
network.send(response)  # STEP 9
client.process_response(response)  # STEP 10

# Steps 11-15: PUT
request = HTTPRequest('PUT', '/resource', 'updated data')  # STEP 11
network.send(request)  # STEP 12
response = server.handle_request(request)  # STEP 13
network.send(response)  # STEP 14
client.process_response(response)  # STEP 15

# Steps 16-20: DELETE
request = HTTPRequest('DELETE', '/resource')  # STEP 16
network.send(request)  # STEP 17
response = server.handle_request(request)  # STEP 18
network.send(response)  # STEP 19
client.process_response(response)  # STEP 20

📊

HTTP Methods - GET, POST, PUT, PATCH, DELETE & Idempotency - Watch the Algorithm Execute, Step by Step

Watching each HTTP method's request and response flow helps you understand the fundamental differences and the concept of idempotency in HTTP.

Client prepares GET request packet.

Hop: 0

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→GET /resource HTTP/1.1

Packet is in transit from client to server.

Hop: 1

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadGET /resource HTTP/1.1

🔌 protocolHTTP

🚩 flags

src→192.168.1.2:12345

dst→192.168.1.10:80

data→GET /resource HTTP/1.1

GET: client→server (request)

Server is processing GET request.

Hop: 1

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→GET /resource HTTP/1.1

GET: client→server (request)

Server sends response packet to client.

Hop: 2

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadHTTP/1.1 200 OK Content: resource data

🔌 protocolHTTP

🚩 flags

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 200 OK Content: resource data

GET: client→server (request)

200 OK: server→client (response)

Client processes response data.

Hop: 2

Client

Server

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 200 OK Content: resource data

GET: client→server (request)

200 OK: server→client (response)

Client prepares POST request packet.

Hop: 0

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→POST /resource HTTP/1.1 Body: new data

GET: client→server (request)

200 OK: server→client (response)

POST request packet is in transit.

Hop: 1

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadPOST /resource HTTP/1.1 Body: new data

🔌 protocolHTTP

🚩 flags

src→192.168.1.2:12345

dst→192.168.1.10:80

data→POST /resource HTTP/1.1 Body: new data

GET: client→server (request)

200 OK: server→client (response)

POST: client→server (request)

Server processes POST request and updates resource.

Hop: 1

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→POST /resource HTTP/1.1 Body: new data

GET: client→server (request)

200 OK: server→client (response)

POST: client→server (request)

Server sends POST response to client.

Hop: 2

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadHTTP/1.1 201 Created

🔌 protocolHTTP

🚩 flags

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 201 Created

200 OK: server→client (response)

POST: client→server (request)

201 Created: server→client (response)

Client processes POST response.

Hop: 2

Client

Server

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 201 Created

200 OK: server→client (response)

POST: client→server (request)

201 Created: server→client (response)

Client prepares PUT request packet.

Hop: 0

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→PUT /resource HTTP/1.1 Body: updated data

200 OK: server→client (response)

POST: client→server (request)

201 Created: server→client (response)

PUT request packet is in transit.

Hop: 1

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadPUT /resource HTTP/1.1 Body: updated data

🔌 protocolHTTP

🚩 flags

src→192.168.1.2:12345

dst→192.168.1.10:80

data→PUT /resource HTTP/1.1 Body: updated data

POST: client→server (request)

201 Created: server→client (response)

PUT: client→server (request)

Server processes PUT request and updates resource.

Hop: 1

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→PUT /resource HTTP/1.1 Body: updated data

POST: client→server (request)

201 Created: server→client (response)

PUT: client→server (request)

Server sends PUT response to client.

Hop: 2

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadHTTP/1.1 200 OK

🔌 protocolHTTP

🚩 flags

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 200 OK

201 Created: server→client (response)

PUT: client→server (request)

200 OK: server→client (response)

Client processes PUT response.

Hop: 2

Client

Server

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 200 OK

201 Created: server→client (response)

PUT: client→server (request)

200 OK: server→client (response)

Client prepares DELETE request packet.

Hop: 0

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→DELETE /resource HTTP/1.1

201 Created: server→client (response)

PUT: client→server (request)

200 OK: server→client (response)

DELETE request packet is in transit.

Hop: 1

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadDELETE /resource HTTP/1.1

🔌 protocolHTTP

🚩 flags

src→192.168.1.2:12345

dst→192.168.1.10:80

data→DELETE /resource HTTP/1.1

PUT: client→server (request)

200 OK: server→client (response)

DELETE: client→server (request)

Server processes DELETE request and removes resource.

Hop: 1

Client

Server

src→192.168.1.2:12345

dst→192.168.1.10:80

data→DELETE /resource HTTP/1.1

PUT: client→server (request)

200 OK: server→client (response)

DELETE: client→server (request)

Server sends DELETE response to client.

Hop: 2

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadHTTP/1.1 200 OK

🔌 protocolHTTP

🚩 flags

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 200 OK

200 OK: server→client (response)

DELETE: client→server (request)

200 OK: server→client (response)

Client processes DELETE response.

Hop: 2

Client

Server

src→192.168.1.10:80

dst→192.168.1.2:12345

data→HTTP/1.1 200 OK

200 OK: server→client (response)

DELETE: client→server (request)

200 OK: server→client (response)

Key Takeaways

✓ HTTP methods differ in how they affect server state and idempotency.

Reading code alone doesn't clearly show how repeated requests behave differently; watching packet flows clarifies this.

✓ GET requests retrieve data without side effects, while POST requests submit data and are not idempotent.

Visualizing the request and response packets helps understand why POST can cause multiple changes if repeated.

✓ PUT and DELETE methods are idempotent, meaning repeated identical requests result in the same server state.

Seeing the packet flow and server processing steps highlights the idempotency concept concretely.

Practice

1. Trace the sequence of events when a client sends a request to a web server protected by a reverse proxy. Which step happens immediately after the reverse proxy receives the client request?

easy

A. The reverse proxy forwards the request to the backend server

B. The firewall inspects and blocks the request if malicious

C. The proxy server caches the response for future requests

D. The client directly connects to the backend server

Solution

1. Step 1: Understand reverse proxy role

   Reverse proxy acts as an intermediary on the server side, receiving client requests first.

2. Step 2: After receiving the request

   The reverse proxy forwards the request to the backend server for processing.

3. Step 3: Other options

   Firewall inspection happens before the reverse proxy in the network path; proxy caching is client-side; client does not connect directly to backend when reverse proxy is used.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Reverse proxy forwards request to backend server immediately after receiving it [OK]

Hint: Reverse proxy forwards requests to backend servers.

Common Mistakes:

• Assuming firewall acts after reverse proxy
• Confusing proxy caching with reverse proxy behavior

2. In which scenario is HTTPS preferred over HTTP for client-server communication?

easy

A. When the client and server are on the same trusted local network

B. When sensitive data like passwords or credit card numbers are transmitted

C. When the server wants to reduce latency by avoiding encryption overhead

D. When the client only needs to fetch static public content like images

Solution

1. Step 1: Understand the purpose of HTTPS

   HTTPS encrypts data to protect confidentiality and integrity, especially for sensitive information.

2. Step 2: Analyze each option

   A: On a trusted local network, encryption may be less critical, so HTTP might suffice.
   B: Sensitive data requires encryption to prevent eavesdropping, so HTTPS is necessary.
   C: HTTPS adds overhead; avoiding it to reduce latency sacrifices security.
   D: Static public content does not require encryption, so HTTP is often acceptable.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   HTTPS is essential when transmitting sensitive data to ensure security.

Hint: Use HTTPS whenever data confidentiality matters

Common Mistakes:

• Assuming HTTPS is always needed regardless of data sensitivity
• Believing HTTPS always causes unacceptable latency
• Thinking HTTP is fine for sensitive data on any network

3. Trace the sequence of steps during a TLS handshake when a client connects to an HTTPS server.

easy

A. Client sends ClientHello, server responds with ServerHello and certificate, client verifies certificate, client sends encrypted pre-master secret, server decrypts it, both derive symmetric keys

B. Client sends encrypted data, server responds with certificate, then symmetric key is exchanged

C. Client sends HTTP request, server sends certificate, client sends symmetric key in plaintext, handshake completes

D. Client sends ClientHello, server sends ServerHello, handshake completes without certificate exchange

Solution

1. Step 1: Identify the TLS handshake flow

   The handshake starts with ClientHello, followed by ServerHello and certificate, then client verifies certificate, sends encrypted pre-master secret, and both derive symmetric keys.

2. Step 2: Evaluate each option

   A: Correct sequence including ClientHello, ServerHello, certificate exchange, verification, encrypted pre-master secret, and key derivation.
   B: Incorrect order and missing ClientHello/ServerHello steps.
   C: Client sends HTTP request too early and symmetric key is never sent in plaintext.
   D: Certificate exchange is mandatory for authentication, so this is incomplete.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Remember the handshake involves hello messages, certificate exchange, key exchange, and symmetric key derivation.

Hint: TLS handshake = Hello messages + certificate + encrypted key exchange

Common Mistakes:

• Confusing when the certificate is sent
• Assuming symmetric keys are exchanged in plaintext
• Skipping certificate verification step

4. Which of the following statements about the OSI and TCP/IP models is INCORRECT?

medium

A. The OSI model has seven layers, while TCP/IP has four layers

B. The TCP/IP model includes a Presentation Layer separate from the Application Layer

C. The OSI model is a theoretical framework, whereas TCP/IP is a practical protocol suite

D. The Internet Layer in TCP/IP corresponds roughly to the Network Layer in OSI

Solution

1. Step 1: Analyze each statement carefully

   Statement A is correct: OSI has 7 layers, TCP/IP has 4. Statement B is incorrect: TCP/IP does not have a separate Presentation Layer; it is combined with Application. Statement C is correct: OSI is theoretical, TCP/IP practical. Statement D is correct: Internet Layer maps to OSI's Network Layer.

2. Final Answer:

   Option B -> Option B

3. Quick Check:

   TCP/IP merges Presentation into Application Layer [OK]

Hint: TCP/IP merges Presentation into Application, no separate layer

Common Mistakes:

• Assuming TCP/IP has all OSI layers distinctly
• Confusing theoretical vs practical nature of models
• Misaligning Internet and Network layers

5. If a real-time chat application needs to support thousands of clients with intermittent connectivity and occasional message bursts, which limitation of WebSockets should be considered, and what fallback mechanism is most appropriate?

hard

A. WebSocket cannot handle intermittent connectivity; fallback to opening multiple WebSocket connections per client

B. WebSocket does not support message ordering; fallback to SSE to guarantee ordered delivery

C. WebSocket connections consume significant server resources per client; fallback to HTTP Long Polling to reduce persistent connections

D. WebSocket has high latency for message bursts; fallback to HTTP/2 multiplexing to improve throughput

Solution

1. Step 1: Identify WebSocket resource usage

   Each WebSocket connection requires server resources to maintain persistent connections, which can be costly at scale.

2. Step 2: Consider intermittent connectivity

   Clients with intermittent connectivity may cause connection drops, increasing server load.

3. Step 3: Evaluate fallback options

   HTTP Long Polling can reduce persistent connections by using short-lived requests, making it a suitable fallback.

4. Step 4: Analyze other options

   WebSocket does not support message ordering; fallback to SSE to guarantee ordered delivery is incorrect; WebSocket supports message ordering. WebSocket cannot handle intermittent connectivity; fallback to opening multiple WebSocket connections per client is wrong because opening multiple connections per client worsens resource usage. WebSocket has high latency for message bursts; fallback to HTTP/2 multiplexing to improve throughput misattributes latency issues to WebSocket and suggests unrelated HTTP/2 multiplexing.

5. Final Answer:

   Option C -> Option C

6. Quick Check:

   WebSocket resource cost + intermittent clients -> fallback to Long Polling

Hint: WebSocket scales poorly with many persistent connections; Long Polling reduces connection count

Common Mistakes:

• Assuming WebSocket handles intermittent connectivity gracefully without resource impact
• Believing WebSocket lacks message ordering
• Confusing HTTP/2 multiplexing with WebSocket fallback