Q:

How to discern between model binding errors and model validation errors?

I'm implementing a REST API project using ASP.NET Core MVC 2.0, and I'd like to return a 400 status code if model binding failed (because the request is syntactically wrong) and a 422 status code if model validation failed (because the request is syntactically correct but contains unacceptable values).
As an example, given an action like
[HttpPut("{id}")]
public async Task<IActionResult> UpdateAsync(
    [FromRoute] int id,
    [FromBody] ThingModel model)

I'd like to return a 400 status code when the id parameter in the route contains a non-digit character or when no body has been specified in the request and a 422 status code when the properties of ThingModel contain invalid values.
From what I've seen both IValueProvider and IModelBinder implementations add their errors to the request's ModelStateDictionary like the validators do, and there is no way to inject code between binding and validation.
How can I implement such a behavior?

A:

Haven't checked option #1 yet, but:

ModelState.ValidationState has 4 possible values (Unvalidated, Invalid, Valid, Skipped) where in case of model binding errors I do get Unvalidated as a value
Also would consider using ApiBehaviorOptions (see sample here) to automatically return a new BadRequestObjectResult(actionContext.ModelState) - since in case of binding error with a NULL bound value there's nothing to do and in case of validation errors we probably can't do anything either.

Quick notes for the ApiBehaviorOptions:

must use ApiController attribute (which requires also routing attribute on the controller level also and does alter the way binding works)
the default behaviour with ApiController attribute will return a BadRequestObjectResult(actionContext.ModelState) without any extra code and configuration
if you decide to roll your own ApiBehaviorOptions - you must initialize it after service.AddMvc or need to use: services.PostConfigure(o => {}) which has similar effect
ApiBehaviorOptions SuppressModelStateInvalidFilter has to be false for the InvalidModelStateResponseFactory to work

So in some cases a custom filter is a better solution (less changes).

