为什么restful设计意味着区分创建和更新？

我正在做一个从MS Access到Rails应用程序的单向数据传输应用程序。我让Rails应用程序保持restful状态，因此我告诉我的同事Access应用程序需要跟踪记录是否已经发送到Rails应用程序，因为Access应用程序需要Rails应用程序中该记录的ID来进行“更新”。他怀疑这是必要的，因为，例如，如果Access向Rails人员模型发送了一条记录，其中包含Access应用程序的人员模型ID，我们称之为AID，那么如果Rails应用程序“看到”传入：name=>“John Doe”，“AID=>123”，并且没有发现“AID”等于123的人员模型，那么Rails应该创建它，当它找到一个“AID”等于123的人物模型时，就更新它

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

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

---

谢谢大家!

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

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

跟踪他是否打过电话 已经创建（这意味着你 无法删除Rails中的记录 （没有告诉他）

他需要 询问Rails应用程序 数据已经在系统中，并且 然后调用正确的API

两种选择都很糟糕

---

还有一件事要补充。这并不意味着您的服务必须首先检查记录是否已经存在。如果您希望您的使用在一次操作中发生严重偏差（即更新经常发生，但插入很少发生），那么“假设记录在那里并进行更新，如果记录不在那里，则进行插入”可能是有意义的。在许多情况下，您可能不需要关心差异，创建和更新是根本不同的概念

在许多情况下，盲目更新（并因此覆盖）记录是致命的，因为发现重复的id会导致创建失败

---

如果你的应用程序不是这样的，将来也不会这样，我想说，合并创建和更新实际上可能是好的，或者保留创建和更新方法，但提供3。api两者兼有。

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

在SQL类比中，POST是一种插入，具有自动生成的 主键，PUT是一个插入项，用于在中指定主键 INSERT语句

---

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

感谢您的帮助。事实上，我为每个控制器创建了三个单独的“access\u create、access\u update和access\u destroy”，仅用于项目的这个数据传输阶段。所以我想，当时机成熟时，我可以“拔掉”整个接入桥，而不会产生任何后果。但我想，有一个“融合”的方法来检查是否存在，然后创建或更新，这是可以的。我希望澄清一件愚蠢的事情：RESTfulRails控制器并不意味着只能有7个动作，对吗？谢谢你的回复。我认为平均而言，创建的数量与更新的数量相同。但这是一个比例，当我看数字时，我想我们谈论的是这样的事情：当一个记录被创建时（创建为1），它通常在其“有用的生命周期”中被更新一次（即，在它被计费之前；）（更新为1，因此50/50）我想让Access总是先发送一个创建，然后再发送一个更新，并使用validate_university_of:AID阻止过多的创建，从而使创建失败并继续后续更新。虽然这听起来很粗糙。是的，这不是很好，但是在你的服务中构建这种逻辑会使两个系统分离。因此，您可以对数据进行更改，而不用担心会破坏Access应用程序。另一种方式是，如果access应用程序需要记住它已经发送了信息，那么就好像你正在access DB中复制数据一样（即保持数据同步很重要）。正如您可能猜到的那样，跨多个数据库复制数据是一个真正的痛苦和糟糕的做法。再次感谢您的洞察力。我有一个很有价值的想法，那就是通过在Rails上做所有的脏活来保持Access应用程序基本上不受影响，这对我做出这样的决策是一个很好的指导。HTTP的PUT和POST方法并不是用来模拟创建和更新操作的。你可以在《谢谢你，乔纳斯》中了解更多，我现在正在阅读。感谢Lotus Notes，感谢你的发现，感谢你回到像这样的老帖子。