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

Re: [rest-discuss] Re: GoogleAPI is Rest?

Expand Messages
  • Asynch Messaging
    Huh? Their genius was in recoginizing that content is king and they ve got the content - and the poor schmucks trolling for something interesting to do with
    Message 1 of 24 , Apr 30, 2002
      Huh? Their genius was in recoginizing that "content is king" and they've got
      the content - and the poor schmucks trolling for something interesting to do
      with SOAP would jump on a dressed up GET request and provide them a quick
      marketing buzz. Can't wait for the AOL boyz to hand out the free SOAP API to
      retrieve content from their pay-to-play network... imagine where CompuServe
      and Prodigy would be today if they had something like SOAP to affect their
      reach...
      > Google's Genius?
      > To pick a wire format for which there are dozens of toolkits poised to
      directly translate the protocol into readily consumable bits.
      How many toolkits can do HTTP GET? Correctly? Why would a stream of XML from
      a response to a GET be less readily consumable?

      > To directly test interop against a small but diverse set of platforms.
      You don't need SOAP to do that.

      > To provide early access to an undisclosed number of other interested
      parties.
      They had an HTTP API that provided XML via GET - but you had to pay to play.
      If they open that one up, you'd get just as many people incorporating it
      into products as the SOAP API.

      > To provide a sample that runs on wide range of operating systems and
      instruction set architectures.
      Uh, so does HTTP?

      > To document the wire protocol adequately, including all the optional type
      annotations.

      > And to provide sufficient metadata, in the form of WSDL, so that a large
      number of developers can be instantly up and running.
      Don't know how to do that in pure HTTP - that's a missing piece. Not enough
      to through out the baby with the bathwater though.



      ----- Original Message -----
      From: "Sam Ruby" <rubys@...>
      To: "Paul Prescod" <paul@...>
      Cc: <rest-discuss@yahoogroups.com>
      Sent: Tuesday, April 30, 2002 5:05 PM
      Subject: [rest-discuss] Re: GoogleAPI is Rest?


      > If you found that weblog entry interesting, I'm sure that you will enjoy
      > this one:
      >
      > http://www.oreillynet.com/cs/weblog/view/wlg/1351
      >
      > - Sam Ruby
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > rest-discuss-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
    • Lucas Gonze
      ... There are a bunch of missing pieces. WSDL for HTTP resources needs to happen. Work on event models needs to get finished. Maybe store and forward (the
      Message 2 of 24 , May 1, 2002
        On Tue, 30 Apr 2002, Asynch Messaging wrote:
        > > And to provide sufficient metadata, in the form of WSDL, so that a large
        > > number of developers can be instantly up and running.
        > Don't know how to do that in pure HTTP - that's a missing piece. Not enough
        > to through out the baby with the bathwater though.

        There are a bunch of missing pieces. WSDL for HTTP resources needs to
        happen. Work on event models needs to get finished. Maybe store and
        forward (the email workalike we discussed here a few months ago) needs to
        happen.

        SOAP-RPC already offers solutions to all of the above. They're not as
        good as HTTP solutions could be but at least they're out there. Until the
        REST stack gets filled out to the same degree as the XML RPC stack, we are
        in ivory tower land.

        - Lucas
      • Mark Baker
        ... Perhaps, but with nowhere near the urgency, and nowhere near the complexity of WSDL. WSDL exists, and is a necessary part of Web Services, because you
        Message 3 of 24 , May 1, 2002
          On Wed, May 01, 2002 at 09:34:09AM -0400, Lucas Gonze wrote:
          > There are a bunch of missing pieces. WSDL for HTTP resources needs to
          > happen.

          Perhaps, but with nowhere near the urgency, and nowhere near the
          complexity of WSDL. WSDL exists, and is a necessary part of Web
          Services, because you don't know anything about an interface. With
          REST, you start off with a lot of information. It's not *all* the
          information everybody would ever need, but it's more than enough for
          most.

          > Work on event models needs to get finished. Maybe store and
          > forward (the email workalike we discussed here a few months ago) needs to
          > happen.

          Yes.

          > SOAP-RPC already offers solutions to all of the above. They're not as

          SOAP doesn't have an event model, or a store and forward model. It has
          an intermediary model, just like HTTP, only better specified.

          > good as HTTP solutions could be but at least they're out there. Until the
          > REST stack gets filled out to the same degree as the XML RPC stack, we are
          > in ivory tower land.

          Oh, please. Without any further work, I can get a whole lot done with
          REST right now, between uncoordinated parties . The same is not true
          for SOAP/Web-services.

          MB
          --
          Mark Baker, Chief Science Officer, Planetfred, Inc.
          Ottawa, Ontario, CANADA. mbaker@...
          http://www.markbaker.ca http://www.planetfred.com
        • Paul Prescod
          ... WSDL for HTTP is -- as far as I can tell -- exactly as functional as WSDL for SOAP. That doesn t mean that WSDL is REST-ful, but it does mean ... How does
          Message 4 of 24 , May 1, 2002
            Lucas Gonze wrote:
            >
            > On Tue, 30 Apr 2002, Asynch Messaging wrote:
            > > > And to provide sufficient metadata, in the form of WSDL, so that a large
            > > > number of developers can be instantly up and running.
            > > Don't know how to do that in pure HTTP - that's a missing piece. Not enough
            > > to through out the baby with the bathwater though.
            >
            > There are a bunch of missing pieces. WSDL for HTTP resources needs to
            > happen. Work on event models needs to get finished. Maybe store and
            > forward (the email workalike we discussed here a few months ago) needs to
            > happen.

            WSDL for HTTP is -- as far as I can tell -- exactly as functional as
            WSDL for SOAP. That doesn't mean that WSDL is REST-ful, but it does mean
            that your next sentence is misleading:

            > SOAP-RPC already offers solutions to all of the above.

            How does SOAP-RPC handle "event models"????

            > ... They're not as
            > good as HTTP solutions could be but at least they're out there. Until the
            > REST stack gets filled out to the same degree as the XML RPC stack, we are
            > in ivory tower land.

            We are already more filled out. WSDL is broken for HTTP but just as
            broken for SOAP. UDDI is entirely useless for both. Our rough ideas at
            event models are better than what I've seen for SOAP. We have *some*
            form of authentication. Most important: we have an addressing and
            resource manipulation model. They don't even know that they lack one yet
            (despite that I've been telling them for six months!).

            Paul Prescod
          • Lucas Gonze
            ... Point taken. ... By allowing SOAP-RPC to be transported over event protocols such as JMS, and by having a more fleshed out model for intermediaries.
            Message 5 of 24 , May 1, 2002
              > WSDL for HTTP is -- as far as I can tell -- exactly as functional as
              > WSDL for SOAP. That doesn't mean that WSDL is REST-ful, but it does mean
              > that your next sentence is misleading:
              >
              > > SOAP-RPC already offers solutions to all of the above.

              Point taken.

              > How does SOAP-RPC handle "event models"????

              By allowing SOAP-RPC to be transported over event protocols such as JMS,
              and by having a more fleshed out model for intermediaries. Precanned
              support for HTTP intermediaries is limited to real time proxying.
              Otherwise you have to get out the power tools and write a gateway by hand,
              which is too low level a job for most projects.

              Rather than argue over the details of what is and isn't available, lets
              focus on building. People are getting the impression -- false IMO -- that
              REST is a religious war. That's what Sam Ruby was mainly reacting to, and
              what Dave Winer has been ranting about on scripting news. The kind of
              obscurantia that we've been arguing over, e.g. URI opacity, needs to be
              solved and polished well enough to allow app developers to focus on
              application needs. I don't believe anyone here thinks that's already
              done.

              Maybe evangelizing is a part of the work. For example, make the point
              that service description tools, specifically Visual .NET, apply equally to
              REST development. So let's do it. but let's not fool ourselves into
              thinking that once somone embraces the one true faith they'll find full
              featured toolkits.

              - Lucas
            • Bill de hÓra
              ... Are you saying the processing style depends on the underlying protocol SOAP is carried over/through? I thought SOAP was supposed to be a protocol. Bill de
              Message 6 of 24 , May 1, 2002
                > -----Original Message-----
                > From: Lucas Gonze [mailto:lucas@...]
                > Sent: 01 May 2002 18:20
                > To: Paul Prescod
                >
                > > How does SOAP-RPC handle "event models"????
                >
                > By allowing SOAP-RPC to be transported over event protocols
                > such as JMS, and by having a more fleshed out model for
                > intermediaries.

                Are you saying the processing style depends on the underlying protocol
                SOAP is carried over/through? I thought SOAP was supposed to be a
                protocol.

                Bill de hÓra
              • Mark Baker
                I m not Lucas. 8-) ... Those two things aren t inconsistent. WebDAV is both a protocol and an HTTP extension. SOAP can be used in the same way. Indeed, this
                Message 7 of 24 , May 1, 2002
                  I'm not Lucas. 8-)

                  On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de hÓra wrote:
                  > Are you saying the processing style depends on the underlying protocol
                  > SOAP is carried over/through? I thought SOAP was supposed to be a
                  > protocol.

                  Those two things aren't inconsistent. WebDAV is both a protocol and
                  an HTTP extension. SOAP can be used in the same way. Indeed, this is
                  the only practical way in which SOAP can be used in a REST friendly
                  manner (the other way being to recast REST semantics on top of SOAP -
                  a horrible, horrible idea).

                  MB
                  --
                  Mark Baker, Chief Science Officer, Planetfred, Inc.
                  Ottawa, Ontario, CANADA. mbaker@...
                  http://www.markbaker.ca http://www.planetfred.com
                • Bill de hÓra
                  ... ? ... Maybe they re not exclusive, I m not sure. A (network) protocol is interesting insofar as it s a useful abstraction (of the network). Having to think
                  Message 8 of 24 , May 1, 2002
                    > -----Original Message-----
                    > From: Mark Baker [mailto:distobj@...]
                    >
                    > I'm not Lucas. 8-)

                    ?


                    > On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de hÓra wrote:
                    > > Are you saying the processing style depends on the
                    > underlying protocol
                    > > SOAP is carried over/through? I thought SOAP was supposed to be a
                    > > protocol.
                    >
                    > Those two things aren't inconsistent. WebDAV is both a
                    > protocol and an HTTP extension. SOAP can be used in the same
                    > way. Indeed, this is the only practical way in which SOAP
                    > can be used in a REST friendly manner (the other way being to
                    > recast REST semantics on top of SOAP - a horrible, horrible idea).

                    Maybe they're not exclusive, I'm not sure. A (network) protocol is
                    interesting insofar as it's a useful abstraction (of the network).
                    Having to think about SOAP and JMS, or SOAP and HTTP or SOAP and BEEP,
                    means I can't just think my application and SOAP, I may as well think
                    about App and JMS or App and HTTP or App and BEEP, and eliminate
                    superfluous noise. This is like C programming; machine power is traded
                    for programmer dissonance. Bad trade. I expect that programmers will
                    just think about the SOAP abstraction, bedamned the supporting protocol.

                    Bill de hOra
                  • Paul Prescod
                    ... Absolutely! ... Key word: was . Seriously, SOAP may meet some technical definition for protocol but I d say it is really some kind of meta-protocol or
                    Message 9 of 24 , May 1, 2002
                      Bill de hÓra wrote:
                      >
                      >...
                      >
                      > Are you saying the processing style depends on the underlying protocol
                      > SOAP is carried over/through?

                      Absolutely!

                      > .... I thought SOAP was supposed to be a
                      > protocol.

                      Key word: "was".

                      Seriously, SOAP may meet some technical definition for "protocol" but
                      I'd say it is really some kind of meta-protocol or protocol framework or
                      "XML vocabulary with processing expectations" or something.

                      That's "SOAP in general" as opposed to "SOAP-RPC over HTTP" which is
                      really a very concrete RPC protocol.

                      Paul Prescod
                    • Lucas Gonze
                      Is there anything to accomplish via a BOF at ETCON? IE, a convincing agenda?
                      Message 10 of 24 , May 1, 2002
                        Is there anything to accomplish via a BOF at ETCON? IE, a convincing
                        agenda?
                      • Paul Prescod
                        ... But WebDAV is only designed to run over HTTP or perhaps over protocols with very HTTP-like characteristics. If you use a WebDAV library you know what to
                        Message 11 of 24 , May 1, 2002
                          Mark Baker wrote:
                          >
                          > I'm not Lucas. 8-)
                          >
                          > On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de hÓra wrote:
                          > > Are you saying the processing style depends on the underlying protocol
                          > > SOAP is carried over/through? I thought SOAP was supposed to be a
                          > > protocol.
                          >
                          > Those two things aren't inconsistent. WebDAV is both a protocol and
                          > an HTTP extension.

                          But WebDAV is only designed to run over HTTP or perhaps over protocols
                          with very HTTP-like characteristics. If you use a WebDAV library you
                          know what to expect in terms of synchronousness, message patterns, etc.
                          SOAP does not predefine message patterns independent of the transport.
                          One transport could be synchronous and the next asynchronous. One
                          unidirectional and the next bidirectional. One transport could have an
                          addressing model and another lack one. etc.

                          Paul Prescod
                        • Paul Prescod
                          I submitted a description for an ETCON BOF called Alternative Web Services Architectures . I don t think that in one or two hours we can make huge progress
                          Message 12 of 24 , May 1, 2002
                            I submitted a description for an ETCON BOF called "Alternative Web
                            Services Architectures". I don't think that in one or two hours we can
                            make huge progress towards understanding each other but it may help to
                            hash out a few issues.

                            Paul Prescod
                          • S. Mike Dierken
                            ... Well put. What are the missing pieces? - discovery (wsdl-style declarative formats, intellisense-tool friendly stuff, etc.) - clients (do we need to write
                            Message 13 of 24 , May 1, 2002
                              > Rather than argue over the details of what is and isn't available, lets
                              > focus on building.

                              > Maybe evangelizing is a part of the work. For example, make the point
                              > that service description tools, specifically Visual .NET, apply equally to
                              > REST development. So let's do it. but let's not fool ourselves into
                              > thinking that once somone embraces the one true faith they'll find full
                              > featured toolkits.

                              Well put. What are the missing pieces?
                              - discovery (wsdl-style declarative formats, intellisense-tool friendly
                              stuff, etc.)
                              - clients (do we need to write new 'resource modelling friendly' clients in
                              all the languages or can we re-user protocol API libraries?)

                              I don't think we need asynch stuff immediately, since there isn't an
                              existing body of resource that support it to hook up to.

                              What else?
                            • Mark Baker
                              ... But that s the rub. The Web *is* your application. Or more precisely, to use the Web, you have to form your application in the shape of the Web;
                              Message 14 of 24 , May 1, 2002
                                On Wed, May 01, 2002 at 10:52:37PM +0100, Bill de hÓra wrote:
                                > Maybe they're not exclusive, I'm not sure. A (network) protocol is
                                > interesting insofar as it's a useful abstraction (of the network).
                                > Having to think about SOAP and JMS, or SOAP and HTTP or SOAP and BEEP,
                                > means I can't just think my application and SOAP,

                                But that's the rub. The Web *is* your application. Or more precisely,
                                to use the Web, you have to form your application in the shape of the
                                Web; hypertext.

                                MB
                                --
                                Mark Baker, Chief Science Officer, Planetfred, Inc.
                                Ottawa, Ontario, CANADA. mbaker@...
                                http://www.markbaker.ca http://www.planetfred.com
                              • sa3ruby
                                ... I posted a few suggestions at http://www.oreillynet.com/cs/weblog/view/wlg/1360
                                Message 15 of 24 , May 2, 2002
                                  --- In rest-discuss@y..., Lucas Gonze <lucas@g...> wrote:
                                  > Is there anything to accomplish via a BOF at ETCON? IE,
                                  > a convincing agenda?

                                  I posted a few suggestions at
                                  http://www.oreillynet.com/cs/weblog/view/wlg/1360
                                • Lucas Gonze
                                  ... Care to run a BOF on any of the below? Not sure which one Alternative Web Services Architectures is... * Standardization of Web Services *
                                  Message 16 of 24 , May 2, 2002
                                    > I submitted a description for an ETCON BOF called "Alternative Web
                                    > Services Architectures". I don't think that in one or two hours we can
                                    > make huge progress towards understanding each other but it may help to
                                    > hash out a few issues.
                                    >
                                    > Paul Prescod

                                    Care to run a BOF on any of the below? Not sure which one "Alternative
                                    Web Services Architectures" is...

                                    * "Standardization of Web Services"
                                    * "Implementing REST" (a tutorial)
                                    * "Choosing the Right Web Services Design for your
                                    Business."

                                    Question: what issues need to be covered in a tutorial?
                                    Strawmen suggestions:
                                    * gross overgeneralizations taken from The Thesis
                                    * something about URIs
                                    Is there anything to say about this?
                                    * semantic meaning of methods; PUT/POST/GET/DELETE
                                    * resource modeling
                                    define resource and representation
                                    content negotiation
                                    * using status codes aside from 200
                                    * where XML fits in
                                    SOAP as payload format rather than RPC packager

                                    - Lucas
                                  • Sam Ruby
                                    ... FYI (not to imply that you are suggesting otherwise, but I have seen others comment on this) http://www.w3.org/TR/SOAP/#_Toc478383529 - Sam Ruby
                                    Message 17 of 24 , May 2, 2002
                                      Lucas Gonze wrote:
                                      >
                                      > * using status codes aside from 200

                                      FYI (not to imply that you are suggesting otherwise, but I have seen others
                                      comment on this)

                                      http://www.w3.org/TR/SOAP/#_Toc478383529

                                      - Sam Ruby
                                    • S. Mike Dierken
                                      [mailed and posted: http://www.oreillynet.com/cs/weblog/view/cs_msg/7174] I think talking about whether REST applies to long lived conversations would be a
                                      Message 18 of 24 , May 2, 2002
                                        [mailed and posted: http://www.oreillynet.com/cs/weblog/view/cs_msg/7174%5d

                                        I think talking about whether REST applies to long lived conversations would
                                        be a great topic.
                                        There has been discussion about this on the REST forums, but it would be
                                        good to go over it again.
                                        As for HTTP, there is a response code of '202 Accepted' which is used to
                                        indicate that the request is being processed asynchronously - which leads to
                                        the 'five days for a response' situation. What hasn't happened is for a
                                        large number of people to implement a standard approach for sending that
                                        final response message to the sender - but there are lots of ways to do that
                                        (take a look at the REST discussion groups).

                                        Mike



                                        ----- Original Message -----
                                        From: "sa3ruby" <rubys@...>
                                        To: <rest-discuss@yahoogroups.com>
                                        Sent: Thursday, May 02, 2002 6:00 AM
                                        Subject: [rest-discuss] Re: etcon BOF?


                                        > --- In rest-discuss@y..., Lucas Gonze <lucas@g...> wrote:
                                        > > Is there anything to accomplish via a BOF at ETCON? IE,
                                        > > a convincing agenda?
                                        >
                                        > I posted a few suggestions at
                                        > http://www.oreillynet.com/cs/weblog/view/wlg/1360
                                        >
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.