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

【问题标题】：Simple CRUD endpoints Vs. more complex endpoints简单的 CRUD 端点 Vs。更复杂的端点
【发布时间】：2019-01-10 01:06:47
【问题描述】：

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

主要思想：处理复杂性应该由谁来负责 - 后端应该有额外的更复杂的端点来组合多个简单的现有端点，还是客户端（前端）应该多次调用简单的端点？

几个例子：

API 密钥再生

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

从同事的角度来看 - 应该有一个端点将这两个操作合二为一，因为如果第二个操作（添加密钥）失败，则更容易还原更改。

其他例子——当用户注册时，我们为他创建了一些嵌套对象，比如

Parent ⮑Child ⮑GrandChild

我的想法又是 - CRUD 操作的简单端点并将它们链接起来（3 次调用），如果其中一个失败，我的同事对处理失败有同样的看法。

【问题讨论】：

简而言之，假设您的端点清晰、面向资源且简单，那么您所指的复杂性应该在前端处理。处理异常，这就是应用程序在与外部或内部服务集成时应该做的事情。您的后端应该返回有意义的错误代码和消息。只要您有诸如创建或删除 API 密钥之类的操作，前端就可以在需要时调用两者或更多。

标签： rest architecture

【解决方案1】：

处理复杂性应该由谁来负责 - 后端是否应该有额外的更复杂的端点来组合多个简单的现有端点，或者客户端（前端）是否应该对简单端点进行多次调用？

如有疑问，请查看网络。你觉得谷歌搜索简单吗？亚马逊一键下单怎么样？

总的来说，REST 是关于将您的实现细节隐藏在网站/文档存储的外观后面。对于你是否使这种伪装变得简单或复杂，这几乎是不可知的。

看看 Jim Webber 在REST with domain models 上的演讲。

【讨论】：

【解决方案2】：

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

从您所说的示例中回答密钥重新生成，重新生成意味着应删除旧密钥并返回新的有效密钥。万一第二次失败，第一次修改应该在你的后端恢复。即，这两个步骤都应被视为单个事务。如果不是这种情况，拥有单独的 API 就足够了。

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

【讨论】：