假设您有一个 Person 资源，其部分表示形式包括一个位置值，该值可以具有"在家"、"在学校"和"在工作中"等值。 你会如何RESTing暴露"回家"，"上班"，"上学"等活动？ 为了讨论起见，让我们规定这些活动需要时间，因此它们是异步执行的，并且它们可能会失败的各种方式(没有可用的交通工具、旅行期间的交通故障、其他天灾等(。 此外，人员资源具有影响这些属性的其他属性和关联操作(例如，属性=能量级别，操作=进食/睡眠/锻炼(。
选项 1：在人员资源上重载 POST，提供一个输入参数，指示您希望该人员执行的操作(例如，操作 = 去学校(。 从 POST 返回 202，并在人员表示形式中公开正在进行的活动状态属性，客户端可以 GET 来观察进度和成功/失败。
好处：保持简单。
缺点：相当于隧道。 发生的操作隐藏在有效负载中，而不是在 URI、谓词、标头等中可见。 此资源上的 POST 谓词没有单一的语义含义。
选项 2：使用 PUT 将人员的位置设置为你希望他们拥有的状态。 从 PUT 返回 202，并公开正在进行的活动属性，以便通过 GET 进行状态轮询。
好处：不确定我看到任何好处。
缺点：真的，这只是用另一个动词隧道。 此外，它在某些情况下不起作用(睡眠和进食都会增加能量水平，因此将能量水平提高到更高的值在您希望资源执行的操作方面是模棱两可的(。
选项 3：公开对 Person 对象进行操作的通用控制器资源。 例如，创建一个 PersonActivityManager 资源，该资源接受 POST 请求，其中包含标识目标人员和请求的操作的参数。 POST 可以返回一个 PersonActivity 资源来表示正在进行的活动，客户端可以 GET 来监视进度和成功/失败。
优点：通过将活动及其状态与"人员"资源分开，似乎更简洁一些。
缺点：现在我们已将隧道移动到 PersonActivityManager 资源。
选项 4：为每个支持的操作建立单独的控制器资源，例如，接受带有标识人员的参数(或 URI 元素(的 POST 请求的 ToWorkTransporter 资源，以及 ToHomeTransporter、ToSchoolTransporter、MealServer、Sleeper 和锻炼器。 其中每个都从其 POST 方法返回适当的任务监视资源(通勤、用餐、睡眠、锻炼(，客户端可以通过 GET 监视该资源。
好处：好的，我们终于消除了隧道。 每个 POST 仅表示一件事。
缺点：现在谈论了很多资源(也许我们可以将传输器组合成一个接受目标参数的传输器(。 其中一些在语义上是相当人为的(睡眠者？ 它可能更令人不安，但它实用吗？
好的，我已经研究和思考了大约一个星期了。 由于没有其他人回答，我将发布我所学到的结果。
Tim Bray 在 RESTful Casuistry 中谈到了将状态字段与 POST-ing 放置到控制器，控制器将执行影响该状态的操作。 他使用了一个 VM 的示例，以及如何 RESTfull 公开"重新启动按钮"的功能。 他说
"如果我想更新现有资源中的某些字段，我倾向于 考虑看跌期权。但这不起作用，因为它应该是 幂等的，重新启动服务器肯定不是。好吧，好吧，用 我猜是帖子;没什么大不了的。
但是你并没有真正改变一个状态，你正在请求一个特定的 要发生的一系列行动，结果是国家可能或可能 未达到所需的值。事实上，当您点击部署开关时， 状态更改为部署，然后在一些不可预测之后 部署时间量。重启操作是经典的 侧面带有大红色开关的盒子外壳;问题是如何 按下开关。
所以，我越想越觉得这些资源是 像按钮一样，只有一个定义的操作：按下。人们已经 抱怨"只写资源"，但我没有问题 那是因为它看起来很准确。重新启动和停止按钮不会 真的有任何状态，所以你不应该期望从 "得。">
Tim 似乎在我的 #3 和 #4 选项之间解决了某个问题，暴露了多个控制器资源，但从"过火"中退缩，并为所有内容提供单独的控制器资源。
Tim的帖子引出了Roy Fielding的另一个帖子(使用POST是可以的(，他说对于存在可监控的实体状态的情况，以及可能更改该状态的操作，他倾向于使用POST而不是PUT。 为了回应评论者的建议，即将被监控的状态公开为单独的 PUT 资源，他说
"我们仅在更新操作是幂等的并且 表示已完成。我认为我们应该定义一个额外的 资源，只要我们认为该资源可能对其他人有用 隔离，并使用该资源的 GET/PUT 方法，但是 我认为我们不应该仅仅为了定义新资源 避免开邮自检。
最后，Bill de hOra在Just use POST中讨论了使用PUT与POST更新集合资源状态的具体情况，以及其中的权衡。