您的网站不应该只提供一套通用 API

后端应该提供两套 API，一套是外部使用的通用 API，服务特定的数据，另一套是自家使用的应用 API，服务特定的页面。

在当今的web开发中，构建一个提供JSON服务的后端和一个渲染应用程序的前端是很流行的。我不太喜欢，但还好。但是如果你认为你的后端需要被设计成一个通用的公共API是不行的。这不会节省你的时间。

为什么不喜欢呢？

当你设计一个通用API时，你必须弄清楚一堆烦人的东西。

如何预测和启用所有可能的工作流
如何避免N+1请求的尴尬工作流程
如何测试每个可能的请求的功能、性能和安全性
如何在不破坏现有工作流的情况下更改API
如何在内部需求和公共需求之间确定API变更的优先级
如何记录每件事，以便各方都能完成工作

在前端，还有很多：

如何收集呈现页面所需的所有数据
如何优化对多个端点的请求
如何避免以非预期的方式使用API数据字段
如何权衡新功能的好处和新API请求的成本

如果你只是为前端制作后端，这些真的是你的问题吗?你是否必须想象每一个可能的工作流程，避免N+1请求问题，测试每个请求配置，或者在确切知道每个页面应该是什么样子的情况下拒绝使用自己的功能?你们可以看出我的意思。

那有什么建议呢

我建议你不要再把你的前端当成一些通用的API客户端，而是把它当成你应用的一半。
想象一下，如果你可以将整个“page”的JSON值发送给它。为/page/a创建一个端点，并在那里渲染/page/a的整个JSON。对每一页都这样做。不要强迫你的前端开发人员发送一堆单独的请求来渲染复杂的页面。不要用人为的限制来烦他们。
在那个JSON中，实际渲染页面。不要渲染抽象的模型和集合。渲染具体的框、节、段落、列表。渲染可视化页面结构。

{"section1": {"topBoxTitle": "Foo","leftBoxTitle": "Bar","linkToClose": "https://…"},"section2": {…}
}

这与服务器驱动的UI类似但不完全相同。也许我们可以称它为服务器通知的UI。

怎么做会更好呢？

你见过上面那些烦人的决定吗?首先，他们现在已经走了。
其次，你现在可以自由决定“我想要页面 a”，然后在后端和前端实现“页面 a”。超级简单。
不再有“我们需要引入什么API工作流才能让这个页面几乎成为可能?”。你可以让“页面 a”保持沉默，只做它需要做的事情。你把“第一页”的漏洞，安全性，性能都测试了个遍。你甚至可以在一个简单的SQL查询中获取“页面a”的所有内容。你可以缓存“页面 a”的整个JSON负载。
前端确切地知道“页面 a”有效载荷中的每个字段的用途。在字段含义上没有差异。它们完全代表了前端的需求。
当项目干系人告诉你修改“页面a”时，你可以直接修改“页面a”，而不是花很多时间来弄清楚后端API如何适应“页面a”的更改。它不是API请求编排的集合。只是“第1页”。你已经将自己从自己强加的API限制中解放出来。

您的业务逻辑现在已经从随意地在前端和后端之间划分为仅后端。你的前端终于可以专注于表现和UI了。你的后端最终可以专注于实现所需的功能。有点像目标，不是吗?

你真的试过这个吗

是的，到目前为止，我已经在几个生产项目中尝试过这种方法。其中一个是个人原因，另一个是在现有公司中持续多年的重构工作。整个团队都被说服了，结果很好。我们遇到的唯一问题是前端团队变得越来越无聊。几乎所有的业务逻辑都被剥夺了。与此同时，后端团队并没有感到“兴奋”。一切都变得有点无聊。不知怎么的，我们最终都讨论了更多的业务而不是代码。
如果你被说服了，请随时停止阅读。下一部分是对我不断听到的各种反驳的回应。