The Fitness Frog client app already includes some validation.

For example, it won't allow the user to submit the add entry form

until they've supplied all the required values.

Notice that the Save button is disabled and can't be clicked.

If we supply all the required values, The client app will enable the Save button.

Having client-side validation doesn't mean that we can

skip implementing server-side validation.

In fact, if you had to choose between implementing client-side and service-side

validations, it's always best to implement your validations on the server.

Client-side validations are just too easy for users to circumvent.

Currently, the post method just accepts an entry object and

adds it to the database by calling the entries repositories add method.

We're just assuming that the provided entry object is in a valid state.

Meaning, that each of its properties that should have a value has a value.

And that all property values meet our expectation as to what valid

values should be.

Luckily, we don't have to assume anything.

Web API gives us a way to check if our model state is in a valid state.

And if it's not in a valid state, we can return an appropriate

error response to the client, letting them know how to correct a problem.

If you've worked with the ASP.NET MVC Framework before,

you'll feel right at home with how Web API implements model validation.

The API controller-based class provides a model state property that we can

use to check if the model state is in a valid state or not.

Here at the top of our action method, let's add an if statement.

If not |ModelState.IsValid.

And if the model state is in an invalid state, we can call the bad request method,

which will return a response with a 400 bad request HTTP status code.

The bad request method also provides an overload that allows us to pass in

the model state property.

Doing this will cause the error messages in the model state dictionary object to be

serialized to the response message body.

That will give the client the information that they'll need to correct any

issues with the data, before they try sending in another request.

Set a breakpoint just inside of the Post method, and press F5 to start debugging,

so we can test our method using Post method.

Let's start with posting an object with no values to the entry's endpoint.

I already have a post request here in my history, so

I'll click on it to load up the request.

Let's remove the exclude in notes properties as they're not required.

Then, let's set date, activityId,

duration and intensity to null.

Then click the Send button.

Here we are at our breakpoint.

Let's press F10 to step through our code.

If we hover over the ModelState.IsValid property, we can see that it was false.

So our if statement evaluated to true.

That means that we're going to return a call to the bad request method,

passing in our model state.

Press F5 to continue execution.

Scroll down to see the response body.

So the request wasn't successful.

We can see that we received back a 400 bad request HTTP status code.

But the error messages that we received, telling us that the provided values

couldn't be converted to the expected types, aren't very user friendly.

Now, let's try sending an empty object.

Just remove all of the properties and send a set of curly braces.

Click the Send button.

Here we are at our breakpoint again, just inside of the post action method.

Press F10 to step through our code, and look at that.

The ModelState.IsValid property is true.

How is that possible when we didn't supply any values?

Hover over the Entry parameter and expand it so

that you can see the Entry object's property values.

All of our required properties are defined in the Entry class as non-nullable types.

During a parameter binding process, non-nullable

types will be set to their default values if there isn't a value to bind to.

For example the date property, which is of type daytime will

be set to the static value daytime.meanvalue.

ActivityId which is of type int will be set to 0.

Duration which is of type decimal, will also be set 0.

And intensity, which is of type intensity level.

An enumeration defined in entry class will also be set to 0.

If we continue execution, we'll encounter an exception.

This is happening because the date properties daytime minimum value can't be

persisted to the database's daytime data column type.

Not providing all of an objects available properties is called under-posting.

As you can from this example,

Web API by default, doesn't prevent a client from under-posting.

We need a strategy for preventing under-posting for breaking our validation.