If you frequently work with APIs or backend development, you’re probably familiar with HTTP methods. GET, POST, PUT, DELETE - these are all ways we “communicate” with the server. Let’s break them down one by one in a simple way!

What are HTTP Methods?

HTTP methods are like “verbs” in communication between client and server. Each method has different tasks and uses.

Here’s an analogy: if the server is a library, then:

• GET = ask to see a book
• POST = add a new book
• PUT = replace the content of a book
• DELETE = remove a book

Commonly Used Methods

Notes:

• Idempotent: Same request multiple times produces the same effect
• Safe: Doesn’t modify data on the server

1. GET - Retrieve Data

The most commonly used method. Its function is to fetch/read data from the server.

Characteristics:

• Doesn’t modify server data
• Data sent via URL (query string)
• Can be bookmarked and cached
• Has URL length limitations (usually 2048 characters)

Usage Examples:

GET /api/users              // Get all users
GET /api/users/123          // Get user with ID 123
GET /api/users?page=1       // Get users page 1
GET /api/products?search=laptop&sort=price

When to Use GET:

• Retrieve list of data
• View data details
• Search/filter data
• Download files

Things to Consider:

• Don’t send sensitive data in URL (passwords, tokens)
• Use pagination for large datasets
• Support caching for better performance

2. POST - Create New Data

Used to create new resources/data on the server.

Characteristics:

• Data sent in request body
• Not idempotent (2 requests can create duplicate data)
• No data size limitation
• Cannot be cached

Usage Examples:

POST /api/users
Body: {
  "name": "John Doe",
  "email": "john@example.com"
}

POST /api/auth/login
Body: {
  "username": "john",
  "password": "secret123"
}

POST /api/posts
Body: {
  "title": "My First Post",
  "content": "Hello World"
}

When to Use POST:

• Create new data
• Upload files
• Submit forms
• Login/authentication
• Processes that change server state

Things to Consider:

• Validate user input
• Return status 201 (Created) on success
• Provide response with newly created data

3. PUT - Update/Replace Data

Used to update existing data, usually replacing it completely.

Characteristics:

• Data sent in request body
• Idempotent (multiple requests produce same result)
• Must send all fields (complete replacement)

Usage Examples:

PUT /api/users/123
Body: {
  "name": "John Smith",
  "email": "john.smith@example.com",
  "age": 30,
  "city": "Jakarta"
}

When to Use PUT:

• Update all fields of data
• Replace data completely
• Rewrite existing resource

Things to Consider:

• Fields not sent might become null/disappear
• Suitable for “saving” complete forms

4. PATCH - Partial Update

Like PUT, but only updates specific fields.

Characteristics:

• Data sent in request body
• Only send fields you want to change
• More efficient than PUT
• Can be non-idempotent depending on implementation

Usage Examples:

PATCH /api/users/123
Body: {
  "email": "newemail@example.com"
}

PATCH /api/posts/456
Body: {
  "published": true
}

PATCH /api/users/123
Body: {
  "name": "John Updated"
}

When to Use PATCH:

• Update only a few fields
• Partial updates
• Toggle status (active/inactive)
• Update single property

Things to Consider:

• Fields not sent remain unchanged
• Saves bandwidth
• Great for mobile apps

5. DELETE - Remove Data

Used to delete resources/data from the server.

Characteristics:

• Idempotent (deleting multiple times produces same result)
• Can use request body (optional)
• Usually returns 204 (No Content) or 200 (OK)

Usage Examples:

DELETE /api/users/123
DELETE /api/posts/456
DELETE /api/comments/789

When to Use DELETE:

• Delete data
• Remove item from list
• Cancel subscription
• Logout (delete session)

Things to Consider:

• Confirm before deleting (in frontend)
• Consider soft delete vs hard delete
• Return 404 if data doesn’t exist

PUT vs PATCH Differences

This often causes confusion. Let’s look at an example:

Scenario: Update User

Initial Data:

{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com",
  "age": 25,
  "city": "Jakarta"
}

Using PUT (Replace All)

PUT /api/users/123
Body: {
  "name": "John Smith",
  "email": "john.smith@example.com"
}

