In .NET 9, a new method, Task.WhenEach, has been introduced to streamline asynchronous programming. This method allows you to process tasks as they complete, rather than waiting for all tasks to finish. This is particularly useful in scenarios where tasks have varying completion times and you want to act on each one as soon as it's done.

Step 1. Create a function named PrintWithDelay
async Task<int> PrintWithDelay(int delay)
{
await Task.Delay(delay);
return delay;
}

This code defines an asynchronous method named PrintWithDelay that takes an integer delay as input and returns an integer.

async Task<int>

• async: This keyword indicates that the method is asynchronous, meaning it can yield execution to other tasks while waiting for I/O operations or other asynchronous operations to complete.
• Task<int>: This specifies the return type of the method. It will return a Task object that, when awaited, will yield the integer result.

await Task.Delay(delay)

• Task.Delay(delay): This creates a new task that will complete after the specified delay milliseconds.
• await: This keyword pauses the execution of the current method until the Task.Delay task completes. While waiting, the thread can be used by other tasks.

return delay
Once the delay has elapsed, the method resumes execution and returns the original delay value.

Step 2. Create a list of tasks that will each execute the PrintWithDelay method with different delay values.
List<Task<int>> printTasks = [
PrintWithDelay(4000),
PrintWithDelay(6000),
PrintWithDelay(2000)
];

• This declares a list named printTasks to store tasks. Each task in this list will return an integer.
• There are three calls to the PrintWithDelay method, each with a different delay value (4000, 6000, and 2000 milliseconds, respectively).
• Each call returns a Task<int>, representing an asynchronous operation that will eventually return an integer.
• These tasks are added to the printTasks list.

Step 3. Utilize Task.WhenEach in .NET 9.

Task.WhenEach yields an IAsyncEnumerable, allowing asynchronous processing of tasks as they complete.
await foreach (var task in Task.WhenEach(printTasks))
{
Console.WriteLine(await task);
}

Task.WhenEach(printTasks)

• This part takes a collection of Task<int> objects (stored in printTasks).
• It returns an IAsyncEnumerable<Task<int>>. This enumerable represents a sequence of tasks that will complete over time.

await foreach (var task in Task.WhenEach(printTasks))

• This is an asynchronous foreach loop that iterates over the IAsyncEnumerable returned by Task.WhenEach.
• The await keyword signifies that the loop will pause execution until the next task in the sequence completes.

In short, the code does the following

• Schedules Tasks: The printTasks are scheduled to run asynchronously.
• Processes Completed Tasks: As each task completes, it is yielded from the Task.WhenEach enumerable.
• Logs Task Completion: The await foreach loop iterates over these completed tasks, and for each one, it logs a message to the console, which includes the task's status and result.

Output

By leveraging Task.WhenEach, you can write more efficient and responsive asynchronous code in .NET 9. Happy Coding!

Because it enables the development of applications that expand and adapt to the requirements of various services and platforms, web API development is a crucial part of the current development scenario. CRUD actions, which enable the fundamental interface with the application's data, are one of the cornerstone procedures in the development of APIs. Starting with CRUD operations makes perfect sense if you are "green" with.NET Core because it teaches you the basics of creating a Web API and handling data.

The creation of a.NET Core 8 Web API project and the specification of the endpoints for each CRUD operation will be covered in this tutorial. Effective data handling techniques are outlined by the Entity Framework Core, an ORM system made to communicate with.NET databases. By the end of this article, you will have mastered the fundamentals of RESTful design in.NET Core and developed a functional Web API that can manipulate data.

This tutorial is intended for both a novice front-end developer looking to hone their skills and an aspiring backend developer with experience in.NET Core 8 API development. Therefore, you will undoubtedly learn how to begin creating APIs in.NET Core 8 if you fit into either of the two categories. Let's go over this initial phase.

Open Visual Studio 2022 and Choose "Create a new project".

On the Create a new project page, search for "Web API" on the search bar, select the project template and press the "next" button.

On the configuration of the project, enter the Project Name and choose the check box to keep the solution file and project in the same directory.

