ASP.NET Core can generate an OpenAPI document from your endpoints, and what it can work out by itself is a list of paths. It can't know that an endpoint "deletes a category that has no products", or that it can answer 409. Four small methods add what's missing. This guide uses them, and shows the JSON that comes out.

logger.LogInformation("Archived product {ProductId}", id) works, but with stricter analyzers it stops the build with CA1848. The replacement is a [LoggerMessage] method: you declare one line, and a source generator writes the rest. Each message gets a name, an event ID and a level in one place, and the call looks like any other method.

Taking an EF Core entity as a request body, and returning one as a response, is less code. It also ties your API to your database, and hands clients control of columns you never meant to share. Here are three real failures of that approach, on a real API, and the small records that prevent them.

On your machine you want to see every SQL statement. In Production you don't: it's noise, and it costs money to store. ASP.NET Core reads appsettings.json, then the file for the current environment on top of it, so one setting in each gives you both. This guide does that for EF Core's SQL log, and checks it in both environments.

DateTime.UtcNow is easy to call and hard to control. Code that checks "is this overdue?" gives a different answer every day, and you can't ask it about next month. TimeProvider, built into .NET 8 and later, is a clock you pass in. Your app uses the real one, and anything else can use a clock that says whatever you need.

{id:int} in a route means "this route only matches if the value is an integer". The difference from a plain {id} shows when someone sends /categories/abc: one answers 404, the other 400. This guide tries every common constraint with real requests, and covers where Microsoft says to stop using them.

A list endpoint collects options: a search term, a category, a sort, a page. Six parameters on one method is hard to read, and passing them along is worse. [AsParameters] puts them in one record, filled from the query string as if each property were its own parameter. This guide uses it on a real product list, with the one detail ASP.NET Core 10 needs.

[Required] and [Range] cover a lot, but not everything. A price in a decimal(12,2) column must be 0 or more, must fit, and must have at most two decimal places, or MySQL rounds it without an error. A custom attribute puts that rule in one class, about ten lines long, that you can use anywhere.

Before .NET 10, minimal APIs didn't check data annotations: you needed a filter or a library. Now one line in Program.cs does it. Put [Required] and [Range] on your request record, and a bad request gets a 400 with every problem listed, before your handler runs. This guide adds it, with the same requests before and after.

Out of the box, an ASP.NET Core API's errors are all different: an empty 404, a stack trace as plain text in Development, and a blank 500 in Production. Problem details is the standard JSON format for errors, and three lines in Program.cs give every failure that one shape. This guide adds them, with the real responses before and after.