Question

我与一位同事讨论了添加/删除条目的逻辑应如何运作。

所以问题是对象具有以下属性

{
   foo: []
}

在foo列表中添加更多内容后，用户可以单击“保存”

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

所以下次对象看起来像

{
   foo: [1, 2, 3]
}

此时用户删除1然后重新添加。然后点击保存。什么都不应该发生。

单击“保存”时会发生对REST方法的实际调用。

我的同事说，为了简化客户端的事情，它应该只需要调用添加的REST方法。 REST方法应该再次添加所有条目。所以他希望add方法基本上删除与该对象相关的每个条目，然后重新添加所有这些条目。

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

为了使添加的REST方法能够完成它的工作，它会添加新条目，而不会删除所有条目，然后添加所有条目。

调用REST方法的示例

Add
POST: REST/{objectId}?entries=1,2,3

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

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

结果条目= [2,3]

Answer 1

＆＃34; ..我认为应该在客户端解决..＆＃34;

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

Answer 2

我的同事说，为了简化客户端的事情，它应该只需要调用添加的REST方法。 REST方法应该再次添加所有条目。所以他希望add方法基本上删除与该对象相关的每个条目，然后重新添加所有这些条目。

我不同意这一点。想象一下你有10k条目，为什么删除9 999条目只是为了删除一个项目？

我反对这是因为它做了不必要的工作。

你是对的。此外，您可能会对数据库执行不必要的请求，并且会对其进行访问。

客户端必须不知道这个逻辑。它没有所有元素来决定在资源中添加或删除元素。因此，客户端要求API执行操作，如果操作完成，API会回答它。

如果你把API放在后端你的API更可重用。明天，你有另一个API客户端，为什么要重写客户端添加或删除的逻辑？通常，它是一样的。

Answer 3

所以，我们假设你现在有

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

调用POST方法：

REST/{objectId}?entries=1,2

会发生什么？根据您的描述，我认为它会导致

{ foo = [1, 2] }

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

现在，另一方面，如果您希望结果是

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

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

这是一个有趣的例子，因为你操纵“子资源”而不是资源本身（在你的例子中是{...}，包括foo）。