To configure the Framework version, tick the boxes according to the screenshot, and click "create" on the project's additional details page. To get things started, it will generate the project using the default files.

Initially, the project folder structure looked like this.

First, we need to install the packages required for the ORM to interact with the Database. To install the packages, Right click on the solution and choose "Manage NuGet Packages... "

On the NuGet page, search for the below two packages and install the versions above 8.
Microsoft.EntityFrameworkCore.Tools
Microsoft.EntityFrameworkCore.SqlServer

Then, Right-click on the solution. Create a new Class file named Employee.cs and paste the code.
namespace EmployeePortal.Models.Entities
{
    public class Employee
    {
        public Guid Id { get; set; }
        public required string Name { get; set; }
        public required string Email { get; set; }
        public required string PhoneNumber { get; set; }
        public decimal Salary { get; set; }
    }
}

Then, we need to create a DB Context file for the application that holds the configuration for the ORM and its Entities. Create a file named ApplicationDbContext.cs and paste the below code.
using EmployeePortal.Models.Entities;
using Microsoft.EntityFrameworkCore;
namespace EmployeePortal
{
    public class ApplicationDbContext : DbContext
    {
        public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
            : base(options)
        {
        }
        public DbSet<Employee> Employees { get; set; }
    }
}

Then, we need to add a DB connection string to the appsettings.json file.
"ConnectionStrings": {
  "DefaultConnection": "Server=your_server_name;Database=your_database_name;User Id=your_username;Password=your_password;TrustServerCertificate=True;"
}

Then, we need to add the SQL Server services to our Program.cs file and add the below code to the program file under the services, which tells the application to use the SQL server from the connection string.
builder.Services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(
    builder.Configuration.GetConnectionString("DefaultConnection")));

Now, we add a migration to create a snapshot of our entities from the application because we are using the Code First Approach in EF. So, we need to specify the entities and their relationships, and then we run the migration which will create a Database and tables based on the relationship of the entities.

Open the package manager console and run the following commands.

• add-migration "initial one": generates a migration file based on the current state of your data models compared to the database schema.
• update-database: applies the migration to your database, creating or altering tables, columns, or relationships as defined in the migration file.

Now, If you open the SQL server, you can see the database and the tables.

We need to create a Web API controller to fetch the data from the database through the endpoints. Right-click on the controller's folder and choose to add a new Web API Controller.

You can request the endpoints using the necessary information.

Endpoints and their use cases with return types

• Get All Employees: it is GET api/employees. Method: GetEmployees(). Purpose: Fetches all the employees from the store. Response: Returns an Ok (HTTP 200) status with the body, which contains the list of employees.
• Get Employee by ID: it is GET api/employees/{id}. Method: GetEmployeeById(Guid id). Purpose: Use unique IDs to retrieve an employee. Response: Returns an Ok (HTTP 200) status and data about an employee when such is available, however, there is a risk that if no such employees can be traced then one will be returned as NotFound (HTTP 404).
• Add a New Employee: it is POST api/employees. Method: AddEmployee(EmployeeDto employees). Purpose: Whenever an employee Dto record is transmitted to the application, the application updates the defined employees in the store. Response: Returned 201 Created status whenever an employer is successfully added.
• Update Employee: it is PUT api/employees/{id}. Method: UpdateEmployee(Guid id, UpdateEmployeeDto employeeDto). Purpose: One has to search the employee by the unique ID and change his information. Response: If the updates work effectively, they return an Ok (HTTP 200) status, while the NotFound (HTTP 404) will be resolved in situations where no suitable culprit persons are available.
• Delete Employee: it is DELETE api/employees/{id}. Method: DeleteEmployee(Guid id). Purpose: When databases are directed to delete certain profiles, the corresponding unique ID numbers are used. Response: If it works, returns NoContent (HTTP 204) in situations where the deletion was successful, whereas NotFound (HTTP 404) if no matching employee is found.

Conclusion
In this article, we explored a basic implementation of CRUD operations for managing employee data in a .NET Core Web API. By following these steps, we created endpoints to add, retrieve, update, and delete employees, using DTOs to encapsulate and simplify data transfer. This approach helps establish a solid foundation for building RESTful APIs and managing data flow in a secure and organized manner.

