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

Hybrid interface - Advantage of REST?

Expand Messages
  • Taisuke Yamada
    Hi. I ve been following this REST vs. document style SOAP debate (I assume RPC style is dead on both sides), and I m starting to think one of the advantages
    Message 1 of 13 , Apr 23, 2003
    • 0 Attachment
      Hi. I've been following this REST vs. "document style" SOAP
      debate (I assume RPC style is dead on both sides), and I'm
      starting to think one of the advantages of REST is that you
      can actually create a hybrid web service that both human and
      machine can handle.

      Correct me if I'm wrong, but I believe this is difficult with
      SOAP (even with document-style one) unless it gets fully
      RESTified and utilizes URI to locate every resource/service.

      For example, while I was attending Amazon BOF held at O'Reilly
      ETech conf, I was playing with the idea of browser extension
      that keep track of books I have shown interest (i.e. clicked or
      browsed). Okay, I'm not sure how useful is that, but the point is
      that embedded, machine-processible REST interface (probably
      using XHTML+XML?) can be used not only for browsing, but to
      seamlessly enhance my ability to explore information. This is
      difficult if "for-human" WS and "for-machine" WS are separate
      things.

      Can anyone here verify me, or am I missing something?

      --
      Taisuke Yamada <tai@...>
      Internet Initiative Japan Inc., Technical Planning Division
    • Kaleem Aziz
      For clarity my reply is inline. Taisuke Yamada wrote: Hi. I ve been following this REST vs. document style SOAP debate (I assume RPC style is
      Message 2 of 13 , Apr 23, 2003
      • 0 Attachment
        For clarity my reply is inline.

        Taisuke Yamada <tai@...> wrote:


        Hi. I've been following this REST vs. "document style" SOAP
        debate (I assume RPC style is dead on both sides), and I'm
        starting to think one of the advantages of REST is that you
        can actually create a hybrid web service that both human and
        machine can handle.

        Correct me if I'm wrong, but I believe this is difficult with
        SOAP (even with document-style one) unless it gets fully
        RESTified and utilizes URI to locate every resource/service.

        For example, while I was attending Amazon BOF held at O'Reilly
        ETech conf, I was playing with the idea of browser extension
        that keep track of books I have shown interest (i.e. clicked or
        browsed). Okay, I'm not sure how useful is that, but the point is
        that embedded, machine-processible REST interface (probably
        using XHTML+XML?) can be used not only for browsing, but to
        seamlessly enhance my ability to explore information.

        This is
        difficult if "for-human" WS and "for-machine" WS are separate
        things.

        <MKA>

        Here's a partial answer of the partial question I understood. Tell me if that's not the question.

        "for person" WS is similar to B2C (business to consumer). The promise of WS to B2C may come much more in future, because of (1) smaller market segmet, (2) lower utility, and (3) lack of clarity in what it could solve in reality (remember, WS is not fully evolved).

        "for machine" WS is similar to EDI, EAI or B2B (automated or semi-automated to a large extent). The current era we are living in WS (REST vs SOAP), I think, is about this mechanization of internet (aka, Internet ver 2.0).

        So, yes, B2C and B2B are two different needs with two different set of requirements, objectives, concentrations and technological infrastructure. Having saturated B2B solutions in the 3 phases (viz, ROI, Strategy & Expansion phases of WS implementations); may be someday we will step in B2C WS (where your refrigerator orders milk automatically, when it is low on supply?).

        I'd like to hear other thoughts/comments/disagreements.

        </MKA>


        Can anyone here verify me, or am I missing something?

        --
        Taisuke Yamada
        Internet Initiative Japan Inc., Technical Planning Division

        ------------------------ Yahoo! Groups Sponsor ---------------------~-->
        Get 128 Bit SSL Encryption!
        http://us.click.yahoo.com/xaxhjB/hdqFAA/bW3JAA/W6uqlB/TM
        ---------------------------------------------------------------------~->

        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/



        Take care.
        Kaleem.
        "Great minds discuss ideas; lesser minds discuss events; small minds discuss persons."



        Do you Yahoo!?
        The New Yahoo! Search - Faster. Easier. Bingo.
      • Berend de Boer
        ... Taisuke Hi. I ve been following this REST vs. document style Taisuke SOAP debate (I assume RPC style is dead on both sides), Taisuke and I m starting
        Message 3 of 13 , Apr 23, 2003
        • 0 Attachment
          >>>>> "Taisuke" == Taisuke Yamada <tai@...> writes:

          Taisuke> Hi. I've been following this REST vs. "document style"
          Taisuke> SOAP debate (I assume RPC style is dead on both sides),
          Taisuke> and I'm starting to think one of the advantages of REST
          Taisuke> is that you can actually create a hybrid web service that
          Taisuke> both human and machine can handle.

          1. RPC is not dead, REST and SOAP are forms of RPC.

          2. REST is about server holds state is stateless, with SOAP you can do
          that, but its not a dogma.

          3. So REST versus SOAP is a meaningless distinction.

          4. REST is about resources that you can access by an URI. No
          implication that it is better or easier human or machine readable.


          --
          Regards,

          Berend. (-:
        • Nic Ferrier
          ... Yes there is. SOAP is encapsulating it s own protocol in HTTP messages. REST is just using HTTP messages. Nic
          Message 4 of 13 , Apr 23, 2003
          • 0 Attachment
            Berend de Boer <berend@...> writes:

            > 4. REST is about resources that you can access by an URI. No
            > implication that it is better or easier human or machine readable.

            Yes there is. SOAP is encapsulating it's own protocol in HTTP
            messages. REST is just using HTTP messages.


            Nic
          • Roy T. Fielding
            ... He said document style SOAP, which is a reference to the interaction style described in the SOAP 1.2 specs. SOAP 1.1 is RPC. SOAP 1.2 is a bunch of
            Message 5 of 13 , Apr 23, 2003
            • 0 Attachment
              > Taisuke> Hi. I've been following this REST vs. "document style"
              > Taisuke> SOAP debate (I assume RPC style is dead on both sides),
              > Taisuke> and I'm starting to think one of the advantages of REST
              > Taisuke> is that you can actually create a hybrid web service that
              > Taisuke> both human and machine can handle.
              >
              > 1. RPC is not dead, REST and SOAP are forms of RPC.

              He said "document style" SOAP, which is a reference to the interaction
              style described in the SOAP 1.2 specs. SOAP 1.1 is RPC. SOAP 1.2 is
              a bunch of things. REST is not a form of RPC.

              > 2. REST is about server holds state is stateless, with SOAP you can do
              > that, but its not a dogma.

              REST is an architectural style that is only present when all of its
              constraints are met. SOAP is a protocol.

              > 3. So REST versus SOAP is a meaningless distinction.

              Yes, but he wasn't talking about SOAP. He was talking about one of
              the interaction styles described by the SOAP specifications.

              > 4. REST is about resources that you can access by an URI. No
              > implication that it is better or easier human or machine readable.

              Having the URI makes it possible for both human and machine-driven
              interaction. He is right -- that is one of the advantages of REST-style
              applications, and it is used every day in the form of bookmarks.
              However, the document-style interactions in SOAP 1.2 do allow for
              the server to provide a URI, so the advantage only exists over those
              SOAP 1.2 resources that are poorly implemented (i.e., all of them).

              ....Roy
            • Berend de Boer
              ... Roy Yes, but he wasn t talking about SOAP. He was talking about Roy one of the interaction styles described by the SOAP Roy specifications. I really
              Message 6 of 13 , Apr 23, 2003
              • 0 Attachment
                >>>>> "Roy" == Roy T Fielding <fielding@...> writes:

                >> 3. So REST versus SOAP is a meaningless distinction.

                Roy> Yes, but he wasn't talking about SOAP. He was talking about
                Roy> one of the interaction styles described by the SOAP
                Roy> specifications.

                I really didn't understand it then. If I read "interaction style", I
                suppose you refer to Request-Response, Solicit-Response stuff?? Was
                already present in SOAP 1.1.

                Throwing document in the mix, I understood this as the RPC versus
                Document style of message exchange, the particular format of the body
                of a SOAP message. I.e. the style attribute in an WSDL <soap:binding>
                with values "rpc" or "document".

                --
                Regards,

                Berend. (-:
              • Berend de Boer
                ... Nic Yes there is. SOAP is encapsulating it s own protocol in HTTP Nic messages. REST is just using HTTP messages. Is it easier for a machine to extract
                Message 7 of 13 , Apr 23, 2003
                • 0 Attachment
                  >>>>> "Nic" == Nic Ferrier <nferrier@...> writes:

                  Nic> Berend de Boer <berend@...> writes:
                  >> 4. REST is about resources that you can access by an URI. No
                  >> implication that it is better or easier human or machine
                  >> readable.

                  Nic> Yes there is. SOAP is encapsulating it's own protocol in HTTP
                  Nic> messages. REST is just using HTTP messages.

                  Is it easier for a machine to extract information from tag soup or
                  from a SOAP response?

                  --
                  Regards,

                  Berend. (-:
                • Mike Dierken
                  ... From: Berend de Boer ... Although a system based on REST may use RPC to accomplish the job, REST is different from RPC in that it is
                  Message 8 of 13 , Apr 23, 2003
                  • 0 Attachment
                    ----- Original Message -----
                    From: "Berend de Boer" <berend@...>
                    >
                    > 1. RPC is not dead, REST and SOAP are forms of RPC.
                    Although a system based on REST may use RPC to accomplish the job, REST is
                    different from RPC in that it is not an 'extensible procedures' type of
                    approach. In fact, it is the opposite - 'limited set of procedures' is the
                    goal.

                    >
                    > 2. REST is about server holds state is stateless, with SOAP you can do
                    > that, but its not a dogma.
                    I'm not sure I understand the grammar of the sentence, but REST isn't about
                    one side or the other 'holding' state - its about the transfer of whatever
                    state you do have between the components.

                    >
                    > 3. So REST versus SOAP is a meaningless distinction.
                    REST is architecture, SOAP is technology. You can build REST based systems
                    with SOAP. But if everybody builds their own unique (non-interoperable) REST
                    based system, then that aggregate larger system becomes unRESTful.

                    >
                    > 4. REST is about resources that you can access by an URI. No
                    > implication that it is better or easier human or machine readable.
                    REST is about resources you can identify. Using a URI is the Web way of
                    doing things. An RDBMS has another way of identifying resources that does
                    not use URI (to the extent that an RDBMS has aspects of REST). A particular
                    implementation system would use a protocol to actually access the resource.
                    For example, HTTP as a protocol can be used to access resources that are not
                    identified via the 'http' URI scheme.

                    ----example request----
                    GET mailto:mdierken@... HTTP/1.1
                    User-Agent: ThoughtExperiment1.0
                    Accept: text/xml
                    Authorization: BASIC Y7HUH876=


                    ----example response----
                    200 OK
                    Content-Type: text/xml
                    Content-Length: nnnn

                    <folder name='inbox'>
                    <item name='msg_001' href='some long uri' />
                    <item name='msg_002' href='another long uri' />
                    <folder name='work messages' href='relative uri' />
                    </folder>
                  • Taisuke Yamada
                    ... Well, it was more of an thought experiment on how to support user s information activity by utilizing for machine WS, so I did not have specific model
                    Message 9 of 13 , Apr 24, 2003
                    • 0 Attachment
                      >> Hi. I've been following this REST vs. "document style" SOAP
                      >> debate (I assume RPC style is dead on both sides), and I'm
                      >> starting to think one of the advantages of REST is that you can
                      >> actually create a hybrid web service that both human and machine
                      >> can handle.
                      >> [snip]
                      >
                      > Here's a partial answer of the partial question I understood. Tell
                      > me if that's not the question.

                      Well, it was more of an thought experiment on how to support
                      user's information activity by utilizing "for machine" WS, so
                      I did not have specific model like B2C or B2B in my mind.

                      I'm using the word "for-human WS" as the current Web as it is
                      today, and "for-machine WS" as an upcoming part of the Web
                      where machines can do information processing. And I came to
                      think that hybrid, complementary use of these two will result
                      in a synergy that brings better web experience. And from this
                      point of view, RESTfullness of a service does seems to matter,
                      because in this case, "for machine" WS is actually part of
                      existing "for human" WS infrastructure (which is, RESTful).

                      > "for person" WS is similar to B2C (business to consumer). The
                      > promise of WS to B2C may come much more in future, because of (1)
                      > smaller market segmet, (2) lower utility, and (3) lack of clarity in
                      > what it could solve in reality (remember, WS is not fully evolved).
                      >
                      > "for machine" WS is similar to EDI, EAI or B2B (automated or
                      > semi-automated to a large extent). The current era we are living in
                      > WS (REST vs SOAP), I think, is about this mechanization of internet
                      > (aka, Internet ver 2.0).

                      Yes, I agree current WS activity focuses more on B2B-like environment.
                      In such environment, machine-to-machine interoperation is the top
                      priority, and humans are usually not in the scope of the problem.

                      However, I disagree that human/machine hybrid style B2C (I'm not
                      sure if this is anything that we call B2C) has a lower utility.
                      Human is the ultimate target of productivity improvement, and so
                      IMHO this is not anything less useful than B2B thing. But yes, it's
                      probably true that it has smaller market in capitalization value.

                      --
                      Taisuke Yamada <tai@...>
                      Internet Initiative Japan Inc., Technical Planning Division
                    • Taisuke Yamada
                      ... I guess you could also say that REST s uniform interface is a variation of RPC that it has lost all hairs because every REST object is the same thing
                      Message 10 of 13 , Apr 24, 2003
                      • 0 Attachment
                        >> 1. RPC is not dead, REST and SOAP are forms of RPC.
                        >
                        > Although a system based on REST may use RPC to accomplish the job, REST is
                        > different from RPC in that it is not an 'extensible procedures' type of
                        > approach. In fact, it is the opposite - 'limited set of procedures' is the
                        > goal.

                        I guess you could also say that REST's "uniform interface" is a
                        variation of RPC that it has lost "all hairs" because every REST
                        object is the same thing from RPC point of view. Is is still RPC
                        even if you have lost traditional RPC way of "differentiating" one
                        service from another?

                        --
                        Taisuke Yamada <tai@...>
                        Internet Initiative Japan Inc., Technical Planning Division
                      • Kaleem Aziz
                        Thoughts inline at places where I had an opinion ... ... Well, it was more of an thought experiment on how to support user s information activity by utilizing
                        Message 11 of 13 , Apr 24, 2003
                        • 0 Attachment
                          Thoughts inline at places where I had an opinion ...

                          Taisuke Yamada <tai@...> wrote:


                          >> Hi. I've been following this REST vs. "document style" SOAP
                          >> debate (I assume RPC style is dead on both sides), and I'm
                          >> starting to think one of the advantages of REST is that you can
                          >> actually create a hybrid web service that both human and machine
                          >> can handle.
                          >> [snip]
                          >
                          > Here's a partial answer of the partial question I understood. Tell
                          > me if that's not the question.

                          Well, it was more of an thought experiment on how to support
                          user's information activity by utilizing "for machine" WS, so
                          I did not have specific model like B2C or B2B in my mind.

                          I'm using the word "for-human WS" as the current Web as it is
                          today, and "for-machine WS" as an upcoming part of the Web
                          where machines can do information processing. And I came to
                          think that hybrid, complementary use of these two will result
                          in a synergy that brings better web experience. And from this
                          point of view, RESTfullness of a service does seems to matter,
                          because in this case, "for machine" WS is actually part of
                          existing "for human" WS infrastructure (which is, RESTful).

                          <MKA>

                          UI vs Server Side distinction is probably what you are refering to? To that I think everything should be attempted to be automated to the extent that you need a user decision or input. User, IMHO, slows the computers down more than any other thing ... but on the flip side, computers of today cannot decide in adhoc ways like we do (no matter how hybrid). So, computers slow down humans too in that way?! :)

                          </MKA>


                          > "for person" WS is similar to B2C (business to consumer). The
                          > promise of WS to B2C may come much more in future, because of (1)
                          > smaller market segmet, (2) lower utility, and (3) lack of clarity in
                          > what it could solve in reality (remember, WS is not fully evolved).
                          >
                          > "for machine" WS is similar to EDI, EAI or B2B (automated or
                          > semi-automated to a large extent). The current era we are living in
                          > WS (REST vs SOAP), I think, is about this mechanization of internet
                          > (aka, Internet ver 2.0).

                          Yes, I agree current WS activity focuses more on B2B-like environment.
                          In such environment, machine-to-machine interoperation is the top
                          priority, and humans are usually not in the scope of the problem.

                          However, I disagree that human/machine hybrid style B2C (I'm not
                          sure if this is anything that we call B2C) has a lower utility.
                          Human is the ultimate target of productivity improvement, and so
                          IMHO this is not anything less useful than B2B thing. But yes, it's
                          probably true that it has smaller market in capitalization value.

                          <MKA>

                          Lower utility or not is economics of it (hardwork that can be traded). I think you are considering market capital and human utility as two different things; but I think they are not. They are related too closely.

                          Businesses exist for human need, but the distinction between prioritizing B2C vs B2B is that more impact can be made for the same human society at this time by B2B rather than B2C.

                          (If not for economics based priorities, I think, people would breaking rocks in search of milk, and justifying their hardwork as very useful. Where we should put our efforts first and when is beyond technology alone to decide -- unless technology is for art and not for practical solutions.)

                          </MKA>
                          --
                          Taisuke Yamada
                          Internet Initiative Japan Inc., Technical Planning Division

                          ------------------------ Yahoo! Groups Sponsor ---------------------~-->
                          Get 128 Bit SSL Encryption!
                          http://us.click.yahoo.com/W7NydA/hdqFAA/bW3JAA/W6uqlB/TM
                          ---------------------------------------------------------------------~->

                          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/



                          Take care.
                          Kaleem.
                          "Great minds discuss ideas; lesser minds discuss events; small minds discuss persons."



                          Do you Yahoo!?
                          The New Yahoo! Search - Faster. Easier. Bingo.
                        • Alex Jacobson
                          This is a strange debate. REST is a web service architecture (style) not a human interface guideline (AFAIK). REST is the back end for web sites or client side
                          Message 12 of 13 , Apr 29, 2003
                          • 0 Attachment
                            This is a strange debate.
                            REST is a web service architecture (style) not a human interface guideline
                            (AFAIK).

                            REST is the back end for web sites or client side apps that expose user
                            interfaces.

                            Notably, Amazon and Google expose web services distinct from their user
                            interfaces.

                            Writing programs that talk to human interfaces strikes me as risky.

                            -Alex-
                          • Mike Dierken
                            ... From: Alex Jacobson ... I think of it as an automation interface parallel with the visual interface of a web site. Same general data,
                            Message 13 of 13 , Apr 30, 2003
                            • 0 Attachment
                              ----- Original Message -----
                              From: "Alex Jacobson" <alex@...>

                              >
                              > REST is the back end for web sites or client side apps that expose user
                              > interfaces.
                              I think of it as an 'automation' interface parallel with the 'visual'
                              interface of a web site. Same general data, use & purposes but different
                              capabilities.

                              >
                              > Notably, Amazon and Google expose web services distinct from their user
                              interfaces.
                              Distinct & much simpler to program with (at least the REST oriented Amazon
                              ones - I don't think Google makes GET/XML available). They'll get better
                              over time.
                            Your message has been successfully submitted and would be delivered to recipients shortly.