Your question is good, but I do believe it to be based on opinions. The choice of the appropriate code should be made according to the current RFC. However, like any other standard, the RFC is not always clear and can be interpreted in a variety of ways.

Here are my thoughts on the answers already given and my opinion.

1. Where and where should I look for sources for questions like this?

First of all, the RFC regarding this and what is in vogue at the moment is the 7231 < a>. If you are familiar with English, I suggest you read it to create your own opinions as well.

2. About not using 200 code

Although some web frameworks return 200 in the case of requests with invalid data, I do not believe that this should be the proper code.

According to item 6.3 of 7231, 2xx codes indicate that the customer request has been received, understood and accepted.

So if the purpose of a POST request is to create a new object on the server, and this is not done due to invalid data, I do not think that the code 200 should be returned saying that the request was a success , but rather a code indicating that an error occurred in the processing of sent data.

3. About using the 400 code

If we think that the data sent is also part of the request, if it is invalid and therefore wrong, it is not fair to return a code 400, which indicates a bad request.

Setting the POST method

Looking at the definition of the POST method in the RFC strengthens this idea. According to item 4.3.3, a POST request is requesting that a given resource (or resource ) process the data present in the request according to the semantics of the resource. So, if you send a data that has no meaning to the server, the request will not be understood and should not be processed.

Definition of class 4xx and code 400

Another argument to strengthen the use of the 400 code is the definition of the 4xx class and its own definition:

Class 4xx has codes for when the client makes a mistake. If you understand that the client is responsible for sending valid data (and that validation on the server is done by security measure) 4xx seems to be the appropriate class. It is important to note that class 4xx, according to the RFC, should always return an explanation of the error to the client.

The code 400, in turn, indicates that the server can not, is not able or will not simply process the request by error of the client (the error of sending data that does not have meaning according to the requested resource).

It is important to remember that the RFC does not list the errors that a client can commit, listing only a few examples (syntax error is one of them).

4. Soon ...

In conclusion, the client is responsible for sending data that makes sense to the server, and if it does not, this should be considered a client error. Therefore, I suggest use code 400 and, as provided in the RFC, send a message explaining the error, saying that the data is not valid.

Bonus: Methods you definitely should not use

418: is not a code present in the current RFC and has no semantic value for data validation.

405: Should be used only when the request method is not accepted by the server and not the data itself.

    

Notice of opinion

This answer expresses my opinion and in no way represents an official or correct interpretation.

Error 400

RFC 7321

  

The 400 (Bad Request) status code indicates that the server can not or      will not process the request due to something that is perceived to be      a client error (e.g., malformed request syntax, invalid request      message framing, or deceptive request routing).

Error 400 means that the server refuses to process the request due to an error on the client-side and there is no problem in using it. I personally prefer to keep it for errors in the request itself, and not for your data. Some libraries may send automatic bug reports by default because of this response.

200 - OK

You can send the response as 200, stating that the request has occurred successfully, which is true. And then in the content of the answer write whether the API validated it or not and what the errors were. This is the option I use and recommend, as I like to separate the request itself from the data.

405 - Method not allowed

I believe to be the second best option, here is the official description translated:

  

A request was made for a resource using an order method that is not compatible with this request.

Example: using GET on a form, which requires data to be submitted via POST.

418 - I am a teapot

This status was created as a prank on April 1st and is useless, so I guess since it has no use, you could assign a "special" use to it.

    

You can use the same 400.
The definition in link says:

  

The request could not be understood by the server due to malformed   syntax. The client SHOULD NOT repeat the request without   modifications.

translating ...

  

The request could not be understood by the server because of the syntax   malformed. The client should not repeat the request without   modifications.