So, Let's get started.

Exception Filter in ASP.NET Core
Exception Filter allows us to handle unhandled exceptions that occur while processing an HTTP request within our application. Exception Filters in ASP.NET Core Applications are used for tasks such as Logging Exceptions, Returning Custom Error Responses, and Performing any other necessary action when an exception occurs.

Exception Filter also provides a way to centralize the exception-handling logic and keep it separate from our controller or from the business and data access logic, making our code more organized and maintainable.

IExceptionFilter

• IExceptionFilter is an interface in ASP.NET Core that provides a mechanism for handling exceptions that occur during the processing of a request. By implementing IExceptionFilter, you can write custom logic to handle exceptions globally or per-controller.
• Advantages of IExceptionFilter
• Centralized Exception Handling: You can manage all your exceptions in a single place, making it easier to maintain and modify your exception-handling strategy.
• Separation of Concerns: By handling exceptions separately, you keep the error-handling logic away from your business logic, improving code readability and maintainability.
• Consistent Error Responses: It allows you to standardize the way errors are reported back to the client, which can improve the API's usability. You can return consistent model formats, error codes, and messages.
• Access to HttpContext: Since filters have access to the `HttpContext`, you can easily log errors, modify responses, or perform any other operation based on the context of the request.
• Interception of All Exceptions: It can catch exceptions that aren't handled anywhere else, ensuring that your application can respond gracefully to unexpected errors.
• Custom Logic: You can implement any custom logic needed for exception handling, such as logging specific exceptions differently.

Disadvantages of IExceptionFilter

• Global Scope: When implemented globally, all exceptions will be handled by the same filter. This might not be desirable if different controllers or actions require different handling strategies.
• Complex Error Handling Logic: If you have complex error-handling needs, managing too many unique cases in a single filter could lead to convoluted code.
• Performance Concerns: Introducing additional logic in exception handling can potentially add overhead, especially if the handling involves extensive processing or logging.
• Limited to Web Context: Unlike middleware, exception filters are limited in scope to the MVC pipeline. They cannot handle exceptions that occur outside of the controller actions, such as in middleware.
• Difficulty in Testing: Since exception filters are tied to the ASP.NET injection system, they can introduce complexity when writing unit tests, particularly if they depend on the HttpContext.

Implementing IExceptionFilter
Implementing IExceptionFilter can greatly benefit your ASP.NET Core applications by providing structured and centralized exception handling. However, balance must be struck in how it's used to avoid complexity, ensure performance, and maintain flexibility. Choosing the right approach to exception handling may also involve combining it with other options like middleware, custom error pages, or even using logged service responses as needed.
public class HandleExceptionFilter : IExceptionFilter
    {
      private readonly ILogger<HandleExceptionFilter> _logger;
      public HandleExceptionFilter(ILogger<HandleExceptionFilter> logger)
        {
            _logger = logger;
        }

      public override void OnException(ExceptionContext filterContext)
        {
            bool isAjaxCall = filterContext.HttpContext.Request.Headers["x-requested-with"] == "XMLHttpRequest";
            filterContext.HttpContext.Session.Clear();

            if (isAjaxCall)
            {
                filterContext.HttpContext.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
                var data = new
                {
                    filterContext.Exception.Message,
                    filterContext.Exception.StackTrace
                };
                filterContext.Result = new JsonResult(data);
                filterContext.ExceptionHandled = true;
            }

            if (!isAjaxCall)
            {
                filterContext.Result = new RedirectResult("/Error/Error");
            }

            _logger.LogError(GetExceptionDetails(filterContext.Exception));

            filterContext.ExceptionHandled = true;
            base.OnException(filterContext);

        }

       private string GetExceptionDetails(Exception exception)
        {
            var properties = exception.GetType()
                .GetProperties();
            var fields = properties
                .Select(property => new
                {
                    Name = property.Name,
                    Value = property.GetValue(exception, null)
                })
                .Select(x => $"{x.Name} = {(x.Value != null ? x.Value.ToString() : String.Empty)}");
            return String.Join("\n", fields);
        }
    }

