我正在尝试了解 RESTful API 的范围和限制。我的具体问题是：如何使用 REST 处理公开操作而不是资源的 API？我是否应该放弃暴露操作的诱惑，重新考虑 API 来暴露数据（资源）。来自 OOP，感觉像是对对象封装的公然违反。
想象一下，您需要公开一个 REST API 来进行汇款：将一笔金额从一个账户转移到另一个账户。如果我理解 REST，这两个帐户应该作为资源公开，并且必须对这两个资源调用两个不同的 UPDATE 操作。对我来说，这感觉像是对数据封装的明显违反。我的倾向是创建一个模拟“转账”操作而不是资源“帐户”的 API。我可以创建一个执行“数据传输”的 REST API 吗？那不再是 REST（因为它似乎不是以资源为中心的）。
对这种 RPC 调用看起来比 REST 更合适的场景有何评论？
谢谢
我认为转移本身就是一种资源，具有自己的生命周期。我们可以 PUT 一个转移资源来（在商业术语中）发起一个转移。转账资源指账户资源；引用其他资源的资源是 RESTful 的。
我们可以获取传输资源以确定其状态。
我们甚至可以 POST 对资源的更新，例如，某些信息不完整。
这真的取决于你的喜好。以纯 REST 方式定义您的 APIS 或采取一些宽松的方式取决于您。
REST 标准化了定义 API 的方式，以便于维护。
例如，在 SOAP 时代，如果您必须创建/修改/删除帐户，则会出现三种不同的 api 定义，例如createAcct。更新帐户，删除帐户。
现在使用 REST，您只需定义一个/accounts/，并且假设GET、PUT、POST和DELTE HTTP 方法执行相应的操作。
要在您的案例中回答您的问题，API 可以通过两种方式定义
1) - /accounts/1234/transfer/或将 json 正文 *{to_account:1212,amount:1221}* 作为请求的一部分。这不是纯粹的 REST 方式
. 因为您将操作定义为 API 的一部分。
2) - /accounts/1234/transactions - post json body *{type:transfer, to_account:1212, amount:1212}*- 这是 PURE REST 方式，因为事务是您要在系统中创建的一种新资源。
对于许多 REST API，纯 REST 方式存在例外。示例之一是“重置密码”。尝试使用 firebug 破解其中的一些 api，您将获得一个大致的了解