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

REST for P2P application?

Expand Messages
  • Ryan Fugger
    Hi. I ve been struggling with trying to apply REST to a project of mine, a decentralized P2P payment system using only IOUs passed between friends in a social
    Message 1 of 19 , Oct 3, 2004
    • 0 Attachment
      Hi. I've been struggling with trying to apply REST to a project of mine,
      a decentralized P2P payment system using only IOUs passed between friends
      in a social network:

      http://ripple.sourceforge.net/

      The payment network is made up of nodes living on http servers. I can see
      how REST would be appropriate for a client API to a node on the network --
      to allow users to perform actions through their node, to allow ecommerce
      sites to access the network, etc. But I'm having trouble seeing how a
      RESTful approach might improve the protocol for communications between
      nodes.

      Some issues I've come across:

      * Identifying distributed objects with resolvable URIs is problematic
      since it seems to want to locate them on a single node, when in reality
      they live on several nodes. Giving them several identifiers seems
      inelegant.
      * Nodes must be able to move to different servers, and if there are URI
      identifiers for resources on a node that must be resolvable, then there
      must a mechanism for changing those identifiers when a node moves. This
      could cause problems with historical audit information backed up on
      offline machines, unless two identifiers are stored. A node could move
      many times, so many identifiers may be needed for each resource.
      * Only fully-functional nodes may communicate with other nodes as nodes.
      Scalability in terms of third-party access to partial node functionality
      (the main benefit of giving all resources a URI?) is not an issue. For
      simplicity and security, all access to the network must be through one's
      own node.

      I'm a big fan of the REST philosophy, and I'd like to take advantage of it
      wherever appropriate. In this case however, REST seems to me like
      complicated overkill compared to simple XML messaging. I don't have a lot
      of experience with RESTful applications, so I'd like to know if others
      agree with me, or if there's something I'm really not getting here.

      Here is a link to the beginnings of a RESTful version of inter-node
      communications:

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

      And here is a link to a fairly complete XML messaging version:

      http://ripple.sourceforge.net/messages.xml.txt

      Much more background information is available at the project home page.

      Thanks,
      Ryan
    • S. Mike Dierken
      This is a lot to digest... so this response isn t going to be extremely helpful. I do have a few questions though. ... By distributed objects do you mean an
      Message 2 of 19 , Oct 4, 2004
      • 0 Attachment
        This is a lot to digest... so this response isn't going to be extremely
        helpful. I do have a few questions though.

        >
        > * Identifying distributed objects with resolvable URIs is problematic
        > since it seems to want to locate them on a single node, when in reality
        > they live on several nodes. Giving them several identifiers seems
        > inelegant.
        By 'distributed objects' do you mean an object that has constituent data
        that is served by multiple hosts, or do you mean a self-contained object
        that has multiple redundant copies on several hosts?
        If a single object is resident on several hosts then the single identifier
        needs to access a single host that then in turns communicates with the
        disparate constituent servers.
        If the several nodes only host redundant copies, then you need a locator
        algorithm that satisfies your technical requirements. Do you need to access
        the same host several times for performance and only switch hosts for
        reliability in the face of a host failure?

        > * Nodes must be able to move to different servers, and if there are URI
        > identifiers for resources on a node that must be resolvable, then there
        > must a mechanism for changing those identifiers when a node moves. This
        > could cause problems with historical audit information backed up on
        > offline machines, unless two identifiers are stored. A node could move
        > many times, so many identifiers may be needed for each resource.
        It sounds like we should talk about what capabilities a single server is
        providing. You may need a proxy that forwards requests to the current
        hosting server, or possibly returns a Location header with the 'new'
        location.
      • Ryan Fugger
        Thanks for the reply. I appreciate the input. On Mon, 4 Oct 2004 22:01:47 -0700, S. Mike Dierken ... Both. ... Due to anonymity
        Message 3 of 19 , Oct 4, 2004
        • 0 Attachment
          Thanks for the reply. I appreciate the input.

          On Mon, 4 Oct 2004 22:01:47 -0700, S. Mike Dierken <mdierken@...>
          wrote:

          > By 'distributed objects' do you mean an object that has constituent data
          > that is served by multiple hosts, or do you mean a self-contained object
          > that has multiple redundant copies on several hosts?

          Both.

          > If a single object is resident on several hosts then the single
          > identifier needs to access a single host that then in turns communicates
          > with the
          > disparate constituent servers.

          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.

          > If the several nodes only host redundant copies, then you need a locator
          > algorithm that satisfies your technical requirements. Do you need to
          > access the same host several times for performance and only switch hosts
          > for
          > reliability in the face of a host failure?

          No, different hosts each holding their aspect of distributed objects is
          integral to the application.

          > It sounds like we should talk about what capabilities a single server is
          > providing.

          A server hosts multiple nodes that each communicate with many neighbouring
          nodes ("friends" with which they can exchange IOUs). Nodes may also
          communicate with a strange node to pay or receive payment from that node.
          Payments are made by passing IOUs along paths connecting two strange nodes
          in the network of neighbours.

          > You may need a proxy that forwards requests to the current
          > hosting server, or possibly returns a Location header with the 'new'
          > location.

          Since trust is such an integral issue with this application, there must be
          a mechanism to change any server that proves untrustworthy, including
          proxy servers. Changing proxy servers then has all the same
          identifier-renaming problems as changing servers.

          Like I said, as hard as I've tried to make it work, it just seems that
          REST is inappropriate for the application. I'm actually looking at
          bypassing HTTP altogether and using something like Jabber for persistent
          XML messaging sessions between servers. Very unRESTful, I know, but it
          would be soooo appealingly simple...

          Ryan
        • thompsonbry
          Ryan, I ve recently been thinking about something similar -- a p2p protocol for a generic object system (data, not behavior) based on a network database model.
          Message 4 of 19 , Oct 5, 2004
          • 0 Attachment
            Ryan,

            I've recently been thinking about something similar -- a p2p protocol
            for a generic object system (data, not behavior) based on a network
            database model. I have done more modeling of the client-server
            interactions than the interactions among the peers, but I can share
            some of my thoughts.

            I am also using URIs to identify objects. A new URI is minted each
            time a new object is created. However, the URIs are NOT providing
            addresses for objects. Instead, each peer needs to lookup whether
            or not it currently holds an copy of an object with that URI. I
            think that you will also need a similar distinction between identifier
            and address. You could make this even more clear by using a URN
            scheme, which would emphasize that the URI is not functioning as an
            address.

            I am just assigning a unique base URI to each peer. The objects
            within the store hosted by a peer have unique identifiers. The
            URI of the object just combines the URI of the store with the
            unique-within-store identifier for the object (which is an
            integer).

            The URI of an object NEVER changes throughout its life cycle. It
            is the persistent identity of that object, but not its address.

            This also means that de-referencing an object, even within the same
            store, requires running through the locator and figuring out whether
            the object is local or remote. While protocol interactions pass URIs
            around, inside a store they are always interned and the peer just
            "thinks" about them as ints.

            In terms of the "simple uniform interface" dimension, I have less
            to say so far. The generic object system is something that I am
            exploring for scalable semantic stores (RDF and TopicMaps). The
            data structure is very simple, so I should be able to use a simple
            kind of representation transfer to materialize the objects, or to
            update them.

            The query side is where I am hoping that things will really shine.
            The network database model makes it possible to get by with a
            stateless protocol for iterators. Basically, the client needs to
            pass back some minimal state in the connection, essentially
            corresponding to the current generic object in a list or the
            current generic object in a tree traversal. All of which are
            identified by URIs.

            One of the interesting things is that I expect that a client will
            be able to ask for itr.next() and recieve the response from whatever
            peer actually holds the next generic object.

            Thanks,

            -bryan

            --- In rest-discuss@yahoogroups.com, Ryan Fugger <rfugger@y...> wrote:
            >
            > Hi. I've been struggling with trying to apply REST to a project of
            mine,
            > a decentralized P2P payment system using only IOUs passed between
            friends
            > in a social network:
            >
            > http://ripple.sourceforge.net/
            >
            > The payment network is made up of nodes living on http servers. I
            can see
            > how REST would be appropriate for a client API to a node on the
            network --
            > to allow users to perform actions through their node, to allow
            ecommerce
            > sites to access the network, etc. But I'm having trouble seeing
            how a
            > RESTful approach might improve the protocol for communications
            between
            > nodes.
            >
            > Some issues I've come across:
            >
            > * Identifying distributed objects with resolvable URIs is
            problematic
            > since it seems to want to locate them on a single node, when in
            reality
            > they live on several nodes. Giving them several identifiers seems
            > inelegant.
            > * Nodes must be able to move to different servers, and if there are
            URI
            > identifiers for resources on a node that must be resolvable, then
            there
            > must a mechanism for changing those identifiers when a node moves.
            This
            > could cause problems with historical audit information backed up
            on
            > offline machines, unless two identifiers are stored. A node could
            move
            > many times, so many identifiers may be needed for each resource.
            > * Only fully-functional nodes may communicate with other nodes as
            nodes.
            > Scalability in terms of third-party access to partial node
            functionality
            > (the main benefit of giving all resources a URI?) is not an issue.
            For
            > simplicity and security, all access to the network must be through
            one's
            > own node.
            >
            > I'm a big fan of the REST philosophy, and I'd like to take
            advantage of it
            > wherever appropriate. In this case however, REST seems to me like
            > complicated overkill compared to simple XML messaging. I don't
            have a lot
            > of experience with RESTful applications, so I'd like to know if
            others
            > agree with me, or if there's something I'm really not getting here.
            >
            > Here is a link to the beginnings of a RESTful version of inter-
            node
            > communications:
            >
            > http://ripple.sourceforge.net/resources.xml.txt
            >
            > And here is a link to a fairly complete XML messaging version:
            >
            > http://ripple.sourceforge.net/messages.xml.txt
            >
            > Much more background information is available at the project home
            page.
            >
            > Thanks,
            > Ryan
          • thompsonbry
            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,
            Message 5 of 19 , Oct 5, 2004
            • 0 Attachment
              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.

              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).

              Where I have complex objects, e.g., a red-black tree, I make each
              node of the tree a first class object and give it a URI IFF I want
              to be able to have the tree span peers. So, while a complex data
              structure such as a tree may span peers, an object is never partially
              represented a given peer.

              I use "local objects" iff the data is always to be materialized
              with the generic object. For example, the property bindings of
              a generic object are always materialized with the generic object,
              so they are modeled as "local" objects (strict containment).

              Thanks,

              -bryan

              --- In rest-discuss@yahoogroups.com, Ryan Fugger <rfugger@y...> wrote:
              > Thanks for the reply. I appreciate the input.
              >
              > On Mon, 4 Oct 2004 22:01:47 -0700, S. Mike Dierken <mdierken@h...>
              > wrote:
              >
              > > By 'distributed objects' do you mean an object that has
              constituent data
              > > that is served by multiple hosts, or do you mean a self-contained
              object
              > > that has multiple redundant copies on several hosts?
              >
              > Both.
              >
              > > If a single object is resident on several hosts then the single
              > > identifier needs to access a single host that then in turns
              communicates
              > > with the
              > > disparate constituent servers.
              >
              > 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.
              >
              > > If the several nodes only host redundant copies, then you need a
              locator
              > > algorithm that satisfies your technical requirements. Do you need
              to
              > > access the same host several times for performance and only
              switch hosts
              > > for
              > > reliability in the face of a host failure?
              >
              > No, different hosts each holding their aspect of distributed
              objects is
              > integral to the application.
              >
              > > It sounds like we should talk about what capabilities a single
              server is
              > > providing.
              >
              > A server hosts multiple nodes that each communicate with many
              neighbouring
              > nodes ("friends" with which they can exchange IOUs). Nodes may
              also
              > communicate with a strange node to pay or receive payment from that
              node.
              > Payments are made by passing IOUs along paths connecting two
              strange nodes
              > in the network of neighbours.
              >
              > > You may need a proxy that forwards requests to the current
              > > hosting server, or possibly returns a Location header with
              the 'new'
              > > location.
              >
              > Since trust is such an integral issue with this application, there
              must be
              > a mechanism to change any server that proves untrustworthy,
              including
              > proxy servers. Changing proxy servers then has all the same
              > identifier-renaming problems as changing servers.
              >
              > Like I said, as hard as I've tried to make it work, it just seems
              that
              > REST is inappropriate for the application. I'm actually looking
              at
              > bypassing HTTP altogether and using something like Jabber for
              persistent
              > XML messaging sessions between servers. Very unRESTful, I know,
              but it
              > would be soooo appealingly simple...
              >
              > Ryan
            • S. Mike Dierken
              I m lost. Perhaps if your applications was re-phrased using resource rather than node and object I d be able to understand. ... What is an originating
              Message 6 of 19 , Oct 5, 2004
              • 0 Attachment
                I'm lost. Perhaps if your applications was re-phrased using 'resource'
                rather than 'node' and 'object' I'd be able to understand.

                > 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'? Is that an HTTP client? To hide the location
                of the pieces, you have a single identifiable resource and clients don't
                know what lays beyond.

                > 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??

                > 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.

                > 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.

                > 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?




                ----- Original Message -----
                From: "Ryan Fugger" <rfugger@...>
                To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
                Sent: Monday, October 04, 2004 11:41 PM
                Subject: Re: [rest-discuss] REST for P2P application?


                > Thanks for the reply. I appreciate the input.
                >
                > On Mon, 4 Oct 2004 22:01:47 -0700, S. Mike Dierken <mdierken@...>
                > wrote:
                >
                > > By 'distributed objects' do you mean an object that has constituent data
                > > that is served by multiple hosts, or do you mean a self-contained object
                > > that has multiple redundant copies on several hosts?
                >
                > Both.
                >
                > > If a single object is resident on several hosts then the single
                > > identifier needs to access a single host that then in turns communicates
                > > with the
                > > disparate constituent servers.
                >
                > 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.
                >
                > > If the several nodes only host redundant copies, then you need a locator
                > > algorithm that satisfies your technical requirements. Do you need to
                > > access the same host several times for performance and only switch hosts
                > > for
                > > reliability in the face of a host failure?
                >
                > No, different hosts each holding their aspect of distributed objects is
                > integral to the application.
                >
                > > It sounds like we should talk about what capabilities a single server is
                > > providing.
                >
                > A server hosts multiple nodes that each communicate with many neighbouring
                > nodes ("friends" with which they can exchange IOUs). Nodes may also
                > communicate with a strange node to pay or receive payment from that node.
                > Payments are made by passing IOUs along paths connecting two strange nodes
                > in the network of neighbours.
                >
                > > You may need a proxy that forwards requests to the current
                > > hosting server, or possibly returns a Location header with the 'new'
                > > location.
                >
                > Since trust is such an integral issue with this application, there must be
                > a mechanism to change any server that proves untrustworthy, including
                > proxy servers. Changing proxy servers then has all the same
                > identifier-renaming problems as changing servers.
                >
                > Like I said, as hard as I've tried to make it work, it just seems that
                > REST is inappropriate for the application. I'm actually looking at
                > bypassing HTTP altogether and using something like Jabber for persistent
                > XML messaging sessions between servers. Very unRESTful, I know, but it
                > would be soooo appealingly simple...
                >
                > Ryan
                >
              • 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.