Task Manager Web API

Build a full CRUD REST API for managing tasks, backed by Entity Framework Core.

ASP.NET CoreEF CoreWeb API

Overview

A task manager API is the standard way to learn how ASP.NET Core turns HTTP requests into typed C# method calls, and how Entity Framework Core turns ordinary C# objects into rows in a database without hand-written SQL. A [HttpGet]-attributed method on a controller is not just a function — it is a routed endpoint the ASP.NET Core framework matches against an incoming request's URL and HTTP verb, extracts route/query/body values into strongly typed parameters for, and calls automatically.

By the end of this tutorial you will have a small but complete REST API: a TaskItem entity, an AppDbContext that EF Core uses to talk to a database, and a TasksController exposing GET, POST, PUT, and DELETE endpoints under /api/tasks. This project uses EF Core's **in-memory provider** — data lives only in the process's memory and resets every time the app restarts. That choice is deliberate: it means this tutorial needs nothing installed beyond the .NET SDK itself to run end to end. A real deployment would swap the single UseInMemoryDatabase(...) line in Step 3 for UseSqlServer(...) or UseNpgsql(...) against a real SQL Server or PostgreSQL database — every line of the TaskItem model and TasksController below would stay exactly the same, because EF Core's LINQ query API is provider-independent.

What You'll Build

A TaskItem entity with Id, Title, IsComplete, and CreatedAt properties.
An AppDbContext exposing a DbSet<TaskItem> that EF Core maps to a table.
Minimal-hosting Program.cs (top-level statements) registering the DbContext and controller routing.
A TasksController with GET /api/tasks and GET /api/tasks/{id} endpoints.
A POST /api/tasks endpoint that creates a task and returns a 201 Created response.
PUT /api/tasks/{id} and DELETE /api/tasks/{id} endpoints completing full CRUD.

Prerequisites

C# fundamentals — classes, properties, and async/await.
HTTP basics — the meaning of GET, POST, PUT, DELETE, and status codes like 200, 201, 204, and 404.
Collections and LINQ basics — List<T> and simple query methods like .Where()/.ToListAsync().
Dependency injection basics — a constructor receiving an object it depends on rather than creating it itself.
JSON basics — how a C# object maps to a JSON request/response body.

Project Structure

Running dotnet new webapi -o TaskManagerApi (or dotnet new webapi --use-controllers -o TaskManagerApi, depending on your SDK version, to guarantee the controller-based template rather than the minimal-API template) scaffolds a project with this layout: Program.cs at the root configures and starts the app; a Controllers/ folder holds one file per controller (TasksController.cs here); a Models/ folder holds plain data classes like TaskItem; appsettings.json holds configuration such as connection strings; and a .csproj file lists NuGet package references, including Microsoft.EntityFrameworkCore and Microsoft.EntityFrameworkCore.InMemory once added for this project.

This tutorial also adds a Data/ folder for AppDbContext.cs, mirroring how a larger ASP.NET Core project typically separates "how the app talks to its database" (Data/) from "what shape the app's data takes" (Models/) and "how the app handles requests" (Controllers/). Every namespace below follows the folder it lives in — TaskManagerApi.Models, TaskManagerApi.Data, TaskManagerApi.Controllers — which is the standard convention dotnet new itself follows.

Step 1: Define the TaskItem Model

EF Core maps a plain C# class to a database table by convention: a DbSet<TaskItem> named Tasks on the DbContext becomes a table, and a property named Id (or TaskItemId) is automatically treated as the primary key with values generated by the database. Title defaults to string.Empty rather than being nullable, which keeps a task from ever existing in a half-formed state where its title is null.

Models/TaskItem.cs

namespace TaskManagerApi.Models;

// Represents one task row in the database. EF Core maps this class directly to
// a table (named "Tasks", to match the DbSet property added in Step 2) using
// nothing but naming convention — no attributes or configuration are required
// for a class this simple.
public class TaskItem
{
    public int Id { get; set; }                          // Primary key; EF Core recognizes "Id" by convention and makes it an identity column
    public string Title { get; set; } = string.Empty;       // Non-nullable with a default so a task can never exist with a null title
    public bool IsComplete { get; set; }                    // Defaults to false, matching bool's own default value
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;   // Set once when the object is constructed, never touched by updates
}

Step 2: Create the DbContext

A DbContext is EF Core's central class: it tracks every entity loaded through it in memory, translates LINQ queries against a DbSet<T> into the operations of whichever database provider Program.cs configures, and batches every tracked change into the database when SaveChangesAsync() is called. AppDbContext receives its configuration through DbContextOptions<AppDbContext> passed into the constructor — it never decides for itself which provider or connection string to use, that decision belongs entirely to Program.cs in Step 3.

