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

Re: [rest-discuss] Re: RESTful shopping basket

Expand Messages
  • Mark Baker
    ... There are cases when you d want this, for example when the shopping basket did things very specific to the app. But generally, I don t think that shopping
    Message 1 of 26 , Jun 4, 2002
      On Tue, Jun 04, 2002 at 10:39:30AM -0400, bhaugen32 wrote:
      > Mark Baker wrote:
      > > So if you wanted to do a shopping basket statelessly, it's up to the
      > > client to manage that the state of the basket, submitting a
      > > representation of the basket to the server when it wants to
      > checkout.
      >
      > Why couldn't the shopping basket be kept on the server, with a
      > customer-specific URI? Why is it any different than an uncommitted
      > order? The order gets a URI on the server.
      >
      > I'm not saying you would always want to do it that way - given the
      > percentage of abandoned shopping baskets - but wouldn't be a RESTful
      > alternative?

      There are cases when you'd want this, for example when the shopping
      basket did things very specific to the app. But generally, I don't
      think that shopping baskets do very much at all, and could be
      generalized to some dumb client-side container in which the
      representations of the things you want are placed.

      MB
      --
      Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
      Ottawa, Ontario, CANADA. distobj@...
      http://www.markbaker.ca http://www.idokorro.com
    • Chuck Hinson
      ... I ve been struggling with authentication/authorization and how to fit it into the REST model... I m probably confusing several issues (and I m probably
      Message 2 of 26 , Jun 4, 2002
        Allan Doyle wrote:
        >
        > Cookies are out of band as far as REST is concerned, and are
        > downright anti-REST because you will probably never see the cookie
        > contents but those contents are responsible for a ton of information
        > transfer between client and server. If you moved the cookie info to a
        > URI-accessible location, then it would be RESTful. A big issue with
        > current practice (not with HTTP or REST) is that usually clients don't
        > have HTTP servers running in them or on their behalf so the server
        > can't get at client-side state with a simple GET. (c.f. the
        > "client-side shopping basket" statement above). This asymmetry also
        > impacts the ability to do decent asynchronous callbacks from the
        > server to the client.
        >

        I've been struggling with authentication/authorization and how to fit it
        into the REST model...

        I'm probably confusing several issues (and I'm probably unaware of others),
        but it seems very difficult to provide authentication and authorization
        without cookies or some similar mechanism - and I'm not sure I see a
        solution that doesn't just shift the problem (state-hiding) somewhere else.

        In all the examples I've seen, the resources are assumed to be publicly
        accessible. In the example above, the suggestion is to move the hidden
        state stored in a cookie to a URI-accessible location. However, once I've
        done that, I would think that I am then obliged to ensure that only the user
        who owns that information is able to retrieve it. How do I do that if I
        cant also issue the user a token (cookie) that they can then use as proof of
        identity?

        My first thoughts were that you could use HTTPS with client certs to provide
        identity, but it seems that you've only shifted the problem around. Instead
        of providing proof of identity with a cookie, your providing it with a
        certificate. Or maybe using a cookie for authentication doesnt violate the
        no-hidden-state rule.

        --Chuck
      • Mark Baker
        ... It s already there, with HTTP authentication. A 401 response to a HTTP request tells the client to provide a header with the authentication info, next time
        Message 3 of 26 , Jun 4, 2002
          On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote:
          > I've been struggling with authentication/authorization and how to fit it
          > into the REST model...

          It's already there, with HTTP authentication.

          A 401 response to a HTTP request tells the client to provide a header
          with the authentication info, next time it does that request. On
          subsequent requests, that header is always included, making the
          interaction stateless.

          MB
          --
          Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
          Ottawa, Ontario, CANADA. distobj@...
          http://www.markbaker.ca http://www.idokorro.com
        • Bill de h├ôra
          ... Hash: SHA1 ... He wants you to store the basket details on the client using URIs to manage the representations. The cost is coordinating client and server
          Message 4 of 26 , Jun 4, 2002
            -----BEGIN PGP SIGNED MESSAGE-----
            Hash: SHA1


            > -----Original Message-----
            > From: Roger L. Costello [mailto:costello@...]
            > Sent: 04 June 2002 13:29
            > To: rest-discuss@yahoogroups.com; costello@...
            > Subject: [rest-discuss] Cookies not RESTful - need explaination
            >
            >
            > Hi Folks,
            >
            > Below is an except from Fielding's REST dissertation,
            > describing why cookies are not RESTful. Can someone explain
            > what he is saying here?
            >
            > "Likewise, the use of cookies to identify a user-specific
            > 'shopping basket' within a server-side database could be more
            > efficiently implemented by defining the semantics of shopping
            > items within the hypermedia data formats, allowing the user
            > agent to select and store those items within their own
            > client-side shopping basket, complete with a URI to be used
            > for check-out when the client is ready to purchase."

            He wants you to store the basket details on the client using URIs
            to manage the representations. The cost is coordinating client and
            server software. I imagine that cost would less if the client could
            also act as a server, i.e. you could get at the basket using HTTP
            methods. It would be efficient insofar as you'd stop routing around
            your local CPU to do processing on the server's. Cookies may not be
            restful, but the more appealing argument to some might be that they
            could throw away their enterprise class web server infrastructure,
            load balancers et al and apportion some of the costs to the client.
            I haven't heard an argument for rest based on reducing server side
            costs, it would be an interesting one.

            Bill



            -----BEGIN PGP SIGNATURE-----
            Version: PGP 7.0.4

            iQA/AwUBPPzvUuaWiFwg2CH4EQLwzwCgiY4ZxB7zVXpORPRBiKWcumiFUd4AoJl4
            7IZp/H7jS9Ne4clLuCChzSB8
            =C8E3
            -----END PGP SIGNATURE-----
          • S. Mike Dierken
            ... From: Mark Baker ... I m confused - a cookie is part of the HTTP message, both request and response. The client can read and write them
            Message 5 of 26 , Jun 4, 2002
              ----- Original Message -----
              From: "Mark Baker" <distobj@...>
              >
              > You know that cookies are stateful, right? That is, they make it so
              > that there isn't enough information in the HTTP message to understand
              > what it does, because it depends on the information represented by
              > the cookie which is invisible to everybody but the server.
              I'm confused - a cookie is part of the HTTP message, both request and
              response.
              The client can read and write them and so can the server.
              And anyway, combining information from the request and server-only state
              isn't a bad thing - security permissions, etc. do this all the time.

              The problem I have is that they are often used to qualify the URI - for
              example
              http://my.example.org/startpage.asp is the same URI for everyone, but the
              page - the 'actual' resource - is different based on the value of the
              cookie. This makes the sample URI unsharable, uncacheable, etc. - which is
              good or bad depending on what you are trying to do.
              They are also often used to identify the user, or at least a user's
              server-side session.
            • S. Mike Dierken
              ... From: Chuck Hinson ... The examples I write have the assumption that permissions exist on the server for the resources. Any message
              Message 6 of 26 , Jun 4, 2002
                ----- Original Message -----
                From: "Chuck Hinson" <hinson@...>

                >
                > In all the examples I've seen, the resources are assumed to be publicly
                > accessible.
                The examples I write have the assumption that permissions exist on the
                server for the resources.
                Any message that has a cookie in it can be captured and re-played with the
                cookie intact, so the message itself is just as 'public' as the URI only.

                > In the example above, the suggestion is to move the hidden
                > state stored in a cookie to a URI-accessible location.
                I wouldn't call it 'state' that is in the cookie, the data usually is used
                as values for lookup on the server side.

                > However, once I've
                > done that, I would think that I am then obliged to ensure that only the
                user
                > who owns that information is able to retrieve it.
                Yes, that would be a good thing.

                > How do I do that if I cant also issue the user a token (cookie)
                > that they can then use as proof of identity?
                This token isn't proof of identity. It can be captured, copied, and replayed
                elsewhere. Cookie based approaches are just breaking the URI into two pieces
                and hoping that the Bad Guys don't capture both pieces. Since that is not
                doable, people make one piece very transient, which only reduces the window
                of opportunity.
                Now that I think about it, using HTTPS would minimize the chance that other
                people will find the cookie.

                >
                > My first thoughts were that you could use HTTPS with client certs to
                provide
                > identity, but it seems that you've only shifted the problem around.
                Instead
                > of providing proof of identity with a cookie, your providing it with a
                > certificate. Or maybe using a cookie for authentication doesnt violate
                the
                > no-hidden-state rule.
                >
                I think there is an interesting design question here regarding coordination
                costs of establishing trust:
                - server provides tokens for identity
                - client provides tokens for identity

                I'll have to think about this for a while.
              • Chuck Hinson
                ... Hmm. I guess I already knew that. However, the lack of support by browsers for anything other than Basic Auth pretty much eliminates the Authorization
                Message 7 of 26 , Jun 4, 2002
                  Mark Baker wrote:
                  > On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote:
                  >
                  >>I've been struggling with authentication/authorization and how to fit it
                  >>into the REST model...
                  >
                  >
                  > It's already there, with HTTP authentication.
                  >
                  > A 401 response to a HTTP request tells the client to provide a header
                  > with the authentication info, next time it does that request. On
                  > subsequent requests, that header is always included, making the
                  > interaction stateless.
                  >

                  Hmm. I guess I already knew that. However, the lack of support by browsers
                  for anything other than Basic Auth pretty much eliminates the Authorization
                  header as a solution today. (Once again, reality interferes...)

                  Given that, it would seem that using a cookie for authentication is a
                  reasonable alternative -- the spec say use the Authorization header;
                  browsers and servers dont support that very well, so I'll use a header that
                  they do support and that happens to be a cookie.

                  --Chuck


                  > MB
                • Mark Baker
                  ... Yes, but the information necessary to understand what a message with a cookie means, is not part of the message. GET /foo HTTP/1.1 has one meaning for all
                  Message 8 of 26 , Jun 4, 2002
                    On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote:
                    > I'm confused - a cookie is part of the HTTP message, both request and
                    > response.

                    Yes, but the information necessary to understand what a message with
                    a cookie means, is not part of the message.

                    GET /foo HTTP/1.1

                    has one meaning for all time, which you can lookup in RFC 2616.

                    GET /foo HTTP/1.1
                    Cookie: bar=goo

                    can have many meanings depending upon what magic that cookie induces
                    in the behaviour of the server. You can't look up what it means
                    anywhere.

                    > The problem I have is that they are often used to qualify the URI - for
                    > example
                    > http://my.example.org/startpage.asp is the same URI for everyone, but
                    > the
                    > page - the 'actual' resource - is different based on the value of the
                    > cookie. This makes the sample URI unsharable, uncacheable, etc. - which
                    > is
                    > good or bad depending on what you are trying to do.
                    > They are also often used to identify the user, or at least a user's
                    > server-side session.

                    Right, that's a special case of the problem I described above; if you
                    allow a message's meaning to change (be it the identified-resource, the
                    authorization info, etc..) depending upon information not in the message
                    itself, then you can very easily do the Wrong Thing.

                    MB
                    --
                    Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                    Ottawa, Ontario, CANADA. distobj@...
                    http://www.markbaker.ca http://www.idokorro.com
                  • Paul Prescod
                    ... I think you mean information in the message or *REFERENCED* by the message through a derferencerable URI. Am I right? For instance it is not wrong for a
                    Message 9 of 26 , Jun 4, 2002
                      Mark Baker wrote:
                      >
                      >...
                      >
                      > Right, that's a special case of the problem I described above; if you
                      > allow a message's meaning to change (be it the identified-resource, the
                      > authorization info, etc..) depending upon information not in the message
                      > itself, then you can very easily do the Wrong Thing.

                      I think you mean "information in the message or *REFERENCED* by the
                      message through a derferencerable URI." Am I right? For instance it is
                      not wrong for a "purchase now" message to point to a shopping cart URI.
                      As long as the two do not change you could understand that message a
                      hundred years from now on a totally different device.

                      Paul Prescod
                    • Mark Baker
                      ... No, in the message itself. If the meaning of the message depends on information you get from dereferencing a URI (or anything else outside the message),
                      Message 10 of 26 , Jun 4, 2002
                        On Tue, Jun 04, 2002 at 02:47:41PM -0700, Paul Prescod wrote:
                        > > Right, that's a special case of the problem I described above; if you
                        > > allow a message's meaning to change (be it the identified-resource, the
                        > > authorization info, etc..) depending upon information not in the message
                        > > itself, then you can very easily do the Wrong Thing.
                        >
                        > I think you mean "information in the message or *REFERENCED* by the
                        > message through a derferencerable URI." Am I right?

                        No, in the message itself. If the meaning of the message depends
                        on information you get from dereferencing a URI (or anything else
                        outside the message), then it is stateful.

                        > For instance it is
                        > not wrong for a "purchase now" message to point to a shopping cart URI.
                        > As long as the two do not change you could understand that message a
                        > hundred years from now on a totally different device.

                        Right, because the meaning of "purchase this shopping cart now" doesn't
                        depend on what you get by dereferencing the shopping cart URI.

                        MB
                        --
                        Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                        Ottawa, Ontario, CANADA. distobj@...
                        http://www.markbaker.ca http://www.idokorro.com
                      • Roger L. Costello
                        ... Let me see if I understand what you are saying Mark: if the HTTP header contains information (e.g., cookie information) that is used by the server
                        Message 11 of 26 , Jun 4, 2002
                          Mark Baker wrote:
                          >
                          > On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote:
                          > > I'm confused - a cookie is part of the HTTP message, both request and
                          > > response.
                          >
                          > Yes, but the information necessary to understand what a message with
                          > a cookie means, is not part of the message.
                          >
                          > GET /foo HTTP/1.1
                          >
                          > has one meaning for all time, which you can lookup in RFC 2616.
                          >
                          > GET /foo HTTP/1.1
                          > Cookie: bar=goo
                          >
                          > can have many meanings depending upon what magic that cookie induces
                          > in the behaviour of the server. You can't look up what it means
                          > anywhere.

                          Let me see if I understand what you are saying Mark: if the HTTP header
                          contains information (e.g., cookie information) that is used by the
                          server application then that is not RESTful. However, if we were to
                          move the (e.g., cookie) information into the HTTP message body, then it
                          would be RESTful. Is that it? That doesn't seem reasonable since the
                          HTTP header contains a lot of information that a server application will
                          typically use, such as the content type that the client will accept
                          (e.g., text/html), and many other things. These HTTP headers induces
                          behaviour in the server application. Taking this argument to its
                          logical conclusion, then I conclude that no HTTP message can ever be
                          RESTful, unless it has no HTTP headers, since HTTP headers by their very
                          nature induces behaviour in the server application. Yes?

                          To restate my earlier question: what exactly does it mean to be
                          stateless? In light of the above, does it mean that all information is
                          carried in the HTTP message body? That is, the server application's
                          behaviour is not influenced by anything in the HTTP header?

                          Sorry to be so dense on this. However, I feel that it is a critical
                          issue that I want to make certain I fully understand as I go out into
                          the world to preach the merits of REST. /Roger
                        • S. Mike Dierken
                          ... From: Chuck Hinson ... browsers ... Authorization ... The systems I m envisioning go way beyond the browser - and then the full
                          Message 12 of 26 , Jun 4, 2002
                            ----- Original Message -----
                            From: "Chuck Hinson" <hinson@...>

                            >
                            > Hmm. I guess I already knew that. However, the lack of support by
                            browsers
                            > for anything other than Basic Auth pretty much eliminates the
                            Authorization
                            > header as a solution today. (Once again, reality interferes...)
                            The systems I'm envisioning go way beyond the browser - and then the full
                            potential of HTTP is available. Build a different user agent, or if you
                            really must, use components that do provide full HTTP access
                            (IXMLHTTPRequest in IE and others).

                            >
                            > Given that, it would seem that using a cookie for authentication is a
                            > reasonable alternative -- the spec say use the Authorization header;
                            > browsers and servers dont support that very well, so I'll use a header
                            that
                            > they do support and that happens to be a cookie.
                            It isn't reasonable, but there is little alternative. I'm amazed the browser
                            world has gone this long without extending FORM to support users entering
                            credentials.
                            A big reason sites use FORMs is to control the UI. It shouldn't be a big
                            deal to for FORM to specify that it is user input for credentials at the
                            specified URI.
                          • Mark Baker
                            ... No ... ... Hmm, no. By message , I mean the entire HTTP message; request line, headers, and body. Think about taking an HTTP message, and storing it to
                            Message 13 of 26 , Jun 4, 2002
                              On Tue, Jun 04, 2002 at 07:16:47PM -0400, Roger L. Costello wrote:
                              > Let me see if I understand what you are saying Mark: if the HTTP header
                              > contains information (e.g., cookie information) that is used by the
                              > server application then that is not RESTful.

                              No ...

                              > However, if we were to
                              > move the (e.g., cookie) information into the HTTP message body, then it
                              > would be RESTful. Is that it?

                              Hmm, no. By "message", I mean the entire HTTP message; request line,
                              headers, and body.

                              Think about taking an HTTP message, and storing it to disk for 20
                              years. When you "reconstitute" it at that time, will people still
                              know what it means? If it used cookies, they won't, because some
                              information necessary to understanding it was on the server, and it
                              expired years ago.

                              Compare it to FTP, if that helps. If I pickle the (logical) command
                              "RETR foo.zip" to disk, and reconstitute it 10 minutes later, nobody
                              will know what it means because they don't know what the current
                              directory is, and hence which foo.zip to retrieve. FTP is a stateful
                              protocol.

                              > Sorry to be so dense on this. However, I feel that it is a critical
                              > issue that I want to make certain I fully understand as I go out into
                              > the world to preach the merits of REST. /Roger

                              It's definitely a critical issue, as statelessness is so key to
                              visibility and reliability.

                              MB
                              --
                              Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                              Ottawa, Ontario, CANADA. distobj@...
                              http://www.markbaker.ca http://www.idokorro.com
                            • Seth Ladd
                              Some thoughts... ... An HTTP message can certainly be RESTful. You can accomplish this by correctly using a URI to reference a real, true object. The headers
                              Message 14 of 26 , Jun 5, 2002
                                Some thoughts...


                                > behaviour in the server application. Taking this argument to its
                                > logical conclusion, then I conclude that no HTTP message can ever be
                                > RESTful, unless it has no HTTP headers, since HTTP headers by their very
                                > nature induces behaviour in the server application. Yes?


                                An HTTP message can certainly be RESTful. You can accomplish this by
                                correctly using a URI to reference a real, true object. The headers can
                                still be there, and are very helpful as metadata and instructions on how
                                to handle the message itself.

                                For instance, REST likes to transfer state of objects. But, some
                                objects can be represented many different ways. For example, a daily
                                report can be represented as a PDF, HTML, XML, etc. That's just the
                                physical form. The logical object itself is the same. Now, this object
                                might have a URI of http://example.org/finance/report/2002/06/05. Using
                                that URI, I can GET and SET that report throughout time and space. But
                                how do I know what I'm getting? HTTP is the protocol we're using, so
                                HTTP headers are introduced. Think of the headers like the envolope.
                                They tell us more info about the resource. That info isn't needed to
                                identify the object (that's done with the URI). So the HTTP header will
                                say "Content-type: application/pdf" to indicate what bytes are being
                                sent. This doesn't violate REST (IMO) since we haven't obfuscated the
                                object identifier.


                                > To restate my earlier question: what exactly does it mean to be
                                > stateless? In light of the above, does it mean that all information is
                                > carried in the HTTP message body? That is, the server application's
                                > behaviour is not influenced by anything in the HTTP header?

                                It might help for your understanding of REST to divorce yourself from
                                HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used
                                for an implementation of REST, but isn't the perfect embodiment of REST.

                                To be stateless means to carry all information needed for the request
                                along with the request. That request must be able to stand alone. If
                                the process requires three messages in a certain order, each depending
                                on the first one, that is not stateless.

                                Hope I didn't confuse things more. :)

                                Seth
                              • Philip Eskelin
                                [snip] ... For obvious reasons, any mention of the word envelope in RESTful discussions makes me shudder....gives me nightmares where employees from
                                Message 15 of 26 , Jun 5, 2002
                                  [snip]
                                  Seth wrote:
                                  > HTTP headers are introduced. Think of the headers like the envolope.

                                  For obvious reasons, any mention of the word "envelope" in RESTful discussions
                                  makes me shudder....gives me nightmares where employees from Microsoft and IBM
                                  force-feed me bars of soap until I wake up in a cold sweat ;-)

                                  -Philip
                                • Seth Ladd
                                  ... Yeah, except SOAP can be used to communicate a RESTful protocol. It s all about how you use the transport mechanism. Seth
                                  Message 16 of 26 , Jun 5, 2002
                                    Philip Eskelin wrote:
                                    > [snip]
                                    > Seth wrote:
                                    >
                                    >>HTTP headers are introduced. Think of the headers like the envolope.
                                    >
                                    >
                                    > For obvious reasons, any mention of the word "envelope" in RESTful discussions
                                    > makes me shudder....gives me nightmares where employees from Microsoft and IBM
                                    > force-feed me bars of soap until I wake up in a cold sweat ;-)

                                    Yeah, except SOAP can be used to communicate a RESTful protocol. It's
                                    all about how you use the transport mechanism.

                                    Seth
                                  • Philip Eskelin
                                    ... discussions ... IBM ... I ve always thought it would be interesting if someone sponsored a tunneling contest to see who can tunnel the most protocols in
                                    Message 17 of 26 , Jun 5, 2002
                                      Seth wrote:
                                      > Philip Eskelin wrote:
                                      > > [snip]
                                      > > Seth wrote:
                                      > >
                                      > > >HTTP headers are introduced. Think of the headers like the envolope.
                                      > >
                                      > >
                                      > > For obvious reasons, any mention of the word "envelope" in RESTful
                                      discussions
                                      > > makes me shudder....gives me nightmares where employees from Microsoft and
                                      IBM
                                      > > force-feed me bars of soap until I wake up in a cold sweat ;-)
                                      >
                                      > Yeah, except SOAP can be used to communicate a RESTful protocol. It's
                                      > all about how you use the transport mechanism.

                                      I've always thought it would be interesting if someone sponsored a "tunneling
                                      contest" to see who can tunnel the most protocols in the most creative fashion.
                                      Someone might try to say "hello world" across a network by distributing dynamic
                                      data exchange between windows on separate machines by taking a DDE execute
                                      message and marshaling it as COM invocation using an RPC tunneled through
                                      canonicalized, base 64-encoded XML-RPC messages communicated via a RESTful
                                      implementation built with Python on SOAP running on HTTP implemented over
                                      TCP/IP, where a proxy server sitting inside a firewall receives the request,
                                      unmarshals each of its layers, and faxes the message to a gorilla who takes the
                                      paper and feeds it into a scanner that performs OCR to interpret the message and
                                      send it to a Windows desktop running a NetDDE server that dispatches the request
                                      by writing the message to a temporary HTML file containing JavaScript loaded by
                                      a web browser that displays the original "hello world" in a message box.

                                      -Phil
                                    • Gordon Weakliem
                                      ... Is it me, or does this sound strangely close to the thinking that brought about Don Box s notorious HTTP is Dead keynote? Replace REST with SOAP in the
                                      Message 18 of 26 , Jun 6, 2002
                                        >It might help for your understanding of REST to divorce yourself from
                                        >HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used
                                        >for an implementation of REST, but isn't the perfect embodiment of REST.

                                        Is it me, or does this sound strangely close to the thinking that brought about Don Box's notorious "HTTP is Dead" keynote? Replace REST with SOAP in the last sentence, and what do you have? Put another way, is there a meaningful non-HTTP implementation of REST out in the wild? Sorry, but I really tripped on this statement. Would anybody care to expand on it?
                                      • S. Mike Dierken
                                        ... From: Gordon Weakliem ... about Don Box s notorious HTTP is Dead ... have? Put another way, is ... expand on it? I think of
                                        Message 19 of 26 , Jun 6, 2002
                                          ----- Original Message -----
                                          From: "Gordon Weakliem" <gweakliem@...>

                                          >
                                          > Is it me, or does this sound strangely close to the thinking that brought
                                          about Don Box's notorious "HTTP is Dead"
                                          > keynote? Replace REST with SOAP in the last sentence, and what do you
                                          have? Put another way, is
                                          > there a meaningful non-HTTP implementation of REST out in the wild?
                                          > Sorry, but I really tripped on this statement. Would anybody care to
                                          expand on it?

                                          I think of SQL based systems as something with a lot of REST-like qualities.
                                          They are much better at the jobs they were designed for than a REST based
                                          system, but REST is better at jobs /it/ was designed for.
                                        Your message has been successfully submitted and would be delivered to recipients shortly.