为什么宁静的设计意味着区分创造和更新？答案

【问题标题】：why restful design means to differentiate create and update?为什么宁静的设计意味着区分创造和更新？
【发布时间】：2011-07-23 05:49:24
【问题描述】：

我正在做一个从 MS Access 到 Rails 应用程序的单向数据传输应用程序。我让 Rails 应用程序保持安静，所以我告诉我的同事 Access 应用程序需要跟踪记录是否已经发送到 Rails 应用程序，因为 Access 应用程序需要 Rails 应用程序中该记录的 ID做“更新”。他怀疑这是必要的，例如，如果 Access 使用 Access 应用程序的人员模型 ID 向 Rails 人员模型发送一条记录，我们称之为 AID，因此如果 Rails 应用程序“看到”传入的“:name => 'John Doe', :aid => 123", 并没有找到 'AID' 等于 123 的 Person 模型，然后 Rails 应该创建它，当它确实找到 'AID' 等于 123 的 Person 模型时，然后更新它.

我告诉他设计很安静，保留两个单独的调用（一个带有 post 一个带有 put）是一件“好事”；带有“put”的那个需要调用即将更新的记录的ID。

但是他有一些好点子，为什么我们要区分创建和更新，而不是在一种方法中合并它，在这种方法中检查记录是否已经存在可以确定它是创建还是更新？

谢谢！

【问题讨论】：

HTTP 的 PUT 和 POST 方法并不等同于 Create 和 Update 操作。您可以在stackoverflow.com/questions/630453/put-vs-post-in-rest 了解更多信息
谢谢乔纳斯，我正在阅读。

标签： rest

【解决方案1】：

关于 POST 与 PUT 的以下链接给出了更全面的描述：

http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/

在 SQL 类比中，POST 是一个自动生成的 INSERT 主键，PUT 是一个 INSERT，它指定了主键 INSERT 语句。

如果您的所有主键都是自动生成的，那么差异可能无关紧要。对于那些希望客户端能够选择主键的人来说，区别就在那里，例如，如果它不仅仅是一个整数（可能是一个 GUID 或文本标识符）。

【讨论】：

感谢 Lotus Notes，感谢您找到并返回这样的旧帖子。

【解决方案2】：

我同意你同事的观点。最终，服务应该易于使用并为调用者完成艰苦的工作。强迫调用者记住是否需要创建或更新是很烦人的。

在我看来，为了让他知道是调用 Create 还是 Update 意味着他需要要么

跟踪他是否打电话已经创建（这意味着您无法删除 Rails 中的记录应用程序而不告诉他）
他需要询问 Rails 应用程序是否数据已经在系统中，并且然后调用正确的 API。

这两个选项都很糟糕。

还有一件事要补充。这并不意味着您的服务必须始终首先检查记录是否已存在。如果预计您的使用会因一项操作而严重倾斜（即更新经常发生，但插入很少），那么“假设记录在那里并进行更新，如果它失败 b/c 记录不是”可能是有意义的在那里，然后执行“插入”。

【讨论】：

感谢您的回复 Mlathe。我认为平均而言，创建与更新一样多。但这就是比例，当我查看数字时，我认为我们正在谈论诸如创建记录时（因此创建为 1），它通常在其“有用生命周期”中更新一次（即，在它之前）已计费；）（所以 1 也用于更新；因此是 50/50）我考虑让 Access 总是先发送创建然后发送更新，并使用 validate_uniqueness_of :AID 来抵御过多的创建，以便创建失败并继续接下来的更新。不过，这听起来很骇人听闻。
是的，这不是很好，但是在您的服务中构建该逻辑可以将两个系统解耦。因此，您可以更改您的数据，而不必担心您可能会破坏 Access 应用程序。另一种看待它的方式是，如果访问应用程序需要记住它已经发送了信息，那么就好像您在访问数据库中制作数据的副本（即，保持它们同步很重要）。正如您可能猜到的那样，跨多个数据库复制数据是一种真正的痛苦和不好的做法。
再次感谢您的洞察力。让我知道我的预感是通过在 Rails 上完成所有肮脏的工作来保持 Access App 基本不变，这对我来说很有价值，这对我做出这样的决定是一个很好的指导。

【解决方案3】：

虽然在许多情况下您可能不需要关心差异，但创建和更新是根本不同的概念。

在很多情况下，盲目地更新（并因此覆盖）一条记录是致命的，因为发现重复的 id 而导致 Create 失败。

如果您的应用程序不是这种情况，并且将来永远不会，我会说合并创建和更新实际上可能没问题 - 或者可能保留创建和更新方法但提供 3. api两者兼而有之。

【讨论】：

感谢您在这里帮助 Leeeroy。事实上，我为每个控制器创建了三个单独的“access_create、access_update 和 access_destroy”，只是为了项目的这个数据传输阶段。只是为了让我想，到时候，我可以“拔掉”整个 Access 桥接器而不会产生任何后果。但是我想可以，然后，有一个“融合”的方法来检查是否存在，然后创建或更新。我希望弄清楚一件愚蠢的事情：RESTful rails 控制器并不意味着只能有 7 个动作，对吧？