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

Web Servers not RESTful by implementation?

Expand Messages
  • Dimitri Glazkov
    Hi, I am just getting into this REST thinking, and kicking around theoretical questions and basic puzzlers seems to help tremendously in getting the thinking
    Message 1 of 9 , Jul 8, 2005
    • 0 Attachment
      Hi,

      I am just getting into this REST thinking, and kicking around
      theoretical questions and basic puzzlers seems to help tremendously in
      getting the thinking straight.

      Here's one: the absolute majority of all Web Servers will generate a
      server log entry for each request. Thus, a GET request is not
      idempotent by implementation, as each GET request (irreversibly)
      changes the state of the server.

      Is this a big deal?

      :DG<
    • Jon Hanna
      ... The state of the resources is unchanged.
      Message 2 of 9 , Jul 8, 2005
      • 0 Attachment
        > Here's one: the absolute majority of all Web Servers will generate a
        > server log entry for each request. Thus, a GET request is not
        > idempotent by implementation, as each GET request (irreversibly)
        > changes the state of the server.
        >
        > Is this a big deal?


        The state of the resources is unchanged.
      • Jan Algermissen
        ... No, because it is the state of the resource on which you invoke GET that matters. Jan ...
        Message 3 of 9 , Jul 8, 2005
        • 0 Attachment
          On Jul 8, 2005, at 2:38 PM, Dimitri Glazkov wrote:

          > Hi,
          >
          > I am just getting into this REST thinking, and kicking around
          > theoretical questions and basic puzzlers seems to help tremendously in
          > getting the thinking straight.
          >
          > Here's one: the absolute majority of all Web Servers will generate a
          > server log entry for each request. Thus, a GET request is not
          > idempotent by implementation, as each GET request (irreversibly)
          > changes the state of the server.
          >
          > Is this a big deal?

          No, because it is the state of the resource on which you invoke GET
          that matters.

          Jan


          >
          > :DG<
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >

          ________________________________________________________________________
          _______________
          Jan Algermissen, Consultant & Programmer
          http://jalgermissen.com
          Tugboat Consulting, 'Applying Web technology to enterprise IT'
          http://www.tugboat.de
        • Dimitri Glazkov
          ... What if my resource is the list of server log entries? I know I am getting into nitpicking here, but this is a mission of learning for me, so nitpicking is
          Message 4 of 9 , Jul 8, 2005
          • 0 Attachment
            On 7/8/05, Jan Algermissen <jalgermissen@...> wrote:
            > No, because it is the state of the resource on which you invoke GET
            > that matters.
            >
            > Jan

            What if my resource is the list of server log entries? I know I am
            getting into nitpicking here, but this is a mission of learning for
            me, so nitpicking is ok :)

            :DG<
          • Jim Ancona
            ... Going back to what RFC 2616 says (in section 9.1.1): Naturally, it is not possible to ensure that the server does not generate side-effects as a result of
            Message 5 of 9 , Jul 8, 2005
            • 0 Attachment
              Dimitri Glazkov wrote:
              > What if my resource is the list of server log entries? I know I am
              > getting into nitpicking here, but this is a mission of learning for
              > me, so nitpicking is ok :)

              Going back to what RFC 2616 says (in section 9.1.1):

              "Naturally, it is not possible to ensure that the server does not
              generate side-effects as a result of performing a GET request; in fact,
              some dynamic resources consider that a feature. The important
              distinction here is that the user did not request the side-effects, so
              therefore cannot be held accountable for them."

              I guess I would consider your example to fit into the "dynamic resources
              consider that a feature" category.

              Jim
            • Nic Ferrier
              ... Then you could have a RESTfull interface to it. But a server log entry s production would not be part of the RESTfull interface since the log is coming
              Message 6 of 9 , Jul 8, 2005
              • 0 Attachment
                Dimitri Glazkov <dimitri.glazkov@...> writes:

                > On 7/8/05, Jan Algermissen <jalgermissen@...> wrote:
                >> No, because it is the state of the resource on which you invoke GET
                >> that matters.
                >>
                >> Jan
                >
                > What if my resource is the list of server log entries? I know I am
                > getting into nitpicking here, but this is a mission of learning for
                > me, so nitpicking is ok :)

                Then you could have a RESTfull interface to it.

                But a server log entry's production would not be part of the RESTfull
                interface since the log is coming from somewhere else.

                There is no need of course to have a log of an HTTP transaction at
                all.

                The logging is orthogonal to the HTTP transaction processing itself.


                Nic Ferrier
              • Mark Baker
                The safety of GET is not an interoperability requirement (and therefore not a MUST), since the client still gets their data if the server changes state as a
                Message 7 of 9 , Jul 8, 2005
                • 0 Attachment
                  The safety of GET is not an interoperability requirement (and therefore
                  not a MUST), since the client still gets their data if the server
                  changes state as a result. Instead, it just serves as a warning to the
                  resource publisher to keep in mind that any mutation action they take is
                  at their own peril.

                  In other words, logging GET requests is fine, just don't expect to be
                  able to seek damages from Google if you're hard drive fills up with
                  Googlebot requests.

                  Mark.

                  On Fri, Jul 08, 2005 at 07:38:58AM -0500, Dimitri Glazkov wrote:
                  > Hi,
                  >
                  > I am just getting into this REST thinking, and kicking around
                  > theoretical questions and basic puzzlers seems to help tremendously in
                  > getting the thinking straight.
                  >
                  > Here's one: the absolute majority of all Web Servers will generate a
                  > server log entry for each request. Thus, a GET request is not
                  > idempotent by implementation, as each GET request (irreversibly)
                  > changes the state of the server.
                  >
                  > Is this a big deal?

                  --
                  Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                  Coactus; Web-inspired integration strategies http://www.coactus.com
                • Jon Hanna
                  There is of course a difference between logical and physical models of what a computer is doing...
                  Message 8 of 9 , Jul 8, 2005
                  • 0 Attachment
                    There is of course a difference between logical and physical models of
                    what a computer is doing...
                  • Dimitri Glazkov
                    ... This makes sense. Thanks for pointing this out.
                    Message 9 of 9 , Jul 8, 2005
                    • 0 Attachment
                      On 7/8/05, Jim Ancona <jim@...> wrote:
                      > Going back to what RFC 2616 says (in section 9.1.1):
                      >
                      > "Naturally, it is not possible to ensure that the server does not
                      > generate side-effects as a result of performing a GET request; in fact,
                      > some dynamic resources consider that a feature. The important
                      > distinction here is that the user did not request the side-effects, so
                      > therefore cannot be held accountable for them."
                      >
                      > I guess I would consider your example to fit into the "dynamic resources
                      > consider that a feature" category.

                      This makes sense. Thanks for pointing this out.

                      :DG<
                    Your message has been successfully submitted and would be delivered to recipients shortly.