A dotnet new template for an HTTP API using ASP.NET Core controllers in .NET 10, built with a streamlined Clean Architecture. All the layers you need, none of the ceremony you don't.

It's one of five Lean Mean Clean Apps templates. They share the same Application and Infrastructure layers and differ only in how they face the world. Same genes, different haircuts.

The guides, the reference and the reasoning behind every opinion live at leanmeancleanapps.github.io/webapi. This is the version for people who skim. We see you.

Get started

You need the .NET 10 SDK. Docker is optional, but it's the quickest way to see it running.

# Install the template
dotnet new install CleanWebApi.Template

# Create a solution
dotnet new cleanwebapi --name WorksOnMyMachine.Movies --authorName "Your Name"
cd WorksOnMyMachine.Movies

cleancontrollers works too, for anyone who'd rather not type cleanwebapi every time, and so do lmca-webapi and leanmeancleanapps-webapi. dotnet new search leanmeanclean lists the whole family.

Option	Default	What it does
--name, -n	The folder's name	Names the solution and its root namespace
--authorName, -an	Stephen Walsh	Puts your name on the assembly instead of ours
--include-auth	Off	Adds JWT bearer token authentication. Leave it out and the API has no auth code at all
--authority, -iss	Empty	Your OAuth authorization server. Required with --include-auth
--audience, -aud	Empty	The audience tokens must be issued for, usually the API's own URL. Only used with --include-auth
--no-restore	Off	Skips the package restore that normally runs once the solution is created

Rather click than type? Visual Studio and Rider show the same options in their new project dialogs. They always show the authority and audience fields, but only use them when Include authentication is ticked. In the terminal, dotnet new cleanwebapi --help lists them all.

That's three layers, four test projects, a Dockerfile and a CI pipeline. Go and tell your team you've been working on it all week.

Run it

# Build the image and start it with sample data, plus a collector and the Aspire dashboard for its telemetry
docker compose up -d --build

# Ask it for a page of movies
curl "http://localhost:8080/api/movies?query=space&limit=2"

{
  "items": [
    {
      "id": "cb188ef6-14e7-f85f-2f78-924c2ab26b28",
      "title": "Deep Space Gardeners",
      "reviewCount": 5,
      "averageStars": 3.4
    },
    {
      "id": "dfefa450-5454-6a4d-a4aa-95a9b047c17b",
      "title": "Postcards from Outer Space",
      "reviewCount": 1,
      "averageStars": 3
    }
  ],
  "offset": 0,
  "limit": 2,
  "totalCount": 4
}

The sample movies are all made up, and the critics are harsh.

Every list endpoint returns one page at a time, with its offset, limit and a totalCount, so you always know how much more there is. Movies and authors come with their review count and average stars, worked out by the database rather than in a loop somewhere. Ask for one by id and its reviews come along for the ride.

Open Scalar at http://localhost:8080/scalar to browse and try every endpoint. Each one is documented with XML comments that the .NET 10 OpenAPI generator reads at build time, so the document at /openapi/v1.json can't drift from the code. Its logs, traces and metrics land in the Aspire dashboard at http://localhost:18888.

No Docker? dotnet run --project src/Presentation works too. Every other way to run it, from plain docker run to stamping a version into the image, is in docs/RUN.md.

The API is open unless you ask for authentication. Create the solution with --include-auth --authority https://login.example.com --audience https://api.example.com and the movie, author and review endpoints ask for a JWT bearer token. The version endpoint asks for one too. Health checks, the OpenAPI document and Scalar stay open, and Scalar has a spot to paste your token. Leave --include-auth out and there's no authentication code in the solution at all, so there's nothing to leave switched off by accident. Securing the API has the details, including how to add it later.

What's inside

Three layers, loosely based on Clean Architecture. Fewer layers than an onion, more than a sandwich.

• Presentation is the HTTP API, with a controller per feature. Each action sends its request through Mediator, and Application errors become Problem Details responses.
• Application owns the rules. Commands and queries are validated by FluentValidation and mapped by Mapperly.
• Infrastructure owns the data, with Entity Framework Core on SQLite. Everything in it is internal, so Presentation can wire it up but can't move in.

There's a little CQRS in how commands and queries are shaped, but reads and writes share one database underneath. CQRS-curious, not CQRS-committed.

And around the edges:

• Tests use xUnit, Shouldly and NSubstitute, with coverage from Coverlet. Each test gets its own throwaway in-memory database, so no test can spoil another one's data.
• Sample data comes from Bogus, and only when Database:SeedSampleData is on. A real deployment never starts with fake reviews.
• Telemetry is OpenTelemetry all the way: a span for every request and use case, metrics from ASP.NET Core, EF Core and the .NET runtime, and Serilog logs that know which trace they belong to. It all leaves over OTLP when OTEL_EXPORTER_OTLP_ENDPOINT is set, so point it at whatever backend you like. Docker Compose runs an OpenTelemetry Collector that forwards it to the Aspire dashboard, the same shape you'd run in production. Health checks answer at /health/live and /health/ready.
• Build rules live in Directory.Build.props. Code style and the recommended analyzers run on every build, warnings fail it, and package versions sit in one place with Central Package Management.
• The container runs as a non-root user and has its own health check.
• The pipeline builds, checks formatting, tests with a 95% coverage bar, makes sure the packed template still works, runs CodeQL, reviews new dependencies and their licences, starts the image to check it actually answers, and scans the container and Dockerfile with Trivy. Then it sums the lot up in one comment on your pull request, so you know exactly who to blame. Your copy, or a solution from dotnet new, gets the format check, build and tests with no accounts, tokens or secrets, so it goes green the moment you push it. The scans stay switched off outside our organisation until you want them, and Jacques can switch them on with you. Trust is earned.
• Dependabot bundles the month's dependency updates into one pull request on the 15th.

The architecture page has the long version, with full credit to Jason Taylor's template and Uncle Bob for the ideas.

Releases

A new version lands on the 1st of each month, as long as something changed, with notes for every pull request in the GitHub release. No changes, no release. We're not here to pad the download stats. Each release also carries an SPDX bill of materials listing every package the API ships with, for anyone whose security team asks nicely (or not so nicely).

dotnet new update

The family

Template	Presentation
Clean Minimal API	ASP.NET Core Minimal APIs
Clean Model Context Protocol	Model Context Protocol server
Clean GraphQL API	GraphQL with Hot Chocolate
Clean Web API	ASP.NET Core controllers, you are here
Clean Lambda Function	AWS Lambda

Contributing

Bug reports, ideas and pull requests are all welcome, and typo fixes doubly so. Start with the contributing guide and the code of conduct. Security problems go through the security policy, not an issue.

Who built this

Built by Stephen Walsh in spare time, with strong coffee and a healthy disregard for pomp and ceremony. Say hello on GitHub, LinkedIn, Medium or at stphnwlsh.github.io.

If this template saves you some time, sponsoring the work keeps all five templates current and the coffee flowing, which is the real dependency here.

License

MIT. Take it, change it, ship it. Just don't blame us for your production incidents.