Building a CRUD REST API with Minimal APIs in .NET 7

For developers heading to the C# Corner Annual Conference 2020, the modern .NET track is one of the most crowded rooms on the agenda. Attendees arrive after months of watching the .NET team strip away ceremony and boilerplate, and they want to know how little code they can ship while still running a production-grade service. Minimal APIs in .NET 7 deliver exactly that, replacing the heavy scaffolding of MVC controllers with a few lines of lambda-rich C#.

In Australia's software scene, this matters because teams in Sydney, Melbourne, Brisbane, and Perth are often small, lean, and asked to move fast for fintechs, agtech startups, and government digital projects. A single developer can stand up a service, deploy it to an Australian Azure region, and still leave the office in time to grab a flat white before the trams stop running in the CBD. The rest of this walkthrough shows how to build a CRUD REST API with Minimal APIs in .NET 7, from a blank dotnet new web project through to a hosted endpoint that respects local data residency.

Why Minimal APIs Matter for Modern .NET Teams

Minimal APIs arrived as a response to years of feedback from teams that wanted to write a tiny service without fighting the conventions of ASP.NET Core MVC. In .NET 7 the experience matured: route groups, typed results, filters, and OpenAPI support all moved out of preview and became first-class citizens. For a CRUD-style microservice, that translates into a single Program.cs file that anyone in the team can read on a Monday morning without skimming three layers of inheritance.

Australian engineering managers appreciate this for hiring reasons. The country imports senior .NET talent from the UK, India, and South-East Asia, and short onboarding time is a competitive edge. A new starter joining a Sydney-based health platform can read a Minimal API codebase over a coffee at a café in Surry Hills and contribute a new endpoint before the next standup. The same person, given a sprawling controller-heavy project, might spend their first week untangling attribute routes.

Setting Up the Project in .NET 7

Open a terminal on a Windows, macOS, or Linux machine and run dotnet new web -n Orders.Api -f net7.0. That single command scaffolds a project with Program.cs as the only meaningful file. Add a few NuGet packages: Microsoft.EntityFrameworkCore.Sqlite for local development and Microsoft.EntityFrameworkCore.SqlServer for production, plus Swashbuckle.AspNetCore if you want a quick OpenAPI surface for the conference demos.

Edit the csproj to enable nullable reference types and implicit usings, then add <TreatWarningsAsErrors>true</TreatWarningsAsErrors> to keep the codebase honest. Many Australian dev shops treat warnings as errors from day one because they operate under strict compliance regimes, especially in banking and federal government. With the project ready, the next step is to model the data the API will expose.

Defining the Data Model and Repository Layer

Even with Minimal APIs, the rule of keeping domain types separate from HTTP concerns still applies. Create an Order record with an Id, CustomerId, Amount, Currency, and CreatedAtUtc. Use a record type because value semantics play nicely with JSON serialisation, and they remove a whole class of bugs around accidental mutation. For an Australian fintech the Currency field will usually be AUD, but storing it explicitly leaves room for cross-border work.

A thin repository interface keeps things testable. Something like IOrderRepository with GetAllAsync, GetByIdAsync, AddAsync, UpdateAsync, and DeleteAsync is enough for a CRUD service. Register the implementation with the DI container in Program.cs, swapping the in-memory version for an Entity Framework Core implementation when the database is wired up. The combination of Minimal APIs and a clean repository is a sweet spot for solo developers in Adelaide building internal tools for local councils.

Implementing CRUD Endpoints with Minimal APIs

Route groups make the endpoint mapping readable. A block such as app.MapGroup("/orders").WithTags("Orders") followed by MapGet, MapPost, MapPut, and MapDelete lambdas is the entire HTTP surface for the resource. Each lambda takes an IOrderRepository parameter, resolves the request, and returns a Results.Ok(...), Results.Created(...), or Results.NotFound() typed result. This pattern is what attendees at C# Corner will see in many of the conference sessions, and it is the recommended way to build a CRUD REST API with Minimal APIs in .NET 7.

