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