“低耦合高凝聚”，“信息隐藏”：众所周知的设计原则。尽管如此，它们在许多软件体系结构中并未得到重视，尤其是在前端和后端之间的交互方面。
API对于隐藏信息很有价值
通过提供API系统，可以确定将哪些信息公开给外界以及将哪些信息保密（信息隐藏）。
为什么这么重要？因为API越广泛，维护起来就越昂贵。考虑一下公开每个实现细节的极端情况。系统中的每个更改都可能破坏使用该代码的客户端。这就是我们努力拥有小型API的原因。
但是，API都会阻止我们自由开发系统。我们始终必须仔细记录API，并考虑不要破坏我们的客户。必须以向后兼容的方式引入更改，否则我们必须调整我们的系统的部署，而这些部署很快就会变成一个庞大的部署地狱。
API作为产品
但是，如果很难维护它们，为什么系统会提供这么多的API？原因之一可能是API是系统的唯一卖点。API是赚钱的产品。在这种情况下，使用诸如超媒体之类的技术并关注向后兼容性。您的客户将不胜感激，并且您的API产品大放异彩。
前端和后端的分离的API
后端和前端之间的凝聚很自然，因为每当需要在前端显示一些新数据时，都需要调整后端。那么，为什么我们要通过在它们之间放置一堵墙（API）来使它们分离呢？
在大多数情况下，这种设计是由组织或技术环境决定的。有专门的后端和前端团队，但是我想知道在决定分离团队时是否总是考虑维护API的开销。
使用客户端渲染的愿望
另一个驱动使用API因素是希望使用现代Javascript UI库（例如Angular，React或Vue.js）来实现前端。与服务器端呈现（SSR）方法相反，这些库在浏览器中的客户端（CSR）处呈现视图，并依赖于后端提供的服务（REST，GraphQL等）来检索数据并执行操作。
尽管我认为SSR现在被大大忽视低估了，但是...使用现代javascript库库并不一定需要API！由于后端代码是在服务器端执行的，而前端代码是在用户的浏览器中执行的，因此您在技术和环境方面都遇到了麻烦。此中断需要使用REST或GraphQL才能同步两个环境。
我称其为桥梁而不是API，因为您可以与前端携手发展后端服务。无需仔细记录API或处理重大更改，因为那里只有一个客户端。这个客户端是众所周知的，因为它位于同一系统中。结果是后端和前端始终部署为一个整体，而这些文档和兼容性方面的挑战就消失了。
结论
技术不应成为系统设计的驱动力。关于后端和前端之间的交互，请考虑需求，并确定是要使用整体式前端还是独立式系统。“低耦合-高凝聚力”是有力的指导方针！
如果您决定使用一个独立的系统，则取决于您选择服务器端还是客户端渲染方法。尽管CSR和SPA（单页应用程序）经常被合并在一起，但是您仍可以使用CSR，同时仍具有每个模块的前端。
banq：该文观点有点偏颇，前端有安卓app 苹果app和html app等各种客户端，如何降低这些不同客户端对后端的耦合，这是需要松耦合，而不是考虑它们的高凝聚，松耦合高凝聚不能只从一个角度考虑，该文只从业务角度考虑，但是在业务领域的聚合是存在上下文边界之内，不是跨上下文边界，API是前端和后端的DDD防腐层。