我有一个用户创建人员记录的表单。每个人可以有几个属性 - 身高，体重等，但他们也可以有相关数据列表，如兴趣爱好，最喜欢的电影等。在单个POST中创建复杂对象是RESTful吗？
我有一个表单，收集所有这些数据。对我来说，似乎我应该在一个请求中发布所有这些数据。但那是RESTful吗？我的阅读表明，兴趣，最喜欢的电影和其他列表应该添加在单独的POST请求中。但我不认为这是有道理的，因为其中一个可能会失败，然后会有一部分人插入，可能会失去他们的兴趣或最喜欢的电影。
我认为在一个请求中添加所有数据并不存在问题，只要它与主资源（即您的案例中的人）固有相关。如果感兴趣，最喜欢。电影等是他们自己的资源，他们也应该如此处理。
如何确定某物是否属于自己的资源？我的意思是技术上个人的利益就是事物，但他们依赖于一个人的存在。 – 2011-06-07 13:08:04
在这种情况下，我会将Person作为资源。如果一部电影是你想要单独演绎的东西（例如通过某个ID）并且只是从一个人引用它（例如从列表中选择），我认为电影应该有自己的创建，删除等手段，因此是视为独立资源。既然它只能存在于一个Person的上下文中，我认为它也可以在一个请求中处理。 – Dirk 2011-06-07 13:09:31
“如何确定某物是否属于自己的资源？” - >它拥有自己的URI。 – DanMan 2013-02-19 17:09:15
我想说它完全取决于依赖数据的可寻址性和唯一性。
如果您的用户相关数据依赖于用户（例如，“独特”字符串，例如表示电影（未经验证）名称的字符串等属性），那么它应该包含在POST创建用户表示;然而，如果数据独立于用户（其中数据可以独立于用户寻址，例如参考，诸如来自一组电影的电影），则应该独立地添加数据。
背后的推理是，与原始POST捆绑在一起时的参考添加意味着事务性;也就是说，如果另一个用户在客户端上选择了“喜欢”电影的时候删除了“喜欢”电影的电影引用，并且当POST通过时，用户添加将会（应该通过该设计）失败，而如果“最喜欢”电影不是关联的，而只是一个属性，没有什么可以失败（属性（大概）不能被第三方无效）。
再一次，这非常符合您的具体需求，但我侧重于允许部分插入和指示失败。处理这种事情的正确方法是，如果你真的不想允许部分插入，只是在后端实现事务;他们是真正处理在关键相关资源在流程中移除的情况的唯一途径。
REST中的真正限制是，对于您获取的可修改资源，您还可以转身并将相同的表示重新放回以更改其状态。或POST。因为获得大量其他资源的资源是合理的（也是非常普遍的），所以也可以把大量的东西放在一起。
非常广泛地考虑REST中的资源。他们可以与数据库行一对一映射，但他们不需要。可寻址资源可以嵌入其他可寻址资源，或者包含指向它们的链接。只要您尊重您的表示和底层协议操作的语义（即HTTP GET POST PUT等），REST就没有任何关于可能会让您的生活更轻松或更难的其他设计考虑因素的说法。
如果信息从用户的角度来看属于单一形式，那么_surely_您应该将其作为一个POST使用？如果你愿意，你可以在幕后做些聪明的事情，但是不要让客户端的交互更加复杂。 – 2011-06-07 23:59:29
@Donal：我非常不同意; RESTful设计的重要一点是客户端应该管理应用程序状态。对于任何不平凡的问题，这涉及到客户跟踪多个国家。对于“单一形式/单一POST”范例，您通过限制状态粒度来削弱客户管理状态的能力。 – 2011-06-08 16:04:08