Is my interpretation of Roy Fielding’s REST alternative to HTTP cookies correct?

312 views Asked by At

HTTP cookies violate the REST architectural style because they are independent of application state and they have no semantics, according to Roy Fielding’s doctoral dissertation Architectural Styles and the Design of Network-Based Software Architectures, § 6.3.4.2 ‘Cookies’:

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.

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.

So he suggests the following alternative:

As a result, cookie-based applications on the Web will never be reliable. The same functionality should have been accomplished via anonymous authentication and true client-side state. A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. 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.

My understanding of his user preference example is the following. Let’s say that a website allows its users to choose between a light theme (the default) and a dark theme in a preference page at URI /preferences (like Stack Overflow). When a user chooses the dark theme, he should be redirected to the URI /preferences?theme=dark whose HTML representation will be the same as the HTML representation of the URI /preferences, except that it will be now in dark mode and the query ?theme=dark will be appended to all the embedded hyperlinks. That way, if the user selects for instance the embedded hyperlink to the home page at URI /home?theme=dark (not /home), then the HTML representation of the home page will also be in dark mode and the query ?theme=dark will also be appended to all its embedded hyperlinks. To revert to the light theme, then the user selects the embedded hyperlink to the preference page at URI /preferences?theme=dark, chooses the light theme in the preference page and should be redirected to the URI /preferences whose HTML representation will be the same as the HTML representation of the URI /preferences?theme=dark, except that it will be now in light mode and the query ?theme=dark will be removed from all the embedded hyperlinks. Is it what Roy Fielding meant?

Likewise for his shopping cart example, when the user adds a product i to cart, he should be redirected to a URI with a query ?product-{i}={product-i}&quantity-{i}={quantity-i} whose HTML representation will have that query appended to all its embedded hyperlinks. That way, when the user selects the check out hyperlink /checkout?product-1={product-1}&quantity-1={quantity-1}&…&product-n={product-n}&quantity-n={quantity-n}, the content of the shopping cart is sent to the website. Is it what Roy Fielding meant?

2

There are 2 answers

4
VoiceOfUnreason On BEST ANSWER

I believe you are correctly interpretting Fielding's thesis in the first case, but not the second.

Your interpretation of "preferences" seems exactly correct: it's perfectly reasonable to have multiple resources whose representations include the same information, but different presentation, like having a dark theme and a light theme as parallel resource structures.

But I believe that you misinterpret Fielding's proposal of "client-side shopping basket". He's not proposing introducing server side resources to be edited (after all, this capability already exists in the web we have today); but rather the introduction of a general purpose language for storing interesting pieces of client state on the client.

In other words, Fielding is talking about introducing within the HTML standard some controls (similar to the controls of a web form) that would allow the human to save some information would would later be loaded into a form when actually placing an order.

Imagine, if you will, a special kind of form that, when submitted, edits a resource that is local to the web browser itself. So you could pick items out of a catalog, and in doing so your local shopping cart resource would be modified. When you were ready to check out, the contents of your shopping cart would be available to sent to the server.

In the same way that forms are general purpose, and can be used for many different domains, so to we would want this shopping cart plumbing to be general purpose, so that it could be used for any sort of "copy this information to be used later" mechanism.

The trick (that didn't happen) is defining a standard and then getting everybody (browsers makers) to implement those standards in similar enough ways that everything just works.

17
Mark Seemann On

As I've also stated in the comments above, I haven't read Fielding's dissertation, but I've been thinking some more about this question and decided to type down my thoughts nonetheless.

I don't think one needs to read the dissertation to understand REST design. I'm not saying this to belittle Fielding's work, which is clearly hugely influential. On the other hand, the dissertation is from 2000, and can't be based on much practical experience. I was a junior developer in 2000, and believe me, REST wasn't a thing. If you did web services at all, SOAP was where it was at.

I've learned REST mainly from Subbu Allamaraju's RESTful Web Services Cookbook and Ian Robinson, Jim Webber, and Savas Parastatidis' REST in Practice. It seems to me that these books are based on more practical experience with developing production services than Fielding could possibly have had when he wrote the dissertation.

All that said, I think I can parse the Fielding quote about a shopping basket:

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

Notice that it talks about a client-side shopping basket. This means that it's the client's responsibility to keep track of state.

The way that I interpret this is that each shopping item is a separate resource, which is hardly controversial. In REST, resources are identified by address, so a shopping basket would simply be a collection of URLs:

/products/12345
/products/56789
/products/90125

A client would have to maintain a list of resource addresses like the above list. Once it's ready to check out, it'd POST the list to the URI given to it for that purpose:

POST /check-out HTTP/1.1
Content-Type: text/plain
/products/12345
/products/56789
/products/90125

Here, I've just used a newline-separated plain-text list, but one could also encode the data in XML or JSON (the latter of which also wasn't really a thing in 2000).

I don't think that I'd design a RESTful shopping basket quite like that, but that's how I interpret the above quote.