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

Re: [rest-discuss] rest-discuss vs rest-implement

Expand Messages
  • Nic Ferrier
    ... I don t see why we can t talk about these things here. Nic
    Message 1 of 19 , May 22 8:15 AM
      > Personally, I have quite some ideas and question that I would like to share or
      > just get quick comments on and that somehow seem to be inappropriate for
      > rest-discuss. That way these (uncooked) ideas do not make it into the
      > collaborative space they propably need for evolution.
      >
      > What do others think?

      I don't see why we can't talk about these things here.


      Nic
    • Jeffrey Winter
      ... The notion of having practical vs. theoretical discussion lists has been tried with rest-explore, but that seems to have withered. I think this list is
      Message 2 of 19 , May 22 8:43 AM
        >> are you proposing to extend the scope of this list
        >> or to create a new one?
        >
        > No idea. I'd leave it to consensus.

        The notion of having practical vs. theoretical discussion
        lists has been tried with rest-explore, but that seems to
        have withered. I think this list is the appropriate place
        for those sorts of discussions.

        I think the world is still waiting for the definitive REST
        case study. The Amazon and Atom interfaces are often
        used as examples of REST in action, but frankly, those
        domains are so simple that they don't offer much insight.

        And I don't think in those cases it's that REST interface
        is making an inherently complex problem simpler to
        deal with; I they are inherently simple models that are
        being exposed.
      • Lucas Gonze
        ... In my experience here, my practical questions get theoretical answers.
        Message 3 of 19 , May 22 9:06 AM
          On Sat, 22 May 2004, Nic Ferrier wrote:

          >
          > > Personally, I have quite some ideas and question that I would like to share or
          > > just get quick comments on and that somehow seem to be inappropriate for
          > > rest-discuss. That way these (uncooked) ideas do not make it into the
          > > collaborative space they propably need for evolution.
          > >
          > > What do others think?
          >
          > I don't see why we can't talk about these things here.

          In my experience here, my practical questions get theoretical answers.
        • S. Mike Dierken
          bad values in form arguments for POST would indicate a problem with the content - either syntax or meaning. For GET requests form arguments would appear in
          Message 4 of 19 , May 22 9:17 PM
            "bad values in form arguments" for POST would indicate a problem with the
            content - either syntax or meaning.
            For GET requests 'form arguments' would appear in the URI & you could say
            'resource not found' or something - I"m assuming you mean POST rather than
            GET.

            The RFC says 400 means "The request could not be understood by the server
            due to malformed syntax. The client SHOULD NOT repeat the request without
            modifications. " However, I don't know what 'malformed syntax' means. Is it
            the syntax of headers only, or content-type specific syntax of the content?
            Also, how do you indicate syntactically correct content, but with 'out of
            range' (or other) type of errors of the content?

            The "406 Not Acceptable" response looked appealing, until I read the
            meaning.

            Hmm "415 Unsupported Media Type" (The server is refusing to service the
            request because the entity of the request is in a format not supported by
            the requested resource for the requested method.) looks interesting.


            ----- Original Message -----
            From: "Lucas Gonze" <lgonze@...>
            To: "Walden Mathews" <walden@...>
            Cc: <lucas@...>; <rest-discuss@yahoogroups.com>
            Sent: Saturday, May 22, 2004 7:00 AM
            Subject: Re: [rest-discuss] error numbers


            >
            > Well, see, that's exactly why I'm frustrated here -- 4xx is for client
            > errors, but there aren't any 4xx status codes that express that meaning.
            >
            > On Sat, 22 May 2004, Walden Mathews wrote:
            >
            > > Bad values in form arguments is client error: 4xx.
            > >
            > > ----- Original Message -----
            > > From: "Lucas Gonze" <lgonze@...>
            > > To: <rest-discuss@yahoogroups.com>
            > > Sent: Friday, May 21, 2004 5:20 PM
            > > Subject: [rest-discuss] error numbers
            > >
            > >
            > > :
            > > : I'm building a restful api, and am finding that the response error
            codes
            > > : are all specific to http aspects of the transaction. There's no way
            to
            > > : signal errors at the application level. In the end I'm using 500 most
            of
            > > : the time with an explanation of the error in the response body, but
            that's
            > > : not IMO informative.
            > > :
            > > : What I'm looking for at this moment is a status code to say "bad
            values in
            > > : form arguments".
            > > :
            > > : Thoughts?
            > > :
            > > :
            > > :
            > > :
            > > :
            > > :
            > > : Yahoo! Groups Links
            > > :
            > > :
            > > :
            > > :
            > > :
            > > :
            > > :
            > > : __________ NOD32 1.770 (20040521) Information __________
            > > :
            > > : This message was checked by NOD32 antivirus system.
            > > : http://www.nod32.com
            > > :
            > > :
            > >
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
          • John Belmonte
            ... I believe the answer is that you should place machine readable application specific error codes within the entity of your HTTP error response. In other
            Message 5 of 19 , May 22 10:05 PM
              Lucas Gonze wrote:
              > I'm building a restful api, and am finding that the response error codes
              > are all specific to http aspects of the transaction. There's no way to
              > signal errors at the application level. In the end I'm using 500 most of
              > the time with an explanation of the error in the response body, but that's
              > not IMO informative.
              >
              > What I'm looking for at this moment is a status code to say "bad values in
              > form arguments".
              >
              > Thoughts?

              I believe the answer is that you should place machine readable
              application specific error codes within the entity of your HTTP error
              response. In other words, HTTP error codes are meant to convey HTTP
              errors, not the specifics of application level errors.

              -John


              --
              http:// ift ile.org/
            • Jon Hanna
              400 is safe as a general client-side error (as is 500 for a general server-side error). Use 400 and give information as to the error in the response body. --
              Message 6 of 19 , May 23 6:52 AM
                400 is safe as a general client-side error (as is 500 for a general server-side
                error). Use 400 and give information as to the error in the response body.

                --
                Jon Hanna
                <http://www.hackcraft.net/>
                "…it has been truly said that hackers have even more words for
                equipment failures than Yiddish has for obnoxious people." - jargon.txt
              • Mark Baker
                ... I think rest-discuss is fine for this sort of stuff as it s intended to be a place for REST newbies to visit. And what better way to explain REST to
                Message 7 of 19 , May 24 5:14 AM
                  On Sat, May 22, 2004 at 05:02:53PM +0200, Jan Algermissen wrote:
                  > I absolutely agree that practical issues that arise when implemeting RESTful
                  > applications should really have a home[1] (assuming that rest-discuss is intended
                  > to remain theoretical).

                  I think rest-discuss is fine for this sort of stuff as it's intended to
                  be a place for REST newbies to visit. And what better way to explain
                  REST to newbies than to demonstrate how it's applied?

                  We have rest-explore for more theoretical discussions, though it hasn't
                  been used in ages.

                  All's well, I'd say.

                  Mark.
                  --
                  Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                • Lucas Gonze
                  This is the most appealing answer to me, since it s the simplest solution. If anybody disagrees with this let me know.
                  Message 8 of 19 , May 24 7:40 AM
                    This is the most appealing answer to me, since it's the simplest
                    solution. If anybody disagrees with this let me know.

                    On Sun, 23 May 2004, Jon Hanna wrote:

                    > 400 is safe as a general client-side error (as is 500 for a general server-side
                    > error). Use 400 and give information as to the error in the response body.
                    >
                    > --
                    > Jon Hanna
                    > <http://www.hackcraft.net/>
                    > "…it has been truly said that hackers have even more words for
                    > equipment failures than Yiddish has for obnoxious people." - jargon.txt
                    >
                    > Yahoo! Groups Sponsor
                    > ADVERTISEMENT
                    > click here
                    > [rand=394801528]
                    >
                    > _______________________________________________________________________________________________
                    > Yahoo! Groups Links
                    > * To visit your group on the web, go to:
                    > http://groups.yahoo.com/group/rest-discuss/
                    >
                    > * To unsubscribe from this group, send an email to:
                    > rest-discuss-unsubscribe@yahoogroups.com
                    >
                    > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                    >
                    >
                  • Josh Sled
                    ... That is what I ve expected to do in the past ... never did get around to it, but I would have liked to develop a simple markup for transferring the
                    Message 9 of 19 , May 24 8:21 AM
                      On Mon, 2004-05-24 at 10:40, Lucas Gonze wrote:

                      > This is the most appealing answer to me, since it's the simplest
                      > solution. If anybody disagrees with this let me know.

                      That is what I've expected to do in the past ... never did get around to
                      it, but I would have liked to develop a simple markup for transferring
                      the relevant logged error message and stack trace of the server-side
                      errors, at least, back to the client. Not that arbitrary clients should
                      have such information, but we didn't have arbirtary clients, and it
                      would have helped much with debugging. :)

                      The alternative for the arbritary-client case might be an encrypted or
                      opaque version of such, that the client can return it alongside a bug
                      report...


                      For the 4xx errors... we had rich resource space queries ... and with
                      that richness came usage failures. I wanted a machine+human-readable
                      description of the interface to go back in response to 400s that were
                      really "you gave me conflicting or didn't give me enough query
                      arguments". Basically: here's the available query-paramater-value
                      schema I support on this resource.

                      This is something I'd expect a RESTful interface description language to
                      provide.

                      ...jsled

                      --
                      http://www.asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                      # A: Because it breaks the flow of normal conversation.
                      # Q: Why don't we put the response before the request?
                    • Lee Fife
                      Sure looks to me like 400 is exactly the error you re looking for ... And, speaking practically, that s the code I ve returned for bad parameters via either
                      Message 10 of 19 , May 24 1:55 PM
                        Sure looks to me like 400 is exactly the error you're looking for ...
                         
                        And, speaking practically, that's the code I've returned for bad parameters via either POST or GET.
                         
                        And continuing to speak practically, what are you trying to do with the error code?
                         
                        Presumably you want to signal that something broke. 4xx and 5xx do that. And you probably want to give a *person* a clue about what's wrong -- the person might be an end-user that another application displays an error message to, or it might be a developer who pours thru error logs or runs debuggers to figure out what went wrong.
                         
                        So, when I'm doing this, I always include a description of the error in the response body, typically just plain ol' HTML that can end up displayed to a user. I can certainly imagine providing a smarter, machine-readable description for some remote non-human agent, but I haven't seen that in action.
                         
                        -Lee
                        ----- Original Message -----
                        Sent: Saturday, May 22, 2004 8:00 AM
                        Subject: Re: [rest-discuss] error numbers


                        Well, see, that's exactly why I'm frustrated here -- 4xx is for client
                        errors, but there aren't any 4xx status codes that express that meaning.

                        On Sat, 22 May 2004, Walden Mathews wrote:

                        > Bad values in form arguments is client error: 4xx.
                        >
                        > ----- Original Message -----
                        > From: "Lucas Gonze" <lgonze@...>
                        > To: <rest-discuss@yahoogroups.com>
                        > Sent: Friday, May 21, 2004 5:20 PM
                        > Subject: [rest-discuss] error numbers
                        >
                        >
                        > :
                        > : I'm building a restful api, and am finding that the response error codes
                        > : are all specific to http aspects of the transaction.  There's no way to
                        > : signal errors at the application level.  In the end I'm using 500 most of
                        > : the time with an explanation of the error in the response body, but that's
                        > : not IMO informative.
                        > :
                        > : What I'm looking for at this moment is a status code to say "bad values in
                        > : form arguments".
                        > :
                        > : Thoughts?
                      • Walden Mathews
                        Lucas, Some basic principles you can practice: Stick with the correct category, even if the exact code you need is not defined. Avoid defining new codes,
                        Message 11 of 19 , May 24 7:26 PM
                          Lucas,

                          Some basic principles you can practice:

                          Stick with the correct category, even if the exact code you
                          need is not defined.

                          Avoid defining new codes, unless you know you'll always
                          have full control over the client and server designs (which
                          is something you can't ever know for sure).

                          Use the response body to add specificity to error responses,
                          but...

                          Concentrate on application design in which it is impossible
                          for the client to make mistakes (no joke).

                          Regards,

                          Walden

                          ----- Original Message -----
                          From: "Lee Fife" <lee@...>
                          To: <lucas@...>
                          Cc: <rest-discuss@yahoogroups.com>
                          Sent: Monday, May 24, 2004 4:55 PM
                          Subject: Re: [rest-discuss] error numbers


                          Sure looks to me like 400 is exactly the error you're looking for ...

                          And, speaking practically, that's the code I've returned for bad parameters
                          via either POST or GET.

                          And continuing to speak practically, what are you trying to do with the
                          error code?

                          Presumably you want to signal that something broke. 4xx and 5xx do that. And
                          you probably want to give a *person* a clue about what's wrong -- the person
                          might be an end-user that another application displays an error message to,
                          or it might be a developer who pours thru error logs or runs debuggers to
                          figure out what went wrong.

                          So, when I'm doing this, I always include a description of the error in the
                          response body, typically just plain ol' HTML that can end up displayed to a
                          user. I can certainly imagine providing a smarter, machine-readable
                          description for some remote non-human agent, but I haven't seen that in
                          action.

                          -Lee
                          ----- Original Message -----
                          From: Lucas Gonze
                          To: Walden Mathews
                          Cc: lucas@... ; rest-discuss@yahoogroups.com
                          Sent: Saturday, May 22, 2004 8:00 AM
                          Subject: Re: [rest-discuss] error numbers



                          Well, see, that's exactly why I'm frustrated here -- 4xx is for client
                          errors, but there aren't any 4xx status codes that express that meaning.

                          On Sat, 22 May 2004, Walden Mathews wrote:

                          > Bad values in form arguments is client error: 4xx.
                          >
                          > ----- Original Message -----
                          > From: "Lucas Gonze" <lgonze@...>
                          > To: <rest-discuss@yahoogroups.com>
                          > Sent: Friday, May 21, 2004 5:20 PM
                          > Subject: [rest-discuss] error numbers
                          >
                          >
                          > :
                          > : I'm building a restful api, and am finding that the response error
                          codes
                          > : are all specific to http aspects of the transaction. There's no way
                          to
                          > : signal errors at the application level. In the end I'm using 500 most
                          of
                          > : the time with an explanation of the error in the response body, but
                          that's
                          > : not IMO informative.
                          > :
                          > : What I'm looking for at this moment is a status code to say "bad
                          values in
                          > : form arguments".
                          > :
                          > : Thoughts?


                          __________ NOD32 1.772 (20040524) Information __________

                          This message was checked by NOD32 antivirus system.
                          http://www.nod32.com
                        • Lucas Gonze
                          These should go on the Wiki, Walden. A practical problem, which incidentally shows how little REST is used for web services: most apache configurations have
                          Message 12 of 19 , May 25 1:07 PM
                            These should go on the Wiki, Walden.

                            A practical problem, which incidentally shows how little REST is used for
                            web services: most apache configurations have ErrorDocument setups which
                            make it impossible (or very hard) to use the response body to add
                            specificity to error responses.

                            - Lucas

                            On Mon, 24 May 2004, Walden Mathews wrote:

                            > Lucas,
                            >
                            > Some basic principles you can practice:
                            >
                            > Stick with the correct category, even if the exact code you
                            > need is not defined.
                            >
                            > Avoid defining new codes, unless you know you'll always
                            > have full control over the client and server designs (which
                            > is something you can't ever know for sure).
                            >
                            > Use the response body to add specificity to error responses,
                            > but...
                            >
                            > Concentrate on application design in which it is impossible
                            > for the client to make mistakes (no joke).
                            >
                            > Regards,
                            >
                            > Walden
                            >
                            > ----- Original Message -----
                            > From: "Lee Fife" <lee@...>
                            > To: <lucas@...>
                            > Cc: <rest-discuss@yahoogroups.com>
                            > Sent: Monday, May 24, 2004 4:55 PM
                            > Subject: Re: [rest-discuss] error numbers
                            >
                            >
                            > Sure looks to me like 400 is exactly the error you're looking for ...
                            >
                            > And, speaking practically, that's the code I've returned for bad parameters
                            > via either POST or GET.
                            >
                            > And continuing to speak practically, what are you trying to do with the
                            > error code?
                            >
                            > Presumably you want to signal that something broke. 4xx and 5xx do that. And
                            > you probably want to give a *person* a clue about what's wrong -- the person
                            > might be an end-user that another application displays an error message to,
                            > or it might be a developer who pours thru error logs or runs debuggers to
                            > figure out what went wrong.
                            >
                            > So, when I'm doing this, I always include a description of the error in the
                            > response body, typically just plain ol' HTML that can end up displayed to a
                            > user. I can certainly imagine providing a smarter, machine-readable
                            > description for some remote non-human agent, but I haven't seen that in
                            > action.
                            >
                            > -Lee
                            > ----- Original Message -----
                            > From: Lucas Gonze
                            > To: Walden Mathews
                            > Cc: lucas@... ; rest-discuss@yahoogroups.com
                            > Sent: Saturday, May 22, 2004 8:00 AM
                            > Subject: Re: [rest-discuss] error numbers
                            >
                            >
                            >
                            > Well, see, that's exactly why I'm frustrated here -- 4xx is for client
                            > errors, but there aren't any 4xx status codes that express that meaning.
                            >
                            > On Sat, 22 May 2004, Walden Mathews wrote:
                            >
                            > > Bad values in form arguments is client error: 4xx.
                            > >
                            > > ----- Original Message -----
                            > > From: "Lucas Gonze" <lgonze@...>
                            > > To: <rest-discuss@yahoogroups.com>
                            > > Sent: Friday, May 21, 2004 5:20 PM
                            > > Subject: [rest-discuss] error numbers
                            > >
                            > >
                            > > :
                            > > : I'm building a restful api, and am finding that the response error
                            > codes
                            > > : are all specific to http aspects of the transaction. There's no way
                            > to
                            > > : signal errors at the application level. In the end I'm using 500 most
                            > of
                            > > : the time with an explanation of the error in the response body, but
                            > that's
                            > > : not IMO informative.
                            > > :
                            > > : What I'm looking for at this moment is a status code to say "bad
                            > values in
                            > > : form arguments".
                            > > :
                            > > : Thoughts?
                            >
                            >
                            > __________ NOD32 1.772 (20040524) Information __________
                            >
                            > This message was checked by NOD32 antivirus system.
                            > http://www.nod32.com
                            >
                            >
                          • Roy T. Fielding
                            ... Generally speaking, if a person isn t capable of setting the configuration file for their own web space, they aren t capable of running a bidirectional
                            Message 13 of 19 , May 25 4:16 PM
                              > A practical problem, which incidentally shows how little REST is used
                              > for
                              > web services: most apache configurations have ErrorDocument setups
                              > which
                              > make it impossible (or very hard) to use the response body to add
                              > specificity to error responses.

                              Generally speaking, if a person isn't capable of setting the
                              configuration file for their own web space, they aren't capable of
                              running a bidirectional application in that space either.
                              Apache httpd configuration defaults to read-only hypertext, but
                              that doesn't prevent anyone from overriding those defaults for
                              any set of URIs on the server, including those for ErrorDocument.

                              ....Roy
                            Your message has been successfully submitted and would be delivered to recipients shortly.