A)当购物车的内容被购买时，购物车被复制到一个固定的订单，并且购物车被删除。
B)如果要更改已下的订单，则创建一个允许编辑订单的购物车。(取消可能会产生取消费用)。当更改被接受时，更改将从购物车转移到订单。购物车将再次被删除。
我正在努力在使用资源的RESTful API中建模这些状态变化?我该如何表达资源的变化?购买购物车内容将删除购物车并创建一个新购物车。这里有一些想法…
a)创建订单:
邮件订单吗?车= cartId或PATCH购物车/:id{状态:已购买}
(响应将保留到Orders/:newid的链接)
b)保存现有订单的更新购物车:
把订单/:id ?车= cartId或PATCH Cart/:id {status: changconfirmed}或把订单/id/: cartID
启发式:想想如何在网络上做。
-
您正在查看一个描述购物车内容的网页。在同一页面上有一个"下订单"的形式。当您提交该表单时，浏览器将向web服务器发送HTTP POST请求，目标是表单的操作元数据所描述的任何资源。这会触发HTTP facade背后的一些业务活动，操纵域模型中的购物车和订单实体。
-
您正在查看描述您的订单的网页。在同一页面上有一个"编辑命令"。的形式。当您提交该表单时，浏览器将向web服务器发送HTTP POST请求，以表单操作元数据描述的任何资源为目标。这会触发HTTP facade背后的一些业务活动，操纵域模型中的购物卡和订单实体。
,。
请求目标可以是任何你想要的;但是，通过网络传输文档的一般目的是使用请求目标进行缓存和缓存失效。这意味着如果您明智地选择请求目标，您可以确保成功的请求使资源的陈旧副本无效。
对于您的第一个示例，放置订单请求将明显改变的资源是购物车资源本身，因此这是对表单操作应该是什么的合理的第一个猜测。
在第二个示例中，order资源是合理的第一个猜测。
必须是POST吗?不——你可以用PUT来代替，效果类似;客户端将资源的编辑副本发送回服务器(PUT)，然后服务器触发业务活动。
(PATCH是PUT的替代方案，我们不发送整个文档，而是以服务器已经发布的格式发送编辑的描述。对于JSON表示的资源，我们通常使用JSON Patch或JSON Merge Patch)。
创建订单
PATCH /Cart/12345 HTTP/2
Content-Type: application/merge-patch+json
{ "status": "purchased" }
保存已更新订单的购物车
PATCH /Cart/12345 HTTP/2
Content-Type: application/merge-patch+json
{"status": "changeConfirmed" }
都很合理。PUT——包括带有更改的/Cart/12345表示的整个副本——如果文档不是太大(与HTTP标头相比)，可能是一个更好的答案:如果HTTP响应在不可靠的网络上丢失，则可以重试具有幂等语义的请求。
请注意，HTTP方法和请求目标可以是相同的，即使意图是触发两个不同的业务活动。这在REST中是完全正常的(但不一定是常见的—您的服务器的HTTP路由框架可能无法区分这两种情况，因此您必须编写一些定制的代码来触发正确的活动)。