REST是否破坏了数据封装？

Question

我正在尝试理解RESTful API的范围和限制。我的具体问题是:我如何使用REST处理公开操作而不是资源的API？我是否应该放弃公开操作的诱惑，重新考虑API来公开数据(资源)。来自OOP，感觉就像是对对象封装的公然违反。

假设您需要公开一个REST API来完成资金转移:将一笔金额从一个帐户转移到另一个帐户。如果我理解REST，这两个帐户应该作为资源公开，并且必须在这两个资源上调用两个不同的更新操作。对我来说，这明显违反了数据封装。我倾向于创建一个API来建模“转账”操作，而不是资源“帐户”。我可以创建一个执行“数据传输”的REST API吗？它不再是REST (因为它似乎不是以资源为中心的)。

对于这种情况，RPC调用看起来比REST更合适，您有什么看法？

谢谢

Answer 1

我认为迁移本身就是一种资源，有自己的生命周期。我们可以放置一个转移资源(在业务术语中)来启动转移。转账资源为账号资源，其他资源为RESTful。

我们可以获得传输资源，以便确定其状态。

例如，如果某些信息不完整，我们甚至可以发布资源的更新。

Answer 2

这真的取决于你的喜好。以纯粹的REST方式定义您的APIS，或者使用一些宽松的方式由您决定。

REST标准化了定义API的方式，以便于维护。

例如，在SOAP时代，如果你必须使用create/modify/delete帐户，就会有三种不同的接口定义，比如createAcct。updateAccount，deleteAccount.

现在使用REST，您只需定义一个/accounts/，并假定GET、PUT、POST和DELTE 方法执行相应的操作。

为了回答您的问题，可以通过两种方式定义API

1) - /accounts/1234/transfer/或将json body *{to_account:1212，amount:1221}*作为请求的一部分发布。这不是一种纯粹的REST方式

。因为您正在将action定义为API的一部分。

type 2)- /accounts/1234/transactions - json body *{：transfer，to_account:1212，amount:1212}*-这是纯粹的REST方式，因为事务是您将在系统中创建的一种新资源。

对于许多rest apis来说，纯REST方式是有例外的。其中一个例子就是‘'resetpassword’‘。尝试使用firebug破解一些apis，您将对此有大致的了解