// Register the filter in Startup.cs

public void ConfigureServices(IServiceCollection services)
  {
    services.AddControllers(options =>
     {
         options.Filters.Add<HandleExceptionFilter>();
     });
  }

// Above .net 6

builder.Services.AddScoped<HandleExceptionFilter>();

Then, add the name as EmployeesController.cs and paste the code below.
using EmployeeAdminPortal.Data;
using EmployeeAdminPortal.DTO;
using EmployeeAdminPortal.Models.Entities;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;

namespace EmployeeAdminPortal.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class EmployeesController : ControllerBase
    {
        private readonly ApplicationDbContext _dbContext;

        public EmployeesController(ApplicationDbContext dbContext)
        {
            _dbContext = dbContext;
        }

        [HttpGet]
        public IActionResult GetEmployees()
        {
            return Ok(_dbContext.Employees);
        }

        [HttpGet]
        [Route("{id:guid}")]
        public IActionResult GetEmployeeById(Guid id)
        {
            var employee = _dbContext.Employees.Find(id);
            if (employee == null)
            {
                return NotFound();
            }
            return Ok(employee);
        }

        [HttpPost]
        public IActionResult AddEmployee(EmployeeDto employeeDto)
        {
            var employee = new Employee
            {
                Name = employeeDto.Name,
                Email = employeeDto.Email,
                PhoneNumber = employeeDto.PhoneNumber,
                Salary = employeeDto.Salary
            };
            _dbContext.Employees.Add(employee);
            _dbContext.SaveChanges();
            return StatusCode(StatusCodes.Status201Created);
        }

        [HttpPut]
        [Route("{id:guid}")]
        public IActionResult UpdateEmployee(Guid id, UpdateEmployeeDto employeeDto)
        {
            var employee = _dbContext.Employees.Find(id);
            if (employee == null)
            {
                return NotFound();
            }
            employee.Name = employeeDto.Name;
            employee.Email = employeeDto.Email;
            employee.PhoneNumber = employeeDto.PhoneNumber;
            employee.Salary = employeeDto.Salary;
            _dbContext.SaveChanges();
            return Ok(employee);
        }

        [HttpDelete]
        [Route("{id:guid}")]
        public IActionResult DeleteEmployee(Guid id)
        {
            var employee = _dbContext.Employees.Find(id);
            if (employee == null)
            {
                return NotFound();
            }
            _dbContext.Employees.Remove(employee);
            _dbContext.SaveChanges();
            return NoContent();
        }
    }
}

Also, you need to create a new folder for DTO(Data Transfer Objects), which is used to transfer data between layers or services within an application.
Create two DTO files named EmployeeDto.cs and UpdateEmployeeDto.cs.
// Employee DTO
namespace EmployeePortal.DTO
{
    public class EmployeeDto
    {
        public required string Name { get; set; }
        public required string Email { get; set; }
        public required string PhoneNumber { get; set; }
        public decimal Salary { get; set; }
    }
}

UpdateEmployeeDto.cs
// Update Employee DTO
namespace EmployeePortal.DTO
{
    public class UpdateEmployeeDto
    {
        public string? Name { get; set; }
        public string? Email { get; set; }
        public string? PhoneNumber { get; set; }
        public decimal Salary { get; set; }
    }
}

Then, build and run your application. You can able to see the endpoints of our application on the chrome with the help of Swagger.

Building scalable and reliable apps is now simpler than ever thanks to.NET 8 and Entity Framework Core (EF Core). Making models that map to database tables is a crucial step in developing a data-driven application because it enables object-oriented data manipulation. This post will demonstrate how to use.NET 8 and Entity Framework Core to create a model and link it to a database table.

Prerequisites
Before we dive in, make sure you have the following set up.

• .NET SDK 8.0 or higher.
• Visual Studio or VS Code installed. In my scenario, I will develop the project in Visual Studio.
• Basic knowledge of C# and object-oriented programming.

