This is a question about understanding the path (i.e. the logical flow) to generate a 400 Bad Request when creating a resource via POST. (Note: I've referred to the Omnigraffle document in writing this; if it is not up-to-date, I would be missing some new information.)
First, I want to mention some relevant creation (i.e. the "create" section) behaviors from the decision diagram:
- If
create_partial_put
is false then respond with 400 Bad Request. (This seems reasonable to me.)
- If
create_has_conflict
is true then respond with 409 Conflict. (This seems reasonable to me.)
- If
create_path
is false then respond with 500 Internal Server Error. (But I don't the meaning of create_path
; see #43)
- If
create
is false, then respond with 500 Internal Server Error. (This seems reasonable; however, what about client errors? More on this next.)
It seems pretty clear that resource creation must happen in create
. But as I show above, if a POST resource creation fails, the decision diagram does not provide an opportunity for a 400 Bad Request response.
Next, I want to figure out where client validation should take place in order to generate a 400. If what I've written above is accurate, then resource validation must happen before the "create" block. So, looking around, there are only two prior checks that can result in 400 Bad Request: from_content
and is_request_block_ok
.
- I see that
from_content
will not run if has_content
is false, therefore it would be possible for a malformed client POST to bypass it. Therefore, this does not seem like a smart place to put validation logic for a POST body.
- By the process of elimination,
is_request_block_ok
would be the place to validate a POST payload.
Is my logic accurate? Did I miss anything?
Now, an opinion: if I'm right, it seems unfortunate that is_request_block_ok
is the correct place to do POST payload validation since it happens so much later in the decision diagram. I would expect POST-related logic to be 'closer' together.
For the point of argument, why not make a POST request's payload processing happen during the 'create' block? That would offer the advantage of letting the 'accept' block run beforehand -- why do the creation if the acceptance criteria are not met?