@lightening 我暂时还没开看你贴的视频，有时间的话会看。

如果我没有理解错，你跟楼主的意思应该都是

sendEmail 对应的是 createDelivery
moveEmail 对应的是 createTransaction

之所以会有这样的对应，是因为 Restuful 只提供了 4 个动词。有了这样的限制，我们不得不对资源名字进行变换，把 email 变成 delivery 和 transaction 。

我同意你说的，我们总是可以想办法把 API fit 进 Rest 这个框架 /风格。但是我不能认同我们应该这样做。

@noli 你看看我有没有误解你的意思。拿『移动到文件夹 X 』举例。

如果是事务的，我猜你对应的 URL 会是
post .../MoveEmailTransaction

如果不是事务的，你说会用两个 HTTP request 来实现，那对应的 URL 肯定跟上面的会有所不同。

如果我的理解是对的话，同样的一件事情，因为实现不同，对应的接口变了。在我看来，好的 API 设计应该是无论实现怎样， API 应该保持稳定。所以我会用
post .../moveEmail?source=???&&destination=???

> 但是是可行的、科学的、经得起考验的
如果因为实现的不同，需要改变 API 的设计，我不太能认同是科学的。

我的主要观点是， Restuful 提供的 4 个动词是远远不够的。在复杂的业务场景里面，如果想用这 4 个动词来表示所有操作，往往会让 API 的设计变的更加困难。

@noli 我不会这么设计我的 API 的。 Messages 这个概念，是因为 Restful 只提供了 4 个动词的一种变通。我的 Server 可能通过 Message Queue 来实现消息的传递，但这种底层的东西不应该暴露给我的客户。我需要暴露给客户的，应该是类似 send email, archive email, move email 之类的接口东西，然而这并不能通过 Restulful 来直接实现。你可参考下 AWS 的服务文档

我支持 @xgfan 说的。在逻辑比较复杂的业务场景里， Restful 提供的 4 个动词是远远不够的。

如果我有个 Email 的 Service ， GET/PUT/DELETE/POST 分别对应增删查改，那『发送』，『存档』，『移到文件夹 X 』又该如何表示呢？

可能你多个网站使用同一套账户密码？然后某个网站被拖库了（网易？），迅雷帐号也随之被『破解』了。之前我爱奇艺的帐号也是这个问题。设置了单独的密码之后，就没再被人登录过了。