Is it OK to return a 500 error when validation fails on ASP NET MVC using Ajax?

I have a master-detail view for adding, deleting and updating customers on an ASP NET 3.5 MVC 1.0 application. The user should be able to, for example, choose a customer from a list to be edited, and a detailed form is shown in the bottom of the page for him/her to edit the customer's data.

When the user accepts the changes, the data is submitted via an Ajax POST to the server. Validation is performed only server-side.

• If validation fails, I want the form with the customer's data to be reloaded with all validation errors displayed. If
• If validation succeeds, I want the whole customers list to be reloaded with all the new customer's data (alternatively I could reload only the customer being edited's record).

Now to the point. I was thinking about returning a partial view with the form with the validation errors in the first case, or a partial vi开发者_如何学Pythonew with the customer's list on the second one.

In order to difference which part of the page should be updated, return a 500 or a 200 status code, and use Ajax failure and succeess functions to perform the updates.

My question is: is it semantically correct to use a 500 error (internal server error) to signal that a validation failed? Or should I return a JSON object containing an isValid boolean as well as the HTML body, and avoid relying on status codes for this?

Thanks!

I'd generally argue returning HTTP-level errors is reserved for when things is actually broken as opposed to a way of handling an application layer error. Much like one wouldn't necessarily want to throw an exception when logical data validation fails. So I'd vote for passing back a json results object to wrap up the error (or not).

This is really up to you. Without knowing all your requirements, underlying infrastructure, and time constraints it would be impossible to make a judgement.