许多企业IT部门已成为“ API优先”策略的忠实拥护者。我认为总的来说，这是一个坏主意。
当您开始使用API时，您必须非常了解API使用用户的需求。API优先则可能导致你不会这样做，取而代之的是，您尝试提出“显然”可以重用的东西，最后得到甚至没有用的东西。
最常见的是，API受其封装的基础系统功能的影响，如果这些封装很棒，那就太好了，但通常不是。
API优先策略的假设前提是：通过“仅仅编排”API公开的功能来构建出色的应用程序。对于某些应用程序是正确的，但对于许多应用程序却不是，通常对于出色的应用程序而言并非如此。
除非API是您提供给外部客户的实际产品，否则通过在最终用户和业务逻辑之间放置API边界（以及由此产生的Conway法则影响）而创建的人为鸿沟会带来很多痛苦，并且几乎没有价值。
在许多情况下，以API为中心的策略标志着战略者不希望面对实际的最终用户及其需求。创建其他人必须组装的可重用服务要容易得多，甚至为此创建元策略也要容易得多。
我将现代企业IT战略中的大部分灾难归咎于这样的事实，就是像我这样的人：后端架构师对UI / UX方面的关注太少了，因为这些架构师被控制得太久了。
您需要一种用于模块化应用程序交付的策略，不仅要包括最终用户的需求，还要从最终用户的需求开始。API是达到此目的的一种有意义的手段。
如果您将API作为产品（例如，作为SaaS提供程序）提供，则将开发人员视为最终用户。如果不是这种情况，那么：您的最终用户不在乎API，因此您不应将它们放在中心地位。
众说纷纭：
完全同意。我从事付款工作。我们引入了一套付款API，在引入ux / ui时的第一个试验就完全失败了。用户要做的第一件事是验证帐号，但API不能验证帐号。
如果您曾经遇到过《 Hyrum定律》中提到的问题，那么API优先甚至意义不大：/->合同中的承诺无关紧要，系统中所有可观察到的行为都将取决于某人。 https://hyrumslaw.com
我一直相信客户会推动API的发展。一切都是由客户端的驱动来询问客户。自下而上的设计很容易出错。
IT无法构建满足需求/期望结果的东西并不是什么新鲜事。工具，技术和体系结构发生了变化，但问题仍然令人沮丧。
所有内容都是正确的。但是，我遇到的许多API-First练习者都是与利益相关者共享模拟，并尽可能早地模拟现实世界实现中发生的一切。不确定为什么API-First意味着没有UI /最终用户参与吗？
我对“ api优先”的思考方式更多地是“ api消费者优先”。api必须说出消费者的语言，并满足消费者的需求。这与自下而上的设计形成鲜明对比，后者在后端定义了数据模型和粒度。
基于实体的CRUD服务应遵循标准模式。查询方面需要针对用例进行定制，以便消费者可以轻松访问需要的数据。简介：构建支持您的用例的API，而不是后端服务可以提供的API。
大多数企业并未意识到..必须关注用户和用户需求，什么时候构建或什么时候不构建基于API的生态系统？这种区分对待是很重要的。
banq评：这也是体现DDD和面向对象不同之处，面向对象重在封装和重用，但是如果没有上下文，这种封装和重用可能是短视的，只从封装和重用角度设计API，这种API优先设计法肯定会有问题。DDD和OO是有区别的：抽象名称选择很重要？
DDD+微服务==>API，将业务领域的能力共享给消费者，消费者可以根据UI/UX要求组合有选择性的使用这些能力，API没有提供的功能表示其能力有限，或超过其能力范围。