我有一个用户创建个人记录的表单。每个人都可以有几个属性 - 身高，体重等。但他们也可以有相关数据列表，如兴趣，喜欢的电影等。
我有一个表单，其中收集了所有这些数据。对我来说，似乎我应该在一个请求中发布所有这些数据。那是RESTful吗？我的阅读建议应该在单独的POST请求中添加兴趣，喜爱的电影和其他列表。但我不认为这是有道理的，因为其中一个可能会失败，然后会有部分插入人物，可能会错过他们的兴趣或喜欢的电影。
答案 0 :(得分：4)
我要说它完全取决于相关数据的可寻址性和唯一性。
如果您的用户相关数据依赖于用户（即“不同”字符串，例如表示电影（未经验证的）电影名称的字符串等属性），那么它应该包含在POST创建中用户表示;但是，如果数据独立于用户（数据可以独立于用户进行寻址，例如参考，例如来自一组电影的电影），那么它应该是独立添加的。
这背后的原因是，与原始POST捆绑在一起时的引用添加意味着事务性;也就是说，如果另一个用户在客户端选择它并且POST通过之间删除了“收藏”电影的电影参考，则用户添加将（应该通过该设计）失败，而如果“喜欢”电影不是关联的，而只是一个属性，没有什么可以失败的（属性（推测）不能被第三方无效）。
同样，这非常符合您的特定需求，但我倾向于允许部分插入并指示失败。如果你真的想要不允许部分插入，处理这类事情的正确方法是在后端实现事务;它们是真正处理在流程中间删除关键相关资源的唯一方法。
答案 1 :(得分：3)
REST中的真正限制是，对于您可以获得的可修改资源，您也可以转向并将相同的表示返回以更改其状态。或POST。由于GET资源是其他东西的大捆绑是合理的（并且非常普遍），所以将PUT大量的东西也很合理。
非常广泛地考虑REST中的资源。它们可以与数据库行一对一映射，但它们不必。可寻址资源可以嵌入其他可寻址资源，或包含指向它们的链接。只要您尊重您的表示和底层协议操作的语义（即HTTP GET POST PUT等），REST就其他可能使您的生活更轻松或更难的设计考虑因素无话可说。
答案 2 :(得分：2)
我不认为在一个请求中添加所有数据存在问题，只要它与主要资源（即您的案例中的人）本身相关联即可。如果有兴趣，最喜欢。电影等是他们自己的资源，他们也应该这样处理。