Step 1. Setting Up the Project
First, create a new .NET 8 project. In this example, we'll make an ASP.NET Core Web API project, but the process is similar for other types of .NET applications.
Open Visual Studio and click on Create a new project. Select ASP.NET Core Web API, and click on the Next button.

Create a project as an E-POS and the Solution name as an E-Business. Click on the Next button.|

After clicking on the create button, the E-POS project was created.

Now, I'm going to create the Models folder in my project. Right-click on your project to open a pop-up menu, then click 'Add,' select 'New Folder,' and name it 'Models.'

Inside the Models folder, create a new class file. Right-click on the Models folder, select 'Add,' then choose 'Class,' click it, and give it the name ‘Product’.

Step 2. Define the Model Class
A model in Entity Framework Core is simply a C# class that defines the structure of a database table. Let's define a simple product model with properties for Id, Name, Price, and CreatedDate.

Create a new folder called Models, and inside it, add a file named Product.cs.
namespace E_POS.Models
{
        public class Product
    {
        public int Id { get; set; }      // Primary Key
        public required string Name { get; set; }

        [Column(TypeName = "decimal(18, 2)")]
        public decimal Price { get; set; }

        public DateTime CreatedDate { get; set; }
    }

}

‘Id’ is the primary key, which EF Core will map to the table's primary key by convention.
Other properties (Name, Price, and CreatedDate) will be mapped to corresponding columns in the table.

Install Required NuGet Packages
To install NuGet packages like those required for Entity Framework Core. There are multiple ways, depending on your environment and tools. Here's a summary of the different methods you can use:

1. Using .NET CLI (Command Line Interface)
This is the method you mentioned, using the terminal or command prompt. It’s a simple and effective way to add packages to your project.

For Microsoft.EntityFrameworkCore
Install-Package Microsoft.EntityFrameworkCore

For Microsoft.EntityFrameworkCore.Tools
Install-Package Microsoft.EntityFrameworkCore.Tools

For Microsoft.EntityFrameworkCore.Design
Install-Package Microsoft.EntityFrameworkCore.Design

For Microsoft.EntityFrameworkCore.SqlServer (to work with SQL Server)
Install-Package Microsoft.EntityFrameworkCore.SqlServer

2. Using NuGet Package Manager in Visual Studio
Visual Studio offers a graphical interface to manage NuGet packages.

Steps

• Right-click on your project in Solution Explorer.
• Select Manage NuGet Packages.
• In the Browse tab, search for the required packages (e.g., Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Tools, etc.).
• Click Install for each package.

3. Using the NuGet Package Manager Console in Visual Studio
This console allows you to install packages using commands similar to the CLI but directly within Visual Studio.

Check whether the packages are installed or not.

Step 3. Configure the Connection String
Now, let's configure the database connection string.

Open the appsettings.json file and add your database connection details under the ConnectionStrings section.
{
  "ConnectionStrings": {
    "DefaultConnection": "Server=LAPTOP-A40000TJ\\SQLEXPRESS; Database=EBusiness; Integrated Security=True; Encrypt=True; TrustServerCertificate=True;"
  }
}

This connection string defines how a .NET application connects to a SQL Server database. It specifies,

• Server: LAPTOP-A4E1RITJ\SQLEXPRESS (machine name and SQL instance)
• Database: E_Business
• Integrated Security: Uses Windows Authentication.
• Encrypt: Secures data transmission.
• TrustServerCertificate: Accepts self-signed SSL certificates.

This connection string assumes you are using SQL Server. Replace the placeholders with your actual database credentials.

Step 4. Create the DbContext Class
The DbContext class in Entity Framework Core manages the database connection and is responsible for querying and saving data. Let’s create the AppDbContext class that represents our database session and exposes the Product model as a DbSet.

In the root of your project, create a folder named Data and add a class file called AppDbContext.cs.
using E_POS.Models;
using Microsoft.EntityFrameworkCore;

namespace E_POS.Data
{
    public class AppDbContext: DbContext
    {
        public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
        {
        }
        public DbSet<Product> Products { get; set; }
    }
}

DbSet<Product> represents the Products table in the database.
The AppDbContext constructor accepts DbContextOptions to configure the database connection.

