By the end of this session, you will be able to:

• Create and run a .NET Web API project from scratch using the CLI
• Navigate and explain every file produced by dotnet new webapi
• Describe the layered architecture — Controllers, Services, and Repositories — and explain why each layer exists
• Understand what dependency injection is, how .NET's container works, and the three service lifetimes
• Write a working TasksController with GET and POST endpoints using in-memory data

TaskManagerApi.Api/
├── Controllers/
│   └── WeatherForecastController.cs   # delete this — sample only
├── Properties/
│   └── launchSettings.json            # controls how the app starts locally
├── appsettings.json                   # configuration values
├── appsettings.Development.json       # dev overrides (gitignored by default)
├── Program.cs                         # entry point — services + pipeline wired here
└── TaskManagerApi.Api.csproj          # project file, NuGet package references

• Middleware is code that runs on every request in a defined order
• Each component can inspect, modify, or short-circuit the pipeline — returning a response before reaching the next step
• The order you call app.UseXxx() in Program.cs is the order they execute
• You will add custom middleware in Session 05 (error handling) and Session 16 (rate limiting, CORS)

• Testability — you can unit-test a TaskService without an HTTP server or a database. This is covered fully in Session 17.
• Replaceability — swap the database (e.g. SQL Server for PostgreSQL) by rewriting only the Repository layer. The Service layer never changes.
• Readability — a controller that is 20 lines long and only delegates is easy to understand. A controller with SQL queries buried in it is not.
• Team scaling — developers can own different layers independently without stepping on each other.

TaskManagerApi.Api/
├── Controllers/            # HTTP layer — one file per resource
├── Services/
│   └── Interfaces/         # ITaskService.cs lives here
├── Repositories/
│   └── Interfaces/         # ITaskRepository.cs lives here
├── Models/
│   ├── Entities/           # TaskItem.cs — the database model
│   └── DTOs/               # request / response shapes (introduced in Session 11)
└── Program.cs

• The problem without DI: a class creates its own dependencies with new TaskService() — it is tightly coupled, impossible to swap, and impossible to test in isolation
• DI inverts this: objects declare what they need (via constructor parameters) and a container provides it — the class never calls new
• The container is IServiceCollection — you describe every service once in Program.cs, then the framework resolves them automatically
• Why interfaces? Depending on ITaskService rather than TaskService means you can substitute a different implementation (e.g. a test double) without touching the controller

How long does the container keep an instance alive?

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddScoped<ITaskService, TaskService>();
builder.Services.AddScoped<ITaskRepository, TaskRepository>();

var app = builder.Build();
// ... pipeline config below

The pattern is always: AddScoped<IInterface, ConcreteClass>(). The container maps the interface to the implementation — callers only ever see the interface.

public class TasksController : ControllerBase
{
    private readonly ITaskService _taskService;

    public TasksController(ITaskService taskService)
    {
        _taskService = taskService;
    }
}

• Declare the dependency as a private readonly field typed to the interface
• Accept it as a constructor parameter — the container injects the concrete instance automatically
• The controller never calls new TaskService() — it does not know the concrete type exists

public class TaskItem
{
    public int Id { get; set; }
    public string Title { get; set; } = string.Empty;
    public bool IsCompleted { get; set; }
    public DateTime CreatedAt { get; set; }
}

// 200 OK — body serialised to JSON automatically
return Ok(tasks);

// 201 Created — sets Location header to /api/tasks/{id}
return CreatedAtAction(nameof(GetById), new { id = task.Id }, task);

// 404 Not Found — empty body
return NotFound();

// 400 Bad Request — empty body or custom message
return BadRequest();

All these helper methods live on ControllerBase — your controller inherits them automatically.

• "What would break if you put database code directly in your controller?"
  Think about testing, readability, and what happens when you need to change the query.
• "Why would you want an interface (ITaskService) rather than depending directly on TaskService?"
  Think about what happens in tests, and what happens if you need a second implementation later.

• dotnet new webapi scaffolds a working project — Program.cs is the single entry point where services are registered and the middleware pipeline is configured
• Every HTTP request passes through the middleware pipeline in the exact order the middleware was registered
• Layered architecture (Controllers → Services → Repositories) separates HTTP handling, business logic, and data access into distinct, testable units
• Dependency injection lets classes declare their dependencies as constructor parameters; the DI container resolves and provides them automatically
• Use Scoped lifetime for services and repositories unless you have a specific reason for Singleton or Transient
• Ok(), NotFound(), CreatedAtAction() are helper methods on ControllerBase that produce semantically correct HTTP responses

HTTP Methods & Status Codes

• A full tour of GET, POST, PUT, PATCH, and DELETE — when to use each and why
• The complete HTTP status code vocabulary: 2xx, 3xx, 4xx, 5xx
• Idempotency and safety — properties that constrain how clients and proxies may behave
• Expanding the TasksController with PUT, PATCH, and DELETE endpoints

Create a new .NET Web API project called BooksApi that applies the layered architecture and dependency injection patterns from this session.

• Project follows the four-folder structure: Controllers/, Services/Interfaces/, Repositories/Interfaces/, Models/Entities/
• A Book entity with Id (int), Title (string), Author (string), and Year (int)
• An IBooksService interface with GetAll() and GetById(int id), and a concrete in-memory BooksService implementation
• A BooksController with GET /api/books and GET /api/books/{id} (404 if not found)
• BooksService registered as Scoped in Program.cs and injected into the controller via constructor