LEARN BUILD GROW TOGETHER
Practical knowledge for developers
DEVELOPER LEARNING HUB
Learn. Build. Grow Together.

Practical tutorials, real-world examples and interview preparation.

.NETC#SQL SERVERANGULAR
Home /.NET Core /HTTP Methods in .NET Core Web API: GET, POST, PUT, PATCH and DELETE Explained

HTTP Methods in .NET Core Web API: GET, POST, PUT, PATCH and DELETE Explained

November 3, 2026 5 min read , , , , ,

 

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/employees

The same endpoint can support different operations depending on the HTTP method.

HTTP methodPurposeExample
GETRetrieve dataGet employees
POSTCreate a resourceAdd an employee
PUTReplace an existing resourceUpdate employee details
PATCHPartially update a resourceChange employee department
DELETEDelete a resourceRemove 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/101

The 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 operationHTTP methodEmployee example
CreatePOSTAdd a new employee
ReadGETView employee details
UpdatePUT / PATCHModify employee information
DeleteDELETERemove 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/employees

You can also retrieve a particular employee using their ID:

GET /api/employees/101

C# 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/101

Response:

{
  "id": 101,
  "name": "Rahul",
  "department": "IT"
}

Status code:

200 OK

If the employee does not exist, the API returns:

404 Not Found

Important 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/employees

Request 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 Created

Response:

{
  "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/101

Request 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 OK

Response:

{
  "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/101

Request 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 OK

Response:

{
  "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/101

C# 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 Content

A 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"
}
ComparisonPUTPATCH
PurposeReplace resource representationPartially modify resource
Request bodyGenerally complete representationOnly required changes
IdempotentYesNot inherently
Common useUpdating employee detailsUpdating 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.

MethodOperationRequest bodyTypical success status
GETRetrieveUsually no200 OK
POSTCreateUsually yes201 Created
PUTReplaceUsually yes200 OK or 204 No Content
PATCHPartial updateUsually yes200 OK or 204 No Content
DELETEDeleteUsually no204 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:

  1. Run your .NET Core Web API application.

  2. Open Postman.

  3. Select the required HTTP method.

  4. Enter the API URL.

  5. For POST, PUT, and PATCH, select Body → raw → JSON.

  6. Enter the request JSON.

  7. Click Send.

  8. Check the response body and status code.

Here are the requests you can test:

OperationMethodURL
Get all employeesGET/api/employees
Get employee by IDGET/api/employees/101
Create employeePOST/api/employees
Replace employeePUT/api/employees/101
Update departmentPATCH/api/employees/101
Delete employeeDELETE/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