Outline what happens on well formed but invalid data

[ransombriggs]

If someone posts well formed JSON that is invalid, what http error status is returned and what is the format of the error response?

For purposes of an example, assume that app_name does not allow spaces, what would be the response and status to this?

POST /apps
{"app_name": "foo bar":}

[neonstalwart]

throwing in my 2 cents - i'm guessing either 400 or 403 would be the right code

status 400

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

your question sounds like you think 400 might not be right since the JSON syntax was not malformed.

status 403

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

i lean towards 403 because the server has understood the JSON but is refusing to use it and it's not an authorization issue. also, with 403, the server is permitted to provide a reason for refusal in the response.

[geemus]

I could go either way (400 or 403). It is well formed JSON but it is malformed or at least non-validating compared to the schema. I believe we presently are using 400 within the platform API, along with a json body that has an error id and error message in plain text. You can see some examples of that in committee's README here: https://github.com/interagent/committee#committeemiddlewarerequestvalidation

[brandur]

I think I landed on 400's in Committee, but I'm open to suggestions on the
issue if that's not quite theoretically correct.

On Fri, May 30, 2014 at 10:55 PM, Wesley Beary notifications@github.com
wrote:

I could go either way (400 or 403). It is well formed JSON but it is
malformed or at least non-validating compared to the schema. I believe we
presently are using 400 within the platform API, along with a json body
that has an error id and error message in plain text. You can see some
examples of that in committee's README here:
https://github.com/interagent/committee#committeemiddlewarerequestvalidation

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[frankieroberto]

I've been using 422 (along with an explanation in the response code), but I'm not sure how well that follows RFC 4918.