[ApiController]
[Route("api/orders")]
public sealed class OrdersController : ControllerBase
{
[HttpGet, EnableQuery]
public IQueryable<OrderDto> Get() => _mediator.Query(new GetOrders());
[HttpPost]
public async Task<IActionResult> Create(CreateOrder cmd) => Ok(await _mediator.Send(cmd));
}A second pair of expert eyes on your C# REST APIs.
I'm Mathias. For more than 20 years I've worked on one thing: C# REST APIs and the systems behind them. I look at your code and tell you, in plain words, what's solid, what's risky, and what to fix first.
I do one thing, and I've done it for over twenty years: C# REST APIs — the services other software talks to. That includes the OData query layer, the database access (EF Core, SQL Server), and the parts that have to keep working when a lot depends on them.
The way I build is the standard I hold your code to: clear boundaries between parts (DDD), reads and writes kept separate (CQRS), and tests you can actually rely on.
If your question isn't in that area, I'll tell you honestly rather than take the work. You get someone who knows this deeply — not a little bit of everything.
It's just me doing the work — and that's the point.
Some review companies have hundreds of developers and pass your code to whoever happens to be free. You never know who actually looked at it, or how experienced they are.
Here, one person reviews your code: me. The person you talk to is the person who reads it, and the one who answers for what he found.
Two short tests tell you roughly where you stand. No code needed to take them.
A quick, scored check of how exposed your system is, with a summary you can pass on.
Are your write commands and read queries handled on separate paths?
The same in plain business terms: what the risk is and what it costs to leave it.
Do customers complain the product gets slow as they grow?
You shouldn't hand your code to someone you don't know yet. So don't. The test tells you whether there's anything worth a closer look — and who you'd be trusting with it — before you share a single file.
Each one explains a real problem and how to fix it, in full. The hard part — knowing what your system needs and in what order — is what I do when I look at your code directly.