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

Re: [rest-discuss] Idempotent sequences

Expand Messages
  • Miles Sabin
    Mark Baker wrote, ... Err ... but if we re only paying attention to the state on the server-side, then this isn t a problem. The effect on the server of
    Message 1 of 26 , Sep 3, 2002
    • 0 Attachment
      Mark Baker wrote,
      > Actually, let me take that back. 8-)
      >
      > Let's say the example was;
      >
      > "2" <= GET /foo
      > PUT "1" /foo
      >
      > i.e. GET returns "2", PUT sets value to "1". Obviously in the steady
      > state, this sequence is idempotent, but it isn't on the first go
      > round.

      Err ... but if we're only paying attention to the state on the
      server-side, then this isn't a problem. The effect on the server of
      multiple executions of that sequence is exactly the same as the
      execution of just one.

      The effect on the client changes from execution to execution, sure, but
      that had better *not* make the sequence non-idempotent, otherwise,

      DELETE /foo (200 OK)
      DELETE /foo (404 Not Found)

      would imply that DELETE is non-idempotent.

      > Please ignore my other rants. I'm sick and my head hurts. 8-(

      Is that an effect of tying to make sense of 9.1 or something else? ;-)

      Cheers,


      Miles
    • Miles Sabin
      Mathews, Walden wrote, ... I think the first definition is just fine. The function here is the request, and the domain and range are states of the server (feel
      Message 2 of 26 , Sep 3, 2002
      • 0 Attachment
        Mathews, Walden wrote,
        > According to mydictionary, idempotence is a property of homogeneous
        > functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent.
        > We have to be careful about extending that model to fit the request/
        > response paradigm of REST. If anything, D is the domain from which
        > representations are drawn and (D -> D) represents the mapping of a
        > pre-state for a given resource to its post-state, and in that sense,
        > the 'return' value of the function we're interested in means that
        > the function is defined as a pair
        >
        > (PUT | POST | DELETE) /foo <representation>
        > GET /foo
        >
        > So that the final get represents the function's value (i.e., the
        > second 'D' in the mapping from D -> D).
        >
        > Other definitions of 'idempotent' refer to things like recursive
        > inclusion of C header files; not very enlightening.

        I think the first definition is just fine. The function here is the
        request, and the domain and range are states of the server (feel free
        to replace "server" with "resource" throughout if you'd prefer, it
        shouldn't make any difference).

        Let's write s, s' for states of the server, g(s) and p(s) for,

        GET /foo

        and,

        PUT /foo (with a fixed PUT entity)

        respectiverly, applied to the server in state s. The 9.1 definitions
        imply that,

        g(s) = s

        hence,

        g(g(s)) = g(s)

        because GET is both safe and idempotent. OTOH, the imply that,

        p(s) = s' (where typically s' != s)

        because PUT isn't safe, but,

        p(s') = s'

        because PUT is idempotent, and hence,

        p(p(s)) = p(s)

        DELETE will be similar to PUT.

        One thing to note here is that what the client sees isn't mentioned at
        all: all the above is defined in terms of server states and functions
        mapping server states to server states.

        Hmm ... spelt out this way, there's a trivial proof that all sequences
        of idempotent requests are idempotent sequences. That means that either
        there's something wrong with spelling things out this way (in which
        case, what?), or there's something not quite right with 9.1

        Thoughts?

        Cheers,


        Miles
      • Mathews, Walden
        We re on the same wavelength. The only thing I wasn t sure about was whether everyone agreed on what the function relates. My explicit GET was intended to
        Message 3 of 26 , Sep 3, 2002
        • 0 Attachment
          We're on the same wavelength. The only thing I wasn't sure
          about was whether everyone agreed on what the 'function' relates.
          My explicit GET was intended to mean exactly what you have
          explained, namely that the function is from resource pre-state to
          post-state, and the latter always visible to client. In my
          two-method model of function, I should have included no-op in
          the list of alternates for mutators, so that *nothing* followed by
          a GET is also a 'function'.

          What's the trivial proof? I also sense that it's easy, but if
          it's that easy, then Alloy won't help.

          Walden

          > -----Original Message-----
          > From: Miles Sabin [mailto:miles@...]
          > Sent: Tuesday, September 03, 2002 2:37 PM
          > To: rest-discuss@yahoogroups.com
          > Subject: Re: [rest-discuss] Idempotent sequences
          >
          >
          > Mathews, Walden wrote,
          > > According to mydictionary, idempotence is a property of homogeneous
          > > functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent.
          > > We have to be careful about extending that model to fit the request/
          > > response paradigm of REST. If anything, D is the domain from which
          > > representations are drawn and (D -> D) represents the mapping of a
          > > pre-state for a given resource to its post-state, and in that sense,
          > > the 'return' value of the function we're interested in means that
          > > the function is defined as a pair
          > >
          > > (PUT | POST | DELETE) /foo <representation>
          > > GET /foo
          > >
          > > So that the final get represents the function's value (i.e., the
          > > second 'D' in the mapping from D -> D).
          > >
          > > Other definitions of 'idempotent' refer to things like recursive
          > > inclusion of C header files; not very enlightening.
          >
          > I think the first definition is just fine. The function here is the
          > request, and the domain and range are states of the server (feel free
          > to replace "server" with "resource" throughout if you'd prefer, it
          > shouldn't make any difference).
          >
          > Let's write s, s' for states of the server, g(s) and p(s) for,
          >
          > GET /foo
          >
          > and,
          >
          > PUT /foo (with a fixed PUT entity)
          >
          > respectiverly, applied to the server in state s. The 9.1 definitions
          > imply that,
          >
          > g(s) = s
          >
          > hence,
          >
          > g(g(s)) = g(s)
          >
          > because GET is both safe and idempotent. OTOH, the imply that,
          >
          > p(s) = s' (where typically s' != s)
          >
          > because PUT isn't safe, but,
          >
          > p(s') = s'
          >
          > because PUT is idempotent, and hence,
          >
          > p(p(s)) = p(s)
          >
          > DELETE will be similar to PUT.
          >
          > One thing to note here is that what the client sees isn't
          > mentioned at
          > all: all the above is defined in terms of server states and functions
          > mapping server states to server states.
          >
          > Hmm ... spelt out this way, there's a trivial proof that all
          > sequences
          > of idempotent requests are idempotent sequences. That means
          > that either
          > there's something wrong with spelling things out this way (in which
          > case, what?), or there's something not quite right with 9.1
          >
          > Thoughts?
          >
          > Cheers,
          >
          >
          > Miles
          >
          > ------------------------ Yahoo! Groups Sponsor
          > ---------------------~-->
          > 4 DVDs Free +s&p Join Now
          > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
          > --------------------------------------------------------------
          > -------~->
          >
          > To unsubscribe from this group, send an email to:
          > rest-discuss-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >
        • Miles Sabin
          Mathews, Walden wrote, ... Hmm ... OK, this is a bit rough and ready, but let s see ... By definition GET, PUT and DELETE are idempotent, so, using the
          Message 4 of 26 , Sep 3, 2002
          • 0 Attachment
            Mathews, Walden wrote,
            > What's the trivial proof? I also sense that it's easy, but if
            > it's that easy, then Alloy won't help.

            Hmm ... OK, this is a bit rough and ready, but let's see ...

            By definition GET, PUT and DELETE are idempotent, so, using the notation
            from my previous mail,

            g(g(s)) = g(s) ie. g.g = g
            p(p(s)) = p(s) p.p = p
            d(d(s)) = d(s) d.d = d

            where PUT entities are constant and the request URI is common to g, p
            and d (I'll remove this last assumption later).

            First off, g is the identity function. That might sound odd, but
            remember, we're only interested in the state of the server, so if
            follows from the safeness of GET.

            It follows that every sequence of g, p, d can be simplified to just g,
            or an alternation of p and d, because the g's can be eliminated and
            runs of p's and d's can be collapsed to a single p or d. That means
            that every sequence is equivalent to one of,

            1. g
            2. p.d ... p.d
            3. p.d ... d.p
            4. d.p ... p.d
            5. d.p ... d.p

            Now, a PUT of /foo followed by a DELETE of /foo is equivalent to just a
            DELETE, so,

            d(p(s)) = d(s) ie. d.p = d

            and a DELETE of /foo followed by a PUT of /foo is equivalent to just a
            PUT, so,

            p(d(s)) = p(s) ie. p.d = p

            So we can now reduce the sequences above to,

            1. g
            2. p
            3. p
            4. d
            5. d

            ie. any sequence of g, p, and d is equivalent to the most recent
            non-GET, or to just GET if there are no PUTs or DELETEs involved. But
            those three are all idempotent, so the original sequence must be
            idempotent too.

            OK, now all we have to do is generalize to the case where the sequence
            includes GETs, PUTs and DELETEs wrt different request URIs. On the
            assumption that a PUT or DELETE of /foo only affect /foo and not any
            other resource we can decompose a mixed URI sequence into distinct
            subsequences, one for each distinct URI. For example,

            GET /foo GET /foo
            PUT /bar PUT /bar
            DELETE /foo DELETE /foo
            GET /bar GET /bar
            PUT /foo PUT /foo
            DELETE /bar DELETE /bar

            Because these subsequences are relative to distinct URIs they can't have
            any interdependencies, hence the mixed URI sequence is idempotent if
            each of the homogenous URI sequences is.

            But we've already seen that the homogenous URI sequences are idempotent,
            so all sequences are.

            QED ;-)

            Cheers,


            Miles
          • Miles Sabin
            I wrote, ... No interest in this anyone? Or no opinions? As a reminder this was the puzzle I posed earlier, Hmm ... spelt out this way, there s a
            Message 5 of 26 , Sep 4, 2002
            • 0 Attachment
              I wrote,
              > Mathews, Walden wrote,
              >
              > > What's the trivial proof? I also sense that it's easy, but if
              > > it's that easy, then Alloy won't help.
              >
              > Hmm ... OK, this is a bit rough and ready, but let's see ...
              <snip/>

              No interest in this anyone? Or no opinions?

              As a reminder this was the puzzle I posed earlier,

              Hmm ... spelt out this way, there's a trivial proof that all sequences
              of idempotent requests are idempotent sequences. That means that
              either there's something wrong with spelling things out this way (in
              which case, what?), or there's something not quite right with 9.1

              Thoughts?

              Cheers,


              Miles
            • Mathews, Walden
              Miles, I think that for my part I am convinced that by using a rigorous interpretation of idempotent that your proof is valid, which leaves me also wondering
              Message 6 of 26 , Sep 5, 2002
              • 0 Attachment
                Miles,

                I think that for my part I am convinced that by using a rigorous
                interpretation of 'idempotent' that your proof is valid, which
                leaves me also wondering what Roy meant. Possibly he was merely
                trying to avoid the assertion that a series of idempotent functions
                is idempotent, as opposed to asserting that there are actual
                counter-examples to that, as we seem to interpret him. I dunno.

                Your proof reminded me of an analysis I did a couple of years
                ago for processing SQL trigger results represented as lists of
                deletes and inserts for an entire transaction, especially the
                technique of looking only at the beginning and the end of each
                sequence.

                I suspect that any disagreement about the idempotence of a string
                of idempotent HTTP operations has more to do with the way you
                might map HTTP operations onto the meaning of 'idempotent' than
                with the particular proof you offered. We touched on this before.
                What is the 'function' of an HTTP PUT? I.e., which mapping are
                we interested in? Clearly, sometimes it's resource before-and-after
                state. At other times it may be more like request-to-response
                mapping?

                I'm still open to trying an Alloy model, but I have a hunch that
                it won't provide any more insight into the problem than your proof
                has already given.

                Walden

                > -----Original Message-----
                > From: Miles Sabin [mailto:miles@...]
                > Sent: Wednesday, September 04, 2002 3:19 PM
                > To: rest-discuss@yahoogroups.com
                > Subject: Re: [rest-discuss] Idempotent sequences
                >
                >
                > I wrote,
                > > Mathews, Walden wrote,
                > >
                > > > What's the trivial proof? I also sense that it's easy, but if
                > > > it's that easy, then Alloy won't help.
                > >
                > > Hmm ... OK, this is a bit rough and ready, but let's see ...
                > <snip/>
                >
                > No interest in this anyone? Or no opinions?
                >
                > As a reminder this was the puzzle I posed earlier,
                >
                > Hmm ... spelt out this way, there's a trivial proof that
                > all sequences
                > of idempotent requests are idempotent sequences. That means that
                > either there's something wrong with spelling things out this way (in
                > which case, what?), or there's something not quite right with 9.1
                >
                > Thoughts?
                >
                > Cheers,
                >
                >
                > Miles
                >
                > ------------------------ Yahoo! Groups Sponsor
                > ---------------------~-->
                > 4 DVDs Free +s&p Join Now
                > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
                > --------------------------------------------------------------
                > -------~->
                >
                > To unsubscribe from this group, send an email to:
                > rest-discuss-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/
              • Miles Sabin
                Mathews, Walden wrote, ... Yes, I think that s right. The problem here is that these two views clearly aren t equivalent, and are typically in conflict. REST,
                Message 7 of 26 , Sep 5, 2002
                • 0 Attachment
                  Mathews, Walden wrote,
                  > I suspect that any disagreement about the idempotence of a string
                  > of idempotent HTTP operations has more to do with the way you
                  > might map HTTP operations onto the meaning of 'idempotent' than
                  > with the particular proof you offered. We touched on this before.
                  > What is the 'function' of an HTTP PUT? I.e., which mapping are
                  > we interested in? Clearly, sometimes it's resource before-and-after
                  > state. At other times it may be more like request-to-response
                  > mapping?

                  Yes, I think that's right.

                  The problem here is that these two views clearly aren't equivalent, and
                  are typically in conflict. REST, as I understand it, looks to have a
                  more natural fit with the resource before-and-after state view. So does
                  that mean that REST is in conflict with part of RFC 2616? If it is in
                  conflict, is that a problem for REST, or is it the inevitable
                  consequence of an inconsistency in RFC 2616?

                  FWIW, the interpretation of idempotent sequences of requests isn't
                  merely a niggling theoretical puzzle: it has direct implications for
                  the implementation of HTTP/1.1 request piplining on the client side.
                  Having built non-caching HTTP/1.1 proxies which support piplining
                  across from downstream clients to upstream origin servers, I can vouch
                  for the fact that the tensions in section 9.1 are a real headache with
                  uncomfortable implications for interoperability.

                  Mark (B and N), you've done work in a similar area, so you must have run
                  into the same issue: how did you resolve it?

                  Cheers,


                  Miles
                • Mathews, Walden
                  ... Sorry, which part of 2616 do you think is in conflict with REST over the issue of idempotence? Walden
                  Message 8 of 26 , Sep 6, 2002
                  • 0 Attachment
                    > -----Original Message-----
                    > From: Miles Sabin [mailto:miles@...]
                    > Sent: Friday, September 06, 2002 12:54 AM
                    > To: rest-discuss@yahoogroups.com
                    > Subject: Re: [rest-discuss] Idempotent sequences
                    >
                    > The problem here is that these two views clearly aren't
                    > equivalent, and
                    > are typically in conflict. REST, as I understand it, looks to have a
                    > more natural fit with the resource before-and-after state
                    > view. So does
                    > that mean that REST is in conflict with part of RFC 2616? If it is in
                    > conflict, is that a problem for REST, or is it the inevitable
                    > consequence of an inconsistency in RFC 2616?

                    Sorry, which part of 2616 do you think is in conflict with REST
                    over the issue of idempotence?

                    Walden
                  • Mark Baker
                    ... I don t understand the distinction I guess. ... We haven t had any troubles. We tried to use Jeff Mogul s out-of-order spec, but had practical issues with
                    Message 9 of 26 , Sep 6, 2002
                    • 0 Attachment
                      On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote:
                      > Mathews, Walden wrote,
                      > > I suspect that any disagreement about the idempotence of a string
                      > > of idempotent HTTP operations has more to do with the way you
                      > > might map HTTP operations onto the meaning of 'idempotent' than
                      > > with the particular proof you offered. We touched on this before.
                      > > What is the 'function' of an HTTP PUT? I.e., which mapping are
                      > > we interested in? Clearly, sometimes it's resource before-and-after
                      > > state. At other times it may be more like request-to-response
                      > > mapping?
                      >
                      > Yes, I think that's right.

                      I don't understand the distinction I guess.

                      > The problem here is that these two views clearly aren't equivalent, and
                      > are typically in conflict. REST, as I understand it, looks to have a
                      > more natural fit with the resource before-and-after state view. So does
                      > that mean that REST is in conflict with part of RFC 2616? If it is in
                      > conflict, is that a problem for REST, or is it the inevitable
                      > consequence of an inconsistency in RFC 2616?
                      >
                      > FWIW, the interpretation of idempotent sequences of requests isn't
                      > merely a niggling theoretical puzzle: it has direct implications for
                      > the implementation of HTTP/1.1 request piplining on the client side.
                      > Having built non-caching HTTP/1.1 proxies which support piplining
                      > across from downstream clients to upstream origin servers, I can vouch
                      > for the fact that the tensions in section 9.1 are a real headache with
                      > uncomfortable implications for interoperability.
                      >
                      > Mark (B and N), you've done work in a similar area, so you must have run
                      > into the same issue: how did you resolve it?

                      We haven't had any troubles. We tried to use Jeff Mogul's out-of-order
                      spec, but had practical issues with it (it requires using a new client
                      stack). But we don't have a lot of heard reliability guarantees in our
                      use of our platform, so it's possible that I'm missing an edge case
                      that demonstrates the disconnect.

                      MB
                      --
                      Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                      Ottawa, Ontario, CANADA. distobj@...
                      http://www.markbaker.ca http://www.idokorro.com
                    • Miles Sabin
                      Mathews, Walden wrote, ... REST operates only in terms of resource/server state (ie. the resource before-and-after state view) and understands idempotence in
                      Message 10 of 26 , Sep 6, 2002
                      • 0 Attachment
                        Mathews, Walden wrote,
                        > Miles Sabin wrote,
                        > > The problem here is that these two views clearly aren't equivalent,
                        > > and are typically in conflict. REST, as I understand it, looks to
                        > > have a more natural fit with the resource before-and-after state
                        > > view. So does that mean that REST is in conflict with part of RFC
                        > > 2616? If it is in conflict, is that a problem for REST, or is it the
                        > > inevitable consequence of an inconsistency in RFC 2616?
                        >
                        > Sorry, which part of 2616 do you think is in conflict with REST over
                        > the issue of idempotence?

                        REST operates only in terms of resource/server state (ie. the resource
                        before-and-after state view) and understands idempotence in only those
                        terms. RFC 2616's understanding of idempotence seems to defined in
                        terms of both resource/server state and client-visible results.

                        That means it's likely that there will be cases which are idempotent
                        according to REST, but not according to RFC 2616 (and possibly vice
                        versa). My proof that on the resource/server state view (which I take
                        to be the REST view) all sequences of idempotent requests are
                        idempotent sequences looks like being an example because it rules out a
                        possibility explictly mentioned by RFC 2616.

                        It could be that RFC 2616 is wrong to suggest the possiblity of
                        non-idempotent sequences of idempotent methods. OTOH, it could mean
                        that there's a disconnect with REST, and that RFC 2616 really does mean
                        to include client visible results in it's definition of idempotence
                        (tho' if that's the case there are some delicate issues with client
                        visible results of PUT and DELETE).

                        I'd like to know which. If nothing else, it'd make implementing HTTP/1.1
                        request piplining a lot easier if the REST view is right.

                        Cheers,


                        Miles
                      • Miles Sabin
                        Mark Baker wrote, ... OK, I think this example illustrates the difference, DELETE /foo = 200 OK DELETE /foo = 404 Not Found On the resource/server
                        Message 11 of 26 , Sep 6, 2002
                        • 0 Attachment
                          Mark Baker wrote,
                          > On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote:
                          > > Mathews, Walden wrote,
                          > >
                          > > > I suspect that any disagreement about the idempotence of a string
                          > > > of idempotent HTTP operations has more to do with the way you
                          > > > might map HTTP operations onto the meaning of 'idempotent' than
                          > > > with the particular proof you offered. We touched on this
                          > > > before. What is the 'function' of an HTTP PUT? I.e., which
                          > > > mapping are we interested in? Clearly, sometimes it's resource
                          > > > before-and-after state. At other times it may be more like
                          > > > request-to-response mapping?
                          > >
                          > > Yes, I think that's right.
                          >
                          > I don't understand the distinction I guess.

                          OK, I think this example illustrates the difference,

                          DELETE /foo => 200 OK
                          DELETE /foo => 404 Not Found

                          On the resource/server state view the only things which count towards
                          idempotence are changes of state at the server (I take this to be the
                          REST view). Because the effect on the server of deleting /foo two or
                          more times is the same as the effect on the server of deleting it just
                          once we can count DELETE as idempotent.

                          On the client-visible-effects view the result is relevant (maybe as well
                          as server state, maybe instead of). Because the client visible results
                          of the second and subsequent deletions of /foo are different from that
                          of the first we can't count DELETE as idempotent.

                          Given that RFC 2616 stipulates that DELETE is idempotent it seems as
                          tho' the client-visible-effects view must be wrong. But that can't be
                          the whole story because of RFC 2616's allusions to non-idempotent
                          sequences of idempotent requests. If my proof that on the resource/
                          server view all sequences of idempotent requests are idempotent
                          sequences is correct, then either there's something wrong with RFC 2616
                          (maybe the discussion of non-idempotent sequences should be dropped, or
                          maybe there's an inconsistency somewhere), or there's something wrong
                          with the resource/server state view and hence a disconnect between REST
                          and RFC 2616.

                          > We haven't had any troubles. We tried to use Jeff Mogul's
                          > out-of-order spec, but had practical issues with it (it requires using
                          > a new client stack). But we don't have a lot of heard reliability
                          > guarantees in our use of our platform, so it's possible that I'm
                          > missing an edge case that demonstrates the disconnect.

                          Does your client stack implement request piplining? If it does, there's
                          presumably somewhere where a decision has to be made about whether to
                          pipeline a request immediately or wait for pending responses to arrive.
                          I played cautious and only allowed piplining for GET and then only if
                          the only pending responses were for GETs.

                          Cheers,


                          Miles
                        • Mark Baker
                          ... Ah, ok. I didn t recognize those terms as characterizing this example. ... I wonder, but I can t find anything in 2616 which says that a DELETE on a
                          Message 12 of 26 , Sep 6, 2002
                          • 0 Attachment
                            On Fri, Sep 06, 2002 at 08:18:58PM +0100, Miles Sabin wrote:
                            > OK, I think this example illustrates the difference,

                            Ah, ok. I didn't recognize those terms as characterizing this
                            example.

                            > DELETE /foo => 200 OK
                            > DELETE /foo => 404 Not Found

                            I wonder, but I can't find anything in 2616 which says that a DELETE
                            on a non-existent resource has to return 404. I also can't find
                            anything that suggests that a 200 response is wrong.

                            So perhaps DELETE is just under-defined? Are there other examples
                            that demonstrate this issue that don't use DELETE? Conditional PUTs
                            maybe? Dunno.

                            > Does your client stack implement request piplining? If it does, there's
                            > presumably somewhere where a decision has to be made about whether to
                            > pipeline a request immediately or wait for pending responses to arrive.
                            > I played cautious and only allowed piplining for GET and then only if
                            > the only pending responses were for GETs.

                            We only block on non-idempotent methods (POST).

                            MB
                            --
                            Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                            Ottawa, Ontario, CANADA. distobj@...
                            http://www.markbaker.ca http://www.idokorro.com
                          • Miles Sabin
                            Mark Baker wrote, ... True, but consider this sequence, DELETE /foo = 200 OK GET /foo = 404 Not Found DELETE /foo = 200 OK (Huh??? Wasn t /foo
                            Message 13 of 26 , Sep 6, 2002
                            • 0 Attachment
                              Mark Baker wrote,
                              > Ah, ok. I didn't recognize those terms as characterizing this
                              > example.
                              >
                              > > DELETE /foo => 200 OK
                              > > DELETE /foo => 404 Not Found
                              >
                              > I wonder, but I can't find anything in 2616 which says that a DELETE
                              > on a non-existent resource has to return 404. I also can't find
                              > anything that suggests that a 200 response is wrong.

                              True, but consider this sequence,

                              DELETE /foo => 200 OK
                              GET /foo => 404 Not Found
                              DELETE /foo => 200 OK (Huh??? Wasn't /foo gone just a moment ago ?)

                              > So perhaps DELETE is just under-defined?

                              Perhaps, but I don't think 200 would be the right way to fill out the
                              gap in this case.

                              > Are there other examples that demonstrate this issue that don't use
                              > DELETE? Conditional PUTs maybe? Dunno.

                              Well, anything where you'd expect to get a different response on the
                              first request than on a second or subsequent request. Actually if the
                              first PUT creates a new resource the request doesn't even need to be
                              conditional to get something similar,

                              PUT /foo => 201 Created (this is a MUST in 9.6)
                              PUT /foo => 200 OK (this is a SHOULD)

                              Given that this behavior isn't underspecified, PUT is probably a better
                              eg. than DELETE.

                              > > Does your client stack implement request piplining? If it does,
                              > > there's presumably somewhere where a decision has to be made about
                              > > whether to pipeline a request immediately or wait for pending
                              > > responses to arrive. I played cautious and only allowed piplining
                              > > for GET and then only if the only pending responses were for GETs.
                              >
                              > We only block on non-idempotent methods (POST).

                              So unless I'm missing something you're treating all sequences of
                              idempotent requests as idempotent sequences? In which case how do you
                              interpret that passage from RFC 2616, 9.1? (seeing as you're ignoring
                              it ;-)

                              Cheers,


                              Miles
                            • Mathews, Walden
                              Miles, This is not a properly researched statement (sorry for that, no time) but I think I recall the same language in the REST manifesto (to be called
                              Message 14 of 26 , Sep 6, 2002
                              • 0 Attachment
                                Miles,

                                This is not a properly researched statement (sorry for that, no
                                time) but I think I recall the same language in the REST manifesto
                                (to be called "maniRESTo" hence) about non-idempotence in sequences
                                of idempotent operations. So if that's true, then it's not RFC
                                2616 vs. REST, it's something else.

                                Walden

                                > -----Original Message-----
                                > From: Miles Sabin [mailto:miles@...]
                                > Sent: Friday, September 06, 2002 3:19 PM
                                > To: rest-discuss@yahoogroups.com
                                > Subject: Re: [rest-discuss] Idempotent sequences
                                >
                                >
                                > Mark Baker wrote,
                                > > On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote:
                                > > > Mathews, Walden wrote,
                                > > >
                                > > > > I suspect that any disagreement about the idempotence
                                > of a string
                                > > > > of idempotent HTTP operations has more to do with the way you
                                > > > > might map HTTP operations onto the meaning of 'idempotent' than
                                > > > > with the particular proof you offered. We touched on this
                                > > > > before. What is the 'function' of an HTTP PUT? I.e., which
                                > > > > mapping are we interested in? Clearly, sometimes it's resource
                                > > > > before-and-after state. At other times it may be more like
                                > > > > request-to-response mapping?
                                > > >
                                > > > Yes, I think that's right.
                                > >
                                > > I don't understand the distinction I guess.
                                >
                                > OK, I think this example illustrates the difference,
                                >
                                > DELETE /foo => 200 OK
                                > DELETE /foo => 404 Not Found
                                >
                                > On the resource/server state view the only things which count towards
                                > idempotence are changes of state at the server (I take this to be the
                                > REST view). Because the effect on the server of deleting /foo two or
                                > more times is the same as the effect on the server of
                                > deleting it just
                                > once we can count DELETE as idempotent.
                                >
                                > On the client-visible-effects view the result is relevant
                                > (maybe as well
                                > as server state, maybe instead of). Because the client
                                > visible results
                                > of the second and subsequent deletions of /foo are different
                                > from that
                                > of the first we can't count DELETE as idempotent.
                                >
                                > Given that RFC 2616 stipulates that DELETE is idempotent it seems as
                                > tho' the client-visible-effects view must be wrong. But that can't be
                                > the whole story because of RFC 2616's allusions to non-idempotent
                                > sequences of idempotent requests. If my proof that on the resource/
                                > server view all sequences of idempotent requests are idempotent
                                > sequences is correct, then either there's something wrong
                                > with RFC 2616
                                > (maybe the discussion of non-idempotent sequences should be
                                > dropped, or
                                > maybe there's an inconsistency somewhere), or there's something wrong
                                > with the resource/server state view and hence a disconnect
                                > between REST
                                > and RFC 2616.
                                >
                                > > We haven't had any troubles. We tried to use Jeff Mogul's
                                > > out-of-order spec, but had practical issues with it (it
                                > requires using
                                > > a new client stack). But we don't have a lot of heard reliability
                                > > guarantees in our use of our platform, so it's possible that I'm
                                > > missing an edge case that demonstrates the disconnect.
                                >
                                > Does your client stack implement request piplining? If it
                                > does, there's
                                > presumably somewhere where a decision has to be made about whether to
                                > pipeline a request immediately or wait for pending responses
                                > to arrive.
                                > I played cautious and only allowed piplining for GET and then only if
                                > the only pending responses were for GETs.
                                >
                                > Cheers,
                                >
                                >
                                > Miles
                                >
                                > ------------------------ Yahoo! Groups Sponsor
                                > ---------------------~-->
                                > 4 DVDs Free +s&p Join Now
                                > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
                                > --------------------------------------------------------------
                                > -------~->
                                >
                                > To unsubscribe from this group, send an email to:
                                > rest-discuss-unsubscribe@yahoogroups.com
                                >
                                >
                                >
                                > Your use of Yahoo! Groups is subject to
                                http://docs.yahoo.com/info/terms/
                              Your message has been successfully submitted and would be delivered to recipients shortly.