Step 5. Register the DbContext in the Program.cs
To ensure that Entity Framework Core can access your DbContext, register it in the Program.cs file. Modify the Program.cs to include AppDbContext.
#region Database Configure

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");

builder.Services.AddDbContext<AppDbContext>(options => options.UseSqlServer(connectionString));

#endregion

Step 6. Create and Apply Migrations
Migrations allow you to create or modify the database schema to match your models.
In Visual Studio, you can open the Package Manager Console by following these steps.

• Go to the Tools menu at the top of Visual Studio.
• Select NuGet Package Manager.
• Click on Package Manager Console.

To make an initial migration and apply it, run the following commands.
Add-Migration InitialCreate
Database-Update

Add-Migration InitialCreate: Creates a new migration based on the Product model and AppDbContext.
Database-Update: Applies the migration to your database, creating the necessary tables.

Let’s check whether the database is created or not.

Summary
In this article, we’ve explored how to create a model and map it to a database table in .NET 8 using Entity Framework Core. The process involves defining a model, creating a DbContext, configuring the database connection, and using migrations to keep your database schema in sync with your models.

The Api.http file in a .NET project is a text file containing one or more HTTP requests that can be executed directly from the development environment, such as Visual Studio or Visual Studio Code. This file enables developers to quickly test API endpoints without the need for external tools such as Postman or cURL. It is particularly useful when you are debugging, developing, or testing an API. This article will describe what Api.http is and how to use it, along with an example.

What is Api.http?
It’s a simple text file with a .http extension that contains the definitions of HTTP requests (such as GET, POST, PUT, DELETE, etc.).
Purpose: It allows developers to send HTTP requests directly from their code editor for testing API endpoints, simulating client requests, and checking API responses.
File Format: It contains HTTP requests along with headers and request bodies. This is similar to how requests are made using tools like Postman or cURL.

Benefits of using Api.http file
Quick API testing
You can make HTTP requests directly from your development environment without having to switch to external tools such as Postman.
This provides a faster feedback loop during API development.

Easy debugging
You can simulate client requests and test your API directly without writing a separate client or using a browser.
When working with RESTful services, you can easily test endpoints, troubleshoot problems, and validate responses.

Lightweight and simple
The .http file is lightweight and easy to set up. It doesn’t require complex configuration or external dependencies.
You can keep all your requests in one file or split them into different files based on API resources or services.

Version control
Because the .http file is just a text file, you can commit it to version control (like Git) along with your project.

This allows teams to share API requests and helps document the expected API inputs and outputs for specific endpoints.

Multiple requests in one file
You can write multiple requests in a single .http file, separating them with comments e.g. ###.

This is useful for testing different aspects of an API, for example, retrieving data, posting data, and updating data in one go.

Environment variables (in Visual Studio Code with the REST client)
In VS Code, you can use environment variables to avoid hardcoding values such as API tokens, endpoints, or other dynamic data, making it easier to move between development, staging, and production environments.

Use case example
Suppose you’re working on a .NET API that manages users. You want to test your API endpoints during development. Instead of using Postman or writing a front client, you can use the Api.http file to test different endpoints directly from your code editor.

Example flow
We can

• Add a GET request to retrieve a list of users.
• Add a POST request to create a new user with a JSON payload.
• Add a PUT request to update user information.
• Add a DELETE request to remove a user.

All of these can be executed directly from the Api.http file. This provides immediate feedback on the functionality of the API.

Structure of http file
The http file contains multiple requests with multiple api calls. Now, let’s go for the structure of the Api.http file. Below is a sample Api.http file.

### Get Users
GET https://api.example.com/users
Authorization: Bearer YOUR_TOKEN

### Create a New User
POST https://api.example.com/users
Content-Type: application/json
Authorization: Bearer YOUR_TOKEN

{
  "name": "John Doe",
  "email": "[email protected]"
}

### Update a User
PUT https://api.example.com/users/123
Content-Type: application/json
Authorization: Bearer YOUR_TOKEN

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

### Delete a User
DELETE https://api.example.com/users/123
Authorization: Bearer YOUR_TOKEN

