我的应用程序交易要求用户在使用服务之前进行注册，并且他们创建应用程序。界面的初始计划如下......
POST /Users/Applications - 创建一个应用程序并返回一个唯一标识符。
GET /Users/Applications/{id} - 检索现有应用程序。
PUT /Users/Applications/{id} - 更新现有应用程序。
DELETE /Users/Applications/{id} - 删除现有的应用程序。
这似乎非常干净和合乎逻辑，并充分利用HTTP动词。但是，如果我现在需要在应用程序上执行其他操作，例如
ActivateApplication - 一旦所有数据都在系统中使用PUT，我现在希望用户激活他们的应用程序。这不仅仅是使用PUT更新应用程序状态的问题，还有一些额外的工作要激活应用程序，例如通过电子邮件发送HR部门。告知他们新的申请已经到达。
PrintApplication - 从客户端调用时将应用程序打印到办公室打印机。 （不是一个理想的例子，但你明白了我的想法！）
我如何构建我的REST接口来处理这种类型的请求？也许是这样的......
POST /Users/Applications/{id}/print
POST /Users/Applications/{id}/activate
...激活我正在改变状态所以我相信我需要使用POST。我理解REST是关于文档的，但是当我需要对文档执行操作时，如何构建我的API，而不仅仅是获取和更新文档本身？
答案 0 :(得分：2)
This Martin Fowler的文章指出： 有些人错误地在POST / PUT和创建/更新之间建立对应关系。他们之间的选择与此截然不同。
当我尝试在PUT和POST之间做出决定时，我遵循下一条规则：
PUT - ＆gt;幂等
POST - ＆gt;不是幂等的
幂等意味着执行一个和多个操作之间没有区别。在第一次操作之后和每次其他操作之后，DB数据将是相同的。
如果是非幂等操作，则每个执行的操作都会更改数据库中的数据。
这就是为什么PUT通常用于UPDATE操作和POST用于CREATE的原因。但这不是正确的规则。
回到你的问题，在我看来你正确使用POST作为一种非幂等的动作，因为多次调用ActivateApplication会发送多封电子邮件。
<强>被修改
正如@elolos评论的那样，按照单一责任原则，发送电子邮件应该是另一个与更新状态没有直接关联的责任。 当属性发生变化时触发事件以触发发送电子邮件等过程将是一种更好的方法。这样 ActivateApplication 操作可以是幂等的，并使用PUT Http方法调用。