Common HTTP Methods
HTTP methods define the action that a client wants to perform on a server resource.
The most commonly used HTTP methods in REST APIs are:
- GET — Retrieve data from the server.
- POST — Create a new resource.
- PUT — Update or completely replace an existing resource.
- PATCH — Partially update an existing resource.
- DELETE — Remove a resource.
GET
The GET method is used to retrieve data from the server.
It does not modify server data and is considered both safe and idempotent.
Common Uses
- Fetch user details
- Retrieve product information
- Get order history
- Search records
Example
GET /users/101
POST
The POST method is used to create a new resource on the server.
Unlike GET, POST sends data in the request body.
Common Uses
- Create a new user
- Submit forms
- Create orders
- Upload data
Example
POST /users
PUT
The PUT method updates or completely replaces an existing resource.
The client sends the complete resource representation to the server.
Common Uses
- Update an entire user profile
- Replace complete records
- Modify all resource fields
Example
PUT /users/101
PATCH
The PATCH method updates only specific fields of an existing resource.
Unlike PUT, it does not require sending the entire resource.
Common Uses
- Update email address
- Change password
- Modify profile picture
- Update account status
Example
PATCH /users/101
DELETE
The DELETE method removes an existing resource from the server.
Common Uses
- Delete users
- Remove products
- Cancel orders
- Delete records
Example
DELETE /users/101
GET vs POST vs PUT vs DELETE
| Method | Purpose | Request Body | Idempotent |
|---|---|---|---|
| GET | Retrieve data | No | Yes (Safe) |
| POST | Create a new resource | Yes | No |
| PUT | Replace or update an entire resource | Yes | Yes |
| DELETE | Remove a resource | Usually No | Yes |
PUT vs PATCH
Although both methods update resources, they behave differently.
| PUT | PATCH |
|---|---|
| Replaces the entire resource | Updates only specified fields |
| Sends the complete object | Sends only changed fields |
| Missing fields may be overwritten | Existing fields remain unchanged |
Example
Suppose a user record contains:
- Name
- Phone
- Address
Using PUT, the complete user object should be sent.
Using PATCH, only the field being updated is sent.
For example, updating only the email address.
Interview Tip:
"We used PUT for complete user profile updates to ensure every field remained synchronized, while PATCH was used for partial updates such as changing only the user's email address or password."
Best Practices
- Return 200 OK after a successful PUT request.
- Return 204 No Content after a successful PATCH request (when no response body is required).
- Ensure PATCH updates only the specified fields without removing existing data.
Can GET Create a Resource?
No.
A GET request should never be used to create a resource.
GET is designed to be:
- Safe
- Idempotent
Its only purpose is retrieving data.
Why GET Should Not Create Resources
- GET retrieves information only.
- GET requests generally do not contain request bodies.
- Browsers and proxies cache GET responses.
- Repeating a GET request should never change server data.
- REST principles reserve POST for resource creation.
Correct Approach
Use:
- POST to create a new resource.
- PUT to replace or update an existing resource.
Interview Tip:
"GET should only retrieve data and never modify server state. Resource creation should always use POST, while PUT is used for updating existing resources."
HTTP Versions Supported by REST
REST is protocol-independent, but almost all REST APIs communicate over HTTP or HTTPS.
The commonly supported HTTP versions are:
HTTP/1.1
- Most widely used.
- Traditional request-response communication.
- Supported by virtually every REST API.
HTTP/2
Improvements include:
- Multiplexing
- Header compression
- Better performance
- Reduced latency
HTTP/3
Built on the QUIC protocol.
Benefits include:
- Faster connections
- Reduced latency
- Improved reliability
- Better performance over unstable networks
Although HTTP/3 adoption is increasing, HTTP/1.1 and HTTP/2 remain the most commonly used versions for REST APIs.
HTTP Status Code Categories
HTTP status codes are grouped into five categories.
2xx — Success
The request was successfully processed.
Common examples:
- 200 OK
- 201 Created
- 204 No Content
3xx — Redirection
Additional action is required to complete the request.
Example:
- 301 Moved Permanently
4xx — Client Errors
The problem exists in the client's request.
Common examples:
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
5xx — Server Errors
The server encountered an unexpected error.
Common examples:
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
Interview Tip:
"During API testing, we validated that each scenario returned the correct HTTP status code—for example, 401 Unauthorized for invalid credentials, 404 Not Found for missing resources, and 500 Internal Server Error when the backend failed."
Best Practices
- Return appropriate HTTP status codes.
- Include meaningful error messages.
- Return structured JSON error responses.
- Avoid exposing sensitive server information.
HTTP vs HTTPS
Both HTTP and HTTPS are communication protocols used by web applications.
The difference is security.
| HTTP | HTTPS |
|---|---|
| Data is transmitted without encryption | Data is encrypted using SSL/TLS |
| Less secure | Highly secure |
| Vulnerable to Man-in-the-Middle (MITM) attacks | Protects against interception and tampering |
| Suitable only for non-sensitive communication | Recommended for all APIs |
Example
A login request:
POST /login
should always use HTTPS to encrypt:
- Username
- Password
- Authentication tokens
- Sensitive personal information
Interview Tip:
"We ensured all authentication APIs used HTTPS to encrypt sensitive information such as usernames, passwords, and access tokens, preventing Man-in-the-Middle (MITM) attacks."
Best Practices
- Always use HTTPS.
- Never transmit credentials over HTTP.
- Encrypt sensitive API communication.
- Meet industry security and compliance requirements.
FAQs
What are the common HTTP methods?
The most commonly used HTTP methods are:
- GET — Retrieve data.
- POST — Create a resource.
- PUT — Replace or update an entire resource.
- PATCH — Partially update a resource.
- DELETE — Remove a resource.
What is the difference between PUT and PATCH?
- PUT replaces the entire resource.
- PATCH updates only selected fields.
Typically:
- PUT returns 200 OK.
- PATCH often returns 204 No Content when no response body is returned.
Can you use GET to create a resource?
No.
GET is a safe and idempotent method intended only for retrieving data. Resource creation should always use POST, while PUT is used to update or replace an existing resource.
What do 2xx, 3xx, 4xx, and 5xx status codes represent?
- 2xx — Successful requests.
- 3xx — Redirection responses.
- 4xx — Client-side errors.
- 5xx — Server-side errors.
What is the difference between HTTP and HTTPS?
HTTP transmits data without encryption, whereas HTTPS uses SSL/TLS encryption to protect data during transmission and prevent Man-in-the-Middle (MITM) attacks.
Which HTTP versions are commonly used with REST APIs?
REST APIs primarily use:
- HTTP/1.1 — Most widely adopted.
- HTTP/2 — Improved performance through multiplexing.
- HTTP/3 — QUIC-based protocol offering lower latency and better reliability.
In practice, REST APIs almost always communicate over HTTP or HTTPS.