What is the difference between safe and unsafe HTTP methods?
Learn the difference between safe and unsafe HTTP methods: which methods are read-only, which change state, and how safety relates to idempotency and caching.
Expected Interview Answer
Safe HTTP methods are read-only — they don't modify server state — while unsafe methods can create, update, or delete resources. GET, HEAD, OPTIONS, and TRACE are safe; POST, PUT, PATCH, and DELETE are unsafe.
Safety is a promise about intent: a safe request should have no side effects visible to the client, which is why crawlers and browsers can prefetch GET links freely. Unsafe methods are expected to change state, so they must never be triggered by simple link-following or prefetching. Note that safe and idempotent are related but distinct: all safe methods are idempotent, but not all idempotent methods (like PUT and DELETE) are safe.
- Lets caches and crawlers prefetch safe requests confidently
- Prevents accidental data changes from link-following
- Guides correct method selection during API design
- Improves cacheability of read operations
- Makes side effects explicit and intentional
AI Mentor Explanation
A safe method is like a spectator reading the scoreboard — glancing at the total as many times as they like never alters a single run or wicket. An unsafe method is like the batter actually hitting the ball, which changes the score. Reading the game is harmless; playing the game changes its state, and the two roles must never be confused.
Step-by-Step Explanation
Step 1
Ask if it reads or writes
If the request only retrieves data, it is safe; if it changes state, it is unsafe.
Step 2
Map the methods
GET, HEAD, OPTIONS, TRACE are safe; POST, PUT, PATCH, DELETE are unsafe.
Step 3
Respect prefetching
Never place state-changing actions behind GET links that crawlers or browsers may prefetch.
Step 4
Combine with idempotency
Remember all safe methods are idempotent, but PUT and DELETE are idempotent yet unsafe.
Step 5
Enable caching
Mark safe read responses as cacheable to improve performance without risking stale writes.
What Interviewer Expects
- Correct definition of safety as no state change
- Accurate lists of safe and unsafe methods
- The relationship between safe and idempotent
- Why GET must not perform actions like delete
- Awareness of caching and prefetch implications
Common Mistakes
- Equating safe with idempotent
- Placing delete or update actions behind a GET request
- Calling PUT or DELETE safe because they are idempotent
- Saying POST is safe
- Forgetting HEAD and OPTIONS are safe
Best Answer (HR Friendly)
“Safe methods only read data and never change anything on the server, so they can be repeated freely — GET is the main example. Unsafe methods like POST, PUT, PATCH, and DELETE actually change data, so they must be used deliberately.”
Code Example
GET /articles/55
Accept: application/json
# Read-only: no server state changes, cacheable, safe to prefetchDELETE /articles/55
# Changes state: removes the resource, must not be triggered by a linkFollow-up Questions
- Why should GET never delete or modify data?
- Are all safe methods also idempotent?
- Why can PUT be idempotent but still unsafe?
- How does safety affect HTTP caching?
- Which safe method returns only headers with no body?
MCQ Practice
1. Which HTTP method is considered safe?
GET is read-only and does not modify server state, so it is a safe method.
2. Which statement is correct?
Every safe method is idempotent, but idempotent methods like PUT and DELETE are not safe because they change state.
3. Why must delete actions not sit behind a GET link?
GET is safe and freely prefetched, so a delete behind a GET link could be triggered accidentally by crawlers or browsers.
Flash Cards
What is a safe HTTP method? — One that only reads data and does not change server state, like GET or HEAD.
Name the safe methods — GET, HEAD, OPTIONS, and TRACE.
Name the unsafe methods — POST, PUT, PATCH, and DELETE — they change server state.
Are safe and idempotent the same? — No — all safe methods are idempotent, but PUT and DELETE are idempotent yet unsafe.