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

🎯

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

easyNETWORKSAmazonGoogleMicrosoft

Imagine ordering food online: you want to check the menu, place an order, update it if needed, or cancel it. Each action corresponds to a different HTTP method with specific rules.

💡 Beginners often confuse HTTP methods as just different ways to send data, missing their semantic differences and the importance of idempotency and safety in APIs.

📋

Interview Question

Explain the HTTP methods GET, POST, PUT, PATCH, DELETE and the concept of idempotency in HTTP. How do these methods differ in usage and behavior?

Purpose and semantics of HTTP methodsIdempotency and safety properties of HTTP methodsHow HTTP methods affect server state and client-server interaction

💡

Scenario & Trace

ScenarioA user browsing an e-commerce site wants to view a product, add it to the cart, update the quantity, and then remove it.

GET request fetches product details without changing server state → POST request adds product to cart creating a new resource → PUT request updates the quantity of the product in the cart replacing the previous value → PATCH request modifies only the quantity field without replacing entire cart item → DELETE request removes the product from the cart.

ScenarioA client sends the same DELETE request twice due to network retry.

First DELETE removes the resource → second DELETE has no effect but returns success because DELETE is idempotent.

• What happens if a POST request is repeated due to network failure?
• How does PATCH differ from PUT when updating partial resource data?
• Is GET always safe and idempotent in practice?
• What if a DELETE request targets a resource that does not exist?

⚠️

Common Mistakes

Confusing idempotency with safety

Interviewer thinks candidate does not understand that safe methods do not change state, while idempotent methods can change state but in a repeatable way.

✅ Clarify that safe methods (like GET) do not modify server state, whereas idempotent methods (like PUT, DELETE) may modify state but repeated calls have the same effect.

Assuming POST is idempotent

Interviewer doubts candidate's grasp of HTTP semantics and API design principles.

✅ Explain that POST is not idempotent because repeated POSTs can create multiple resources or trigger multiple actions.

Treating PATCH as always idempotent

Interviewer questions candidate's understanding of partial updates and their implications.

✅ Mention that PATCH is generally idempotent if designed properly, but it depends on the implementation and the nature of the partial update.

Believing GET requests can modify server state

Interviewer suspects candidate lacks knowledge of HTTP safety principles.

✅ State that GET should be safe and not change server state; if it does, it's a design flaw.

Not understanding the difference between PUT and PATCH

Interviewer thinks candidate cannot distinguish full replacement from partial update semantics.

✅ Explain PUT replaces the entire resource, while PATCH applies partial modifications.

🧠

Basic Definition - What It Is

💡 This level covers the fundamental purpose of each HTTP method and the basic idea of idempotency and safety.

Intuition

HTTP methods define the action to perform on a resource, with some methods safe (no side effects) and some idempotent (repeatable without additional effect).

Explanation

HTTP methods are standardized verbs used in requests to indicate the desired action on a resource. GET retrieves data without changing server state and is considered safe and idempotent. POST submits data to create a resource and is neither safe nor idempotent. PUT replaces a resource entirely and is idempotent. PATCH partially updates a resource and is usually idempotent but not guaranteed. DELETE removes a resource and is idempotent. Idempotency means that making the same request multiple times results in the same server state as making it once.

Memory Hook

💡 Think of HTTP methods as verbs in a sentence: GET is 'read', POST is 'create', PUT is 'replace', PATCH is 'edit', DELETE is 'remove'. Idempotent methods are like pressing the same button multiple times but only one action happens.

Interview Questions

❓ What is the difference between GET and POST?

• GET retrieves data without side effects
• POST submits data to create or process and can change server state

⏱

Depth Level

Interview Time30 seconds

Depthbasic

Covers fundamental definitions and basic properties; sufficient for screening rounds.

Interview Target: Minimum floor - never go below this

Knowing only this will help pass initial screening but not detailed technical interviews.

🧠

Mechanism Depth - How It Works

💡 This level explains the internal semantics, idempotency nuances, and practical implications in API design.

Intuition

Each HTTP method has defined semantics affecting server state and client expectations, with idempotency ensuring safe retries and consistent state.

