以RESTfull方式公开资源上的操作-过载的POST与PUT与控制器资源

假设您拥有一个人力资源，其表示的一部分包括一个位置值，该值可以有“在家”、“在学校”和“在工作”等值。你会如何平静地揭露诸如“回家”、“上班”、“上学”等活动？为了便于讨论，让我们规定这些活动需要时间，因此它们是异步执行的，并且它们可能以各种方式失败（没有可用的交通工具、旅行期间交通中断、其他天灾等）。此外，人员资源还具有影响这些属性的其他属性和相关操作（例如，属性=能量水平，操作=吃/睡/锻炼）

选项1：在人员资源上超负荷发布，提供一个输入参数，指示您希望该人员做什么（例如，操作=上学）。从POST返回202，并公开人员表示中的“活动进行中”状态属性，客户端可以获得这些属性来观察进度和成功/失败

优点：保持简单

缺点：相当于隧道。发生的操作隐藏在有效负载中，而不是在URI、谓词、标题等中可见。此资源上的POST谓词没有单一的语义含义

选项2：使用PUT将此人的位置设置为您希望他们处于的状态。从PUT和expose activity in progress属性返回202，以便通过GET进行状态轮询

好处：我不确定我看到了什么

缺点：真的，这只是另一个动词的隧道。此外，它在某些情况下不起作用（睡觉和吃饭都会增加能量水平，因此将能量水平设置为更高的值在您希望资源执行的操作方面是不明确的）

选项3：公开在Person对象上操作的通用控制器资源。例如，创建一个PersonalActivityManager资源，该资源接受POST请求，其参数标识目标人员和请求的操作。POST可以返回一个PersonActivity资源来表示正在进行的活动，客户端可以获得该资源来监控进度和成功/失败

好处：通过将活动及其状态从人力资源中分离出来，看起来更干净一些

缺点：现在我们已经将隧道转移到PersonalActivityManager资源

选项4： 为每个受支持的操作建立单独的控制器资源，例如，接受POST请求的ToWorkTransporter资源，该资源带有一个参数（或URI元素），该参数用于标识人员，另外还有一个ToHomeTransporter、一个ToSchoolTransporter、一个MealServer、一个Sleeper和一个Exerciser。每种方法都从POST方法返回一个适当的任务监控资源（通勤、吃饭、睡眠、锻炼），客户机可以通过GET进行监控

好处：好的，我们终于消除了隧道。每个帖子只意味着一件事

---

缺点：现在我们讨论了很多资源（也许我们可以将传输程序组合成一个接受目的地参数的传输程序）。其中一些在语义上相当做作（睡眠者？）。它可能更安静，但它实用吗？

好的，我已经研究和思考了大约一周了。既然没有人回答，我就把我学到的结果贴出来

年，蒂姆·布雷（Tim Bray）谈到了将一个状态字段放入控制器与将执行影响该状态的操作的控制器的POST ing。他使用了虚拟机的例子以及如何RESTfully公开“重新启动按钮”的功能。他说

“如果我想更新现有资源中的某些字段，我倾向于 想一想PUT，但这不起作用，因为它应该是 幂等，而重新启动服务器肯定不是。好吧，用 我想是邮局吧；没什么大不了的

但你并不是真的在改变一个状态，你是在要求一个特定的 将要发生的一组操作，其结果可能是 没有达到所需的值。事实上，当您点击deploy开关时， 状态更改为部署，然后在一些不可预测的事件之后 部署所需的时间。重启操作是最经典的 箱子的侧面有一个红色的大开关；问题是如何 按下开关

所以，我越想它，我就越觉得这些资源 就像按钮一样，只有一个定义的操作：按下。人们已经 抱怨“只写资源”，但我对 因为它看起来很准确。重启和停止按钮不正确 真的有任何状态，所以你不应该期望从 得到。”

Tim似乎在我的#3和#4选项之间找到了一个平衡点，公开了多个控制器资源，但从“过火”中退出，所有事情都有单独的控制器资源

Tim的帖子引向了Roy Fielding（）的另一篇帖子，他在帖子中说，对于存在可监控实体状态的情况，以及可能改变该状态的操作，他倾向于使用帖子而不是放置。针对一位评论者的建议，他说，将被监控的状态作为一个单独的可放置资源公开

“我们仅在更新操作为幂等且 表示已完成。我认为我们应该定义一个附加的 当我们认为资源可能对其他人有用时 隔离，并使用该资源的GET/PUT方法，但是 我认为我们不应该仅仅为了一个目的而定义新的资源 避岗。”

---

最后，中的Bill de hOra讨论了使用PUT vs.POST更新集合资源状态的具体案例，以及其中的权衡。

为什么您认为在资源名称中放置操作是一个好主意？邮政手段?