Bird
Raised Fist0
Interview Prepcomputer-networkseasyAmazonGoogleMicrosoftFlipkartSwiggyRazorpayZepto

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

Choose your preparation mode3 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
🎯
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.
LevelInterview TimeSuitable ForRisk
Basic Definition30sScreening call or initial roundsToo shallow for on-site or system design interviews
Mechanism Depth2-3 minutesOn-site interviews, FAANG, and senior rolesRequires 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/5)
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 encapsulation process when a user sends an email from their client application. Which sequence correctly represents the PDUs as data moves down the OSI layers?
easy
A. Data -> Packet -> Segment -> Frame -> Bits
B. Bits -> Frame -> Packet -> Segment -> Data
C. Data -> Segment -> Packet -> Frame -> Bits
D. Segment -> Data -> Packet -> Frame -> Bits

Solution

  1. Step 1: Identify PDU names per OSI layer

    Application Layer and Presentation Layer use 'Data', Transport Layer uses 'Segment', Network Layer uses 'Packet', Data Link Layer uses 'Frame', Physical Layer uses 'Bits'.
  2. Step 2: Follow encapsulation order

    Data is segmented, then packets are created, frames are formed, and finally bits are transmitted.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Correct encapsulation order matches OSI layering [OK]
Hint: Data -> Segment -> Packet -> Frame -> Bits follows OSI top-down encapsulation [OK]
Common Mistakes:
  • Confusing order of PDUs
  • Mixing up Segment and Packet roles
  • Reversing encapsulation direction
3. Which of the following statements about the TLS certificate chain is INCORRECT?
medium
A. The certificate chain is transmitted encrypted during the TLS handshake to protect privacy
B. The client must trust the root CA certificate to validate the entire chain
C. The certificate chain includes the server certificate and intermediate CA certificates up to a trusted root CA
D. If any certificate in the chain is invalid or expired, the client should reject the connection

Solution

  1. Step 1: Understand certificate chain transmission

    The certificate chain is sent in plaintext during the handshake because encryption is not established yet.
  2. Step 2: Evaluate each statement

    A: Correct, chain includes server and intermediate certificates.
    B: Correct, client must trust root CA.
    C: Incorrect, chain is sent unencrypted.
    D: Correct, invalid certificates cause rejection.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Certificate chain is sent before encryption is established, so it cannot be encrypted.
Hint: Certificate chain is public info sent before encryption
Common Mistakes:
  • Assuming certificate chain is encrypted during handshake
  • Confusing trust anchor with intermediate certificates
  • Ignoring certificate expiration impact
4. If a DHCP client moves to a different subnet with a new DHCP server, what happens to its existing IP lease and how does the DHCP process adapt?
hard
A. The client keeps its old IP lease and continues using it without changes
B. The client must release the old IP and start a new DORA sequence to obtain a new IP from the new server
C. The client automatically renews the old lease with the new DHCP server
D. The client sends a DHCP Release message to the old server and then uses the same IP on the new subnet

Solution

  1. Step 1: Understand subnet change impact

    IP addresses are subnet-specific; moving to a new subnet requires obtaining a new IP address.
  2. Step 2: Analyze DHCP behavior

    The client must initiate a new DORA sequence to get a valid IP from the new DHCP server.
  3. Step 3: Evaluate other options

    Options B, C, and D are incorrect because the old IP lease is not valid on the new subnet and lease renewal is with the original server only.
  4. Final Answer:

    Option B -> Option B
  5. Quick Check:

    Subnet change triggers new DHCP discovery and IP assignment.
Hint: New subnet -> new DHCP Discover -> new IP lease
Common Mistakes:
  • Assuming IP leases are portable across subnets
  • Believing lease renewal works with a different DHCP server
  • Thinking client can keep old IP without releasing
5. If a NAT router uses Port Address Translation (PAT) with a single public IP, what happens when two internal hosts simultaneously initiate connections to the same external server using the same source port number internally?
hard
A. The router blocks the second connection because the source port is already in use
B. The router forwards both connections using the same external source port, causing packet mix-up
C. The router changes the destination port on the external server to differentiate connections
D. The router assigns different external source ports to each connection to avoid conflicts

Solution

  1. Step 1: Understand PAT port mapping

    PAT uses unique external source ports to distinguish simultaneous connections even if internal source ports collide.
  2. Step 2: Analyze options

    The router assigns different external source ports to each connection to avoid conflicts correctly states that the router assigns unique external ports. The router forwards both connections using the same external source port, causing packet mix-up is false; PAT prevents port conflicts. The router blocks the second connection because the source port is already in use is incorrect; connections are not blocked due to port reuse internally. The router changes the destination port on the external server to differentiate connections is wrong; destination ports on external servers are not changed by PAT.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    PAT ensures unique external source ports per connection [OK]
Hint: PAT remaps source ports externally to avoid collisions
Common Mistakes:
  • Assuming PAT cannot handle internal source port collisions
  • Believing PAT blocks connections with same internal ports
  • Thinking PAT changes destination ports on external servers