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