Result:
{
  "id": 123,
  "name": "John Smith",
  "email": "john.smith@example.com"
  // age and city are GONE!
}

Using PATCH (Partial Update)

PATCH /api/users/123
Body: {
  "name": "John Smith"
}

Result:
{
  "id": 123,
  "name": "John Smith",
  "email": "john@example.com",
  "age": 25,
  "city": "Jakarta"
  // Other fields remain
}

Conclusion:

• PUT: Replace everything, send complete data
• PATCH: Update partially, send only what changes

Response Status Codes

Each method has commonly used status codes:

Success Responses

Error Responses

RESTful URL Structure

Here are examples of good URL structure:

Good Practice ✅

GET    /api/users           // Get all users
GET    /api/users/123       // Get specific user
POST   /api/users           // Create new user
PUT    /api/users/123       // Update user (full)
PATCH  /api/users/123       // Update user (partial)
DELETE /api/users/123       // Delete user

GET    /api/users/123/posts       // Get user's posts
POST   /api/users/123/posts       // Create post for user
DELETE /api/users/123/posts/456   // Delete user's post

Bad Practice ❌

GET  /api/getUsers
GET  /api/getUserById?id=123
POST /api/createUser
POST /api/updateUser
POST /api/deleteUser
GET  /api/user-posts?userId=123

Tips:

• Use nouns, not verbs
• Use plural for collections (/users not /user)
• Nested resources for relations (/users/123/posts)

Idempotent vs Non-Idempotent

Idempotent Methods ✅

Multiple requests = same result

GET  /api/users/123     // Fetch data, doesn't change
PUT  /api/users/123     // Update to same data = same result
DELETE /api/users/123   // Delete what's already gone = still gone

Non-Idempotent Methods ❌

Multiple requests = different results

POST /api/users
// 3 requests = 3 new users

POST /api/orders
// 2 requests = 2 separate orders

Why is this important?

• Idempotent methods are safer to retry
• If network error occurs, can retry without worry
• POST needs caution as it can create duplicates

Best Practices

1. Use Appropriate Methods

Don’t use POST for everything. Choose semantically correct methods.

2. Be Consistent with REST Principles

Follow REST conventions so APIs are predictable and easy to understand.

3. Return Meaningful Data

// Success
{
  "success": true,
  "data": { ... },
  "message": "User created successfully"
}

// Error
{
  "success": false,
  "error": {
    "code": "USER_NOT_FOUND",
    "message": "User with ID 123 not found"
  }
}

4. Support Pagination

For GET that returns lots of data:

GET /api/users?page=1&limit=20

Response:
{
  "data": [...],
  "pagination": {
    "page": 1,
    "limit": 20,
    "total": 150,
    "totalPages": 8
  }
}

5. Versioning

GET /api/v1/users
GET /api/v2/users

Or via header:

GET /api/users
Header: Accept: application/vnd.api.v1+json

6. Security

• Use HTTPS
• Validate all input
• Implement rate limiting
• Authentication & authorization
• Sanitize output

Common Mistakes

1. Using GET for Operations that Modify Data

❌ GET /api/users/123/delete
✅ DELETE /api/users/123

2. Using POST for All Operations

❌ POST /api/getUsers
❌ POST /api/updateUser
✅ GET /api/users
✅ PUT /api/users/123

3. Not Handling Errors Properly

❌ Return 200 for all responses
✅ Use appropriate status codes

4. Inconsistent URLs

❌ /api/getUser, /api/user-create, /api/DeleteUser
✅ /api/users (use methods for operations)

Conclusion

HTTP methods are an important foundation in backend development and REST APIs. By understanding and using the right methods, your API will be:

• More semantic - Clear intent from the method
• Standard - Follows common conventions
• Maintainable - Other developers immediately understand
• Predictable - Behavior matches expectations

Key Takeaways:

• GET for reading data (safe & idempotent)
• POST for creating new data (not idempotent)
• PUT for replacing complete data (idempotent)
• PATCH for partial data updates
• DELETE for removing data (idempotent)

Don’t just use POST for everything. Start simple, be consistent, and always improve 😊

References

• MDN - HTTP Methods
• REST API Tutorial
• HTTP Status Codes