If a HTTP request is called on an endpoint that does validation and the validation fails, should it still return 200, but stating in the body the validation failed?
From a HTTP Code perception 200 OK is absolutley correct in my opinion:
<ul>
<li>The request was valid (from an HTTP perspective).</li>
<li>The server understood the request.</li>
<li>The server could process the request.</li>
<li>There was absolutely nothing wrong with the client sending this request.</li>
<li>The server performed exactly what it was supposed to and returned a result with a body.</li>
</ul>
I have been burned in the past by clients only checking the status code and not the actual body message. This means that even if the validation failed, since it returned 200 they assumed the validation passed. So I have done both in the past, just been consistent and clear in the API docs.
This started quite a bit of discussion in my company, with multiple stack overflow links flying around:
<ul>
<li><a href="https://stackoverflow.com/questions/11257470/is-returning-http-409-appropriate-for-a-validation-check/11978941#11978941" target="_blank" rel="noopener nofollow">https://stackoverflow.com/questions/11257470/is-returning-http-409-appropriate-for-a-validation-check/11978941#11978941</a></li>
<li><a href="https://stackoverflow.com/questions/23496217/http-status-code-for-a-boolean-resource" target="_blank" rel="noopener nofollow">https://stackoverflow.com/questions/23496217/http-status-code-for-a-boolean-resource</a></li>
<li><a href="https://stackoverflow.com/questions/31526843/what-http-response-code-should-i-return-for-validation-only-api-methods" target="_blank" rel="noopener nofollow">https://stackoverflow.com/questions/31526843/what-http-response-code-should-i-return-for-validation-only-api-methods</a></li>
</ul>

The hottest most controversial dev discussions. Found something you'd like to share? Add it in the thread 👇


controversy.dev

HTTP Code for Failed Validation: 200 (OK)?

Hm, really good question. As the endpoint is only for validation, as in check this data if it is OK, I would presume a 200 is correct. But if the endpoint was used to submit the data and that in turn failed validation, I would probably use a 422.
But the most important thing isn’t really what status code you return, but that is well documented what behaviour and status codes are returned when and where.

Coming from the graphql direction, you always get a 200 unless the server is not reachable :D So I am kind of used to it.

One thing I learned, the user is always right. So if people assume to get different status code then this is what we should do

I guess 409 is for conflicts, so validation is not really a conflict. What about a 400 which stands for <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400" target="_blank" rel="noopener nofollow">Bad request</a>, but a 200 with a message should be fine I think

it depends on who is handling the response. some dev deal in response status as a differentiator, some on payload.
but it is better to use 409, which gives a clear picture.