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

Re: [rest-discuss] REST for P2P application?

Expand Messages
  • Ryan Fugger
    On Tue, 5 Oct 2004 22:10:10 -0700, S. Mike Dierken ... Gotcha. ... Ripple is a P2P trust network of software node-agents living on http
    Message 1 of 19 , Oct 6, 2004
    • 0 Attachment
      On Tue, 5 Oct 2004 22:10:10 -0700, S. Mike Dierken <mdierken@...>
      wrote:

      > I'm lost. Perhaps if your applications was re-phrased using 'resource'
      > rather than 'node' and 'object' I'd be able to understand.

      Gotcha.

      >
      >> Due to anonymity requirements, the originating node cannot know where
      >> all
      >> the pieces of an object are (for example, a query or a transaction), and
      >> nodes usually cannot know where the object originated.
      > What is an 'originating node'?

      Ripple is a P2P trust network of software node-agents living on http
      servers. To make it more clear, I'll just use the word "hosts" from now
      on, even though that's not technically what I mean.

      > Is that an HTTP client?

      Yes, and server.

      > To hide the location of the pieces, you have a single identifiable
      > resource and clients don't
      > know what lays beyond.

      No, for example, a transaction involves a chain of hosts, but each host
      only knows about the host directly before and after it. What I'm
      struggling with is that it seems so convenient to give the transaction a
      single name, but I can't identify it with a single host for privacy
      reasons, and so I can't give it a single URI. Using a proxy doesn't work
      either, unless everyone used the same one, which is a central point of
      failure and therefore bad.


      >> No, different hosts each holding their aspect of distributed objects is
      >> integral to the application.
      > Okay, but how can you have different hosts holding aspects of a single
      > distributed object but not tell any client where those different aspects
      > are located??

      They only tell neighbouring host on the trust network, ie, those they
      trust. All the bits can be found by passing queries down and back up the
      chain of trusted hosts, without the requesting host ever knowing exactly
      where the queries go.

      >
      >> A server hosts multiple nodes that each communicate with many
      >> neighbouring
      >> nodes ("friends" with which they can exchange IOUs).
      > Okay - each 'node' is a resource. Clients communicate with this 'public'
      > node. Clients do not know about neighboring nodes. The resource is a
      > type of aggregating proxy for those other nodes.

      Sounds about right. It may be informative to say also that clients are
      the means through which the owner of a node accesses his node and gives it
      instructions, whether in person (opening an account with another node), or
      automatically (accepting payments through an ecommerce site).

      >
      >> Nodes may also communicate with a strange node to pay or receive payment
      > from that node.
      > Okay - each 'node' may also be a client and can transfer payment to other
      > resources or request payment from other resources. In order to receive
      > unsolicited transfers, a node needs to have an identifier and the sender
      > of payment needs to know what that is.

      Right. The node identifier being a resolvable URI makes perfect sense --
      until the node moves to a different server!

      >
      >> Payments are made by passing IOUs along paths connecting two strange
      >> nodes
      > in the network of neighbours.
      > Ah... a chain of proxies... and this chain is used to obscure the legal
      > entity requesting a transfer?

      Not primarily, although that might be a side benefit, I don't know. The
      chain of intermediaries is literally necessary to make the payment with
      IOUs. For example, would you ship me something if I paid you with my
      digitally-signed IOU? Of course you wouldn't. But you might if we could
      find a common friend who would vouch for my IOU by promising to make good
      on it himself if I didn't. Ripple works by finding chains of these
      intermediaries.

      --------------
      I'm actually beginning to feel like a bit of a troll on this list, because
      the more I type about this, the more I become convinced that not only is
      REST not particularly suited to my application, but HTTP isn't really
      either. Stateful bi-directional peer connections seem like the right fit
      (been reading about BEEP - http://beepcore.org/). Ripple really seems to
      want to be a closed, relatively tightly-coupled private network, despite
      my best efforts to make it otherwise. So while I'm still open to having
      my mind changed, I won't ask the list to delve any more into my arcane
      little project unless it truly interests you as a "hard case"...

      I very much appreciate the responses. Thanks Mike. I may be back for
      some help with a RESTful client API, although I think that will be much
      easier.

      Ryan
    • rfugger
      Thanks for the input Bryan. I think I will be going with non-resolvable URIs (ie, URNs) to separate resource identity from resource location, as location is
      Message 2 of 19 , Oct 6, 2004
      • 0 Attachment
        Thanks for the input Bryan. I think I will be going with non-resolvable URIs (ie, URNs) to separate resource identity from resource location, as location is such a sticky thing to pin down in my case.

        --- In rest-discuss@yahoogroups.com, "thompsonbry" <thompsonbry@s...> wrote:
        >
        > REST != HTTP. HTTP provides a protocol that can be used REST-fully
        > in many ways, but it can also be used non-REST-fully. I don't know
        > the Jabber protocol, but you may be able to use that REST-fully also.

        Yes, I'm starting to realize this. I've been doing some reading on BEEP/APEX, which seems more appropriate than Jabber for this kind of thing.

        >
        > I find it interesting that you are distributing transactions. I had
        > been thinking of transactions as local to a peer and not materializing
        > on other peers until they were committed (so only a client could hold
        > a URI for any object within the transaction).

        That's just the way it works out for my application. I'm trying to do something very specific, not create a general framework.

        Thanks for the comments. I feel confident I'm on the right path.

        Ryan
      • S. Mike Dierken
        For me, once I understand the use cases (alice buys from bob, alice pays bob via ted) we could work on identifying resources. I actually think it s pretty
        Message 3 of 19 , Oct 6, 2004
        • 0 Attachment
          For me, once I understand the use cases (alice buys from bob, alice pays bob
          via ted) we could work on identifying resources.
          I actually think it's pretty reasonable and doable to express via REST, even
          with the anonymity and migrating 'nodes'.
          But I understand that it can be pretty difficult to take an existing
          description of an approach & unwind it and re-map to another architecture.


          ----- Original Message -----
          From: "Ryan Fugger" <rfugger@...>
          To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
          Sent: Wednesday, October 06, 2004 12:33 AM
          Subject: Re: [rest-discuss] REST for P2P application?


          > On Tue, 5 Oct 2004 22:10:10 -0700, S. Mike Dierken <mdierken@...>
          > wrote:
          >
          > > I'm lost. Perhaps if your applications was re-phrased using 'resource'
          > > rather than 'node' and 'object' I'd be able to understand.
          >
          > Gotcha.
          >
          > >
          > >> Due to anonymity requirements, the originating node cannot know where
          > >> all
          > >> the pieces of an object are (for example, a query or a transaction),
          and
          > >> nodes usually cannot know where the object originated.
          > > What is an 'originating node'?
          >
          > Ripple is a P2P trust network of software node-agents living on http
          > servers. To make it more clear, I'll just use the word "hosts" from now
          > on, even though that's not technically what I mean.
          >
          > > Is that an HTTP client?
          >
          > Yes, and server.
          >
          > > To hide the location of the pieces, you have a single identifiable
          > > resource and clients don't
          > > know what lays beyond.
          >
          > No, for example, a transaction involves a chain of hosts, but each host
          > only knows about the host directly before and after it. What I'm
          > struggling with is that it seems so convenient to give the transaction a
          > single name, but I can't identify it with a single host for privacy
          > reasons, and so I can't give it a single URI. Using a proxy doesn't work
          > either, unless everyone used the same one, which is a central point of
          > failure and therefore bad.
          >
          >
          > >> No, different hosts each holding their aspect of distributed objects is
          > >> integral to the application.
          > > Okay, but how can you have different hosts holding aspects of a single
          > > distributed object but not tell any client where those different aspects
          > > are located??
          >
          > They only tell neighbouring host on the trust network, ie, those they
          > trust. All the bits can be found by passing queries down and back up the
          > chain of trusted hosts, without the requesting host ever knowing exactly
          > where the queries go.
          >
          > >
          > >> A server hosts multiple nodes that each communicate with many
          > >> neighbouring
          > >> nodes ("friends" with which they can exchange IOUs).
          > > Okay - each 'node' is a resource. Clients communicate with this 'public'
          > > node. Clients do not know about neighboring nodes. The resource is a
          > > type of aggregating proxy for those other nodes.
          >
          > Sounds about right. It may be informative to say also that clients are
          > the means through which the owner of a node accesses his node and gives it
          > instructions, whether in person (opening an account with another node), or
          > automatically (accepting payments through an ecommerce site).
          >
          > >
          > >> Nodes may also communicate with a strange node to pay or receive
          payment
          > > from that node.
          > > Okay - each 'node' may also be a client and can transfer payment to
          other
          > > resources or request payment from other resources. In order to receive
          > > unsolicited transfers, a node needs to have an identifier and the sender
          > > of payment needs to know what that is.
          >
          > Right. The node identifier being a resolvable URI makes perfect sense --
          > until the node moves to a different server!
          >
          > >
          > >> Payments are made by passing IOUs along paths connecting two strange
          > >> nodes
          > > in the network of neighbours.
          > > Ah... a chain of proxies... and this chain is used to obscure the legal
          > > entity requesting a transfer?
          >
          > Not primarily, although that might be a side benefit, I don't know. The
          > chain of intermediaries is literally necessary to make the payment with
          > IOUs. For example, would you ship me something if I paid you with my
          > digitally-signed IOU? Of course you wouldn't. But you might if we could
          > find a common friend who would vouch for my IOU by promising to make good
          > on it himself if I didn't. Ripple works by finding chains of these
          > intermediaries.
          >
          > --------------
          > I'm actually beginning to feel like a bit of a troll on this list, because
          > the more I type about this, the more I become convinced that not only is
          > REST not particularly suited to my application, but HTTP isn't really
          > either. Stateful bi-directional peer connections seem like the right fit
          > (been reading about BEEP - http://beepcore.org/). Ripple really seems to
          > want to be a closed, relatively tightly-coupled private network, despite
          > my best efforts to make it otherwise. So while I'm still open to having
          > my mind changed, I won't ask the list to delve any more into my arcane
          > little project unless it truly interests you as a "hard case"...
          >
          > I very much appreciate the responses. Thanks Mike. I may be back for
          > some help with a RESTful client API, although I think that will be much
          > easier.
          >
          > Ryan
          >
        • Ryan Fugger
          On Wed, 6 Oct 2004 20:29:22 -0700, S. Mike Dierken ... It s all pretty much there at the project site: http://ripple.sf.net/ The
          Message 4 of 19 , Oct 7, 2004
          • 0 Attachment
            On Wed, 6 Oct 2004 20:29:22 -0700, S. Mike Dierken <mdierken@...>
            wrote:

            > For me, once I understand the use cases (alice buys from bob, alice pays
            > bob via ted) we could work on identifying resources.

            It's all pretty much there at the project site:

            http://ripple.sf.net/

            The requirements might help:

            http://ripple.sf.net/requirements.html

            > I actually think it's pretty reasonable and doable to express via REST,
            > even with the anonymity and migrating 'nodes'.
            > But I understand that it can be pretty difficult to take an existing
            > description of an approach & unwind it and re-map to another
            > architecture.

            Funny, I started out with REST in mind and ended up but kept ending up
            with straight messaging...

            There's a beginning of a REST design at:

            http://ripple.sf.net/resources.xml.txt

            Ryan
          • Nic Ferrier
            I had a discussion with some people at work today about RPC and REST (starting from my premise that RPC systems are always rubbish). In the context of this
            Message 5 of 19 , Jun 3, 2005
            • 0 Attachment
              I had a discussion with some people at work today about RPC and REST
              (starting from my premise that RPC systems are always rubbish).

              In the context of this discussion a programmer, who was actually very
              much in agreement with the REST way of doing things, suggested that
              one of the things REST could not do was transactions.

              What he meant was something like you see with SQL:

              start transaction

              sql statement

              sql statement

              sql statement

              commit transaction

              I pointed out that REST could be used with a packaged transaction
              system, where the individual items to be transacted are packaged into
              a single document and then sent with a POST.

              He agreed but still thought that transactions which were separated out
              over different 'calls' would be more useful.

              I've never done that with REST but it occured to me 5 minutes after
              this that transactions could be easily modelled with REST. I'd like to
              know what people here think of this scheme:

              POST /transaction
              => /transaction/xxx

              POST /transaction/xxx
              <item1/>
              => /transaction/xxx/item1

              POST /transaction/xxx
              <item2/>
              => /transaction/xxx/item2

              POST /transaction/xxx
              <item3/>
              => /transaction/xxx/item3

              To commit the transaction:

              GET /transaction/xxx
              => <xxx>
              <item1/>
              <item2/>
              <item3/>
              </xxx>

              PUT /transaction/xxx
              <xxx>
              <item1/>
              <item2/>
              <item3/>
              </xxx>

              It seems to me this would work as well as anything done with an RPC
              client.

              I think that the point about this is that it only *models*
              transactions with REST, there's no change to the way REST is done.


              Anyway, I'd be interested to hear what people think about it.



              Nic Ferrier
              http://www.tapsellferrier.co.uk
            • Andrzej Jan Taramina
              ... REST (and even SOAP) calls are typically of long duration. This is exacerbated if the invocation is going across the internet. In that situation, it is
              Message 6 of 19 , Jun 4, 2005
              • 0 Attachment
                Nic:

                > In the context of this discussion a programmer, who was actually very much in
                > agreement with the REST way of doing things, suggested that one of the things
                > REST could not do was transactions.

                REST (and even SOAP) calls are typically of long duration. This is
                exacerbated if the invocation is going across the internet.

                In that situation, it is usually considered very poor design to hold a
                transaction and tie up the resources on the back end.

                Better bet is to keep the granularity of your REST (or WS) calls coarse
                enough that the transaction is handled entirely by the back end.

                It points to your colleage thinking of the world in local RPC terms. That
                doesn't fly very well in a distributed system. You might want to point him
                at the Fallacies of Distributed Computing (from Peter Deustch, extended by
                James Gosling):

                1) The network is reliable.
                2) Latency is zero.
                3) Bandwidth is infinite.
                4) The network is secure.
                5) Topology doesn't change.
                6) There is one administrator.
                7) Transport cost is zero.
                8) The network is homogeneous.


                In other words, wrt REST: it's a feature, not a bug! ;-)

                Andrzej Jan Taramina
                Chaeron Corporation: Enterprise System Solutions
                http://www.chaeron.com
              • Jan Algermissen
                ... I am also wrestling with the transaction issues at the moment and while I fully agree with the issue above, I wonder - if that means that a 2 phase commit
                Message 7 of 19 , Jun 4, 2005
                • 0 Attachment
                  On Jun 4, 2005, at 3:14 PM, Andrzej Jan Taramina wrote:
                  >
                  > REST (and even SOAP) calls are typically of long duration. This is
                  > exacerbated if the invocation is going across the internet.
                  >
                  > In that situation, it is usually considered very poor design to hold a
                  > transaction and tie up the resources on the back end.
                  >
                  > Better bet is to keep the granularity of your REST (or WS) calls
                  > coarse
                  > enough that the transaction is handled entirely by the back end.

                  I am also wrestling with the transaction issues at the moment and
                  while I fully
                  agree with the issue above, I wonder

                  - if that means that a 2 phase commit is just not realistically
                  doable in a networked
                  system and therefore no issue with REST (and we just forget about
                  it; no travel bookings
                  etc.)

                  or

                  - if transactions across unrelated systems indeed make sense in a
                  networked system and
                  how we do them with REST.

                  (I read the postings/Wiki pages but I am having a hard time
                  distinguishing the ideas on
                  local transactions from those about 'distributed' ones. Maybe it
                  wouyld be a good idea
                  to split the material on the Wiki? Any transaction guru that would
                  help me out in doing
                  this?)


                  BTW: can a single HTTP method call considered to be atomic? If a PUT
                  fails, can I
                  assume that nothing of the operation succeded? Can a POST be
                  partially processed and
                  still return with an error? Or is this allways either/or?

                  Thanks.

                  Jan

                  ________________________________________________________________________
                  ____________________
                  Jan Algermissen, Consultant & Programmer
                  http://jalgermissen.com
                  Tugboat Consulting, 'Applying Web technology to enterprise IT'
                  http://www.tugboat.de
                • Peter Marks
                  Distributed transactions are hard to do. You might be interested in looking at how Jini Technology ( http://www.jini.org ) does it:
                  Message 8 of 19 , Jun 4, 2005
                  • 0 Attachment
                    Distributed transactions are hard to do. You might be interested in looking at how Jini Technology ( http://www.jini.org ) does it:

                    http://www.jini.org/nonav/standards/davis/doc/specs/html/txn-spec.html

                    Note, also, that there is a free implementation of a Transaction Manager (that can also be distributed) built according to the above specification. It can be obtained at the Jini website.

                    It would be interesting to see this style of distributed transaction management  done in support of a RESTful application.

                    Maybe if I get the time...

                    Peter

                    Andrzej Jan Taramina wrote:
                    > Nic:
                    >
                    >  > In the context of this discussion a programmer, who was actually very
                    > much in
                    >  > agreement with the REST way of doing things, suggested that one of
                    > the things
                    >  > REST could not do was transactions.
                    >
                    > REST (and even SOAP) calls are typically of long duration. This is
                    > exacerbated if the invocation is going across the internet.
                    >
                    > In that situation, it is usually considered very poor design to hold a
                    > transaction and tie up the resources on the back end.
                    >
                    > Better bet is to keep the granularity of your REST (or WS) calls coarse
                    > enough that the transaction is handled entirely by the back end.
                    >
                    > It points to your colleage thinking of the world in local RPC terms.  That
                    > doesn't fly very well in a distributed system.  You might want to point him
                    > at the Fallacies of Distributed Computing  (from Peter Deustch, extended by
                    > James Gosling):
                    >
                    > 1) The network is reliable.
                    > 2) Latency is zero.
                    > 3) Bandwidth is infinite.
                    > 4) The network is secure.
                    > 5) Topology doesn't change.
                    > 6) There is one administrator.
                    > 7) Transport cost is zero.
                    > 8) The network is homogeneous.
                    >
                    >
                    > In other words, wrt REST: it's a feature, not a bug! ;-)
                    >
                    > Andrzej Jan Taramina
                    > Chaeron Corporation: Enterprise System Solutions
                    > http://www.chaeron.com
                    >
                    >
                    > ------------------------------------------------------------------------
                    > *Yahoo! Groups Links*
                    >
                    >     * To visit your group on the web, go to:
                    >       http://groups.yahoo.com/group/rest-discuss/
                    >
                    >     * To unsubscribe from this group, send an email to:
                    >       rest-discuss-unsubscribe@yahoogroups.com
                    >       <mailto:rest-discuss-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                    >
                    >     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                    >       Service <http://docs.yahoo.com/info/terms/>.
                    >
                    >

                  • Bob Haugen
                    Please forgive me if you eventually get two copies of this message. The first one appears to have gone off into space. I think it is possible to do
                    Message 9 of 19 , Jun 4, 2005
                    • 0 Attachment
                      Please forgive me if you eventually get two copies of this message.
                      The first one appears to have gone off into space.

                      I think it is possible to do transactions RESTfully. Or at least
                      something a lot like transactions.

                      If you abstract the idea or pattern of a transaction protocol away
                      from the details of database implementations, they get easier. In
                      particular, 2-phase outcomes no longer require holding locks for the
                      duration of the "transaction". Nor does the server need to keep track
                      of the state of the transaction.

                      For example, see
                      http://www.oasis-open.org/committees/download.php/9836/business_transaction-btp-1.1-spec-wd-04.pdf

                      One way to deal with transactions RESTfully is to PUT or POST the
                      first phase result in a provisional state, and the second phase final.
                      In other words, the resource state is the transaction state.

                      For a business example, a quote is a provisional state, an order is final.

                      Another aspect of transactions from a RESTful point of view is that
                      the actual transaction protocol involves only two components at a
                      time, one client which acts as the transaction coordinator, and one
                      server which acts as the transaction participant or resource manager.

                      The client may also coordinate other participants in the same logical
                      transaction, but only needs to interact with one at a time, and none
                      of the resources need to interact with or know about each other. All
                      distributed state management can be done by the client/coordinator.

                      I don't know if a transaction tree would be RESTful - where a
                      server/resource manager/participant is also a sub-coordinator. But in
                      fact that is what happens when Amazon authorizes your credit with
                      Visa. In this case, the credit authorization is the provisional
                      state, and the drawdown is the final state.

                      You could also use compensations, where the provisional state is the
                      same as the final state, and you undo the action if the transaction
                      aborts, but compensation often doesn't work.

                      See also http://www.choreology.com/standards/standards_btm_spectrum.htm
                      - it's written in terms of Web service transactions, but the
                      provisional-final and do-compensate patterns will work for REST, too.
                    • Hugh Winkler
                      ... It would be astonishingly poor design if your server held open a transaction in the underlying database across these calls. But you don t have to implement
                      Message 10 of 19 , Jun 4, 2005
                      • 0 Attachment
                        > REST (and even SOAP) calls are typically of long duration. This is
                        > exacerbated if the invocation is going across the internet.
                        >
                        > In that situation, it is usually considered very poor design to hold a
                        > transaction and tie up the resources on the back end.
                        >

                        It would be astonishingly poor design if your server held open a transaction
                        in the underlying database across these calls. But you don't have to
                        implement it that way. Nic's original post modeled the transaction as just
                        another resource, so you could come back and commit that resource even days
                        later -- I'm sure the implementation would just implement its own simple
                        sort of transaction log and execute it on commit -- easy. You'd probably
                        want to combine this model with one of the reliable HTTP ideas floating
                        around.

                        > Better bet is to keep the granularity of your REST (or WS) calls coarse
                        > enough that the transaction is handled entirely by the back end.
                        >
                        > It points to your colleage thinking of the world in local RPC terms. That
                        > doesn't fly very well in a distributed system. You might want to point
                        > him
                        > at the Fallacies of Distributed Computing (from Peter Deustch, extended
                        > by
                        > James Gosling):
                        >
                        > 1) The network is reliable.
                        > 2) Latency is zero.
                        > 3) Bandwidth is infinite.
                        > 4) The network is secure.
                        > 5) Topology doesn't change.
                        > 6) There is one administrator.
                        > 7) Transport cost is zero.
                        > 8) The network is homogeneous.
                        >

                        Excellent list!


                        Hugh
                      • Nic Ferrier
                        ... Yes, I broadly agree with you. But when a transaction is necessary (and sometimes they are) REST could handle it just as well (I believe better) than RPC
                        Message 11 of 19 , Jun 4, 2005
                        • 0 Attachment
                          "Andrzej Jan Taramina" <andrzej@...> writes:

                          > Better bet is to keep the granularity of your REST (or WS) calls coarse
                          > enough that the transaction is handled entirely by the back end.

                          Yes, I broadly agree with you.

                          But when a transaction is necessary (and sometimes they are) REST
                          could handle it just as well (I believe better) than RPC systems.

                          Since a lot of the focus of certain RPC systems has been on
                          distributing transactions (ahem, EJB) that is quite an interesting
                          point.


                          > It points to your colleage thinking of the world in local RPC terms.

                          It really doesn't. As I said, my colleague was actually enthusiastic
                          about REST. But he had been put in situations where he needed
                          transactions and felt that REST wouldn't allow him get the job done.

                          I think it's just another one of the things about REST and how little
                          it is understood because of it's simplicity.

                          I think that people tend to be too concrete about the nouns.


                          Nic
                        • Nic Ferrier
                          ... The system I outlined could be easily made to do distributed transactions. Just allow a GET against /transactions to return the current in progress
                          Message 12 of 19 , Jun 4, 2005
                          • 0 Attachment
                            Jan Algermissen <jalgermissen@...> writes:

                            > - if transactions across unrelated systems indeed make sense in a
                            > networked system and how we do them with REST.

                            The system I outlined could be easily made to do distributed
                            transactions.

                            Just allow a GET against /transactions to return the current
                            in progress transactions. A discovery protocol if you like.

                            Once you know what transaction you want to join in with then you just
                            POST an item into it as I previously described.



                            Some of this could be formalized, the list of extant transactions
                            could be defined by DTD or schema, the current state of a transaction
                            could be modeled by a namespace document.

                            Anyone think that it's worthwhile specing these out and doing a demo
                            app?


                            > BTW: can a single HTTP method call considered to be atomic? If a PUT
                            > fails, can I assume that nothing of the operation succeded? Can a
                            > POST be partially processed and still return with an error? Or is
                            > this allways either/or?

                            Single HTTP methods can never be truly atomic because HTTP doesn't
                            necessarily care about whether you recieve the response or not.

                            You can implement the methods to be atomic on the program side.

                            But unless you write your own webserver, and write it to be really
                            smart, then you won't know that the client definitely receieved the
                            response from your method implementation.


                            It's not just implementing a server to roll back the operation
                            if the response was not completly transmitted to the client... there
                            are no semantics for that.

                            For example, if the client gets the status code, and if the status
                            code is an error (so the client knows the operation failed) but the
                            client doesn't get the rest of the response, is that a failure to
                            send, or not?

                            That's why you need something else on top, to implement transactions
                            (well, you do when you need this kind of behaviour).


                            One of the reasons why I think my suggestion works is that it's able
                            to do 2 phase commit quite well. The final commit can be:

                            x = GET ; PUT x ; assert x == GET


                            Nic
                          • S. Mike Dierken
                            ... And there you have the perfect example of a transaction using the REST design patterns - if at first you don t succeed, try try again.
                            Message 13 of 19 , Jun 6, 2005
                            • 0 Attachment
                              > Please forgive me if you eventually get two copies of this message.
                              > The first one appears to have gone off into space.
                              And there you have the perfect example of a transaction using the REST
                              design patterns - if at first you don't succeed, try try again.
                            Your message has been successfully submitted and would be delivered to recipients shortly.