Another model binder mystery unveiled

The other day, I set about writing a little API to do some address verification with the USPS. Yeah, I could have just had the apps access the USPS API directly, but there's some other stuff in there that makes it just more convenient to wrap their stuff in my stuff. (Hey Mr. Postman - if you're reading this, I'm still complying with the API rules. :))

To test the API through Swagger, I set up a simple little JSON object in the POST. Wanting to see how resilient the USPS API was, I started with a fully qualified, but slightly incorrect address and started to remove properties. In a JSON object, the easy way to do that is simply not provide them. 

For example, if I've got an address object that looks like this:

• Street 1
• Street 2
• City
• Region
• Zip

To pass it without a Street 2, I simply post this:

In this case, I omitted "street2". Worked like a charm.

Then, I did this:

Didn't hit the controller. Gave me a validation error. "Zip" field required. 

So, I checked the Address object. 

Now, had I seen THIS, I would've immediately understood:

But I didn't. It WASN'T a required attribute. "Street2" was also not a required attribute and worked just fine. So... huh?

As usual, the devil's in the details. Now that Visual Studio has embraced #nullable, it really means it. Turns out, this was all I needed to do to get the controller breakpoint to hit:

In years past, you could get away without that question mark. Not the case now (for a nullable project anyway). 

I spent more time trying to figure this out than I did writing this post. Which is why I wrote this post. Hopefully, it helps somebody else out of this non-obvious obvious dilemma.

And now...coffee.