Explanation

GET requests are safe and idempotent because they only retrieve data without modifying it, allowing caching and safe retries. POST requests create new resources or trigger processing and are neither safe nor idempotent, so repeated POSTs may create duplicates. PUT replaces the entire resource at the target URI and is idempotent because multiple identical PUTs result in the same resource state. PATCH applies partial modifications and is generally idempotent if designed carefully, but this depends on implementation. DELETE removes the resource and is idempotent because deleting an already deleted resource has no further effect. Understanding these properties is crucial for designing robust APIs, handling retries, and ensuring correct client-server interactions.

Memory Hook

💡 Imagine PUT as replacing a file completely, PATCH as editing a paragraph inside the file, POST as adding a new file, GET as reading the file, and DELETE as deleting the file. Idempotency means replacing or deleting the file multiple times leads to the same final state.

Interview Questions

❓ Why is PUT idempotent but POST is not?

• PUT replaces resource at URI, so repeated PUTs have same effect
• POST creates new resources or triggers actions, so repeated POSTs can create duplicates

❓ How does PATCH differ from PUT?

• PATCH applies partial updates, PUT replaces entire resource
• PATCH may not be idempotent depending on implementation

⏱

Depth Level

Interview Time2-3 minutes

Depthintermediate

Demonstrates understanding of HTTP semantics, idempotency, and practical API design considerations.

Interview Target: Target level for FAANG on-sites

Mastering this level distinguishes you from most candidates and prepares you for system design discussions.

📊

Explanation Depth Levels

💡 Choose your explanation depth based on interview stage and role requirements.

Level	Interview Time	Suitable For	Risk
Basic Definition	30s	Screening call or initial rounds	Too shallow for on-site or system design interviews
Mechanism Depth	2-3 minutes	On-site interviews, FAANG, and senior roles	Requires good understanding and ability to explain nuances

💼

Interview Strategy

💡 Use this guide to structure your explanation clearly and confidently before interviews.

How to Present

Start with a concise definition of each HTTP method and their purpose.Give a real-world analogy or example illustrating their use.Explain the concept of idempotency and safety with respect to these methods.Discuss edge cases and implications for retries and API design.

Time Allocation

Definition: 30s → Example: 1min → Mechanism: 2min → Edge cases: 30s. Total ~4min

What the Interviewer Tests

Interviewer checks your understanding of HTTP method semantics, idempotency, and ability to apply these concepts in real-world scenarios.

Common Follow-ups

• What happens if a POST request is retried due to network failure? → It may create duplicate resources unless handled carefully.
• Can GET requests ever change server state? → Ideally no, but some poorly designed APIs violate this.

💡 These common curveballs test your deeper understanding and practical awareness.

🔍

Pattern Recognition

When to Use

When asked to explain HTTP methods, REST API design, or how client-server communication works in web applications.

Signature Phrases

'Explain HTTP methods and their differences''What is idempotency in HTTP?''Compare PUT vs PATCH'

NOT This Pattern When

Similar Problems

Practice

1. In a local area network, when a device needs to send a packet to another device but only knows the destination IP address, which component is responsible for resolving the corresponding MAC address?

easy

A. The DNS server

B. The ARP protocol

C. The DHCP server

D. The routing table

Solution

1. Step 1: Identify the role of ARP

   ARP (Address Resolution Protocol) is specifically designed to map IP addresses to MAC addresses within a local network segment.

2. Step 2: Why not DNS?

   DNS resolves domain names to IP addresses, not MAC addresses.

3. Step 3: Why not DHCP?

   DHCP assigns IP addresses dynamically but does not resolve MAC addresses.

4. Step 4: Why not routing table?

   Routing tables determine the next hop IP address but do not resolve MAC addresses.

5. Final Answer:

   Option B -> Option B

6. Quick Check:

   ARP is the protocol that resolves IP to MAC addresses on local networks [OK]

Hint: ARP maps IP to MAC on local networks [OK]

Common Mistakes:

• Confusing DNS with ARP
• Thinking DHCP handles MAC resolution