How to create Api.http file?
If you create a new WebAPI project in .NET 8 using Visual Studio 2022, select the WebAPI default project template, then it will automatically create YourPeojectname.http file where you can add your API requests.

However, we can add it manually for existing projects as well. To add the http file manually, follow the below steps:

Step 1. Adding http file
For Visual Studio – Right-click on your project in Solution Explorer.
Select Add > New Item and choose a Text File or File. Rename it to Api.http.

For Visual Studio code– Right-click on your project folder, select New File and name it Api.http.

Step 2. Write Http Request
Now, we can add HTTP requests to the Api.http file. Each request can be a GET, POST, PUT, or DELETE with optional headers and body, like in the example above.

Step 3. Running the request
In Visual Studio 2022
Open the Api.http file.
Visual Studio automatically detects the HTTP requests in the file. For each request, you will see a Send Request button below.

Then click on the Send Request button to execute the request.
The response status code, headers, and body will be displayed in the output pane.

In Visual Studio Code
Install the REST Client extension.
Open the Api.http file.
Hover over the HTTP request you want to execute and click on the Send Request button.
The response will be shown in a separate tab or panel.

Step 4. Check the Response
When you send the request, you can view the response in your editor, which includes:
HTTP status code e.g., 200, 404, 500.
Response body JSON, XML, or other formats.
Headers such as Content-Type, Authorization, etc..
Below is an example output of the Get Weather Forecast API.

Conclusion
The Api.http file is a powerful tool that allows you to test and debug API endpoints directly within your development environment. It provides a lightweight and integrated alternative to external tools such as Postman and can be a significant time saver when it comes to API development and testing in .NET projects.

Logging is an essential part of the application, especially when you want to monitor traffic communicating with an external client that is having some problems connecting to your site. Let's say a very obscure error is happening with regard to third-party software you are using, and the software provider is asking for debug-level logs in order to help you.

So, the solution is simple, add a logging component like NLog and log to a file by configuring the nlog.config file. But many times your application may not allow you a simple implementation. The complications appear when your application is a multi-tenant deployment, or if you can't modify nlog.config or appsettings.json after the deployment, and what if you need to temporarily enable the Debug logging for a specific library only or any temporary logging for that matter?

If we just add an NLog to the multi-tenant application with five clients, then all five clients will start writing logs in the same location, be it a file or a database. And what if the deployed code is not possible to modify (like a read-only zipped version)?

There is a solution for all of the above. NLog libraries provide all the necessary features to resolve the above problems.

The best part is that NLog allows you to use a new instance of NLog per each request and allows you to modify the logger instance just for this scope (per request).

Let's address the issues one by one.

To start, let's use a middleware to set the NLog in a generic manner.

In the middleware class, we will set all the dynamic properties specific to the tenant. In my case, they are

a DB connection string; logger filters for specific libraries (like Microsoft, ThirdPartyLib(substitute it with any namespace you want), Nlog.API (current application), and everything(*)).

In the Nlog.config file, we set the logger like the following code (please note mdlc:Nlog_mainDebug). I found that this is the only way to modify the logger dynamically - by using the 'filters' tag.

For loggers
<logger name="Nlog.API*" minlevel="Debug" writeTo="dbTarget" ><!--only works if Nlog_mainDebug is Yes-->
        <filters defaultAction="Log">
            <when condition="'${mdlc:Nlog_mainDebug}' != 'Yes'" action="Ignore" /><!--comparisson is case-sensetive-->
        </filters>
</logger>

For the database target we set a connectionString with a dynamic variable (please note mdlc:NLog_DbCon).
<target xsi:type="Database"
name="dbTarget"
connectionString="${mdlc:NLog_DbCon}"
commandText="INSERT INTO NLogs(CreatedOn,Message,Level,Exception,StackTrace,Logger,Url)
            VALUES (@datetime,@msg,@level,@exception,@trace,@logger,@url)"
            >
        <parameter name="@datetime" layout="${date}" />
        <parameter name="@msg" layout="${message}" />
       <parameter name="@level" layout="${level}" />
        <parameter name="@exception" layout="${exception}" />
        <parameter name="@trace" layout="${stacktrace}" />
        <parameter name="@logger" layout="${logger}" />
        <parameter name="@url" layout="${aspnet-request-url}" />
