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

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

Expand Messages
  • 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 1 of 24 , May 1, 2002
    • 0 Attachment
      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 2 of 24 , May 1, 2002
      • 0 Attachment
        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 3 of 24 , May 1, 2002
        • 0 Attachment
          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 4 of 24 , May 1, 2002
          • 0 Attachment
            > 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 5 of 24 , May 1, 2002
            • 0 Attachment
              > -----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 6 of 24 , May 1, 2002
              • 0 Attachment
                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 7 of 24 , May 1, 2002
                • 0 Attachment
                  > -----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 8 of 24 , May 1, 2002
                  • 0 Attachment
                    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 9 of 24 , May 1, 2002
                    • 0 Attachment
                      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 10 of 24 , May 1, 2002
                      • 0 Attachment
                        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 11 of 24 , May 1, 2002
                        • 0 Attachment
                          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 12 of 24 , May 1, 2002
                          • 0 Attachment
                            > 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 13 of 24 , May 1, 2002
                            • 0 Attachment
                              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 14 of 24 , May 2, 2002
                              • 0 Attachment
                                --- 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 15 of 24 , May 2, 2002
                                • 0 Attachment
                                  > 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 16 of 24 , May 2, 2002
                                  • 0 Attachment
                                    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 17 of 24 , May 2, 2002
                                    • 0 Attachment
                                      [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.