如果资源与其他资源有关系，如何设计RESTful API？

Question

假设我有2个资源，Account和User。当有人注册时，/account的POST会创建一个帐户。但Account和User之间存在如下关系：

1. User属于Account
2. Account有很多users
3. User是Account中的外键约束（即，如果没有account我无法创建User）

因此，对/account的POST请求将创建Account和User。在这种情况下，它是否违反RESTful原则，因为我创建/修改2个资源而不是仅仅一个？

为了讨论，假设Account和User的创建必须在事务中发生（即如果User无法创建，则Account也不会被创建）。

如何设计一个RESTful API来修改与其他资源有关系并且必须在单个事务中发生的资源？

Answer 1

对于一个更新其他资源的资源更新没有REST原则，但是您应该通知客户端响应中更新的资源。

考虑以下内容（我引用Fielding的RESTful principles行）：
＆＃34;资源是对一组实体的概念映射，而不是与任何特定时间点的映射相对应的实体。＆＃34;

想象一下资源/last_user，它返回有关从另一个资源/book_info请求信息的最后一个用户的信息。现在，只要客户端使用/book_info，资源/last_user就会更新，甚至无法通过/last_user资源完成此更新。

关于更新其他资源的资源更新的设计，请考虑以下事项：

• ＆＃34;任何可以命名的信息都可以是资源＆＃34;包括＆＃34;其他资源的集合＆＃34;。
• ＆＃34; REST将所有控制状态集中到为响应交互而收到的表示中。＆＃34;
• ＆＃34;默认情况下，对检索请求的响应是可缓存的，对其他请求的响应是不可缓存的。＆＃34; ＆＃34;组件可以通过包含控制数据来覆盖这些默认值，这些控制数据仅在有限的时间内将交互标记为可缓存，不可缓存或可缓存。＆＃34;

实际上，在回复后包括更新资源（例如创建的帐户和用户）的（完整）详细信息，并指出“可缓存的”＃34;。有关此练习的更多信息，请查看this answer及相关问题。

单个事务要求是服务器端实现细节，我想在大多数情况下，资源的创建和/或更新将导致涉及创建和/或更新多个（相关）数据库记录的单个数据库事务（例如审计记录）。