When you send a request to a .NET Core Web API, it goes thru series of steps before a response is returned. Understanding this lifecycle is important in order to built what we need and how to use some of the prebuild functionalities. In this post, we’ll break down the main steps of the .NET Core Web API request lifecycle.

1. Application Startup

Before any request is handled, the application goes through the startup process:

  • Program.cs / Main Method: This is the entry point. It builds and runs the web host.
  • Startup.cs (if used):
    • ConfigureServices: This method is used to register services in the Dependency Injection (DI) container.
    • Configure: This sets up the HTTP request pipeline using middleware.

With .NET 6 and later, the startup logic is often consolidated into the Program.cs file using the minimal hosting model.

2. HTTP Request Pipeline (Middleware)

Once the application is running, every incoming HTTP request goes through the middleware pipeline. Middleware components can perform operations before and after the next component runs:

  • Built-in Middleware Examples:
    • UseRouting – Matches the request to an endpoint.
    • UseAuthentication – Handles authentication.
    • UseAuthorization – Checks user permissions.
    • UseEndpoints – Executes the matched endpoint (controller action, etc.).

Custom middleware can also be added for logging, request modification, etc.

3. Routing and Endpoint Matching

Routing determines which controller and action should handle the request:

  • Based on the request URL and HTTP method (GET, POST, etc.).
  • Routes can be attribute-based ([HttpGet("api/products")]) or convention-based (defined in MapControllers()).

4. Model Binding and Validation

Once the endpoint is matched:

  • Model Binding kicks in to map HTTP request data (query strings, headers, body) to method parameters and models.
  • Validation is performed using data annotations ([Required], [StringLength], etc.) or custom validators.

If validation fails, the framework can automatically return a 400 Bad Request.

5. Controller Action Execution

Now the actual controller method (action) is invoked. Here’s what happens:

  • Dependencies required by the controller or action method are injected.
  • The logic in the controller is executed.
  • It returns a result (e.g., Ok(), NotFound(), or a custom object).

6. Result Execution

The action result is processed and converted into an HTTP response:

  • This may involve serializing objects into JSON (typically using System.Text.Json or Newtonsoft.Json).
  • The framework sets the response headers and status code.

7. Middleware Response Processing

After the action result is generated, control returns back up through the middleware pipeline in reverse order. This gives middleware components the chance to:

  • Modify or inspect the response (e.g., add custom headers).
  • Log the outcome (status code, response time, etc.).
  • Handle exceptions globally (via custom exception-handling middleware).
  • Apply cross-cutting features like CORS, caching, and compression.

This is the final point where behavior can be influenced before the response goes back to the client.

8. Response Sent to Client

Finally, the HTTP response is sent back to the client. At this point, the request lifecycle is complete.

Conclusion

The .NET Core Web API request lifecycle is powerful and highly extensible. By understanding each step, you can design better APIs, implement robust logging and error handling, and create a maintainable architecture that scales well.

Happy coding!