简单的CRUD端点Vs。更复杂的端点

Question

与同事（前端）进行了讨论，讨论应该由谁来负责处理复杂性，我们并没有真正得出结论。

主要思想：应对复杂性应由谁负责-后端应具有结合了多个简单现有端点的其他更复杂的端点，还是客户端（前端）应多次调用简单端点？

夫妇的例子：

API密钥再生

从我的角度来看-非常简单-有一个端点可以删除密钥并创建密钥，客户端应该只调用这两个端点，特别是因为有一个扩展想法以支持每个最终用户多个密钥。

从同事的角度来看-应该有一个将这两个动作组合为一个的端点，因为在第二个动作（添加键）失败的情况下还原更改更容易。

其他示例-用户注册时，我们为他创建了一些嵌套对象，例如

Parent ⮑Child ⮑GrandChild

我的想法再次是-用于CRUD操作的简单端点并将其链接（3个调用），如果其中一个失败，我的同事也有处理失败的观点。

Answer 1

  

应该负责处理复杂性-后端应该具有结合了多个简单现有端点的其他更复杂的端点，还是客户端（前端）应该对简单端点进行多次调用？

如有疑问，请上网。您认为Google搜索很简单吗？亚马逊一键订购怎么样？

总体而言，

REST是关于在网站/文档存储的幕后隐藏您的实现细节。无论您将这种伪装变得简单还是复杂，都与之不可知。

看看吉姆·韦伯（Jim Webber）在REST with domain models上的演讲。

Answer 2

客户端或服务器的处理复杂性取决于您尝试开发的实际用例。

从您陈述的样本中获取KEY的再生结果，Regeneration意味着应删除旧的密钥，并应返回新的有效密钥。如果第二个失败，则第一个修改应在您的后端恢复。即两个步骤都应视为单笔交易。如果不是这种情况，那么拥有单独的API就足够了。

另一个示例是，如果要删除的资源数量为“ n”，则客户端可能会循环调用/ resources / $ resource_id- HTTP DELETE ，这反过来可能会打击您的数据库'n'次。因此，考虑到后端资源的优化，最好的方法是支持在单个API中删除多个资源。例如：/ resources？ids = 1,2,3,4- HTTP DELETE