Imagine you're in a backend interview.
The interviewer asks:
"Design an API for a food delivery application."
You quickly answer:
POST /createOrderThe interviewer smiles and asks,
"Why POST and not PUT?"
Most candidates stop there.
This article covers the HTTP and REST concepts interviewers actually expect you to know.
What is HTTP?
HTTP (HyperText Transfer Protocol) is the communication protocol between clients and servers.
Every request follows the same lifecycle.
Client
↓
HTTP Request
↓
Server
↓
HTTP Response
↓
ClientA request contains:
- URL
- HTTP Method
- Headers
- Body (optional)
Example:
POST /users HTTP/1.1
Content-Type: application/json
Authorization: Bearer eyJhbGc...{
"name":"Jitesh",
"email":"jitesh@gmail.com"
}The server responds with
201 Created{
"id":101,
"name":"Jitesh"
}HTTP Methods
Choosing the correct HTTP method is one of the easiest ways interviewers judge your API design skills.
GET
Used to fetch data.
GET /users/101Should never modify data.
Multiple GET requests should always return the same resource.
GET
Safe ✅
Idempotent ✅POST
Creates a new resource.
POST /users{
"name":"Jitesh"
}Response
201 CreatedPOST is not idempotent.
Calling it twice creates two users.
PUT
Replaces an entire resource.
PUT /users/101{
"name":"Jitesh",
"city":"Delhi"
}Every field should be included.
Missing fields are usually overwritten.
PUT is idempotent.
Calling it ten times produces the same result.
PATCH
Updates only selected fields.
PATCH /users/101{
"city":"Pune"
}Only the city changes.
Everything else remains unchanged.
PATCH is generally considered idempotent if the same patch always produces the same final state.
DELETE
Removes a resource.
DELETE /users/101Calling DELETE multiple times still results in the resource being deleted.
Therefore,
DELETE
Idempotent ✅Safe vs Idempotent
One of the most common interview questions.
| Method | Safe | Idempotent | |---------|------|------------| | GET | ✅ | ✅ | | POST | ❌ | ❌ | | PUT | ❌ | ✅ | | PATCH | ❌ | Usually ✅ | | DELETE | ❌ | ✅ |
Safe means
It doesn't change server data.
Idempotent means
Performing the same request multiple times has the same final effect.
What is Idempotency?
Suppose you're paying ₹1000 online.
You click Pay.
Your internet disconnects.
You click Pay again.
Without idempotency...
₹1000
+
₹1000
=
₹2000 ❌Production systems prevent this using an Idempotency Key.
POST /payments
Idempotency-Key:
9e82-123-abcdThe server stores this key.
If another request arrives with the same key,
it simply returns the previous response.
Request 1
↓
Payment Created
-------------------
Request 2
↓
Same Key
↓
Return Existing PaymentThis concept is heavily used in payment gateways like Stripe and Razorpay.
HTTP Status Codes
Interviewers expect you to know more than just 200.
200 OK
Request completed successfully.
GET /users/101201 Created
A new resource was created.
POST /users204 No Content
Operation succeeded.
No response body is returned.
Often used with DELETE.
DELETE /users/101400 Bad Request
The client sent invalid data.
{
"email":"abc"
}Invalid request.
401 Unauthorized
Authentication failed.
Examples:
- Missing JWT
- Expired JWT
- Invalid Token
403 Forbidden
User is authenticated.
But doesn't have permission.
User
↓
Trying to access
/admin
↓
403404 Not Found
Resource doesn't exist.
GET /users/99999409 Conflict
Usually returned when the request conflicts with existing data.
Examples:
- Duplicate Email
- Duplicate Username
- Version Conflict
500 Internal Server Error
Unexpected server failure.
NullPointerException.
Database failure.
Unhandled exception.
Designing Good REST APIs
Bad API
POST /createUser
GET /getUsers
DELETE /deleteUserGood API
POST /users
GET /users
GET /users/101
PATCH /users/101
DELETE /users/101Notice something.
The URL represents a resource, not an action.
The HTTP method defines the action.
Resource Naming
Use nouns.
/users
/orders
/products
/paymentsAvoid verbs.
/createUser
/updateOrder
/deleteProductNested Resources
Instead of
/getCommentsByPostprefer
GET /posts/101/commentsMuch cleaner.
Filtering
Avoid creating multiple endpoints.
Instead of
/getActiveUsers
/getInactiveUsers
/getAdminUsersUse query parameters.
GET /users?status=ACTIVE
GET /users?role=ADMINPagination
Never return one million records.
Bad
GET /usersGood
GET /users?page=1&size=20Even better
GET /users?cursor=abc123Cursor pagination performs much better at scale.
API Versioning
APIs evolve.
Old mobile applications may still depend on older endpoints.
Instead of breaking clients,
create versions.
/api/v1/users
/api/v2/usersThis allows gradual migration.
Large companies often support multiple API versions simultaneously.
Good API Responses
A consistent response format makes frontend integration easier.
Success
{
"success": true,
"data": {
"id": 101,
"name": "Jitesh"
}
}Error
{
"success": false,
"message": "User not found"
}Consistency matters more than the exact structure.
Common Interview Questions
PUT vs PATCH?
PUT replaces the entire resource.
PATCH updates only specific fields.
Why is POST not idempotent?
Because sending the same POST request multiple times can create multiple resources.
Why shouldn't GET modify data?
GET requests may be cached, retried, or pre-fetched by browsers and proxies. They should never have side effects.
When would you return 409 instead of 400?
Return 409 Conflict when the request is valid, but it conflicts with the current state of the resource, such as creating a user with an email that already exists.
How do payment systems avoid duplicate payments?
By using Idempotency Keys.
Even if the client retries the request, only one payment is processed.
Final Thoughts
Most interviewers aren't testing whether you've memorized HTTP status codes.
They're evaluating whether you understand how production APIs are designed.
A well-designed API is:
- Predictable
- Consistent
- Idempotent where required
- Properly versioned
- Uses the correct HTTP methods
- Returns meaningful status codes
These fundamentals appear in almost every backend and full stack interview. Master them once, and you'll use them throughout your career.