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

[rest-discuss] Groove Web Services

Expand Messages
  • Michael Smith
    http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml I ve just read this article on the upcoming Groove web services interfaces. It talks about
    Message 1 of 14 , Nov 4, 2002
      http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml

      I've just read this article on the upcoming Groove web services
      interfaces. It talks about how Groove have tried to create a RESTful
      interface using SOAP/WSDL and that the result is an "exceptionally
      elegant and productive Web services API".

      Then I read that;
      "It's all organized as a web of linked XML documents controlled by a
      handful of verbs such as Create, Read, Update, and Delete." !

      They really seem to have grasped the value of uri-addressable resources
      represented in xml, accessed using a small number of standardised methods.
      So what did they need SOAP for ?
      I have to hope that their next step is to make SOAP optional. Or will
      they continue, and start reinventing http-caching.

      Any thoughts ?
      Michael Smith.
    • Mark Baker
      ... It sounds just like Hailstorm/My-Services. I think their protocol was called HSML or something, but was basically CRUD (in more ways than one). MB -- Mark
      Message 2 of 14 , Nov 4, 2002
        On Mon, Nov 04, 2002 at 09:11:44PM +0000, Michael Smith wrote:
        > Then I read that;
        > "It's all organized as a web of linked XML documents controlled by a
        > handful of verbs such as Create, Read, Update, and Delete." !
        >
        > They really seem to have grasped the value of uri-addressable resources
        > represented in xml, accessed using a small number of standardised methods.
        > So what did they need SOAP for ?
        > I have to hope that their next step is to make SOAP optional. Or will
        > they continue, and start reinventing http-caching.
        >
        > Any thoughts ?

        It sounds just like Hailstorm/My-Services. I think their protocol was
        called HSML or something, but was basically CRUD (in more ways than
        one).

        MB
        --
        Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
        http://www.markbaker.ca http://www.idokorro.com
      • Phil Eskelin
        ... When there was buzz around P2P, and Groove was the first mover, I really thought Groove would be the Netscape of the P2P wave. After downloading and
        Message 3 of 14 , Nov 5, 2002
          Michael wrote:
          > Then I read that;
          > "It's all organized as a web of linked XML documents controlled by a
          > handful of verbs such as Create, Read, Update, and Delete." !
          >
          > They really seem to have grasped the value of uri-addressable resources
          > represented in xml, accessed using a small number of standardised methods.
          > So what did they need SOAP for ?
          > I have to hope that their next step is to make SOAP optional. Or will
          > they continue, and start reinventing http-caching.
          >
          > Any thoughts ?

          When there was buzz around P2P, and Groove was the first mover, I really
          thought Groove would be the "Netscape" of the P2P wave. After downloading
          and attempting to use it, I found that it was worth the space it took on my
          hard disk, so I removed it. My sense was that it was more hype than
          anything.

          Regarding Groove Web Services, my thought is that their interface may in
          fact be very RESTful, but the sentence you quote above leads me to believe
          that nothing has changed - more hype than anything. A REST developer who
          *really* got it would call them like they are: GET, PUT, POST, and DELETE.
          And that same developer would know that SOAP was irrelevant.

          Philip

          ________________________________________________________________________
          This e-mail may contain confidential and/or privileged information. If you
          are not the intended recipient (or have received this e-mail in error)
          please notify the sender immediately and destroy this e-mail. Any
          unauthorized copying, disclosure or distribution of the material in this
          e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
          e-mail communications through its networks.
        • Phil Eskelin
          ... I meant that it was *not* worth the space it took on my hard drive. I don t know what others thought, and I don t mean to venture off-topic, but it was a
          Message 4 of 14 , Nov 5, 2002
            I wrote:
            > After downloading and attempting to use it, I found that it was
            > worth the space it took on my hard disk, so I removed it. My
            > sense was that it was more hype than anything.

            I meant that it was *not* worth the space it took on my hard drive. I don't
            know what others thought, and I don't mean to venture off-topic, but it was
            a classic example of a tight, simple concept gone overbloated and
            overcomplicated.

            Philip

            ________________________________________________________________________
            This e-mail may contain confidential and/or privileged information. If you
            are not the intended recipient (or have received this e-mail in error)
            please notify the sender immediately and destroy this e-mail. Any
            unauthorized copying, disclosure or distribution of the material in this
            e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
            e-mail communications through its networks.
          • Seairth Jacobs
            From: Phil Eskelin ... All other arguments aside, I strongly disagree that a REST developer would only get it right if they
            Message 5 of 14 , Nov 5, 2002
              From: "Phil Eskelin" <philip.eskelin@...>
              >
              > Regarding Groove Web Services, my thought is that their interface may in
              > fact be very RESTful, but the sentence you quote above leads me to believe
              > that nothing has changed - more hype than anything. A REST developer who
              > *really* got it would call them like they are: GET, PUT, POST, and DELETE.
              > And that same developer would know that SOAP was irrelevant.

              All other arguments aside, I strongly disagree that a REST developer would
              only get it right if they were to use HTTP verbs. HTTP verbs have specific,
              limited meanings that are not necessarily a good match with the Groove Web
              Services. It is just as RESTful to create ones own set of verbs that
              actually provide the exact functionality needed. While I admit that HTTP
              (and its verbs) is fairly prolific, it is not the "be all, end all" of web
              protocols. While HTTP is RESTful, not all things RESTful are HTTP.

              ---
              Seairth Jacobs
              seairth@...
            • Mark Baker
              ... No it isn t. You ve been here long enough to know that Seairth! 8-O With REST, you re constrained to using methods that you could use on anything. So
              Message 6 of 14 , Nov 5, 2002
                On Tue, Nov 05, 2002 at 12:16:17PM -0500, Seairth Jacobs wrote:
                > It is just as RESTful to create ones own set of verbs that
                > actually provide the exact functionality needed.

                No it isn't. You've been here long enough to know that Seairth! 8-O
                With REST, you're constrained to using methods that you could use on
                anything. So "CREATE" isn't a REST method, because I don't know what
                it would mean to invoke that on a URI identifying a stock quote.

                This is a severe constraint on *form*, but does not in any way constrain
                *function*. i.e. every problem has a solution with a system built with
                this constraint in mind.

                > While HTTP is RESTful, not all things RESTful are HTTP.

                That's true, but largely irrelevant today; it's all we've got that is.

                MB
                --
                Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
                http://www.markbaker.ca http://www.idokorro.com
              • Seairth Jacobs
                From: Mark Baker ... Huh? This is the first time I ve heard that all RESTful methods must be usable on *anything*. All I understood of
                Message 7 of 14 , Nov 5, 2002
                  From: "Mark Baker" <distobj@...>
                  >
                  > On Tue, Nov 05, 2002 at 12:16:17PM -0500, Seairth Jacobs wrote:
                  > > It is just as RESTful to create ones own set of verbs that
                  > > actually provide the exact functionality needed.
                  >
                  > No it isn't. You've been here long enough to know that Seairth! 8-O
                  > With REST, you're constrained to using methods that you could use on
                  > anything. So "CREATE" isn't a REST method, because I don't know what
                  > it would mean to invoke that on a URI identifying a stock quote.

                  Huh? This is the first time I've heard that all RESTful methods must be
                  usable on *anything*. All I understood of REST was that you should use a
                  few, generic methods. Within the domain that Groove is functioning, their
                  choice of methods are RESTful.

                  *sigh* Just when I thought that I understood this REST thing...

                  > This is a severe constraint on *form*, but does not in any way constrain
                  > *function*. i.e. every problem has a solution with a system built with
                  > this constraint in mind.
                  >
                  > > While HTTP is RESTful, not all things RESTful are HTTP.
                  >
                  > That's true, but largely irrelevant today; it's all we've got that is.

                  If it is largely irrelevant today, then why do we talk about REST at all?
                  Why not just talk about HTTP Best Practices instead? If HTTP is the only
                  RESTful thing we will be using for any forseeable future, REST concepts
                  would get much further if we were to just put it aside and get people to
                  focus on HTTP...

                  ---
                  Seairth Jacobs
                  seairth@...
                • Mark Baker
                  ... Oops. 8-( Yah, that s what uniform interface means. If a method doesn t mean something to everything you can invoke it on, then it s not uniform! It s
                  Message 8 of 14 , Nov 5, 2002
                    On Tue, Nov 05, 2002 at 02:09:32PM -0500, Seairth Jacobs wrote:
                    > > No it isn't. You've been here long enough to know that Seairth! 8-O
                    > > With REST, you're constrained to using methods that you could use on
                    > > anything. So "CREATE" isn't a REST method, because I don't know what
                    > > it would mean to invoke that on a URI identifying a stock quote.
                    >
                    > Huh? This is the first time I've heard that all RESTful methods must be
                    > usable on *anything*. All I understood of REST was that you should use a
                    > few, generic methods. Within the domain that Groove is functioning, their
                    > choice of methods are RESTful.
                    >
                    > *sigh* Just when I thought that I understood this REST thing...

                    Oops. 8-(

                    Yah, that's what "uniform interface" means. If a method doesn't mean
                    something to everything you can invoke it on, then it's not uniform!
                    It's like being restricted to interacting with Java objects by using
                    java.lang.Object.

                    The uniform interface constraint is really two constraints in one.
                    First, there's the constraint that you need to prespecify the methods
                    you'll use, for visibility and low-coordination cost reasons. Second,
                    there's the additional constraint that the interface will be the most
                    general one possible, which you get by constraining that all methods
                    are usable on everything.

                    > > > While HTTP is RESTful, not all things RESTful are HTTP.
                    > >
                    > > That's true, but largely irrelevant today; it's all we've got that is.
                    >
                    > If it is largely irrelevant today, then why do we talk about REST at all?
                    > Why not just talk about HTTP Best Practices instead? If HTTP is the only
                    > RESTful thing we will be using for any forseeable future, REST concepts
                    > would get much further if we were to just put it aside and get people to
                    > focus on HTTP...

                    That's what some of us are doing, but it's also useful to focus on REST
                    to explain how some HTTP related things are broken. e.g. cookies. Plus,
                    sometimes it's not obvious from just looking at RFC 2616 why things are
                    the way they are. That's where REST helps. For example, statelessness.

                    MB
                    --
                    Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
                    http://www.markbaker.ca http://www.idokorro.com
                  • Phil Eskelin
                    ... One of the big benefits that one should receive from taking a RESTful approach is purification and simplification of an otherwise ugly situation that will
                    Message 9 of 14 , Nov 5, 2002
                      Mark Baker wrote:
                      > Seairth Jacobs wrote:
                      > > It is just as RESTful to create ones own set of verbs that
                      > > actually provide the exact functionality needed.
                      >
                      > No it isn't. You've been here long enough to know that Seairth!
                      > 8-O With REST, you're constrained to using methods that you could
                      > use on anything. So "CREATE" isn't a REST method, because I
                      > don't know what it would mean to invoke that on a URI identifying
                      > a stock quote.

                      One of the big benefits that one should receive from taking a RESTful
                      approach is purification and simplification of an otherwise ugly situation
                      that will only get uglier. If Groove uses 'Create', then someone else will
                      use 'myCreate', then someone else will use hungarian notiation with
                      'urilstCreate', and then in a few years we circle back to the same recursive
                      scope creep scenario that led to the creation of SOAP in the first place.
                      People agreeing on HTTP and its verbs is a key success factor of REST.

                      > This is a severe constraint on *form*, but does not in any way
                      > constrain *function*. i.e. every problem has a solution with a
                      > system built with this constraint in mind.

                      I went back and read the entire article [1], written by Jon Udell at
                      InfoWorld. I can't tell if my problem comes from what I perceive as a
                      writer trying to sound smart, Groove trying to cash in on hype, or from
                      those who created the notion of RESTful SOAP trying to start a riot.

                      Udell says GWS is a textbook example of "RESTful SOAP" - is that good or
                      bad? To elaborate on what that means, he references the SOAP 1.2 working
                      draft, saying that URIs should be used as resource identifiers. DUH!! Then
                      comes this paragraph:

                      For example, the root of GWS is a SOAP service with an address
                      like http://localhost:9080/GWS/Groove/1.0/Accounts. Since a
                      Groove account is a container of identities, a Read operation
                      on this resource produces an XML document that enumerates them.
                      Each identity includes an element like
                      /GWS/Groove/1.0/Spaces/grooveIdentity/123...xyz -- that is, the
                      URI of the SOAP service that enumerates the shared spaces for
                      that identity. Traversal of spaces, tools, and data proceeds
                      in a similar fashion. It's all organized as a web of linked
                      XML documents controlled by a handful of verbs such as Create,
                      Read, Update, and Delete.

                      First (if I was claiming to be RESTful), I would replace every instance of
                      'SOAP service' with 'resource'. Then, I would replace 'Create, Read,
                      Update, and Delete' with 'PUT, GET, POST, and DELETE'. To clarify my point,
                      I might reword the last sentence to say "...web of linked resources accessed
                      by a handful of verbs that allow you to create, read, update, and delete
                      them." I would then elaborate on the connection between a RESTful style and
                      HTTP and make sure I reference Fielding's thesis.

                      Philip

                      1. http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml

                      ________________________________________________________________________
                      This e-mail may contain confidential and/or privileged information. If you
                      are not the intended recipient (or have received this e-mail in error)
                      please notify the sender immediately and destroy this e-mail. Any
                      unauthorized copying, disclosure or distribution of the material in this
                      e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
                      e-mail communications through its networks.
                    • S. Mike Dierken
                      ... From: Phil Eskelin ... point, ... accessed ... and ... I don t believe that REST depends on those /particular/ operations.
                      Message 10 of 14 , Nov 5, 2002
                        ----- Original Message -----
                        From: "Phil Eskelin" <philip.eskelin@...>

                        >
                        > First (if I was claiming to be RESTful), I would replace every instance of
                        > 'SOAP service' with 'resource'. Then, I would replace 'Create, Read,
                        > Update, and Delete' with 'PUT, GET, POST, and DELETE'. To clarify my
                        point,
                        > I might reword the last sentence to say "...web of linked resources
                        accessed
                        > by a handful of verbs that allow you to create, read, update, and delete
                        > them." I would then elaborate on the connection between a RESTful style
                        and
                        > HTTP and make sure I reference Fielding's thesis.

                        I don't believe that REST depends on those /particular/ operations. Any
                        self-consistent system can pick whatever small number of operations it
                        wants. It will only be consistent with itself though, unless it uses the
                        same operations (with the same meanings, etc) as other systems though.

                        If your job is to build a system, without regard to interoperability with
                        other systems, then using those particular operations is a lower priority.
                        But if you are successful, you will eventually run into them, so you better
                        be prepared to translate, or just use them from day one.
                      • bhaugen32
                        ... as a ... This development marks the onset of REST as a buzzword. The pioneers should feel both proud and appalled. I remember when the same thing happened
                        Message 11 of 14 , Nov 6, 2002
                          Phil Eskelin wrote:
                          > I went back and read the entire article [1], written by Jon Udell at
                          > InfoWorld. I can't tell if my problem comes from what I perceive
                          as a
                          > writer trying to sound smart, Groove trying to cash in on hype...

                          This development marks the onset of REST as a buzzword.
                          The pioneers should feel both proud and appalled.

                          I remember when the same thing happened to patterns,
                          and objects before that.

                          A new concept gets promoted, initially adopted by a few
                          and disdained by many. If the promoters are successful,
                          the new concept becomes synonymous with goodness.
                          Pretty soon everybody wants to claim the goodness.
                          Unfortunately, many of them only put it on like lipstick.

                          Next step, a rack of REST books,
                          some of them based on RPC-oriented SOAP?

                          But the fact remains, Roy, Mark, Paul and colleagues
                          have executed a remarkably successful education campaign!
                          Going from disdain to hype-as-goodness in about a year?
                        • Phil Eskelin
                          ... Very very true. Remember requests like I need a pattern to search a string for a token on patterns-discussion? Journalists thrive on change, and often
                          Message 12 of 14 , Nov 6, 2002
                            Bob wrote:
                            > This development marks the onset of REST as a buzzword.
                            > The pioneers should feel both proud and appalled.
                            >
                            > I remember when the same thing happened to patterns,
                            > and objects before that.

                            Very very true. Remember requests like 'I need a pattern to search a string
                            for a token' on patterns-discussion? Journalists thrive on change, and
                            often you see them struggle with a new concept when they're early adopters
                            to a potentially mainstream trend. In this case, I don't think Udell
                            struggled with the concept, since in my experience he seems to articulate
                            new concepts well, but he seems to be stuck somewhere in the gray area
                            between being a SOAP and REST (clearly anybody who boasts 'RESTful SOAP' is
                            missing or hiding something).

                            > Next step, a rack of REST books,
                            > some of them based on RPC-oriented SOAP?

                            It must be funny for people browsing in bookstores who are not technical.
                            First they see patterns, thinking maybe programmers are sewers. Then they
                            see SOAP, thinking that programmers finally discovered hygiene. Now
                            REST...will they think it's a new form of meditation? It sort of is, if you
                            do it right ;-)

                            > But the fact remains, Roy, Mark, Paul and colleagues
                            > have executed a remarkably successful education campaign!
                            > Going from disdain to hype-as-goodness in about a year?

                            Gush gush gush! For me, all three have contributed greatly to my
                            understanding of what I'm doing in my own efforts. Roy's dissertation
                            helped me understand the core concepts, but Mark and Paul helped me realize
                            I needed to refactor and redesign my toolkit a lot more before it was
                            RESTful enough for release.

                            Philip

                            ________________________________________________________________________
                            This e-mail may contain confidential and/or privileged information. If you
                            are not the intended recipient (or have received this e-mail in error)
                            please notify the sender immediately and destroy this e-mail. Any
                            unauthorized copying, disclosure or distribution of the material in this
                            e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
                            e-mail communications through its networks.
                          • Mark Baker
                            ... More like two-and-a-half for me. It was March 2000 when I started the REST/Web promotion on soap@discuss.develop.com. I got one convert out of that brief
                            Message 13 of 14 , Nov 6, 2002
                              On Wed, Nov 06, 2002 at 12:44:02PM -0000, bhaugen32 wrote:
                              > But the fact remains, Roy, Mark, Paul and colleagues
                              > have executed a remarkably successful education campaign!
                              > Going from disdain to hype-as-goodness in about a year?

                              More like two-and-a-half for me. It was March 2000 when I started the
                              REST/Web promotion on soap@.... I got one convert out
                              of that brief stint (though I'm still subscribed), Ken MacLeod. 8-)

                              Thanks for the kind words.

                              MB
                              --
                              Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
                              http://www.markbaker.ca http://www.idokorro.com
                            • Paul Prescod
                              (from the thread at http://groups.yahoo.com/group/rest-discuss/message/2781) ... Yes, REST has been quite a buzzword for a while. For some it means use
                              Message 14 of 14 , Nov 6, 2002
                                (from the thread at http://groups.yahoo.com/group/rest-discuss/message/2781)

                                bhaugen32 wrote:
                                >...
                                > This development marks the onset of REST as a buzzword.
                                > The pioneers should feel both proud and appalled.

                                Yes, REST has been quite a buzzword for a while. For some it means "use
                                existing Internet infrastructure". For others it means "use few methods,
                                whether they are HTTP's or not." For others it means "use lots of URIs."

                                If people are thinking about the issues enough to misunderstand them,
                                that's at least progress. ;)

                                I'm somewhat confused about how the RESTful SOAP Groove thing will work.
                                First, I wonder how they will work around the well-known problems in
                                using service URIs in WSDL. Second, I wonder why they would use a READ
                                method instead of the GET method embedded in the implementations of
                                hundreds of tools and standards, from Xalan to Squid, XPath to the DOM.

                                My guess is that the answers to those questions are linked. They
                                couldn't use HTTP GET because WSDL has such poor support for REST. I
                                would guess they've built a REST-a-like on top of a standard
                                single-endpoint SOAP services. I would guess that the addressing model
                                is *still* broken into domain/port/service-path and resource-path
                                whereas the Web has domain/port/resource-path. The
                                service-path/resource-path split is still proprietary, just as if
                                resource-path was using some kind of proprietary GrooveIDs. And of
                                course the method names and semantics are still proprietary to Groove.

                                If we all do this then we will end up with hundreds of incompatible
                                web-alikes.

                                I understand the position Groove is in: they have to ship software and
                                can't wait until WSDL is fixed. And they have to demo Visual Studio.NET
                                integration so they can't dump WSDL. Maybe they did the right thing from
                                a marketing and sales point of view.

                                But nevertheless, fans of "RESTful SOAP" should get out there and
                                publicize the problems with WSDL so that they will be fixed one day. It
                                would be really tragic if five years from now that the REST acronym is
                                associated with a design pattern that has been deployed in hundreds of
                                incompatible ways in hundreds of incompatible services.

                                These issues are discussed further here:

                                * http://www.blogstream.com/pauls/1032521623/index_html
                                * http://www.prescod.net/rest/wsdlhttp.html

                                Paul Prescod
                              Your message has been successfully submitted and would be delivered to recipients shortly.