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

Re: [rest-discuss] Idempotent sequences

Expand Messages
  • 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 1 of 26 , Sep 3, 2002
      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 2 of 26 , Sep 3, 2002
        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 3 of 26 , Sep 3, 2002
          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 4 of 26 , Sep 4, 2002
            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 5 of 26 , Sep 5, 2002
              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 6 of 26 , Sep 5, 2002
                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 7 of 26 , Sep 6, 2002
                  > -----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 8 of 26 , Sep 6, 2002
                    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 9 of 26 , Sep 6, 2002
                      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 10 of 26 , Sep 6, 2002
                        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 11 of 26 , Sep 6, 2002
                          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 12 of 26 , Sep 6, 2002
                            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 13 of 26 , Sep 6, 2002
                              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.