Database 决策逻辑是客户端的责任还是服务器端的责任？

我与一位同事就添加/删除条目的逻辑应该如何工作进行了一些辩论

所以问题是一个对象有以下属性

{
   foo: []
} 

向foo列表添加更多内容时，用户可以单击保存

其中调用REST方法以在foo属性中添加新条目

所以下一次这个对象看起来像

{
   foo: [1, 2, 3]
}

用户这次删除1，然后重新添加它。然后单击保存。 什么都不应该发生

单击save时，实际调用REST方法

我的同事说，为了简化客户端的工作，它应该只需要调用REST方法，而REST方法确实添加了。REST方法应该再次添加所有条目。因此，他希望add方法基本上删除与该对象相关的所有条目，然后重新添加所有条目

我反对这样做，因为它做了不必要的工作。我可以编写逻辑来检查哪个条目是新条目。然而，由于这是一个业务类的应用程序，我不认为将该逻辑放在服务器端是一个好主意，因为成本太高。相反，我认为应该在客户端解决这个问题

因此，要添加的REST方法执行它所执行的操作，它添加新条目，而不是执行两项操作，即删除所有条目，然后添加所有条目

调用REST方法示例

结果条目=[1,2,3]

Remove
DELETE: REST/{objectId}?entries=1

结果条目=[2,3]

。。我认为应该由客户方来解决

我不同意。REST服务应该是一个黑盒，客户端不必知道添加或删除项的逻辑，这是服务器的责任

我的同事说，为了简化客户端的工作，它应该只需要调用REST方法，而REST方法确实添加了。REST方法应该再次添加所有条目。因此，他希望add方法基本上删除与该对象相关的所有条目，然后重新添加所有条目

我不同意这一点。假设你有10k个条目，为什么只删除一个条目就删除9999个条目

我反对这样做，因为它做了不必要的工作

你说得对。此外，您可能会对数据库执行不必要的请求，从而影响对数据库的访问

客户一定不知道这个逻辑。它没有所有元素来决定向资源中添加或删除元素。因此，客户机要求API执行一个操作，如果该操作完成或未完成，API将对此进行回答

---

如果您将逻辑放在后端，那么您的API将更加可重用。明天，您将拥有另一个API客户端，为什么要在客户端重写添加或删除的逻辑？通常情况下，情况是一样的。

那么，让我们假设您当前有

{ foo = [1, 3, 4] }.

调用POST方法：

REST/{objectId}?entries=1,2

会发生什么？根据你的描述，我想这会导致

{ foo = [1, 2] }

不是[1,2,3,4]。如果是这样的话，那么我认为你的同事是对的。您必须删除现有项，然后重新添加新指定的项。在这种情况下，您的REST方法真的应该被放置而不是POST

另一方面，如果你希望结果是

{ foo = [1, 2, 3, 4] }

不是[1,2]，那么您的方法似乎更合理。在这种情况下，REST方法在语义上似乎比POST更接近补丁

---

这是一个有趣的示例，因为您正在操作子资源，而不是示例中的资源本身{…}，其中包括foo。

除了您的答案，我想说的是，后面的工作是查看要删除/添加的项目是否相同，因此忽略请求。所以你们两个的意思是相同的REST方法应该有责任？你和同事之间的辩论似乎很有趣。但是，为了更好地理解这场争论，你能给我们一些关于你的REST方法的具体例子吗？@realharry补充说example这也是我的想法，但我想它归结为处理添加内容和删除内容过滤的逻辑应该在哪里。我也希望它能在客户端

{ foo = [1, 2, 3, 4] }