I struggle to understand Roy Fielding’s REST alternative to HTTP cookies, § 188.8.131.52 ‘Cookies’ and § 184.108.40.206 ‘Application State in a Network-Based System’ of his doctoral dissertation Architectural Styles and the Design of Network-Based Software Architectures. How do you interpret it?
An example of where an inappropriate extension has been made to the protocol to support features that contradict the desired properties of the generic interface is the introduction of site-wide state information in the form of HTTP cookies . Cookie interaction fails to match REST's model of application state, often resulting in confusion for the typical browser application.
An HTTP cookie is opaque data that can be assigned by the origin server to a user agent by including it within a Set-Cookie response header field, with the intention being that the user agent should include the same cookie on all future requests to that server until it is replaced or expires. Such cookies typically contain an array of user-specific configuration choices, or a token to be matched against the server's database on future requests. The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser. When the browser's history functionality (the "Back" button) is subsequently used to back-up to a view prior to that reflected by the cookie, the browser's application state no longer matches the stored state represented within the cookie. Therefore, the next request sent to the same server will contain a cookie that misrepresents the current application context, leading to confusion on both sides.
Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. The combination of cookies with the Referer [sic] header field makes it possible to track a user as they browse between sites.
220.127.116.11 Application State in a Network-based System
REST defines a model of expected application behavior which supports simple and robust applications that are largely immune from the partial failure conditions that beset most network-based applications. However, that doesn't stop application developers from introducing features which violate the model. The most frequent violations are in regard to the constraints on application state and stateless interaction.
Architectural mismatches due to misplaced application state are not limited to HTTP cookies. The introduction of "frames" to the Hypertext Markup Language (HTML) caused similar confusion. Frames allow a browser window to be partitioned into subwindows, each with its own navigational state. Link selections within a subwindow are indistinguishable from normal transitions, but the resulting response representation is rendered within the subwindow instead of the full browser application workspace. This is fine provided that no link exits the realm of information that is intended for subwindow treatment, but when it does occur the user finds themself viewing one application wedged within the subcontext of another application.
For both frames and cookies, the failure was in providing indirect application state that could not be managed or interpreted by the user agent. A design that placed this information within a primary representation, thereby informing the user agent on how to manage the hypermedia workspace for a specified realm of resources, could have accomplished the same tasks without violating the REST constraints, while leading to a better user interface and less interference with caching.
- How do we carry user preferences stored in a URI across multiple actions?
Example. — I assume that Roy Fielding meant that the server should propagate user preferences in the hyperlinks of response representations: from the HTML representation in light mode of the URI
/preferencesof a website, a user selects a dark theme button which is an hyperlink to the URI
/preferences?theme=dark. The server responds with an HTML representation in dark mode with hyperlinks to URIs updated with an additional query component
theme=dark. So if the user then selects the website logo which is an hyperlink to the URI
/home), the server responds again with an HTML representation in dark mode with hyperlinks to URIs updated with an additional query component
- How do we embed shopping items in the HTML hypermedia format?
Example. — I assume that Roy Fielding meant that HTML should define a new
<shopping>element for representing shopping items.
<!DOCTYPE html> <html lang="en"> <title>Shop</title> <h1>Our products</h1> <shopping name="beer" stock="4" price="5.99" currency="USD"> <quantity>1<quantity/> Beer (USD 5.99) </shopping> <shopping name="cider" stock="1" price="3.99" currency="USD"> <quantity>0<quantity/> Cider (USD 3.99) </shopping> <shopping name="wine" stock="3" price="9.99" currency="USD"> <quantity>0<quantity/> Wine (USD 9.99) </shopping> </html>
Example. — I assume that Roy Fielding meant that if the HTML hypermedia format supported a new
<shopping>element for representing shopping items, browsers would understand them natively and therefore would be able to update their application states according to user interactions with the
<shopping>elements, instead of relying on client-side scripting.