Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] API using 422 status code

Expand Messages
  • Julian Reschke
    ... 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,
    Message 1 of 12 , Feb 14, 2012
    • 0 Attachment
      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
    • Philippe Mougin
      ... With what exactly? ... Well, I even wonder if the WebDAV WG would have minted 422 if 400 was defined as in the http-bis draft back then. BTW, I find the
      Message 2 of 12 , Feb 14, 2012
      • 0 Attachment
        Le 14 févr. 2012 à 17:17, Julian Reschke a écrit :

        > 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;

        :-o
        With what exactly?

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

        Well, I even wonder if the WebDAV WG would have minted 422 if 400 was defined as in the http-bis draft back then.

        BTW, I find the new definition much better than the current one (which is too narrow given that 400 is also meant to be the fallback for unrecognized 4xx codes).

        Philippe Mougin
      • Julian Reschke
        ... Yes, that s why we changed it. But this wasn t done to discourage the use of more specific codes. Best regards, Julian
        Message 3 of 12 , Feb 14, 2012
        • 0 Attachment
          On 2012-02-14 17:53, Philippe Mougin wrote:
          > Le 14 févr. 2012 à 17:17, Julian Reschke a écrit :
          >
          >> 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;
          >
          > :-o
          > With what exactly?
          >
          >> if you get this impression then we may have to re-tune the definition of 400.
          >
          > Well, I even wonder if the WebDAV WG would have minted 422 if 400 was defined as in the http-bis draft back then.
          >
          > BTW, I find the new definition much better than the current one (which is too narrow given that 400 is also meant to be the fallback for unrecognized 4xx codes).

          Yes, that's why we changed it. But this wasn't done to discourage the
          use of more specific codes.

          Best regards, Julian
        • Alessandro Nadalin
          ... Good to know! So I guess that in the process of writing a generic HTTP client, I should implement rfc-2616 (draft standard) and its webdav extension,
          Message 4 of 12 , Feb 15, 2012
          • 0 Attachment
            On Tue, Feb 14, 2012 at 3:54 PM, Julian Reschke <julian.reschke@...> wrote:
            > 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.

            Good to know!

            So I guess that in the process of writing a generic HTTP client, I
            should implement rfc-2616 (draft standard) and its webdav extension,
            rfc-4918 (proposed standard), am I right?

            --
            Nadalin Alessandro
            www.odino.org
            www.twitter.com/_odino_
          • Julian Reschke
            ... Actually, you should implement the HTTPbis drafts ( ). If you do things right, you won t need to consider specific
            Message 5 of 12 , Feb 15, 2012
            • 0 Attachment
              On 2012-02-15 15:35, Alessandro Nadalin wrote:
              > On Tue, Feb 14, 2012 at 3:54 PM, Julian Reschke<julian.reschke@...> wrote:
              >> 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.
              >
              > Good to know!
              >
              > So I guess that in the process of writing a generic HTTP client, I
              > should implement rfc-2616 (draft standard) and its webdav extension,
              > rfc-4918 (proposed standard), am I right?

              Actually, you should implement the HTTPbis drafts
              (<http://trac.tools.ietf.org/wg/httpbis/>).

              If you do things right, you won't need to consider specific extensions.
              So design your API so it's not limited to a predefined set of
              methods/status codes/header field names.

              Best regards, Julian
            • Alessandro Nadalin
              ... Yeah, but the approach used by others is pretty different. Just to make an example of a really well engineered php framework (Symfony2):
              Message 6 of 12 , Feb 15, 2012
              • 0 Attachment
                On Wed, Feb 15, 2012 at 3:42 PM, Julian Reschke <julian.reschke@...> wrote:
                >
                > Actually, you should implement the HTTPbis drafts
                > (<http://trac.tools.ietf.org/wg/httpbis/>).
                >
                > If you do things right, you won't need to consider specific extensions. So
                > design your API so it's not limited to a predefined set of methods/status
                > codes/header field names.

                Yeah, but the approach used by others is pretty different.

                Just to make an example of a really well engineered php framework (Symfony2):
                https://github.com/symfony/HttpFoundation/blob/master/Response.php#L52

                If you look at the status codes, this library implements rfc2616 (and
                it's because of this that a 422 status code drives my API client nuts,
                as I'm using Symfony to handle the HTTP layer).

                Do you guys think that limiting themselves at rfc2616 is too naive?

                >
                > Best regards, Julian
                >



                --
                Nadalin Alessandro
                www.odino.org
                www.twitter.com/_odino_
              • Julian Reschke
                ... It s not only naive, it s a bug. Best regards, Julian
                Message 7 of 12 , Feb 15, 2012
                • 0 Attachment
                  On 2012-02-15 15:52, Alessandro Nadalin wrote:
                  > On Wed, Feb 15, 2012 at 3:42 PM, Julian Reschke<julian.reschke@...> wrote:
                  >>
                  >> Actually, you should implement the HTTPbis drafts
                  >> (<http://trac.tools.ietf.org/wg/httpbis/>).
                  >>
                  >> If you do things right, you won't need to consider specific extensions. So
                  >> design your API so it's not limited to a predefined set of methods/status
                  >> codes/header field names.
                  >
                  > Yeah, but the approach used by others is pretty different.
                  >
                  > Just to make an example of a really well engineered php framework (Symfony2):
                  > https://github.com/symfony/HttpFoundation/blob/master/Response.php#L52
                  >
                  > If you look at the status codes, this library implements rfc2616 (and
                  > it's because of this that a 422 status code drives my API client nuts,
                  > as I'm using Symfony to handle the HTTP layer).
                  >
                  > Do you guys think that limiting themselves at rfc2616 is too naive?

                  It's not only naive, it's a bug.

                  Best regards, Julian
                Your message has been successfully submitted and would be delivered to recipients shortly.