</target>

In the middleware, the properties are set to specific values (TenantMiddleware.cs).
NLog.ScopeContext.PushProperty("Nlog_Microsoft",Constants_NLogMicrosoft);
NLog.ScopeContext.PushProperty("Nlog_ThirdPartyLib", Constants_NLogThirdPartyLib);
NLog.ScopeContext.PushProperty("Nlog_mainDebug", Constants_NLogMainDebug);
NLog.ScopeContext.PushProperty("Nlog_mainWarning", Constants_NLogMainWarning);
NLog.ScopeContext.PushProperty("Nlog_EverythingElseWarn", Constants_NLogEverythingElseWarn);
NLog.ScopeContext.PushProperty("NLog_DbCon", connectionString);

In this sample, the connection string is static, but it can be retrieved based on the current domain + subdomain dynamically. Depending on the subdomain, the connection string could vary. The same is true for the logger enabling. The source of the values could be dynamic (like a database).
Testing

Try Cool, Fantastic, and WeatherForecast APIs by making requests to all three controllers.

As a result, you should see the logged database rows.

There are multiple possible scenarios. And here are a few.

In a day to day logging I would set only one logger, which is Warning for everything like:
<logger name="*" minlevel="Warn" writeTo="dbTarget" >

When you need to debug a specific library then additionally enable this:
<logger name="ThirdPartyLib*" minlevel="Debug" writeTo="dbTarget">

And of course, set the DB destination per URL if multi-tenant. If not multi-tenant, for simplicity, set the DB connection in nlog.config instead. I'm demonstrating the most complex case here to see what's possible.

The source code is attached, and more details can be found in the Nlog Multi-tenant Strategy.txt file inside the project. Cheers!

In the previous five to six years,.NET has seen substantial evolution. It's now simpler than ever to create applications using MVC or APIs (Application Programming Interfaces). The Minimal APIs feature, new in ASP.NET Core 6, streamlines API development by doing away with the requirement to create controllers, which are often placed at the front of APIs. Currently,.NET supports two methods: Minimal APIs (the new method) and Controllers (the old method). Which one, though, ought to you use?

What are Minimal APIs?
Minimal APIs define endpoints as logical handlers using lambdas or methods. They utilize method injection for services, while controllers use constructor or property injection. In Minimal APIs, each endpoint only requires the specific services it needs. This is in contrast to controllers, where all endpoints within the controller use the same class constructor, which can make the controller "fat" as it grows. Minimal APIs are designed to hide the host class by default and emphasize configuration and extensibility via extension methods that take lambda expressions.

Here is an example of minimal API.

app.MapGet("/weatherforecast", (HttpContext httpContext) =>
{
    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = summaries[Random.Shared.Next(summaries.Length)]
        })
        .ToArray();

    return forecast;
});

Here are the important points that we should know before jumping into the minimal API. These points are from the Microsoft docs.

Minimal APIs lack built-in support for,

• Model binding (IModelBinderProvider, IModelBinder). However, support can be added via custom binding shims.
• Validation (IModelValidator).
• Application parts or the application model. There is no way to apply or build your conventions.
• View rendering. For this, it is recommended to use Razor Pages.
• JsonPatch.
• OData.

You can work around these limitations by implementing custom solutions for each of these missing features.

Conclusion
Minimal APIs are an excellent way to start building APIs. One practical use case for Minimal APIs is in Vertical Slice Architecture (Vertical Slice Architecture is a design approach where features are implemented end-to-end, encapsulating all layers (UI, business logic, and data access) within self-contained slices.). In this approach, you can define endpoints for each module separately, making management easier. Since each endpoint in Minimal APIs declares the specific services it needs, this approach helps avoid the issue of controller classes becoming "fat" as they grow and more endpoints are added.

For me, minimal APIs are good to go for small-scale projects and they are easy to handle when endpoints grow.