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

missing REST

Expand Messages
  • elseielstad
    Ok, I haven t made it through the original disertation -- but I ve gone through some of the posts here -- and read up on the wiki -- I think I grok the basics
    Message 1 of 12 , Jan 12, 2005
    • 0 Attachment
      Ok, I haven't made it through the original disertation -- but I've
      gone through some of the posts here -- and read up on the wiki -- I
      think I grok the basics of the REST concepts.

      Am I correct in assuming that, the existing web-browser/web-server
      model are too limited to produce a real REST app -- because there is
      no mechanism available for resources to communicate...

      except through the client --and basic web-browsers don't have any mechanism to handle
      that sort of transaction. ( that's not a bad thing - it just means that you need to
      understand that a "RESTful" client is not a typical web-browser-- but the REST resources
      can be talked to using web-protocols )

      --erik
    • Justin Sampson
      The Web is *the* real REST app . REST is a description of the principles that made the Web architecture so successful, and guidelines for keeping it that way.
      Message 2 of 12 , Jan 12, 2005
      • 0 Attachment
        The Web is *the* "real REST app". REST is a description of the principles
        that made the Web architecture so successful, and guidelines for keeping
        it that way. As we build more and more dynamic Web sites (that is, "Web
        applications" and "Web services") we should keep in mind why the Web works
        in the first place. Too many Web applications and Web services are
        implemented in total ignorance of the architecture of the Web itself,
        resulting in awkward, unscalable systems.

        That's my take on it, anyway.

        Justin


        On Thu, 13 Jan 2005, elseielstad wrote:

        > Ok, I haven't made it through the original disertation -- but I've
        > gone through some of the posts here -- and read up on the wiki -- I
        > think I grok the basics of the REST concepts.
        >
        > Am I correct in assuming that, the existing web-browser/web-server
        > model are too limited to produce a real REST app -- because there is no
        > mechanism available for resources to communicate...
        >
        > except through the client --and basic web-browsers don't have any
        > mechanism to handle that sort of transaction. ( that's not a bad thing
        > - it just means that you need to understand that a "RESTful" client is
        > not a typical web-browser-- but the REST resources can be talked to
        > using web-protocols )
        >
        > --erik
      • Jan Algermissen
        ... Do it! And do it with passion :o) It takes time because it is dense (==value in every sentence), but it pays off very well. ... No, that snot true.
        Message 3 of 12 , Jan 13, 2005
        • 0 Attachment
          elseielstad wrote:

          >
          >
          > Ok, I haven't made it through the original disertation --
          >
          Do it! And do it with passion :o) It takes time because it is dense
          (==value in every sentence), but it pays off very well.

          >but I've
          >gone through some of the posts here -- and read up on the wiki -- I
          >think I grok the basics of the REST concepts.
          >
          > Am I correct in assuming that, the existing web-browser/web-server
          >model are too limited to produce a real REST app -- because there is
          >no mechanism available for resources to communicate...
          >
          >
          No, that'snot true. Resources do not communicate. User agents invoke
          methods on resources and receive hypermedia representations. By
          traversing the links contained in that hypermedia, a user agent proceeds
          through a RESTful application (e.g. a Web search in Google, a purchase
          at Amazon or a ticket in a trouble ticket system.

          The Web is full of RESTful applications.

          >except through the client --and basic web-browsers don't have any mechanism to handle
          >that sort of transaction. ( that's not a bad thing - it just means that you need to
          >understand that a "RESTful" client is not a typical web-browser-- but the REST resources
          >can be talked to using web-protocols )
          >
          >
          The Browser is a perfect REST client.

          Maybe rephrase your question, I feel I am missing something.

          HTH,

          Jan

          > --erik
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >


          --
          Jan Algermissen
          Consultant & Programmer
          http://jalgermissen.com
        • John Coe
          The place that I have found REST most interesting, is in assembiling content from many web source using client side XSL processing, here is a snip that uses
          Message 4 of 12 , Jan 13, 2005
          • 0 Attachment
            The place that I have found REST most interesting, is in assembiling content from many web source using client side XSL processing, here is a snip that uses google's REST interface, the select=document( ) line performs the google search.


            -<!-- Obtain the first 6 items from the search criteria ========================= -->
            - <xsl:template name="six-pack">
            <xsl:param name="search-term" />
            <!-- Build the query string -->
            - <xsl:variable name="google-query-string">
            - <xsl:variable name="base-query">
            - <xsl:call-template name="google-request">
            <xsl:with-param name="search-term" select="$search-term" />
            </xsl:call-template>
            </xsl:variable>
            <xsl:value-of select="concat($base-query, '&maxResults=6')" />
            </xsl:variable>
            <xsl:variable name="google-results" select="document($google-query-string)" />
            - <xsl:for-each select="$google-results//xoomle:item">
            .......
            </xsl:for-each >

            here is my Wiki page that uses REST in this way.

            HTH
            John

            --- On Thu 01/13, Jan Algermissen < jalgermissen@... > wrote:

            From: Jan Algermissen [mailto: jalgermissen@...]
            To: elseielstad@...
            Cc: rest-discuss@yahoogroups.com
            Date: Thu, 13 Jan 2005 10:59:37 +0100
            Subject: Re: [rest-discuss] missing REST

            elseielstad wrote:

            >
            >
            > Ok, I haven't made it through the original disertation --
            >
            Do it! And do it with passion :o) It takes time because it is dense
            (==value in every sentence), but it pays off very well.

            >but I've
            >gone through some of the posts here -- and read up on the wiki -- I
            >think I grok the basics of the REST concepts.
            >
            > Am I correct in assuming that, the existing web-browser/web-server
            >model are too limited to produce a real REST app -- because there is
            >no mechanism available for resources to communicate...
            >
            >
            No, that'snot true. Resources do not communicate. User agents invoke
            methods on resources and receive hypermedia representations. By
            traversing the links contained in that hypermedia, a user agent proceeds
            through a RESTful application (e.g. a Web search in Google, a purchase
            at Amazon or a ticket in a trouble ticket system.

            The Web is full of RESTful applications.

            >except through the client --and basic web-browsers don't have any mechanism to handle
            >that sort of transaction. ( that's not a bad thing - it just means that you need to
            >understand that a "RESTful" client is not a typical web-browser-- but the REST resources
            >can be talked to using web-protocols )
            >
            >
            The Browser is a perfect REST client.

            Maybe rephrase your question, I feel I am missing something.

            HTH,

            Jan

            > --erik
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >


            --
            Jan Algermissen
            Consultant & Programmer
            http://jalgermissen.com




            Join Excite! - http://www.excite.com
            The most personalized portal on the Web!
          • elseielstad
            ... perhaps I m giving the REpresentational State Transfer theory too much credit -- the current http-server/http-client model for doing a GET -- follow
            Message 5 of 12 , Jan 13, 2005
            • 0 Attachment
              > elseielstad wrote:
              > > Am I correct in assuming that, the existing
              > > web-browser/web-server model are too limited
              > > to produce a real REST app -- because there
              > > is no mechanism available for resources to communicate...

              Jan Algermissen <jalgermissen@t...> wrote:
              > Maybe rephrase your question, I feel I am missing something.

              perhaps I'm giving the REpresentational State Transfer theory
              too much credit -- the "current" http-server/http-client model for
              doing a "GET" -- follow links, or fill out a form, "POST", the
              server
              generates a new page...the "application" flows along (blah, blah...)

              but my impression (and this is where I could be giving the whole
              idea too much credit) is that the concept behind the REST model is
              advance web technology by building network "resources" that can
              be used ((and re-used), and linked together) to form distributed
              client
              applications.

              Debating the finer points of human-readable formats versus binary
              API's, or the semantic difference in RFC2616 between a http PUT and
              a POST does not effect people looking to build something truely new.

              I can see some benefit to breaking a web applications into
              resource manipulations -- you're buying a new iPod on a
              commerce-site, and it wants a mailing address -- so your
              client queries your network address-book resource (say,
              http://addresses.yahoo.com/ ) and ships the appropriate
              information to the shipping-address resource on the commerce
              site.

              I don't see how you can make a web-browser talk to distributed
              resources (especially when part of the power of the internet is
              that *I* may use address.yahoo.com, you may use your .mac address
              book -- someone else may have their own apache server at home
              to provide that resource.)

              build me a distributed set of resources (and a client-application
              that can query/integrate the results from each) -- and then you're
              on to something...I want to send a book to my dad, so I type in part
              of the title -- ship that to a search-resource on Amazon,
              get the ISBN number, query my address-book for my dad's mailing
              address...push that to the Barnes and Noble web-site order
              resource...plug in my credit card number and BOOM
              -- sale pending.

              --erik
            • Jan Algermissen
              ... Hmm...I don t understand what you are up to here. What do you mean by talk to distributed resources ? ... Besides the question wheather your address book
              Message 6 of 12 , Jan 14, 2005
              • 0 Attachment
                elseielstad wrote:

                > I don't see how you can make a web-browser talk to distributed
                >
                >resources (especially when part of the power of the internet is
                >that *I* may use address.yahoo.com, you may use your .mac address
                >book -- someone else may have their own apache server at home
                >to provide that resource.)
                >
                >
                Hmm...I don't understand what you are up to here. What do you mean by
                'talk to distributed resources'?

                > build me a distributed set of resources (and a client-application
                >that can query/integrate the results from each) -- and then you're
                >on to something...I want to send a book to my dad, so I type in part
                >of the title -- ship that to a search-resource on Amazon,
                >get the ISBN number, query my address-book for my dad's mailing
                >address...push that to the Barnes and Noble web-site order
                >resource...plug in my credit card number and BOOM
                >-- sale pending.
                >
                >
                Besides the question wheather your address book is on the Web or not
                (could do this in a bunch of ways) all of what you request can be done
                easily with any scripting labguage that provides an HTTP implementation.
                It is actually one of the easiest use cases, because it does not involve
                the need for any form of transaction (there is only one order-request at
                the end). Given JavaScrips's emerging capability to issue arbitrary HTTP
                requests, the whole flow could also be done as a JS function (that's
                propably worthwhile investigating).

                Hmm....using RDF (or Topic Maps) as an integration data model you could
                propably fill in an HTML form and hit an 'order' button that will
                triggger the following JS functionality: read title form field and send
                to Amazon to get ISBN -> read 'receiver name' field and go to your
                address book to find address -> integrate both answers (using RDF) and
                export as B&N's accepted MIME type for POSTing the order. GET on the 201
                order-URI response header of the POST and fill in your credit card
                number in the received form. POST back to B&N and do an additional
                MONITOR on the order URI, supplying your email address as the
                notification target.

                Makes sense?

                Jan

                > --erik
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >
                >
                >
                >


                --
                Jan Algermissen
                Consultant & Programmer
                http://jalgermissen.com
              • Jan Algermissen
                ... In addition, it would be interesting to show that/how REST reduces the need to know about the specific semantics of the interaction up front. That is: how
                Message 7 of 12 , Jan 14, 2005
                • 0 Attachment
                  Jan Algermissen wrote:

                  > Hmm....using RDF (or Topic Maps) as an integration data model you could
                  >
                  >propably fill in an HTML form and hit an 'order' button that will
                  >triggger the following JS functionality: read title form field and send
                  >to Amazon to get ISBN -> read 'receiver name' field and go to your
                  >address book to find address -> integrate both answers (using RDF) and
                  >export as B&N's accepted MIME type for POSTing the order. GET on the 201
                  >order-URI response header of the POST and fill in your credit card
                  >number in the received form. POST back to B&N and do an additional
                  >MONITOR on the order URI, supplying your email address as the
                  >notification target.
                  >
                  >Makes sense?
                  >
                  >
                  In addition, it would be interesting to show that/how REST reduces the
                  need to know about the specific semantics of the interaction up front.
                  That is: how can a script as the one above decide how to step through
                  the application at runtime (by traversing links) without knowing
                  everything about the involved steps up-front. With an RPC style
                  approach, the components would not be able to *talk* to each other at
                  all, but it needs to be demonstrated how 'moving the semantics from the
                  API to the message format' solves this problem. Hmm...

                  Jan

                  >Jan
                  >
                  >
                  >
                  >> --erik
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>Yahoo! Groups Links
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >>
                  >
                  >
                  >
                  >


                  --
                  Jan Algermissen
                  Consultant & Programmer
                  http://jalgermissen.com
                • Jan Algermissen
                  ... Autsch....forgot about JS s security issue: no cross site scripting..... Seems one needs a server-based app for that sort of integration. Jan -- Jan
                  Message 8 of 12 , Jan 14, 2005
                  • 0 Attachment
                    Jan Algermissen wrote:

                    > Given JavaScrips's emerging capability to issue arbitrary HTTP
                    >requests, the whole flow could also be done as a JS function (that's
                    >propably worthwhile investigating).
                    >
                    >

                    Autsch....forgot about JS's security issue: no cross site scripting.....

                    Seems one needs a server-based app for that sort of integration.

                    Jan


                    --
                    Jan Algermissen
                    Consultant & Programmer
                    http://jalgermissen.com
                  • elseielstad
                    ... [ to which I added - to do a good RESTful apps we may need a better client platform ] ... the premise behind all the REST discussions revolve around
                    Message 9 of 12 , Jan 14, 2005
                    • 0 Attachment
                      > elseielstad wrote:
                      > > I don't see how you can make a web-browser talk
                      > > to distributed resources
                      [ to which I added - to do a good RESTful apps we may
                      need a better client platform ]

                      Jan Algermissen <jalgermissen@t...> replied:
                      > Hmm...I don't understand what you are up to here. What do
                      > you mean by 'talk to distributed resources'?

                      the premise behind all the REST discussions revolve around
                      dealing with "resources" (which should be nouns) using a small
                      set of methods (get, put, post, delete), instead of
                      hap-hazard forms submitted to random cgi or servlets...( and I am
                      to think of resources and not services...)

                      I then tried a pie-in-the-sky example:

                      > > build me a distributed set of resources (and a client-application
                      > >that can query/integrate the results from each) -- and then you're
                      > >on to something...I want to send a book to my dad, so I type in part
                      > >of the title -- ship that to a search-resource on Amazon,
                      > >get the ISBN number, query my address-book for my dad's mailing
                      > >address...push that to the Barnes and Noble web-site order
                      > >resource...plug in my credit card number and BOOM
                      > >-- sale pending.

                      If I scale-back the ambition -- I still see problems with
                      using the web-browser...the REST-process would be something like:

                      1. GET the B&N order resource http://www.bn.com/order
                      [ I get back a list of things I need -- say it provides an order number (say o99)
                      (which I can use to PUT my result), I need a "bill-to" address,
                      a "ship-to" address, and a list of items I would like to purchase ]

                      2. GET the B&N address resource http://www.bn.com/address
                      [ I get back a unique address ID number (say a10) (for when I PUT the resource)
                      and a list of things I need (address, city, state, zip-code...blah blah) ]

                      3. PUT my bill-to address back to B&N http://www.bn.com/address/a10
                      [ hopefully I get back a 201 (created) ... ] (note -- I need to keep this
                      ID on my client (somewhere) to plug in when I PUT my order) ]

                      4. GET the B&N address resource http://www.bn.com/address
                      [ to get my UID for the shipping address ... ( say a22 ) -- I need to keep
                      this ID somewhere on the client...for when I PUT my order ]

                      5. GET the B&N catalog resource http://www.bn.com/catalog
                      [ and I'll assume there is some easy way to pick what I want ]

                      6. [magically take the collection of resource-identifiers and build the
                      order form ] then PUT http://www.bn.com/order/o10


                      now, keeping each of the Unique identifiers on the client between
                      interactions with each resource may be an issue using existing
                      web-browsers ( I suppose you could use cookies...)

                      I suppose you could have a state-machine on the server
                      that walks the user through each if these steps -- but if you do
                      that I'm not sure where the REST architecture is any better than
                      building a complicated "POST" form.

                      --erik
                      [disclaimer: I am not affiliated with any of the multi-billion dollar
                      corporations which I use in my examples ]
                    • elseielstad
                      ... I d like to see that as well -- I just am not sure how that would work. ... that s the part I m still missing -- if I talk to an address resource and an
                      Message 10 of 12 , Jan 14, 2005
                      • 0 Attachment
                        > Jan Algermissen wrote:
                        > In addition, it would be interesting to show that/how REST reduces the
                        > need to know about the specific semantics of the interaction up front.

                        I'd like to see that as well -- I just am not sure how that would work.

                        > That is: how can a script as the one above decide how to step through
                        > the application at runtime (by traversing links) without knowing
                        > everything about the involved steps up-front.

                        that's the part I'm still missing -- if I talk to an "address" resource
                        and an "order" resource..when I get behind the scenes -- all that
                        data has to verified and linked back together. (when I submit an
                        order -- how does my order resource know that the
                        address-resources I submitted are valid?)

                        > an RPC style approach, the components would not be able
                        > to *talk* to each other at all,

                        I'm not sure I would say that -- you may need to say that developers
                        would need to understand the RPC API's for the given protocol, and build
                        it into a client...X11, nettrek, doom, and probably even the P2P clients
                        all demonstrate you can build traditional client-server applications using
                        RPC.

                        just because you're communicating in plain-text.. your resources still
                        need to know that a specific tag is refering to the zip-code ( which will make
                        interacting with differenent resources more challenging. )

                        but I digress... I like the idea of distributed resources...I'm even OK with
                        building a better client to make it happen...but I wanted to make sure I'm
                        not completely out in left field.

                        --erik
                      • Lucas Gonze
                        ... The trick is that you model interactions differently in a RESTful design. You have to learn to collapse the state into a single URI which expresses
                        Message 11 of 12 , Jan 14, 2005
                        • 0 Attachment
                          On Sat, 15 Jan 2005, elseielstad wrote:
                          > now, keeping each of the Unique identifiers on the client between
                          > interactions with each resource may be an issue using existing
                          > web-browsers ( I suppose you could use cookies...)

                          The trick is that you model interactions differently in a RESTful design.
                          You have to learn to collapse the state into a single URI which expresses
                          everything a resource needs to generate a representation. (modulo HTTP
                          headers used for things like content type negotiation).

                          - Lucas
                        • Jan Algermissen
                          ... Mostly through standardisation of the message type (MIME type). When you use RDF, you enter the wonderful world of partial understanding: Although a user
                          Message 12 of 12 , Jan 15, 2005
                          • 0 Attachment
                            elseielstad wrote:

                            >
                            >
                            >
                            >>Jan Algermissen wrote:
                            >>In addition, it would be interesting to show that/how REST reduces the
                            >>need to know about the specific semantics of the interaction up front.
                            >>
                            >>
                            >
                            > I'd like to see that as well -- I just am not sure how that would work.
                            >
                            >
                            Mostly through standardisation of the message type (MIME type). When you
                            use RDF, you enter the wonderful world of partial understanding:
                            Although a user agent or intermediary might not understand *all* RDF
                            schemas used in an RDF message, it can still use the statements that it
                            *does* understand.


                            >>That is: how can a script as the one above decide how to step through
                            >>the application at runtime (by traversing links) without knowing
                            >>everything about the involved steps up-front.
                            >>
                            >>
                            >
                            > that's the part I'm still missing -- if I talk to an "address" resource
                            >and an "order" resource..when I get behind the scenes -- all that
                            >data has to verified and linked back together. (when I submit an
                            >order -- how does my order resource know that the
                            >address-resources I submitted are valid?)
                            >
                            >

                            What do you mean by 'valid' here? Valid in terms of a DTD/schema?

                            >
                            >
                            >>an RPC style approach, the components would not be able
                            >>to *talk* to each other at all,
                            >>
                            >>
                            >
                            > I'm not sure I would say that --
                            >
                            >you may need to say that developers
                            >would need to understand the RPC API's for the given protocol, and build
                            >it into a client...X11, nettrek, doom, and probably even the P2P clients
                            >all demonstrate you can build traditional client-server applications using
                            >RPC.
                            >
                            >
                            Yes, but you have to *know* *all* the APIs up front, otherwise you
                            cannot build the apps. OTH, if you use a uniform API, your apps can
                            allways communicate (e.g. to negotiate a representation type they
                            both understand - see HTTP content negitiation).

                            > just because you're communicating in plain-text..
                            >
                            But REST is not about communicating in plain text (text/plain?) it is
                            about making the message type explicit (Content-Type HTTP header).

                            >your resources still
                            >need to know that a specific tag is refering to the zip-code ( which will make
                            >interacting with differenent resources more challenging. )
                            >
                            >
                            Challanging - sure, but if I use RDF and use a
                            standardized/well-known/company-wide schema for the ZIP property,
                            all/most of the apps can at least see it is a ZIP, even if they do not
                            understand the rest of the message. To me this is a whole lot better
                            than not being able to engage in a conversation at all because the RPC
                            APIs are not equal, e.g. getStockQuote("IBM") vs getStockQuoteIBM().


                            > but I digress... I like the idea of distributed resources...I'm even
                            OK with

                            >building a better client to make it happen...but I wanted to make sure I'm
                            >not completely out in left field.
                            >
                            >
                            Make sure you look at Mark Baker's work regarding RDFForms and Resource
                            State:

                            http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt
                            http://www.markbaker.ca/2003/05/RDF-Forms/

                            Jan

                            > --erik
                            >
                            >
                            >
                            >
                            >
                            >
                            >Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >


                            --
                            Jan Algermissen
                            Consultant & Programmer
                            http://jalgermissen.com
                          Your message has been successfully submitted and would be delivered to recipients shortly.