2 回答
我相信您在第一种情况下正确解释了菲尔丁的论文，但不是在第二种情况下。
您对“首选项”的解释似乎完全正确：拥有多个资源，其表示包含相同的信息但不同的表示是完全合理的，例如将深色主题和浅色主题作为并行资源结构。
但我相信你误解了菲尔丁提出的“客户端购物篮”的建议。他并不是提议引入要编辑的服务器端资源（毕竟，这种能力已经存在于我们今天的网络中）；而是引入了一种通用语言，用于在客户端上存储有趣的客户端状态。
换句话说，Fielding 正在讨论在 HTML 标准中引入一些控件（类似于 Web 表单的控件），这些控件将允许人们保存一些信息，然后在实际下订单时将其加载到表单中。
想象一下，如果你愿意，一种特殊的表单在提交时会编辑Web 浏览器本身的本地资源。因此，您可以从目录中挑选商品，这样您的本地购物车资源就会被修改。当您准备结账时，您的购物车中的内容就可以发送到服务器了。
就像表单是通用的一样，可以用于许多不同的领域，所以我们希望这个购物车管道是通用的，这样它就可以用于任何类型的“复制此信息以供使用后”机制。
诀窍（没有发生）是定义一个标准，然后让每个人（浏览器制造商）以足够相似的方式实施这些标准，让一切正常工作。
正如我在上面的评论中所说的那样，我没有阅读菲尔丁的论文，但我一直在思考这个问题，并决定写下我的想法。
我认为不需要阅读论文来理解 REST 设计。我这样说并不是要贬低菲尔丁的工作，这显然是非常有影响力的。另一方面，论文是从2000年开始的，不能有太多的实践经验。2000 年我还是一名初级开发人员，相信我，REST 不是一回事。如果您完全从事 Web 服务，那么 SOAP 就是它的所在。
我主要从 Subbu Allamaraju 的RESTful Web Services Cookbook以及 Ian Robinson、Jim Webber 和 Savas Parastatidis 的REST in Practice 中学习 REST。在我看来，这些书的基础是开发生产服务方面的更多实践经验，而不是菲尔丁在撰写论文时可能拥有的经验。
综上所述，我想我可以解析菲尔丁关于购物篮的报价：
在超媒体数据格式中定义购物项目的语义，允许用户代理在他们自己的客户端购物篮中选择和存储这些项目，并在客户端准备购买时使用 URI 进行结账
请注意，它讨论的是客户端购物篮。这意味着客户有责任跟踪状态。
我对此的解释是，每个购物项目都是一个单独的资源，这几乎没有争议。在 REST 中，资源由地址标识，因此购物篮只是 URL 的集合：
/products/12345
/products/56789
/products/90125
客户端必须维护一个资源地址列表，如上面的列表。一旦它准备好签出，它就会POST列出为此目的而提供给它的 URI：
POST /check-out HTTP/1.1
Content-Type: text/plain
/products/12345
/products/56789
/products/90125
在这里，我刚刚使用了一个换行符分隔的纯文本列表，但也可以将数据编码为 XML 或 JSON（后者在 2000 年也不是真正的东西）。
我不认为我会像那样设计一个 RESTful 购物篮，但这就是我对上面引用的解释。