当您在 REST 中需要更多动词时该怎么办

还有一个类似的question https://stackoverflow.com/questions/2001773/understanding-rest-verbs-error-codes-and-authentication对我来说，但讨论偏离了我遇到的问题。

假设我有一个处理费用报告 (ER) 的系统。您可以创建和编辑它们、添加附件以及批准/拒绝它们。

费用报告可能如下所示：

GET /er/1
=>
{"title": "Trip to NY", "totalcost": "400 USD",
 "comments": [
   "john: Please add the total cost",
   "mike: done, can you approve it now?"
   ],
 "approvals": [
   {"john": "Pending"}, {"finance-group": "Pending"}]
}

看起来不错，对吧？这就是费用报告文档的样子。

如果你想更新它，你可以这样做：

POST /er/1
{"title": "Trip to NY 2010"}

如果您想批准它，您可以这样做：

POST /er/1/approval
{"approved": true}

但是，如果您想更新报告怎么办and同时批准吗？我们该怎么做呢？如果您只想批准，那么做一个POST类似的东西/er/1/approval说得通。

我们可以在 URL 中添加一个标志，POST /er/1?approve=1，并将数据更改作为正文发送，但该标志似乎不是 RESTful。

我们也可以设置要提交的特殊字段，但这似乎也有点老套。如果我们这样做了，那么为什么不发送具有以下属性的数据：set_title or add_to_cost?

我们可以创建一个用于更新和批准的新资源，但是（1）我无法想到如何在没有动词的情况下命名它，并且（2）根据可以执行的操作来命名资源似乎不正确它（如果我们添加更多操作会发生什么？）

我们可以有一个 X-Approve: True|False 标头，但标头似乎不适合这项工作。如果不在浏览器中使用 javascript，也很难获得设置的标头。

我们可以使用自定义媒体类型，application/approve+yes，但这似乎并不比创建新资源更好。

我们可以创建一个临时的“批量操作”url，/er/1/batch/A。然后客户端发送多个请求，也许POST /er/1/batch/A更新，然后POST /er/1/batch/A/approval批准，然后POST /er/1/batch/A/status结束批次。在后端，服务器将所有批处理请求排队到某处，然后在收到“结束批处理”请求时在同一后端事务中处理它们。显然，这样做的缺点是它引入了很多复杂性。

那么，有什么好的通用方法可以解决在单个请求中执行多个操作的问题呢？通用是因为很容易想象在同一请求中可能执行的其他操作：

1. 禁止或发送通知（发送至电子邮件、聊天、其他系统等）
2. 覆盖一些验证（最高成本、晚宴参加者姓名）
3. 触发文档中没有表示的后端工作流程。

这也是一个性能问题。 HTTP 调用会访问网络（如果您的延迟较高或连接不稳定，这可能会成为问题），因此您可以进行的调用越少越好。

REST 架构表示资源由服务器管理并由 URL 标识。

在那样的光线下/er/1/approval不是一个合理的 URL 或模型，除非您有在服务器端管理和操作的批准对象或实体。在我看来，该实体就是费用报告本身，这意味着，/er/1是你的 URL 路径。

现在，至于动词...您可以将任何您喜欢的消息发送（POST）到该资源。

设置数据：

{ action: "modify", data: { purpose : "Club hopping" } }

批准：

{ action: "approve" }

新增项目：

{ action:"additem", data: { amount:72.13, category:113, note:"client dinner" }}

etc.

From Fielding 的 Ch5，定义了 REST http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm,

（请求的）内参数由请求控制数据、指示请求目标的资源标识符和可选表示组成。

...和...

控制数据定义组件之间消息的用途，例如请求的操作或回应的意义。它还用于参数化请求并覆盖某些连接元素的默认行为。例如，可以通过请求或响应消息中包括的控制数据来修改缓存行为。

因此，如果您想对资源执行多个操作，那么您应该在“控制数据”中嵌入多个消息或操作请求。在我的示例中，发布的数据类似于：

{ action: "modify", data: { purpose : "Club hopping" } }
{ action: "approve" }

但你可能想概括一下，这样它就是：

{ actions: [ {action:"modify", data: {...} }, { action:"approve"} ] } 

您的服务器可以对每种特定类型的实体处理的消息或操作由您定义。

ps：有时 REST 实现使用 HTTPPUT创建资源并POST修改或作用于现有资源。

并且：我喜欢这篇文章，如何获得一杯咖啡 http://www.infoq.com/articles/webber-rest-workflow.