我对 Roy Fielding 的 REST 替代 HTTP cookie 的解释是否正确？
Is my interpretation of Roy Fielding’s REST alternative to HTTP cookies correct?
根据 Roy Fielding 的博士论文 Architectural Styles and the Design of Network-Based Software Architectures[=37]，HTTP cookie 违反了 REST 架构风格，因为它们独立于应用程序状态并且没有语义=], § 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.
因此他提出以下替代方案：
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.
我对他的用户偏好示例的理解如下。假设一个网站允许其用户在 URI /preferences 的首选项页面中选择浅色主题（默认）和深色主题（如 Stack Overflow）。当用户选择深色主题时，他应该被重定向到 URI /preferences?theme=dark，其 HTML 表示与 URI /preferences 的 HTML 表示相同，除了它现在将处于暗模式，查询 ?theme=dark 将附加到所有嵌入的超链接。这样，如果用户选择例如 URI /home?theme=dark（而不是 /home）主页的嵌入式超链接，那么主页的 HTML 表示也将处于暗模式并且查询 ?theme=dark 也将附加到其所有嵌入的超链接。要恢复到浅色主题，然后用户在 URI /preferences?theme=dark 处选择指向首选项页面的嵌入式超链接，在首选项页面中选择浅色主题并应重定向到 /preferences 的 URI [=39] =] 表示将与 URI /preferences?theme=dark 的 HTML 表示相同，只是它现在处于轻量模式并且查询 ?theme=dark 将从所有嵌入的超链接中删除。这是 Roy Fielding 的意思吗？
同样对于他的购物车示例，当用户将产品 i 添加到购物车时，他应该被重定向到带有查询 ?product-{i}={product-i}&quantity-{i}={quantity-i} 的 URI，其 HTML 表示会将查询附加到其所有嵌入的超链接。这样，当用户选择结帐超链接 /checkout?product-1={product-1}&quantity-1={quantity-1}&…&product-n={product-n}&quantity-n={quantity-n} 时，购物车的内容就会发送到网站。这是 Roy Fielding 的意思吗？
我相信您在第一种情况下正确地解释了菲尔丁的论点，但在第二种情况下则不是。
您对“首选项”的解释似乎完全正确：拥有多个资源，其表示包含相同的信息，但呈现方式不同，例如将深色主题和浅色主题作为并行资源结构，这是完全合理的。
但我认为您误解了 Fielding 的“客户端购物篮”提议。他并没有提议引入服务器端资源进行编辑（毕竟，这种能力已经存在于我们今天拥有的网络中）；而是引入一种通用语言，用于在客户端上存储有趣的客户端状态片段。
换句话说，Fielding 正在谈论在 HTML 标准中引入一些控件（类似于 Web 表单的控件），这些控件允许人们保存一些信息，这些信息稍后会被加载到实际下单时的形式。
想象一下，如果您愿意，可以想象一种特殊的表单，当提交时，它会编辑 Web 浏览器本身的本地资源。因此，您可以从目录中挑选商品，这样做会修改您的本地购物车资源。当您准备好结帐时，您购物车中的内容将可以发送到服务器。
就像表格是通用的一样，可以用于许多不同的领域，所以我们希望这个购物车管道是通用的，这样它就可以用于任何类型的“复制”此信息稍后使用”机制。
诀窍（没有发生）是定义一个标准，然后让每个人（浏览器制造商）以足够相似的方式实施这些标准，以确保一切正常。
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.
根据 Roy Fielding 的博士论文 Architectural Styles and the Design of Network-Based Software Architectures[=37]，HTTP cookie 违反了 REST 架构风格，因为它们独立于应用程序状态并且没有语义=], § 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.
因此他提出以下替代方案：
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.
我对他的用户偏好示例的理解如下。假设一个网站允许其用户在 URI /preferences 的首选项页面中选择浅色主题（默认）和深色主题（如 Stack Overflow）。当用户选择深色主题时，他应该被重定向到 URI /preferences?theme=dark，其 HTML 表示与 URI /preferences 的 HTML 表示相同，除了它现在将处于暗模式，查询 ?theme=dark 将附加到所有嵌入的超链接。这样，如果用户选择例如 URI /home?theme=dark（而不是 /home）主页的嵌入式超链接，那么主页的 HTML 表示也将处于暗模式并且查询 ?theme=dark 也将附加到其所有嵌入的超链接。要恢复到浅色主题，然后用户在 URI /preferences?theme=dark 处选择指向首选项页面的嵌入式超链接，在首选项页面中选择浅色主题并应重定向到 /preferences 的 URI [=39] =] 表示将与 URI /preferences?theme=dark 的 HTML 表示相同，只是它现在处于轻量模式并且查询 ?theme=dark 将从所有嵌入的超链接中删除。这是 Roy Fielding 的意思吗？
同样对于他的购物车示例，当用户将产品 i 添加到购物车时，他应该被重定向到带有查询 ?product-{i}={product-i}&quantity-{i}={quantity-i} 的 URI，其 HTML 表示会将查询附加到其所有嵌入的超链接。这样，当用户选择结帐超链接 /checkout?product-1={product-1}&quantity-1={quantity-1}&…&product-n={product-n}&quantity-n={quantity-n} 时，购物车的内容就会发送到网站。这是 Roy Fielding 的意思吗？
我相信您在第一种情况下正确地解释了菲尔丁的论点，但在第二种情况下则不是。
您对“首选项”的解释似乎完全正确：拥有多个资源，其表示包含相同的信息，但呈现方式不同，例如将深色主题和浅色主题作为并行资源结构，这是完全合理的。
但我认为您误解了 Fielding 的“客户端购物篮”提议。他并没有提议引入服务器端资源进行编辑（毕竟，这种能力已经存在于我们今天拥有的网络中）；而是引入一种通用语言，用于在客户端上存储有趣的客户端状态片段。
换句话说，Fielding 正在谈论在 HTML 标准中引入一些控件（类似于 Web 表单的控件），这些控件允许人们保存一些信息，这些信息稍后会被加载到实际下单时的形式。
想象一下，如果您愿意，可以想象一种特殊的表单，当提交时，它会编辑 Web 浏览器本身的本地资源。因此，您可以从目录中挑选商品，这样做会修改您的本地购物车资源。当您准备好结帐时，您购物车中的内容将可以发送到服务器。
就像表格是通用的一样，可以用于许多不同的领域，所以我们希望这个购物车管道是通用的，这样它就可以用于任何类型的“复制”此信息稍后使用”机制。
诀窍（没有发生）是定义一个标准，然后让每个人（浏览器制造商）以足够相似的方式实施这些标准，以确保一切正常。
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.