0

Before WebAPI, I did all client-side remote validation calls using regular MVC action methods. With WebAPI, I can now have POST, PUT, DELETE, and GET methods on an ApiController. However, validation still needs to happen.

I have successfully been able to put remote validation action methods on an ApiController and get them to work. Before submitting a POST, PUT, or DELETE for a resource, the client can POST to one or more validation URL's to validate user input and receive appropriate validation messages.

My question is, should these remote validation actions be on an ApiController? Or a regular MVC controller? It seems to me having them all in the ApiController makes the most sense, because that class can then encapsulate everything having to do with resource (and resource collection) mutations.

Update: reply @tugberk

I should elaborate. First, we are not using DataAnnotations validation. There are already rich validation rules and messages configured on the domain layer commands using FluentValidation.NET. Many of the validation classes use dependency injection to call into the database (to validate uniqueness for example). FluentValidation has good pluggability with MVC ModelState, but I have not found a good way to plug it into WebAPI ModelState yet.

Second, we are doing validation at the POST, PUT, and DELETE endpoints. Clients do not need to know the validation endpoints in order to discover what went wrong. Here is an example:

var command = Mapper.Map<CreateCarCommand>(carApiModel);
try
{
    _createHandler.Handle(command);
}
catch (ValidationException ex)
{
    return Request.CreateResponse(HttpStatusCode.BadRequest, ex.Message);
}

Clients will get a 400 response along with a message indicating what went wrong. Granted, this is not as granular as the response in the example you linked to. Because we are just returning a string, there is no easy way to parse out which fields each validation message belongs to, which is needed for our own HTML + javascript client of the API. This is why I spiked out adding more granular validation endpoints (as a side note, they are consumed by field-specific knockout-validation calls on our javascript client).

Community
  • 1
  • 1
danludwig
  • 46,965
  • 25
  • 159
  • 237

1 Answers1

0

I am assuming that you are referring to something similar to ASP.NET MVC Remote Validation by saying remote validation. In that case, I don't think that your HTTP API needs a remote validation. Think about a scenario where I need to consume your HTTP API with my .NET application and assume that you have a remote validation. Two things bother me here:

  1. That remote validation is not discoverable unless you are providing a .NET client for your API by yourself and put that logic inside that client.
  2. Assuming that the remote validation is there for the .NET client and the application will make a validation call to the server before sending the actual request, this is just a overkill.

In my opinion, the user send a request to your API and you should make the validation there. You can find a sample from the following URL:

ASP.NET Web API and Handling ModelState Validation

tugberk
  • 57,477
  • 67
  • 243
  • 335
  • Thank you for bringing up these points. I have updated the question in response. – danludwig Oct 31 '12 at 13:36
  • @danludwig Have a look at the `ModelValidatorProvider` extensibility point. It is not as easy as pie but by viewing the default implementations, you may be able to create your own `ModelValidatorProvider` for FluentValidation and register it into the system. – tugberk Oct 31 '12 at 13:49
  • I found a link, and updated my question with it. There is apparently already a pull request for a WebAPI FluentValidation.NET ModelValidatorProvider. I think I would rather wait on that, and in the meantime, continue with my current approach (as long as I don't hear any more compelling arguments against it). It works, and it's not very difficult. – danludwig Oct 31 '12 at 13:57