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.

Advertisement

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
  • Email
  • 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:

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.