Data/AppDbContext.cs

using Microsoft.EntityFrameworkCore;
using TaskManagerApi.Models;

namespace TaskManagerApi.Data;

public class AppDbContext : DbContext
{
    // DbContextOptions carries the provider + connection string chosen in Program.cs.
    // AppDbContext itself stays completely agnostic about where its data actually lives.
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
    }

    public DbSet<TaskItem> Tasks => Set<TaskItem>();   // One DbSet per table; "Tasks" becomes the queryable collection used everywhere below
}

Step 3: Configure Program.cs

WebApplication.CreateBuilder(args) sets up configuration, logging, and the dependency-injection container in one call — everything registered on builder.Services becomes something a controller's constructor can ask for later. AddDbContext<AppDbContext>() is where the in-memory provider is chosen for this tutorial; swapping to a real database in production means changing only the single line inside that call.

Program.cs

using Microsoft.EntityFrameworkCore;
using TaskManagerApi.Data;

var builder = WebApplication.CreateBuilder(args);   // Top-level statements: no explicit Main method needed, the compiler generates one

// EF Core's in-memory provider needs no real database server, which keeps this
// tutorial runnable with nothing installed beyond the .NET SDK. A real deployment
// would swap this one call for UseSqlServer(...) or UseNpgsql(...) against SQL
// Server or PostgreSQL — nothing in the controller or model code would need to change.
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseInMemoryDatabase("TaskManagerDb"));

builder.Services.AddControllers();   // Registers controller-based routing, so [HttpGet]/[HttpPost] attributes below get wired up

var app = builder.Build();

app.MapControllers();   // Maps every attribute-routed controller (like TasksController) found in the project's assembly

app.Run();   // Starts the built-in Kestrel web server and blocks until the process is stopped

Step 4: Build the GET Endpoints

[ApiController] turns on a set of conventions specific to Web APIs, including automatic 400 Bad Request responses when model validation fails, and automatic inference of where a parameter's value should come from (route, query string, or body). [Route("api/[controller]")] uses the [controller] token, which ASP.NET Core replaces with the class name minus its Controller suffix — TasksController becomes the route prefix api/tasks. The constructor receiving AppDbContext db is dependency injection in action: the framework itself creates a new TasksController per request and hands it the same AppDbContext instance registered back in Step 3.

Controllers/TasksController.cs

using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using TaskManagerApi.Data;
using TaskManagerApi.Models;

namespace TaskManagerApi.Controllers;

[ApiController]                   // Turns on automatic model validation and parameter-source inference for a Web API controller
[Route("api/[controller]")]       // [controller] becomes "Tasks" (the class name minus "Controller"), giving the route prefix /api/tasks
public class TasksController : ControllerBase
{
    private readonly AppDbContext _db;   // Injected per-request by the DI container configured in Program.cs

    public TasksController(AppDbContext db)
    {
        _db = db;
    }

    [HttpGet]                                                    // GET /api/tasks
    public async Task<ActionResult<IEnumerable<TaskItem>>> GetAll()
    {
        return await _db.Tasks.ToListAsync();   // Async all the way down avoids blocking a thread while waiting on I/O
    }

    [HttpGet("{id}")]                                             // GET /api/tasks/5
    public async Task<ActionResult<TaskItem>> GetById(int id)
    {
        var task = await _db.Tasks.FindAsync(id);   // FindAsync checks EF Core's in-memory change tracker before querying the database
        if (task is null)
        {
            return NotFound();                        // 404: no task with that id exists
        }
        return task;
    }
}

Step 5: Build the POST Endpoint

[ApiController]'s automatic model binding is what turns the raw JSON body of a POST request into a fully populated TaskItem parameter, with no manual deserialization code anywhere in this method. CreatedAtAction() builds a proper 201 Created response: its second and third arguments generate a Location header pointing back at the new resource's GetById URL, which is the behavior the HTTP spec expects from a successful resource-creation request rather than a bare 200 OK.

[HttpPost]                                             // POST /api/tasks
public async Task<ActionResult<TaskItem>> Create(TaskItem task)
{
    _db.Tasks.Add(task);              // Starts tracking the new entity with a state of "Added"
    await _db.SaveChangesAsync();     // Flushes every tracked change to the database in one round trip, generating task.Id

    // 201 Created, with a Location header pointing at GET /api/tasks/{task.Id} — the
    // conventional response shape for "a new resource now exists at this URL".
    return CreatedAtAction(nameof(GetById), new { id = task.Id }, task);
}

Step 6: Build the PUT and DELETE Endpoints

Update() loads the existing tracked entity with FindAsync() and mutates its properties directly rather than replacing it outright — EF Core's change tracker notices those property assignments automatically, so SaveChangesAsync() knows exactly which UPDATE to issue without being told explicitly. Both endpoints return 204 No Content on success, the conventional response for "the operation succeeded and there is nothing meaningful to send back."

