AspNetCore.Docs/aspnet/web-api/overview/formats-and-model-binding/model-validation-in-aspnet-...

5.1 KiB

uid title author description ms.author ms.date ms.assetid msc.legacyurl msc.type
web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api Model Validation in ASP.NET Web API | Microsoft Docs MikeWasson aspnetcontent 07/20/2012 7d061207-22b8-4883-bafa-e89b1e7749ca /web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api authoredcontent

Model Validation in ASP.NET Web API

by Mike Wasson

When a client sends data to your web API, often you want to validate the data before doing any processing. This article shows how to annotate your models, use the annotations for data validation, and handle validation errors in your web API.

Data Annotations

In ASP.NET Web API, you can use attributes from the System.ComponentModel.DataAnnotations namespace to set validation rules for properties on your model. Consider the following model:

[!code-csharpMain]

If you have used model validation in ASP.NET MVC, this should look familiar. The Required attribute says that the Name property must not be null. The Range attribute says that Weight must be between zero and 999.

Suppose that a client sends a POST request with the following JSON representation:

[!code-jsonMain]

You can see that the client did not include the Name property, which is marked as required. When Web API converts the JSON into a Product instance, it validates the Product against the validation attributes. In your controller action, you can check whether the model is valid:

[!code-csharpMain]

Model validation does not guarantee that client data is safe. Additional validation might be needed in other layers of the application. (For example, the data layer might enforce foreign key constraints.) The tutorial Using Web API with Entity Framework explores some of these issues.

"Under-Posting": Under-posting happens when the client leaves out some properties. For example, suppose the client sends the following:

[!code-jsonMain]

Here, the client did not specify values for Price or Weight. The JSON formatter assigns a default value of zero to the missing properties.

The model state is valid, because zero is a valid value for these properties. Whether this is a problem depends on your scenario. For example, in an update operation, you might want to distinguish between "zero" and "not set." To force clients to set a value, make the property nullable and set the Required attribute:

[!code-csharpMain]

"Over-Posting": A client can also send more data than you expected. For example:

[!code-jsonMain]

Here, the JSON includes a property ("Color") that does not exist in the Product model. In this case, the JSON formatter simply ignores this value. (The XML formatter does the same.) Over-posting causes problems if your model has properties that you intended to be read-only. For example:

[!code-csharpMain]

You don't want users to update the IsAdmin property and elevate themselves to administrators! The safest strategy is to use a model class that exactly matches what the client is allowed to send:

[!code-csharpMain]

[!NOTE] Brad Wilson's blog post "Input Validation vs. Model Validation in ASP.NET MVC" has a good discussion of under-posting and over-posting. Although the post is about ASP.NET MVC 2, the issues are still relevant to Web API.

Handling Validation Errors

Web API does not automatically return an error to the client when validation fails. It is up to the controller action to check the model state and respond appropriately.

You can also create an action filter to check the model state before the controller action is invoked. The following code shows an example:

[!code-csharpMain]

If model validation fails, this filter returns an HTTP response that contains the validation errors. In that case, the controller action is not invoked.

[!code-consoleMain]

To apply this filter to all Web API controllers, add an instance of the filter to the HttpConfiguration.Filters collection during configuration:

[!code-csharpMain]

Another option is to set the filter as an attribute on individual controllers or controller actions:

[!code-csharpMain]