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

Restful validation error reporting

Expand Messages
  • Sebastien Lambla
    Hi all, I am wondering how you would react to a POST that does not pass a set of criterias? An example: a POST to /customers can create a new customer based on
    Message 1 of 5 , May 31, 2008

      Hi all,

       

      I am wondering how you would react to a POST that does not pass a set of criterias?

       

      An example: a POST to /customers can create a new customer based on a number of content-types. One of them is www-urlencoded from a browser. That browser uses a form that lives at /customers;editor.html and has a <form> pointing to /customer. The editor page was accessed after the client dereferenced /customers and was given a 300.

       

      Enoug said, data validation fails, /customers cannot accept the request entity. Would you 400 to the request and pass /customers;editor.html in the body with an appropriate Content-Location header (assuming the client has Accept: application/html+xml) and the details of why the validation failed?

       

      It seems to be the best solution I’ve found so far but I’m sure other people have come up with better alternatives J

       

      Seb

    • mike amundsen
      Seb: I usually do just what you describe: return 400 with an informative error message. As for the media-type of the return, I do this: - return a helpful
      Message 2 of 5 , May 31, 2008
        Seb:

        I usually do just what you describe: return 400 with an informative
        error message.

        As for the media-type of the return, I do this:
        - return a helpful (possibly brief) message as the status description
        (400 "Invalid Document ID")
        - build up a body in the same media-type as the Content-Type header
        used in the POST
        - if the Content-Type of the POST was "www-urlencoded", use
        "text/html" as the body type
        - if the Content-Type of the POST was some form of binary", use
        "text/plain" as the body type

        This way clients that do not render the body will have some helpful
        data they can echo in a dialog box

        MikeA

        On Sat, May 31, 2008 at 8:08 AM, Sebastien Lambla <seb@...> wrote:
        > Hi all,
        >
        >
        >
        > I am wondering how you would react to a POST that does not pass a set of
        > criterias?
        >
        >
        >
        > An example: a POST to /customers can create a new customer based on a number
        > of content-types. One of them is www-urlencoded from a browser. That browser
        > uses a form that lives at /customers;editor.html and has a <form> pointing
        > to /customer. The editor page was accessed after the client dereferenced
        > /customers and was given a 300.
        >
        >
        >
        > Enoug said, data validation fails, /customers cannot accept the request
        > entity. Would you 400 to the request and pass /customers;editor.html in the
        > body with an appropriate Content-Location header (assuming the client has
        > Accept: application/html+xml) and the details of why the validation failed?
        >
        >
        >
        > It seems to be the best solution I've found so far but I'm sure other people
        > have come up with better alternatives J
        >
        >
        >
        > Seb
        >
        >



        --
        mca
        http://amundsen.com/blog/
      • Berend de Boer
        ... mike As for the media-type of the return, I do this: - return a mike helpful (possibly brief) message as the status description mike (400 Invalid
        Message 3 of 5 , Jun 1, 2008
          >>>>> "mike" == mike amundsen <mamund@...> writes:

          mike> As for the media-type of the return, I do this: - return a
          mike> helpful (possibly brief) message as the status description
          mike> (400 "Invalid Document ID")

          I do this as well.

          mike> - build up a body in the same
          mike> media-type as the Content-Type header used in the POST

          Nice idea, however wouldn't you say that text/plain would suffice in all
          cases? A browser renders text/plain just as well, if it is just a short
          message. For more complex responses and formatting text/html is ideal of
          course.

          Is that the reason for you to return text/html? I.e. you have error
          content that renders better in HTML?

          --
          Cheers,

          Berend de Boer
        • Daniel Yokomizo
          ... I use something similar to Mike s approach. If we use the same media-type as the request we can ensure the agent will understand it, sometimes the agent is
          Message 4 of 5 , Jun 1, 2008
            On Sun, Jun 1, 2008 at 4:39 PM, Berend de Boer <berend@...> wrote:
            >>>>>> "mike" == mike amundsen <mamund@...> writes:
            >
            > mike> As for the media-type of the return, I do this: - return a
            > mike> helpful (possibly brief) message as the status description
            > mike> (400 "Invalid Document ID")
            >
            > I do this as well.
            >
            > mike> - build up a body in the same
            > mike> media-type as the Content-Type header used in the POST
            >
            > Nice idea, however wouldn't you say that text/plain would suffice in all
            > cases? A browser renders text/plain just as well, if it is just a short
            > message. For more complex responses and formatting text/html is ideal of
            > course.
            >
            > Is that the reason for you to return text/html? I.e. you have error
            > content that renders better in HTML?

            I use something similar to Mike's approach. If we use the same
            media-type as the request we can ensure the agent will understand it,
            sometimes the agent is a browser but sometimes it isn't. Also if the
            Content-Type is extensible you can just return the POSTed entity with
            annotated error messages. The difference in my approach is that we
            check the Accepts header to see if the Content-Type is acceptable to
            the agent, because if it isn't the agent probably won't be prepared to
            handle it.

            > --
            > Cheers,
            >
            > Berend de Boer

            Best regards,
            Daniel Yokomizo
          • Sebastien Lambla
            Rasta automatically returns an error message in whatever is in the Accept: header, using hte request media type as a differenciating factor only when there s a
            Message 5 of 5 , Jun 2, 2008
              Rasta automatically returns an error message in whatever is in the Accept:
              header, using hte request media type as a differenciating factor only when
              there's a doubt as to what conneg would return.

              The issue here is for browsers. Returning text/plain is not an option and
              returning the original form with a marker of what the error was (missing
              email address for example) is the expectation. Hence why I was suggesting
              sending back the editor html page in the body of the 400, it will be the
              same response code as with other media-types, but the user's expectations in
              form validation are preserved.

              -----Original Message-----
              From: Daniel Yokomizo [mailto:daniel.yokomizo@...]
              Sent: 01 June 2008 21:00
              To: Berend de Boer
              Cc: mike amundsen; Sebastien Lambla; rest-discuss@yahoogroups.com
              Subject: Re: [rest-discuss] Restful validation error reporting

              On Sun, Jun 1, 2008 at 4:39 PM, Berend de Boer <berend@...> wrote:
              >>>>>> "mike" == mike amundsen <mamund@...> writes:
              >
              > mike> As for the media-type of the return, I do this: - return a
              > mike> helpful (possibly brief) message as the status description
              > mike> (400 "Invalid Document ID")
              >
              > I do this as well.
              >
              > mike> - build up a body in the same
              > mike> media-type as the Content-Type header used in the POST
              >
              > Nice idea, however wouldn't you say that text/plain would suffice in all
              > cases? A browser renders text/plain just as well, if it is just a short
              > message. For more complex responses and formatting text/html is ideal of
              > course.
              >
              > Is that the reason for you to return text/html? I.e. you have error
              > content that renders better in HTML?

              I use something similar to Mike's approach. If we use the same
              media-type as the request we can ensure the agent will understand it,
              sometimes the agent is a browser but sometimes it isn't. Also if the
              Content-Type is extensible you can just return the POSTed entity with
              annotated error messages. The difference in my approach is that we
              check the Accepts header to see if the Content-Type is acceptable to
              the agent, because if it isn't the agent probably won't be prepared to
              handle it.

              > --
              > Cheers,
              >
              > Berend de Boer

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