[HttpPut("{id}")]                                      // PUT /api/tasks/5
public async Task<IActionResult> Update(int id, TaskItem updated)
{
    var task = await _db.Tasks.FindAsync(id);
    if (task is null)
    {
        return NotFound();
    }
    task.Title = updated.Title;             // Mutate the tracked entity's properties directly instead of replacing it
    task.IsComplete = updated.IsComplete;    // EF Core's change tracker detects these assignments automatically
    await _db.SaveChangesAsync();
    return NoContent();                       // 204: the update succeeded, nothing meaningful to return
}

[HttpDelete("{id}")]                                   // DELETE /api/tasks/5
public async Task<IActionResult> Delete(int id)
{
    var task = await _db.Tasks.FindAsync(id);
    if (task is null)
    {
        return NotFound();
    }
    _db.Tasks.Remove(task);                  // Marks the entity as "Deleted" in the change tracker
    await _db.SaveChangesAsync();            // Issues the actual DELETE against the database
    return NoContent();
}

Complete Code

Here is the full project across its four files, ready to run with dotnet run after installing the Microsoft.EntityFrameworkCore.InMemory NuGet package (dotnet add package Microsoft.EntityFrameworkCore.InMemory).

Models/TaskItem.cs

namespace TaskManagerApi.Models;

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

Data/AppDbContext.cs

using Microsoft.EntityFrameworkCore;
using TaskManagerApi.Models;

namespace TaskManagerApi.Data;

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
    }

    public DbSet<TaskItem> Tasks => Set<TaskItem>();
}

Program.cs

using Microsoft.EntityFrameworkCore;
using TaskManagerApi.Data;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseInMemoryDatabase("TaskManagerDb"));

builder.Services.AddControllers();

var app = builder.Build();

app.MapControllers();

app.Run();

Controllers/TasksController.cs

using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using TaskManagerApi.Data;
using TaskManagerApi.Models;

namespace TaskManagerApi.Controllers;

[ApiController]
[Route("api/[controller]")]
public class TasksController : ControllerBase
{
    private readonly AppDbContext _db;

    public TasksController(AppDbContext db)
    {
        _db = db;
    }

    [HttpGet]
    public async Task<ActionResult<IEnumerable<TaskItem>>> GetAll()
    {
        return await _db.Tasks.ToListAsync();
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<TaskItem>> GetById(int id)
    {
        var task = await _db.Tasks.FindAsync(id);
        if (task is null)
        {
            return NotFound();
        }
        return task;
    }

    [HttpPost]
    public async Task<ActionResult<TaskItem>> Create(TaskItem task)
    {
        _db.Tasks.Add(task);
        await _db.SaveChangesAsync();
        return CreatedAtAction(nameof(GetById), new { id = task.Id }, task);
    }

    [HttpPut("{id}")]
    public async Task<IActionResult> Update(int id, TaskItem updated)
    {
        var task = await _db.Tasks.FindAsync(id);
        if (task is null)
        {
            return NotFound();
        }
        task.Title = updated.Title;
        task.IsComplete = updated.IsComplete;
        await _db.SaveChangesAsync();
        return NoContent();
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> Delete(int id)
    {
        var task = await _db.Tasks.FindAsync(id);
        if (task is null)
        {
            return NotFound();
        }
        _db.Tasks.Remove(task);
        await _db.SaveChangesAsync();
        return NoContent();
    }
}

Sample Run

Click Run to see what this code prints.

Extend This Project

Add [Required]/[StringLength] data annotations to TaskItem.Title so [ApiController] rejects an invalid POST/PUT body with an automatic 400 Bad Request before your code even runs.
Swap UseInMemoryDatabase("TaskManagerDb") for UseSqlite("Data Source=tasks.db") (with the Microsoft.EntityFrameworkCore.Sqlite package) so tasks survive an app restart.
Add a GET /api/tasks?isComplete=true filter using a query-string parameter and a .Where() clause.
Add Swagger/OpenAPI support with Swashbuckle.AspNetCore so the API is explorable and testable from a browser.
Add a DueDate property to TaskItem and a GET /api/tasks/overdue endpoint that filters tasks whose due date has passed.

Summary

You built a working REST API where ASP.NET Core routes HTTP requests to strongly typed controller methods, and EF Core translates ordinary C# objects and LINQ queries into database operations without a single hand-written SQL statement. The GetAll/GetById/Create/Update/Delete shape you wrote in TasksController is the same shape almost every CRUD API in ASP.NET Core follows, whether it is backed by EF Core's in-memory provider for a tutorial or a production SQL Server database.