在 .NET Core 3.1 API 中验证 http 请求的好方法是什么？

Question

I am new to building API's. My project contains three typical layers: controllers, services responsible for business logic, and repositories which are accessing data. Every request coming to my controllers have to go through some validation process before a specific action is performed. For an example, please inspect the code below:

[HttpPost]
public async Task<ActionResult<TicketDTO>> CreateTicketAsync([FromBody] CreateTicketDTO ticket)
{
    try
    {
        if (ticket.Events == null)
        {
            return BadRequest(new {Message = _localizer["LackOfEventsErrorMessage"].Value});
        }

        var user = await _userService.GetUserByIdAsync(ticket.UserId);

        if (user == null)
        {
            return NotFound(new { Message = _localizer["UserNotFoundErrorMessage", ticket.UserId].Value });
        }

        var invalidTicket = await _ticketService.CheckHasUserPlayedAnyOfGamesBeforeAsync(ticket);

        if (invalidTicket)
        {
            return BadRequest(new { Message = _localizer["EventsRepeatedByUserErrorMessage"].Value });
        }

        var createdTicket = await _ticketService.AddTicketAsync(ticket);

        if (createdTicket == null)
        {
            return BadRequest(new { Message = _localizer["TicketNotCreatedErrorMessage"].Value });
        }

        return CreatedAtAction(nameof(GetTicketById), new {ticketId = createdTicket.TicketId}, createdTicket);
    }
    catch (Exception ex)
    {
        return StatusCode(StatusCodes.Status500InternalServerError,
            new
            {
                Message = ex.InnerException != null
                    ? $"{ex.Message} {ex.InnerException.Message}"
                    : ex.Message
            });
    }
}

This is one of my controller methods. Before the ticket is saved to database, it has to pass few checks. The owner of the ticket must exist, if not i return user not found etc. The problem is I do not really like this way of validating requests. The method is messy, and not very readable. I would like to know what is a good approach to validate requests, and react properly if something wents wrong (for example return "UserNotFoundErrorMessage" if there is no user in a database, etc. single catch block doesn't solve my problem. I wouldn't also like to have multiple catch blocks there, it's also messy i think. Am i wrong?) I wonder does the attached snippet violate some clean code rules or not? How the code should look like? What I am doing wrong?

Answer 1

All of this logic should be shuffled into your business layer, ie your services. The service methods, then, should return a "result" class, which is basically just a way of sending multiple bits of information back as the return, ie success/fail status, errors, if any, the actual result in the case of a query or something, etc. Then, you can simply switch on the error and respond accordingly.

As far as the catches go, especially the main one that simply returns a 500, use a global exception handler. Let the error bubble up from the action and rely on the global handler to return an appropriate response.

Answer 2

Like others have already pointed out, this does not seem half bad.

I can tell you as much that we have snippets of code that are 10 times the size of this. Tbh, this seems like small part compared to some modules i've seen in my company's codebase.

That being said, you could move a bit more logic away from the controller, and to other layers. For example, when getting a user by its Id, you can also throw a not found exception from your serviceclass if an user by that id does not exist. you have now stuffed everything into a controller, whilst it feels like this is more the resposibility of the service.

Another thing you could do is perhaps use middleware:

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.1

You can create validation pipelines for your response.

I've also tried working with a validation pattern. In this case i would create some rules for checks, and applied these rules to stuff to validate. I then had a validator object that would take all the rules an prompt an appropriate output. This made the code cleaner and resuse better, however added some complexity and i ended up not using it. It was different than the rest of the codebase and therefore foreign to colleagues, and thus i had good argument not to use it.