API优先(API-first)是一个坏主意! - stilkov

20-09-11 banq

许多企业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没有提供的功能表示其能力有限,或超过其能力范围。

                   

1
猜你喜欢