Introduction
In the previous article, we learned how a .NET Core Web API processes an incoming HTTP request, executes the required logic, and returns a response to the client.
Now let's understand an important part of that communication: HTTP Methods.
Imagine you are developing an Employee Management application. Users should be able to:
View all employees.
View a particular employee.
Add a new employee.
Update existing employee information.
Delete an employee record.
How does the client tell the API which operation it wants to perform?
This is where HTTP methods come into the picture.
HTTP methods describe the intended operation that a client wants to perform on a resource.
In this article, we'll understand five commonly used HTTP methods and implement them using C# in a .NET Core Web API.
1. What are HTTP Methods?
HTTP methods are part of the HTTP protocol. They indicate the intended action for a particular request.
For example, consider this API endpoint:
/api/employeesThe same endpoint can support different operations depending on the HTTP method.
| HTTP method | Purpose | Example |
|---|---|---|
| GET | Retrieve data | Get employees |
| POST | Create a resource | Add an employee |
| PUT | Replace an existing resource | Update employee details |
| PATCH | Partially update a resource | Change employee department |
| DELETE | Delete a resource | Remove an employee |
Notice that the URL can remain the same while the HTTP method changes.
For example:
GET /api/employees
POST /api/employees
GET /api/employees/101
PUT /api/employees/101
PATCH /api/employees/101
DELETE /api/employees/101The API identifies the operation using both the HTTP method and the requested URL.
2. Understand CRUD operations and HTTP methods
Before writing code, let's connect HTTP methods with CRUD operations.
CRUD stands for:
Create
Read
Update
Delete
These are the four fundamental operations performed on application data.
| CRUD operation | HTTP method | Employee example |
|---|---|---|
| Create | POST | Add a new employee |
| Read | GET | View employee details |
| Update | PUT / PATCH | Modify employee information |
| Delete | DELETE | Remove an employee |
For example, when an administrator adds a new employee, the client sends a POST request.
When the administrator opens the employee list, the client sends a GET request.
This mapping is commonly used when designing RESTful APIs.
3. GET – Retrieve data
The GET method is used to retrieve information from the server.
It should not be used to create, delete, or modify application resources.
Consider an Employee Management application.
You want to retrieve all employees.
API endpoint:
GET /api/employeesYou can also retrieve a particular employee using their ID:
GET /api/employees/101C# implementation
[HttpGet]
public IActionResult GetEmployees()
{
return Ok(Employees);
}
[HttpGet("{id:int}")]
public IActionResult GetEmployeeById(int id)
{
var employee = Employees.FirstOrDefault(x => x.Id == id);
if (employee is null)
{
return NotFound(new
{
Message = "Employee not found."
});
}
return Ok(employee);
}Expected response
Request:
GET /api/employees/101Response:
{
"id": 101,
"name": "Rahul",
"department": "IT"
}Status code:
200 OKIf the employee does not exist, the API returns:
404 Not FoundImportant points about GET
GET is used to retrieve resources.
It should not modify server-side resource state.
GET requests are considered safe.
GET is idempotent, meaning repeating the same request should have the same intended effect on server state.
GET responses can be cached when appropriate HTTP caching rules permit it.
4. POST – Create a new resource
The POST method is commonly used to create a new resource.
Suppose an administrator wants to add a new employee to the system.
The client sends employee information in the request body.
API endpoint:
POST /api/employeesRequest body:
{
"name": "Amit",
"department": "Finance"
}C# implementation
[HttpPost]
public IActionResult CreateEmployee(Employee employee)
{
employee.Id = Employees.Count == 0
? 1
: Employees.Max(x => x.Id) + 1;
Employees.Add(employee);
return CreatedAtAction(
nameof(GetEmployeeById),
new { id = employee.Id },
employee
);
}Expected response
Status code:
201 CreatedResponse:
{
"id": 103,
"name": "Amit",
"department": "Finance"
}CreatedAtAction() returns a 201 Created response and includes a location identifying the newly created resource.
Important points about POST
POST is commonly used to create resources.
Data is generally sent in the request body.
POST is not inherently idempotent.
Sending the same POST request multiple times may create multiple resources unless the application implements duplicate prevention or idempotency handling.
Real-world example: When a user submits a registration form, the frontend can send a POST request to create a new user account.
5. PUT – Update an existing resource
The PUT method is generally used to replace the current representation of a resource with the representation provided in the request.
Suppose an employee has the following details:
{
"id": 101,
"name": "Rahul",
"department": "IT"
}Now the administrator wants to update the employee's information.
API endpoint:
PUT /api/employees/101Request body:
{
"name": "Rahul Sharma",
"department": "Engineering"
}C# implementation
[HttpPut("{id:int}")]
public IActionResult UpdateEmployee(int id, Employee updatedEmployee)
{
var employee = Employees.FirstOrDefault(x => x.Id == id);
if (employee is null)
{
return NotFound(new
{
Message = "Employee not found."
});
}
employee.Name = updatedEmployee.Name;
employee.Department = updatedEmployee.Department;
return Ok(employee);
}Expected response
Status code:
200 OKResponse:
{
"id": 101,
"name": "Rahul Sharma",
"department": "Engineering"
}Important points about PUT
PUT is generally used to replace a resource representation.
The client normally sends the complete representation of the resource being updated.
PUT is idempotent.
Sending the same PUT request multiple times should produce the same intended final resource state.
Important distinction: PUT does not automatically update a database record. The controller or application logic must perform the actual update operation.
6. PATCH – Partially update a resource
PATCH is used when you want to update only a specific part of an existing resource.
Let's understand this with the same employee example.
Current employee information:
{
"id": 101,
"name": "Rahul",
"department": "IT"
}Suppose the employee changes departments, but their name remains the same.
You only need to update the department.
API endpoint:
PATCH /api/employees/101Request body:
{
"department": "Engineering"
}C# implementation
For this example, we'll create a small request model containing only the field that can be changed.
public class UpdateEmployeeDepartmentRequest
{
public string Department { get; set; } = string.Empty;
}Now add the PATCH action:
[HttpPatch("{id:int}")]
public IActionResult UpdateEmployeeDepartment(
int id,
UpdateEmployeeDepartmentRequest request)
{
var employee = Employees.FirstOrDefault(x => x.Id == id);
if (employee is null)
{
return NotFound(new
{
Message = "Employee not found."
});
}
employee.Department = request.Department;
return Ok(employee);
}Expected response
Status code:
200 OKResponse:
{
"id": 101,
"name": "Rahul",
"department": "Engineering"
}Notice that only the department was changed. The employee's name remained unchanged.
Important points about PATCH
PATCH is used for partial updates.
The client sends only the information required for the update.
PATCH is not inherently idempotent, although a particular PATCH operation can be designed to be idempotent.
PATCH does not require you to use a particular request-body format. The API and its documentation should define the expected patch format.
Real-world example: A profile management application may allow a user to update only their phone number without submitting their entire profile again.
7. DELETE – Remove a resource
The DELETE method is used to request the removal of a resource.
Suppose an administrator wants to remove employee ID 101.
API endpoint:
DELETE /api/employees/101C# implementation
[HttpDelete("{id:int}")]
public IActionResult DeleteEmployee(int id)
{
var employee = Employees.FirstOrDefault(x => x.Id == id);
if (employee is null)
{
return NotFound(new
{
Message = "Employee not found."
});
}
Employees.Remove(employee);
return NoContent();
}Expected response
Status code:
204 No ContentA 204 response means the operation succeeded and there is no response body.
Important points about DELETE
DELETE is used to remove a resource.
DELETE is idempotent in terms of its intended effect on server state.
Repeating a DELETE request should not delete additional copies of the same resource.
The response to a repeated request does not have to be identical. For example, the first request might return 204 and a later request might return 404.
Real-world example: When an administrator removes an employee from an application, the frontend sends a DELETE request to the API.
8. Difference between PUT and PATCH
This is one of the most common questions asked during .NET developer interviews.
Both PUT and PATCH are used to update resources, but their intended behavior is different.
Consider an employee record:
{
"id": 101,
"name": "Rahul",
"department": "IT",
"location": "Delhi"
}Now suppose you want to change only the department.
Using PUT
A PUT request generally provides the complete replacement representation:
{
"name": "Rahul",
"department": "Engineering",
"location": "Delhi"
}Using PATCH
A PATCH request can provide only the field that needs to change:
{
"department": "Engineering"
}| Comparison | PUT | PATCH |
|---|---|---|
| Purpose | Replace resource representation | Partially modify resource |
| Request body | Generally complete representation | Only required changes |
| Idempotent | Yes | Not inherently |
| Common use | Updating employee details | Updating one employee field |
Remember: The exact update behavior depends on how the API implements its PUT and PATCH operations.
9. Complete HTTP methods comparison
Let's summarize all five methods.
| Method | Operation | Request body | Typical success status |
|---|---|---|---|
| GET | Retrieve | Usually no | 200 OK |
| POST | Create | Usually yes | 201 Created |
| PUT | Replace | Usually yes | 200 OK or 204 No Content |
| PATCH | Partial update | Usually yes | 200 OK or 204 No Content |
| DELETE | Delete | Usually no | 204 No Content |
These are common patterns, not mandatory response codes for every possible API implementation.
10. Test the API using Postman
After implementing the controller, you can test the endpoints using Postman.
Follow these steps:
Run your .NET Core Web API application.
Open Postman.
Select the required HTTP method.
Enter the API URL.
For POST, PUT, and PATCH, select Body → raw → JSON.
Enter the request JSON.
Click Send.
Check the response body and status code.
Here are the requests you can test:
| Operation | Method | URL |
|---|---|---|
| Get all employees | GET | /api/employees |
| Get employee by ID | GET | /api/employees/101 |
| Create employee | POST | /api/employees |
| Replace employee | PUT | /api/employees/101 |
| Update department | PATCH | /api/employees/101 |
| Delete employee | DELETE | /api/employees/101 |
Note: The example uses an in-memory list. Data is not permanently saved, and restarting the application resets the list. We'll introduce database connectivity later in Week 2.
11. Common mistakes developers should avoid
1. Using GET to modify data
GET should retrieve resources, not perform operations that change server-side state.
2. Using POST for every operation
Although POST can support many types of processing, use the HTTP method that accurately describes the intended operation when designing a resource-oriented API.
3. Confusing PUT and PATCH
PUT generally replaces a resource representation, while PATCH applies partial modifications.
4. Ignoring status codes
A successful API response and a failed API response should not return the same status code. Use meaningful HTTP status codes.
5. Assuming DELETE always physically removes a database record
Real applications may implement soft deletion, where a record is marked inactive instead of being physically deleted.
6. Forgetting input validation
An API should validate incoming data before processing it. We'll cover DTOs and model validation in Day 9.
12. Interview questions
Q1. What are HTTP methods in Web API?
HTTP methods indicate the intended operation that a client wants to perform on a resource. Common methods include GET, POST, PUT, PATCH, and DELETE.
Q2. What is the difference between POST and PUT?
POST is commonly used to create resources or submit data for processing. PUT is generally used to replace an existing resource representation. POST is not inherently idempotent, whereas PUT is idempotent.
Q3. What is the difference between PUT and PATCH?
PUT generally replaces the resource representation, whereas PATCH applies partial modifications to a resource.
Q4. Which HTTP method is used to retrieve data?
GET is used to retrieve data from an API.
Q5. Which HTTP method is used to delete a resource?
DELETE is used to request the removal of a resource.
Q6. What is an idempotent HTTP method?
An idempotent method is one where making the same request multiple times has the same intended effect on server state as making it once. GET, PUT, and DELETE are idempotent methods.
Q7. Is POST idempotent?
POST is not inherently idempotent. Repeating the same POST request may create multiple resources unless the application implements idempotency or duplicate prevention.
Q8. What is the difference between 200 OK and 201 Created?
200 OK indicates that the request was successfully processed. 201 Created indicates that the request resulted in the creation of a resource.
Q9. What does 204 No Content mean?
It means the request was successfully processed, but the server has no response content to return.
Q10. Can we use the same URL for different HTTP methods?
Yes. For example, /api/employees can support GET to retrieve employees and POST to create an employee. Routing uses the HTTP method and URL to identify the appropriate endpoint.
Conclusion
HTTP methods are fundamental to building well-designed .NET Core Web APIs.
Understanding when to use GET, POST, PUT, PATCH, and DELETE helps you design predictable APIs and communicate effectively with frontend applications.
In our Employee Management example, we used:
GET to retrieve employees.
POST to create an employee.
PUT to replace employee information.
PATCH to update a specific field.
DELETE to remove an employee.
Now you have a practical understanding of how CRUD operations map to HTTP methods.
What's next?
In Day 4, we'll explore Minimal APIs vs Controllers in .NET Core Web API.
We'll understand both approaches, compare their architecture, explore their code structure, and learn when to choose each approach while building real-world applications.
Skills Tutorials – Learn • Build • Grow Together
Continue learning with our 30-day .NET Core Web API series.
No comments:
Post a Comment