2. 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

3. A client sends a request to a web server and receives a 3xx status code in response. Which scenario best explains why the server returned this status code?

easy

A. The requested resource has been permanently moved to a new URL, and the client should update its bookmarks.

B. The server successfully processed the request and returned the requested data.

C. The client sent a malformed request that the server could not understand.

D. The server encountered an unexpected error and could not fulfill the request.

Solution

1. Step 1: Identify the meaning of 3xx status codes

   3xx status codes indicate redirection, meaning the client must take additional action to complete the request.

2. Step 2: Analyze each option

   The requested resource has been permanently moved to a new URL, and the client should update its bookmarks. describes a permanent redirect (301), which is a typical 3xx scenario.
   The server successfully processed the request and returned the requested data. describes a successful 2xx response.
   The client sent a malformed request that the server could not understand. describes a client error (4xx).
   The server encountered an unexpected error and could not fulfill the request. describes a server error (5xx).

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   3xx codes always involve redirection, so The requested resource has been permanently moved to a new URL, and the client should update its bookmarks. is correct.

Hint: 3xx = redirection, telling client to look elsewhere

Common Mistakes:

• Confusing 3xx with 2xx success codes
• Thinking 3xx means client or server error
• Assuming 3xx means temporary server failure

4. Which of the following statements about geo-routing in CDNs is INCORRECT?

medium

A. Geo-routing decisions can be influenced by DNS resolution or IP anycast

B. Geo-routing directs user requests to the nearest edge server to minimize latency

C. Geo-routing always guarantees the lowest latency path regardless of network congestion

D. Geo-routing helps distribute load geographically to avoid overloading a single edge server

Solution

1. Step 1: Understand geo-routing purpose

   Geo-routing aims to route users to nearby edge servers to reduce latency.

2. Step 2: Analyze Geo-routing always guarantees the lowest latency path regardless of network congestion

   Geo-routing does not always guarantee lowest latency because network congestion or routing policies can affect actual latency.

3. Step 3: Confirm other options

   Geo-routing directs user requests to the nearest edge server to minimize latency is correct as geo-routing targets proximity. Geo-routing decisions can be influenced by DNS resolution or IP anycast is true since DNS and IP anycast are common geo-routing methods. Geo-routing helps distribute load geographically to avoid overloading a single edge server is valid because geo-routing balances load across regions.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Geo-routing optimizes for proximity but cannot guarantee lowest latency in all network conditions.

Hint: Geo-routing ≠ always lowest latency due to network dynamics

Common Mistakes:

• Assuming geo-routing always picks the fastest path
• Ignoring network congestion effects
• Confusing geo-routing with load balancing only

5. Which of the following statements about the scalability and overhead trade-offs between Distance Vector and Link State routing is TRUE?

medium

A. Distance Vector routing scales better in large networks because it floods link state advertisements less frequently

B. Distance Vector routing has lower convergence time but higher memory usage compared to Link State

C. Link State routing requires more memory and CPU but scales better due to faster convergence and less routing loops

D. Link State routing uses less bandwidth overall because it only sends updates when topology changes

Solution

1. Step 1: Understand resource usage

   Link State routing stores the entire network topology, requiring more memory and CPU for Dijkstra's algorithm.

2. Step 2: Analyze scalability and convergence

   Link State converges faster and avoids routing loops better, making it more scalable despite higher resource use.

3. Step 3: Evaluate options

   Distance Vector routing scales better in large networks because it floods link state advertisements less frequently is false because Distance Vector does not flood link state advertisements at all. Distance Vector routing has lower convergence time but higher memory usage compared to Link State is false because Distance Vector generally has slower convergence and lower memory usage. Link State routing uses less bandwidth overall because it only sends updates when topology changes is misleading; Link State floods updates on topology changes, which can be bandwidth intensive.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Link State trades higher resource use for better scalability and convergence.

Hint: More CPU/memory but faster convergence -> Link State scales better

Common Mistakes:

• Assuming Distance Vector floods updates like Link State
• Confusing convergence time and memory usage
• Believing Link State sends fewer updates overall