Before locking in the pattern, it helps to compare it with the alternatives that older .NET teams still maintain.

Filters attach cross-cutting behaviour without polluting the handlers. A simple ValidateFilter checks ModelState before the lambda runs and short-circuits with a 400 response. A logging filter wraps the endpoint in a stopwatch and emits a structured log entry with the route template and elapsed milliseconds, which is gold for ops teams in Brisbane watching latency during peak AEST trading hours. Adding WithOpenApi() and WithName(...) at this stage sets up the service for free Swagger documentation and link generation.

Validation, Error Handling, and Observability

Minimal APIs play well with the same validation ecosystem that MVC developers already know. Plug in FluentValidation, register validators as transient services, and call validator.ValidateAsync inside the POST and PUT handlers. Return a Results.ValidationProblem(errors) so clients receive a standard RFC 7807 problem-details payload. Localised error messages can be sourced from IStringLocalizer for Australian English, which is occasionally useful when a user sees "colour" instead of "color" in their validation response.

For error handling, an exception-handling middleware that wraps app.UseExceptionHandler(...) keeps stack traces out of HTTP responses in production. Pair this with Serilog or the built-in Microsoft.Extensions.Logging and a sink such as Seq or Application Insights. Australian teams often default to Application Insights because it ships with the Azure subscription already negotiated through the enterprise agreement, and the Melbourne-based Microsoft team has been pushing adoption hard with local partners.

Testing Locally and in CI

Run dotnet run and curl the endpoints. A smoke test suite using WebApplicationFactory<Program> and xUnit gives end-to-end coverage that boots the API in-memory and exercises every route. Australian teams with a strong financial-services presence, including the big four banks' engineering outposts in Sydney, treat integration tests as non-negotiable. The cost of skipping them is a Sev-1 incident that hits the ATO-fed reconciliation pipelines at 9 a.m. AEDT.

Wire the same test project into a GitHub Actions or Azure DevOps pipeline. Cache the NuGet packages by hashing the csproj, restore on a hosted Linux agent, run dotnet test, and publish coverage to Coveralls or SonarQube. Set a quality gate of 80 percent line coverage for the repository and handler code; relax it only for the Program.cs composition root, which is mostly configuration.

Deploying and Operating in the Australian Cloud

Deployment decisions in Australia lean heavily on latency and data sovereignty. The Australia East (Sydney) and Australia Southeast (Melbourne) regions cover most workloads, with Australia Central (Canberra) reserved for government and defence tenants that require specific certifications. Pick a region close to the user base, then add a second region only when the business case is solid; cross-region replication is not free, and Azure bandwidth between Sydney and Melbourne can rack up surprising bills on a usage-based invoice.

Pair the deployment with Azure Cosmos DB when the workload needs global distribution, low-latency reads, or elastic throughput. The official write-up on Azure Cosmos DB globally walks through partition keys, consistency levels, and change-feed patterns that line up neatly with Minimal API handlers. For workloads that stay inside Australia, a SQL database in Australia East plus a Basic App Service plan is enough for a CRUD service handling a few thousand requests per minute.

Before shipping, tick off the operational habits that separate a demo from a real service:

• Enable HTTPS redirection, HSTS, and a sensible CORS policy from the first deployment.
• Ship OpenAPI metadata through Swashbuckle or NSwag, and publish a client package for downstream .NET teams.
• Wire health checks for liveness and readiness, including a database ping, and expose them at /health/live and /health/ready.
• Add an integration test that posts a real order and reads it back, so the happy path stays green across refactors.
• Configure structured logging with correlation IDs that flow from the gateway all the way to repository calls.
• Use dotnet user-secrets or Azure Key Vault for connection strings, never check secrets into git.
• Document the runbook for on-call, including how to roll back an App Service slot swap during a Sydney trading-day incident.

These habits matter even more in the Australian market, where compliance teams routinely request SOC 2 reports, IRAP assessments, and APRA CPS 234 evidence. A service that ticks the boxes on observability, secret management, and deployment hygiene sails through vendor onboarding, while a sloppy one spends three months answering questionnaires.