Jimmy

Academic

TaskFlow — A Project Management REST API with ASP.NET Core

An academic REST API for managing projects and tasks, built with ASP.NET Core and a relational SQL Server model managed by Entity Framework Core.

Completed
List of the API endpoints in the Swagger interface, grouped by projects, tasks and users
The endpoints documented in Swagger.

My contribution

I built the entire current technical implementation of the API: the ASP.NET Core structure, services, the EF Core model, authentication, validation, error handling and the Swagger documentation.

Highlights

  • Relational model of users, projects and tasks, versioned through an EF Core migration
  • Business logic in injected services, kept apart from the HTTP controllers
  • Centralized error handling, mapped to the appropriate HTTP status codes

Goal

Build the API of a project management tool: users, the projects they own and the tasks attached to those projects. The result is an academic REST API, not a full project management platform.

Architecture

The API runs on ASP.NET Core and .NET 9. The application keeps the HTTP controllers apart from the business logic, which lives in injected services declared behind interfaces. Those services use Entity Framework Core directly for data access. Requests and responses go through data transfer objects (DTOs) separate from the entities, and a middleware handles all exceptions in one place; logs are written to the console.

Features

  • Accounts: sign-up and login, with a JWT valid for two hours.
  • Projects: create, read, update and delete; each project belongs to the signed-in user who creates it.
  • Tasks: create, read, update and delete, with a status, a due date and comments.
  • Demo: besides the Swagger interface, a small HTML page lets you try the API.

Data model

The model is relational and stored in SQL Server: a user owns projects, and each project holds tasks. Foreign keys link these entities, with cascading deletes, and a unique index ensures an email address is only used once. The schema is described by a versioned Entity Framework Core migration rather than created on the fly as data is written. Queries are written in LINQ and load related entities when needed.

Validation and errors

DTOs carry declarative validation rules — required fields, email format, minimum length — applied automatically by ASP.NET Core before reaching the business code. Errors are handled in one place: a middleware catches exceptions and maps them to the appropriate HTTP status codes (conflict, not found, access denied, bad request), with a detailed message in development and a neutral one otherwise.

Authentication and documentation

JWTs are signed and validated by the framework — issuer, audience, expiry and signature — and the project and task routes are restricted to authenticated users. The OpenAPI documentation is generated and browsable in Swagger, configured to send the token and to display enums in a readable way.

Limits

The project remained an academic API: the roles planned in the model and some resource isolation rules were not completed, and no automated test suite was added.