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.