On 2012-02-14 17:07, Philippe Mougin wrote:
>
> Le 14 févr. 2012 à 15:54, Julian Reschke a écrit :
>
>> On 2012-02-14 14:29, Philippe Mougin wrote:
>>> Hi,
>>> Using 422 is fine. It isn't defined the HTTP spec but in RFC 2518, which
>>> is as cool. The HTTP spec allows for definition of new HTTP status codes.
>>
>> RFC 4918, actually. But yes, it's ok to use it; that's why HTTP has a status
code registry.
>>
>>> 422 is used in a number of Web APIs. However, it may not be used as much
>>> in new APIs in the future, as the new definition of 400 in HTTP bis
>>> makes it less needed.
>>
>> How so? Me surprised :-)
>
> One of the main incentive for 422 is that 400 is defined as meaning "The
request could not be understood by the server due to malformed syntax".
Therefore 422 comes handy when you want to signal a client error which isn't
"malformed syntax" and isn't covered by other 4xx codes, but comes from an
"unprocessable entity".
> The new definition of 400 in the current http-bis draft is broader: "The
server cannot or will not process the request, due to a client error (e.g.,
malformed syntax)". Hence, there is less incentives to use 422.

I disagree; if you get this impression then we may have to re-tune the
definition of 400.

If 422 is a good match, there is absolutely no reason to use 400, no
matter what we changed in HTTPbis.

Best regards, Julian