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

Re: [rest-discuss] REST, HTTP, Sessions and Cookies

Expand Messages
  • Roy T. Fielding
    ... That concept tends to be a little confusing, partly because HTTP, like many network protocols, has a notion of stateless interactions that only refers to
    Message 1 of 30 , Apr 15 8:36 PM
    View Source
    • 0 Attachment
      > Any application of cookies breaks REST, because they are by definition
      > stateful, and all REST interactions are stateless. That doesn't mean
      > they don't have their uses, of course. But there other ways of doing
      > "sessions" statelessly, and doing them statefully is not REST.

      That concept tends to be a little confusing, partly because HTTP,
      like many network protocols, has a notion of stateless interactions
      that only refers to having all of the information needed to
      understand each request inside the request or defined by universal
      standard. REST goes further and constrains application state
      (not resource state) to be held on the client. It is hard to
      describe without further defining what "application" means, but
      we can think of it as the context between user agent requests:
      the server cannot be aware of any such context and still be REST.

      This is also what allows individual pages to be bookmarked and
      shared with others, but that's a longer story.

      The purpose of statelessness is to prevent partial failures and
      allow for substrate independence (e.g., load-balanced gateways
      managing the traffic for many servers). Cookies don't
      necessarily break that because they are inside the request,
      unless developers make the mistake of defining the cookie such
      that it varies by gateway.

      Most of the problems with cookies are due to breaking visibility,
      which impacts caching and the hypertext application engine, but
      even worse is its use for authentication, as evidenced by the
      cross-site-scripting security holes in sites that use it.
      It ends up being a weird trade-off of security versus efficiency.

      Using cookies is more efficient than authentication because the
      server (and intermediaries) will simply ignore cookies for the
      vast majority of URI (e.g., inline images). That allows everything
      except the pages that set cookies to be cacheable, and those are
      typically non-cacheable pages in any case. However, using cookies
      in that fashion means the server is relying on security by obscurity
      to associate the client's stored cookie with the application state
      (attackers ability to guess the cookie or obtain it illegitimately
      via XSS). Likewise, keeping state in the cookie means that the
      URIs can be independent of the user state, but doing that messes-up
      the client's understanding of state as presented by the hypertext
      engine: it breaks the "back" button.

      Unfortunately, cookies were not presented for discussion by the
      community until after they had been deployed and announced as one
      of Netscape's infamous "extensions". If they had, then it is more
      likely that HTML would have been extended to indicate selectable
      items, and browsers could then have developed a client-side
      market basket that is more reliable and subject to a fancier UI.
      Doing that now is simply a chicken-and-egg problem: browers won't
      bother til there is user demand for the feature, and sites won't
      offer it as an option until browsers implement it consistently.
      Java was supposed to solve that problem, but Sun screwed that up.

      Cookies that simply store a reference to server-maintained state
      do violate REST's constraint on state being stored on the client,
      rather than the server, for scalability. The effect of violating
      that constraint can be seen on any site that uses client-sessions
      on the back-end, such as is common in J2SE. Such sites are usually
      several orders of magnitude less scalable than REST-based
      applications, but some folks still prefer it for "personalization".
      My experience has been that this is the number one cause of failed
      website applications: reliance on server-side sessions.

      BTW, "personalization" can be defined as deliberately trading off
      scalability for customized content. The advertising folks who took
      over the Web design space in 1996 claimed that this was a necessity,
      often making it a core component of third-party "evaluations" of
      website usability, but if you actually go and talk to the customers
      using those sites you will find that they hate it with a passion.
      Amazon is the only site that did it well, and it continues to cost
      them a fortune in back-end costs.

      ....Roy
    • Mark Baker
      Hi Roy, ... Right. Correct me if I m wrong, but I ve always assumed that this additional constraint is a constraint on application semantics. That is, that a
      Message 2 of 30 , Apr 16 8:07 AM
      View Source
      • 0 Attachment
        Hi Roy,

        On Tue, Apr 15, 2003 at 08:36:00PM -0700, Roy T. Fielding wrote:
        > > Any application of cookies breaks REST, because they are by definition
        > > stateful, and all REST interactions are stateless. That doesn't mean
        > > they don't have their uses, of course. But there other ways of doing
        > > "sessions" statelessly, and doing them statefully is not REST.
        >
        > That concept tends to be a little confusing, partly because HTTP,
        > like many network protocols, has a notion of stateless interactions
        > that only refers to having all of the information needed to
        > understand each request inside the request or defined by universal
        > standard. REST goes further and constrains application state
        > (not resource state) to be held on the client.

        Right. Correct me if I'm wrong, but I've always assumed that this
        additional constraint is a constraint on application semantics. That
        is, that a RESTful application semantic may not punt application
        state. So "LOGIN" wouldn't be a permitted semantic, because even though
        a LOGIN message may be semantically self-contained (and uniform even),
        it defers the maintenance of some application state (whether you're
        authorized or not) to the server.

        Is that right? Does this additional constraint impact anything else?

        > The purpose of statelessness is to prevent partial failures and
        > allow for substrate independence (e.g., load-balanced gateways
        > managing the traffic for many servers). Cookies don't
        > necessarily break that because they are inside the request,
        > unless developers make the mistake of defining the cookie such
        > that it varies by gateway.

        Very good point.

        But there's also a problem if the cookie is defined such that the
        referenced state varies with time, which I would expect is much more
        common than varying by gateway. A message that references some other
        state may be processed at a time when that state is different than it
        was when the message was constructed.

        I understand that this isn't as relevant to the simple browser/server
        interactions of today, but architecturally speaking it seems quite
        important, especially as we move towards disconnected and queued
        interactions.

        MB
        --
        Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
        Web architecture consulting, technical reports, evaluation & analysis
      • Walden Mathews
        ... After reading carefully, I m not sure I can discern any additional constraint in the above. I m starting with the assumption that without application
        Message 3 of 30 , Apr 16 8:26 AM
        View Source
        • 0 Attachment
          > > That concept tends to be a little confusing, partly because HTTP,
          > > like many network protocols, has a notion of stateless interactions
          > > that only refers to having all of the information needed to
          > > understand each request inside the request or defined by universal
          > > standard. REST goes further and constrains application state
          > > (not resource state) to be held on the client.
          >
          > Right. Correct me if I'm wrong, but I've always assumed that this
          > additional constraint is a constraint on application semantics. That
          > is, that a RESTful application semantic may not punt application
          > state. So "LOGIN" wouldn't be a permitted semantic, because even though
          > a LOGIN message may be semantically self-contained (and uniform even),
          > it defers the maintenance of some application state (whether you're
          > authorized or not) to the server.
          >
          > Is that right? Does this additional constraint impact anything else?


          After reading carefully, I'm not sure I can discern any additional
          constraint in the above. I'm starting with the assumption that without
          "application state" there is no application. Moving from there, if
          each request is self-contained in that the server can interpret it
          adding only universal standards, then by process of elimination there
          must be some conversational state maintained by the client, because
          there's not other place it can be. And if the client doesn't maintain
          that state, then there is no application, just an isolated iteraction.

          What am I missing?

          --Walden
        • Mark Baker
          ... Consider that a single LOGIN message may be stateless (semantically self-contained), yet have consequences for the interpretation of the semantics of
          Message 4 of 30 , Apr 16 9:57 AM
          View Source
          • 0 Attachment
            On Wed, Apr 16, 2003 at 11:26:03AM -0400, Walden Mathews wrote:
            > After reading carefully, I'm not sure I can discern any additional
            > constraint in the above.

            Consider that a single LOGIN message may be stateless (semantically
            self-contained), yet have consequences for the interpretation of the
            semantics of subsequent messages. So while it's true that those
            subsequent messages wouldn't be stateless in that case, the interaction
            that made that the case, by handing off (right term?) application state,
            was stateless.

            Subtle, for sure. But I don't even know that I'm right about how this
            additional constraint reveals itself, so there could be more to it than
            that.

            MB
            --
            Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
            Web architecture consulting, technical reports, evaluation & analysis
          • Roy T. Fielding
            ... Well, keep in mind that the actions of PUT and POST also defer the maintenance of state to the server. Since we could construct a login semantic via the
            Message 5 of 30 , Apr 16 11:50 AM
            View Source
            • 0 Attachment
              >> That concept tends to be a little confusing, partly because HTTP,
              >> like many network protocols, has a notion of stateless interactions
              >> that only refers to having all of the information needed to
              >> understand each request inside the request or defined by universal
              >> standard. REST goes further and constrains application state
              >> (not resource state) to be held on the client.
              >
              > Right. Correct me if I'm wrong, but I've always assumed that this
              > additional constraint is a constraint on application semantics. That
              > is, that a RESTful application semantic may not punt application
              > state. So "LOGIN" wouldn't be a permitted semantic, because even
              > though
              > a LOGIN message may be semantically self-contained (and uniform even),
              > it defers the maintenance of some application state (whether you're
              > authorized or not) to the server.

              Well, keep in mind that the actions of PUT and POST also defer the
              maintenance of state to the server. Since we could construct a login
              semantic via the PUT of a user-specific resource, with logout being
              signified by a DELETE, it would be odd for REST to disallow LOGIN
              just on the basis of it being a stateful semantic. I think it is more
              accurate to say that, because user identification must be supplied
              with each request subject to authentication, that an action like LOGIN
              would only add overhead.

              > But there's also a problem if the cookie is defined such that the
              > referenced state varies with time, which I would expect is much more
              > common than varying by gateway. A message that references some other
              > state may be processed at a time when that state is different than it
              > was when the message was constructed.
              >
              > I understand that this isn't as relevant to the simple browser/server
              > interactions of today, but architecturally speaking it seems quite
              > important, especially as we move towards disconnected and queued
              > interactions.

              That same problem applies to resources. We could attempt to model REST
              as a shared-memory-by-message-passing system, but don't because that
              model tries to maintain distributed consistency. REST just says that
              there is no consistency -- only representations that indicate state
              at some point in the past and an implicit grant of use for some time
              into the future.

              ....Roy
            • Mark Baker
              Oi, LOGIN was a terrible example. I didn t think it through. What I was trying to learn by asking was this; what am I constrained from doing with the
              Message 6 of 30 , Apr 16 8:41 PM
              View Source
              • 0 Attachment
                Oi, LOGIN was a terrible example. I didn't think it through.

                What I was trying to learn by asking was this; what am I constrained
                from doing with the application-state-on-the-client constraint, that I'm
                not already constrained from doing by the
                all-necessary-info-in-the-message constraint?

                Thanks.

                MB
                --
                Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                Web architecture consulting, technical reports, evaluation & analysis
              • Walden Mathews
                Oh, then we have the same question afterall. WM ... From: Mark Baker To: Roy T. Fielding Cc:
                Message 7 of 30 , Apr 17 4:30 AM
                View Source
                • 0 Attachment
                  Oh, then we have the same question afterall.

                  WM

                  ----- Original Message -----
                  From: "Mark Baker" <distobj@...>
                  To: "Roy T. Fielding" <fielding@...>
                  Cc: <rest-discuss@yahoogroups.com>
                  Sent: Wednesday, April 16, 2003 11:41 PM
                  Subject: Re: [rest-discuss] REST, HTTP, Sessions and Cookies


                  > Oi, LOGIN was a terrible example. I didn't think it through.
                  >
                  > What I was trying to learn by asking was this; what am I constrained
                  > from doing with the application-state-on-the-client constraint, that I'm
                  > not already constrained from doing by the
                  > all-necessary-info-in-the-message constraint?
                  >
                  > Thanks.
                  >
                  > MB
                  > --
                  > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                  > Web architecture consulting, technical reports, evaluation & analysis
                  >
                  >
                  > 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/
                  >
                  >
                • Roy T. Fielding
                  ... Oh, I see what you mean. If you look back in my dissertation, http://www.ics.uci.edu/~fielding/pubs/dissertation/ net_arch_styles.htm#sec_3_4_3
                  Message 8 of 30 , Apr 17 5:30 PM
                  View Source
                  • 0 Attachment
                    On Wednesday, April 16, 2003, at 08:41 PM, Mark Baker wrote:
                    > Oi, LOGIN was a terrible example. I didn't think it through.
                    >
                    > What I was trying to learn by asking was this; what am I constrained
                    > from doing with the application-state-on-the-client constraint, that
                    > I'm
                    > not already constrained from doing by the
                    > all-necessary-info-in-the-message constraint?

                    Oh, I see what you mean. If you look back in my dissertation,

                    http://www.ics.uci.edu/~fielding/pubs/dissertation/
                    net_arch_styles.htm#sec_3_4_3
                    http://www.ics.uci.edu/~fielding/pubs/dissertation/
                    rest_arch_style.htm#sec_5_1_3

                    you will notice that there is only one constraint: communication must
                    be stateless in nature. The remainder of the description is simply
                    explaining the properties induced by that constraint and the effect it
                    has on architectures based on that style.

                    In other words, they are just two sides of the same coin.

                    ....Roy
                  • bhaugen32
                    ... that ... What do you think of the attempts of Paul Prescod and others to cast state-transition models into RESTful hyperlinked resources? For example,
                    Message 9 of 30 , Apr 19 8:11 AM
                    View Source
                    • 0 Attachment
                      --- In rest-discuss@yahoogroups.com, "Roy T. Fielding"
                      <fielding@a...> wrote:
                      > We could attempt to model REST
                      > as a shared-memory-by-message-passing system, but don't because that
                      > model tries to maintain distributed consistency. REST just says
                      that
                      > there is no consistency -- only representations that indicate state
                      > at some point in the past and an implicit grant of use for some time
                      > into the future.

                      What do you think of the attempts of Paul Prescod and others to cast
                      state-transition models into RESTful hyperlinked resources?

                      For example,
                      http://www.prescod.net/rest/state_transition.html

                      For another example, many if not most business dealings require
                      explioit agreements between trading partners, which is a form of
                      consistency.

                      A common business protocol for contracts (of which orders are a
                      subtype) is Offer-Acceptance, which we have tried to RESTify several
                      times on this list.

                      One way to do it, I think following Paul's proposals, would be to
                      create separate hyperlinked resources for Offer, Response (Acceptance
                      or Rejection) and Order.

                      If the Offer resource exists, and is not already hyperlinked to a
                      Response, then the counter-party can post an Acceptance to the Offer
                      resource.

                      If an Acceptance is posted, then an Order resource will be created,
                      hyperlinked to the Offer and Acceptance.

                      Does this kind of interaction seem acceptably RESTful to you? The
                      interpretation of a message is dependent on the state of the resource
                      to which it is posted, and to which it refers, in addition to the
                      contents of the message itself. (But nothing else.)

                      Thanks,
                      Bob Haugen
                    • Berend de Boer
                      ... Roy you will notice that there is only one constraint: Roy communication must be stateless in nature. It is too bad that the theoretic ideals don t map
                      Message 10 of 30 , Apr 21 12:29 PM
                      View Source
                      • 0 Attachment
                        >>>>> "Roy" == Roy T Fielding <fielding@...> writes:

                        Roy> you will notice that there is only one constraint:
                        Roy> communication must be stateless in nature.

                        It is too bad that the theoretic ideals don't map easily to the real
                        world of web servers and web browsers.

                        --
                        Regards,

                        Berend. (-:
                      • Mark Baker
                        ... That s the point, really. Where the mapping is problematic, it s not a failing of REST, it s it working as planned; it tells you that your app probably
                        Message 11 of 30 , Apr 21 7:42 PM
                        View Source
                        • 0 Attachment
                          On Tue, Apr 22, 2003 at 07:29:03AM +1200, Berend de Boer wrote:
                          > >>>>> "Roy" == Roy T Fielding <fielding@...> writes:
                          >
                          > Roy> you will notice that there is only one constraint:
                          > Roy> communication must be stateless in nature.
                          >
                          > It is too bad that the theoretic ideals don't map easily to the real
                          > world of web servers and web browsers.

                          That's the point, really. Where the mapping is problematic, it's not a
                          failing of REST, it's it working as planned; it tells you that your app
                          probably has issues, and what they may be.

                          MB
                          --
                          Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                          Web architecture consulting, technical reports, evaluation & analysis
                        • Walden Mathews
                          It s the Principle of Beneficint Difficulty at work, as Michael Jackson would say. WM ... From: Mark Baker To:
                          Message 12 of 30 , Apr 22 4:26 AM
                          View Source
                          • 0 Attachment
                            It's the Principle of Beneficint Difficulty at work, as
                            Michael Jackson would say.

                            WM

                            ----- Original Message -----
                            From: "Mark Baker" <distobj@...>
                            To: <rest-discuss@yahoogroups.com>
                            Sent: Monday, April 21, 2003 10:42 PM
                            Subject: Re: [rest-discuss] REST, HTTP, Sessions and Cookies


                            > On Tue, Apr 22, 2003 at 07:29:03AM +1200, Berend de Boer wrote:
                            > > >>>>> "Roy" == Roy T Fielding <fielding@...> writes:
                            > >
                            > > Roy> you will notice that there is only one constraint:
                            > > Roy> communication must be stateless in nature.
                            > >
                            > > It is too bad that the theoretic ideals don't map easily to the real
                            > > world of web servers and web browsers.
                            >
                            > That's the point, really. Where the mapping is problematic, it's not a
                            > failing of REST, it's it working as planned; it tells you that your app
                            > probably has issues, and what they may be.
                            >
                            > MB
                            > --
                            > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                            > Web architecture consulting, technical reports, evaluation & analysis
                            >
                            >
                            > 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/
                            >
                            >
                          • Nic Ferrier
                            I have just given a talk about REST to the other techies at my current client (including the man in charge of development). The audience was of mixed ability,
                            Message 13 of 30 , Apr 23 2:46 PM
                            View Source
                            • 0 Attachment
                              I have just given a talk about REST to the other techies at my
                              current client (including the man in charge of development). The
                              audience was of mixed ability, from old time hackers to complete
                              newbies in web development.

                              Here is a very short summary of audience reaction and my thoughts
                              about it. I hope it's useful.


                              The reaction of most was to question whether I was talking about
                              anything clever, to question the validity of REST because of it's
                              simplicity. The more experience programmers (who have topyed with
                              SOAP and XMLRPC) were more enthusisatic.


                              It's clear that many people don't really understand HTTP. REST
                              evangelists need to do more to explain HTTP to people.


                              I expected some confusion and incredulity about the stuff about
                              sessions and I got some. Again, the more experienced were more
                              inclined to listen to the REST p-o-v. But the prevaliing view about
                              sessions was "go tell the marketing dept" because this company does
                              quite a lot of personalization based on cookies.


                              So, in summary, the talk was pretty succesful. My only doubt is how
                              much I should push the sessions issue. I'm still not clear myself
                              about that.



                              Nic Ferrier
                            • Mike Dierken
                              ... From: Nic Ferrier ... This is truly an understatement. Even when explained, it takes some implementation practice for
                              Message 14 of 30 , Apr 23 9:35 PM
                              View Source
                              • 0 Attachment
                                ----- Original Message -----
                                From: "Nic Ferrier" <nferrier@...>

                                >
                                > It's clear that many people don't really understand HTTP.
                                This is truly an understatement. Even when explained, it takes some
                                implementation practice for people to really trust that it really is that
                                easy & that it really can do a lot.

                                Here are some books to look at:

                                <http://www.amazon.com/exec/obidos/ASIN/1565925092/topiczero-20/>
                                HTTP: The Definitive Guide (Price: $31.47US)
                                by David Gourley, Brian Totty
                                Behind every web transaction lies the Hypertext Transfer Protocol (HTTP)-the
                                language of web browsers and servers, of portals and search engines, of
                                e-commerce and web services. Understanding HTTP is essential for practically
                                all web-based programming, design, analysis, and administration.

                                <http://www.amazon.com/exec/obidos/ASIN/1565928628/topiczero-20>
                                HTTP Pocket Reference (Price: $9.95US)
                                by Clinton Wong
                                All web programmers, administrators, and application developers need to be
                                familiar with HTTP in order to work effectively. The HTTP Pocket Reference
                                provides a solid conceptual foundation of HTTP, and also serves as a quick
                                reference to each of the headers and status codes that compose an HTTP
                                transaction. For those who need to get "beyond the browser," this book is
                                the place to start.

                                <http://www.amazon.com/exec/obidos/ASIN/0471398233/topiczero-20/>
                                HTTP Essentials (Price: $24.49US)
                                by Stephen A. Thomas
                                This guide explains the protocol that defines how Web browsers communicate
                                with Web servers, the mechanisms that keep that communication secure, and
                                techniques for accelerating HTTP. Topics include the structure and format of
                                HTTP messages; security technologies such as SSL, TLS, and SHTTP; and how to
                                handle compatibility between HTTP versions. Coverage extends to related
                                technologies such as Proxy Auto Configuration (PAC), Web Proxy Auto
                                Discovery (WPAD), Web Cache Coordination Protocol (WCCP), Internet Cache
                                Protocol (ICP) and Hypertext Caching Protocol (HTCP).
                              • S. Alexander Jacobson
                                The sessions issue seems like a Red Herring. You make UI web servers that interact with the web service. They can be as stateful as you want them to be
                                Message 15 of 30 , Apr 30 4:57 PM
                                View Source
                                • 0 Attachment
                                  The sessions issue seems like a Red Herring.
                                  You make UI web servers that interact with the web
                                  service. They can be as stateful as you want them
                                  to be because they are really just web based user
                                  agents (not really different from X-windows based
                                  user-agents).

                                  -Alex-

                                  On Wed, 23 Apr 2003, Nic Ferrier wrote:

                                  > I have just given a talk about REST to the other techies at my
                                  > current client (including the man in charge of development). The
                                  > audience was of mixed ability, from old time hackers to complete
                                  > newbies in web development.
                                  >
                                  > Here is a very short summary of audience reaction and my thoughts
                                  > about it. I hope it's useful.
                                  >
                                  >
                                  > The reaction of most was to question whether I was talking about
                                  > anything clever, to question the validity of REST because of it's
                                  > simplicity. The more experience programmers (who have topyed with
                                  > SOAP and XMLRPC) were more enthusisatic.
                                  >
                                  >
                                  > It's clear that many people don't really understand HTTP. REST
                                  > evangelists need to do more to explain HTTP to people.
                                  >
                                  >
                                  > I expected some confusion and incredulity about the stuff about
                                  > sessions and I got some. Again, the more experienced were more
                                  > inclined to listen to the REST p-o-v. But the prevaliing view about
                                  > sessions was "go tell the marketing dept" because this company does
                                  > quite a lot of personalization based on cookies.
                                  >
                                  >
                                  > So, in summary, the talk was pretty succesful. My only doubt is how
                                  > much I should push the sessions issue. I'm still not clear myself
                                  > about that.
                                  >
                                  >
                                  >
                                  > Nic Ferrier
                                  >
                                  >
                                  >
                                  > 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/
                                  >
                                  >

                                  ___________________________________________________________________
                                  S. Alexander Jacobson i2x Media
                                  1-212-787-1914 voice 1-603-288-1280 fax
                                Your message has been successfully submitted and would be delivered to recipients shortly.