REST API约定以事务方式更新2个不同的资源

Question

我有一个包含多个资源的 REST API。有一种情况需要更新两个不同的资源。这两者具有一对一的关系，必须以事务方式更新。

假设我们有用户和房屋资源。您更喜欢哪种选择或认为这是最好的方法？我想知道哪种方式在尊重 REST API 设计约定的同时更不易出错。

选项 1

定义一个端点，它将用户和房屋作为主体并将其更新为事务。

[PUT] BASE/users/houses/update
{
  "user": {...},
  "house": {...}
}

选项 2

定义两个单独的端点，每个端点分别更新自己的资源并处理错误。

[PUT] BASE/users/:id
{
 ...
}

[PUT] BASE/houses/:id
{
 ...
}

解决方案

根据 Evert 的建议，我定义了一个名为 landlords 的虚拟资源，并且更新以事务方式发生。 REST端点如下:

[PUT] BASE/landlords
{
  "user": {...},
  "house": {...}
}

Answer 1

我认为很多人都陷入了 REST 必须是 CRUD 的陷阱，但实际上您并不局限于此。

与其考虑两个需要更新某些属性的实体，不如尝试考虑“意图”。如果有一个明确的“意图”，该意图具有更新多个实体的副作用，并且它们应该一起成功或失败，那么最好将其公开为单个操作。

尽管普遍认为，RPC 又名“提交表单”并不反 RESTful。许多复杂的系统最终需要将突变与读取状态分开。

也就是说，这个模式:

PUT /users/houses/update
{
  "user": {...},
  "house": {...}
}

感觉不对，因为从 HTTP 的角度来看，这建议您“替换“更新”端点”。您应该:

• 尝试提出一个同时代表用户和房屋的 URI/资源。
• 在这些情况下采用 POST。