在一篇文章中， Tim Bray，审视了 Sun Cloud API 的第一版公众草稿所收到的反馈。 对于其中一些反馈他在文中作出了回应，对于如何对交互进行建模，例如以 RESTful 的方式创建一个 VM 集群，进行了探索。
他展示了在设计 Sun Cloud API 范畴中的几个场景，并问到用 POSTing 状态来建模这样的交互是否是一种合适的策略。
但你不是真正的在改变状态，你是在请求一系列特定动作的执行，作为其结果，该状态是否能获得期望的值皆有可能。实际上，当你触发部署开关，状态变为了部署中，在不可预知的一段时间之后，又改变为已部署。而重启操作这一经典例子，就是在机器旁边有一个红色的大开关，问题是如何按这个开关。
所以啊，我越想越觉得，这些资源就像是按钮，只有唯一定义的操作：按下。人们对于“只写资源”牢骚满腹，但我却觉得不存在什么问题，因为这非常准确。重启和停止按钮实际上没有任何状态，所以你不应该期待 GET 操作能得到什么有用的东西。
Bill de hóra 在 对这篇文章的回应中提供了例子，来说明 PUT 和 POST 两者何时相对于另一方来说更为合适。
什么时候 PUT 与 POST 的比较才真正有影响？据我所知，当你的资源代表着一个集合时，它是有影响的，而这也很普遍－文件夹，专辑列表，订阅种子，收集物，博客，标签云，订单，购物车－任何基于列表的结构。
他同时还展现了关于整个讨论更加实用的方面，并建议将 POSTting 表单作为一种可能的解决方案。
另一方面，很多很多人不会，不想，（有时候也不能）去关心 REST/HTTP/AtomPub 的秘密。所以我也考虑到我们需要模式和实践来帮助开发者上手。
但是到目前为止我并不确认在我们支持 REST 的社区阵营里对于部分的更新资源已经有了一个很好的普遍答案或是设计模式。除非是这样，不然我推测人们还是会回到使用表单 posting，因为它是最为简单和兼容的部署客户端库和 web 框架的方式。要不就这样。要不就为部分更新定义一些特定的媒体类型。
Roy Fielding 也对这篇文章作出了回应
在我的论文中没有特指的主要原因，是因为这些方法是作为 Web 架构定义的一部分，由 HTTP 来定义的，而不是 REST 架构风格（所定义的）。特定的方法定义 […] 对 REST 架构风格没有影响，所以对它们进行风格讨论非常困难。REST 对方法的唯一要求就是它们需要为所有的资源有着统一的定义 (例如，中介不必需要去了解资源的类型就可以理解请求的含义)。
只有当 POST 被用在有其它的方法理想适用的场合，才是一个问题。其它的方法对中介更有价值，因为它们说明了失效如何被自动处理以及中间缓存如何去优化它们的行为。POST 不具备这些特点，但这并不意味着我们离得开它。POST 在 HTTP 里为许多有用的目的而服务，包括主要目标：“这一行为不需要符合于标准。”
Roy 作出了总结：
我们没必要对于 HTTP 的每个状态改变都使用 PUT。REST 从没说过我们应该这样。[…] 我个人的话，对这些按钮我就使用 POST。API 可以对使用 POST 作出补偿，可以在响应中表示客户端应当刷新对更大资源状态的表象。换句话说，我会返回一个 303 响应，重定向回 VM 状态，这样客户端就知道状态已经改变了。
这里有原文， 以及社区的所作出的回应。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论