Use 422 instead of 400 when request is syntactically correct

[jar398]

We have many cases where a 400 is delivered when a 422 is more appropriate, e.g.

curl -D - -X POST https://api.opentreeoflife.org/v3/tree_of_life/node_info -H "content-type:application/json" -d '{"ott_id":81461999}'

The difference is that 400 should be reserved for syntactically ill-formed requests, while 422 is for requests that can't be processed because of some kind of state (e.g. database state), i.e. semantics.

I hadn't been aware of 422 at the time we were doing the API, so I apologize. Perhaps at least for new work ( @bredelings ) we might start using 422.

Related: #80

[bredelings]

What do you think about this?

https://stackoverflow.com/questions/16133923/400-vs-422-response-to-post-of-data

It suggests staying with 400, and that 422 is a WebDAV extension.

[jar398]

Hmm, maybe.

It is indeed specified in a webdav RFC, but there is nothing about it that says it can only be used with webdav. Clients are required to treat unrecognized 4xx statuses the same as 400, so nothing bad can happen if a client sees 422 when it only understands 400.

The odd thing is that it only applies to the semantics of the entity (i.e. the content), not to the query string, so it would not be appropriate if we were to switch from POST to GET as we have discussed. That to me sort of kills the idea, since we would be setting up a future with a weird inconsistency.

So 422 is correct, but (now that I see the change to 400) 400 is also correct, and I guess we should stick with 400.