Earlier today, I was in an interview for a frontend engineering role when the interviewer asked a seemingly simple question:
“Can you explain the difference between a PUT and a PATCH request?”
I froze…
Despite having made hundreds, probably thousands of API calls throughout my career, most of them using GET and POST, I realized I didn’t have a solid grasp of how PUT and PATCH differed. I admitted as much in the interview, and while I’m not sure how much it impacted the outcome, it definitely stuck with me.
That moment served as a wake-up call.
As frontend engineers, we’re constantly interfacing with APIs. Fetching data, updating records, deleting resources. But how well do we actually understand the semantics of the HTTP methods we’re using? And are we using the right one for the right job?
In this post, I’ll break down the most commonly used HTTP verbs, what they do, when to use them, and how they differ. Especially PUT vs PATCH, which trip up more people than you might think.
The 5 Most Common HTTP Verbs (and When to Use Them)
🔍 1. GET – Retrieve Data
- Purpose: Fetch data from the server.
- Request Body: None.
- Idempotent: Yes (repeated calls should return the same result).
- Example Use Case: Fetch a list of blog posts, user profile data, product listings, etc.
fetch('/api/posts')
.then(res => res.json())
.then(data => console.log(data));Frontend tip: GET is used whenever you’re displaying information but not modifying it. Be mindful of caching and query parameters for filtering and pagination.
➕ 2. POST – Create New Data
- Purpose: Send data to the server to create a new resource.
- Request Body: Yes (contains the data you’re submitting).
- Idempotent: No (each request may create a new resource).
- Example Use Case: Submitting a form, registering a new user, posting a comment.
fetch('/api/comments', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text: 'Great post!', postId: 123 })
});Frontend tip: If you’re sending user-generated content or creating something new, you’re likely using POST.
✏️ 3. PUT – Replace Entire Resource
- Purpose: Update a resource completely by replacing it with the new data.
- Request Body: Yes (should include the entire updated object).
- Idempotent: Yes (repeating the same PUT call will yield the same result).
- Example Use Case: Updating a user’s profile with a full payload (all fields, even unchanged ones).
fetch('/api/user/123', {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
name: 'Bryan',
email: 'bryan@example.com',
bio: 'Frontend engineer.'
})
});Frontend tip: Use PUT when you’re updating the entire record and want to be explicit about all fields. Be cautious, omitting a field might remove it entirely.
🩹 4. PATCH – Partially Update Resource
- Purpose: Update part of a resource (only the fields that have changed).
- Request Body: Yes (but only the fields to be updated).
- Idempotent: ✅ Yes.
- Example Use Case: Editing a single field, like updating a username or toggling a “liked” status.
fetch('/api/user/123', {
method: 'PATCH',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ bio: 'Loves React & fishing 🎣' })
});Frontend tip: If you’re changing just one or two fields, PATCH is cleaner and more efficient than sending the entire object via PUT.
❌ 5. DELETE – Remove Resource
- Purpose: Permanently remove a resource.
- Request Body: Usually none (some APIs allow it, but not typical).
- Idempotent: Yes.
- Example Use Case: Deleting a comment, removing a user, or clearing saved items.
fetch('/api/comments/789', {
method: 'DELETE'
});Frontend tip: Confirm destructive actions with the user (e.g., a confirmation modal) before triggering a DELETE request.
PUT vs PATCH: What’s the Real Difference?
This is where things get subtle but important.
| Feature | PUT | PATCH |
|---|---|---|
| Type of update | Full (replaces the entire object) | Partial (only updates fields) |
| Required fields | All fields (even unchanged) | Only the fields being updated |
| Risk | Can overwrite data if fields are omitted | Safer for minor updates |
| Idempotent | ✅ Yes | ✅ Yes |
Quick analogy:
– Think of PUT as replacing a full document.
– Think of PATCH as editing a sentence or two in that document.
Final Thoughts
As frontend engineers, we may not always control the backend, but understanding the intent behind these HTTP verbs helps us write clearer, more accurate, and more maintainable code, while communicating better with backend teams.
The next time you hit a REST API, ask yourself:
- Am I creating or updating?
- Am I changing the whole resource or just part of it?
- Could I be accidentally overwriting data by using the wrong method?
Learning from small interview missteps like mine can lead to stronger fundamentals, and ultimately make you a more thoughtful engineer.