微服务,API和创新:API的力量

大家好!



今天,我们想为您提供API学院首席架构师Mike Amundsen撰写的编程文章的译文。 在这段比较简短的文章中,Mike聪明地解释了为什么您需要特别注意开发API以及如何正确完成API。

API学院任教期间,我有机会环游世界,结识了许多很棒的人。 他们致力于各种公司的出色项目-从年轻的初创公司到成熟的全球企业。 令人难以置信的是,无论我身在何处以及与谁交谈,我们的对话中都会浮现出许多共同的想法,技巧和印象。 最常见的三种是微服务,API和创新文化。 引入这三者是为了加快组织的数字化转型。

本文是三个出版物系列中的第二篇。 在这里,我将讨论我们在API学院中根据这三种强大趋势所讲授的内容,并描述一些技巧,这些技巧将帮助您的公司从大字转为真正的转换。 在上一篇文章中,我特别关注了微服务的重要性,并着重介绍了您今天可以做的三件事:1)向连续交付的过渡,2)提供准备好的部署,以及3)减少“工作中的队列”以减少产品交付之前的时间市场。 这三个基本习惯将帮助您的组织充分利用微服务的优势。

API提供多渠道交付

许多公司使用微服务,试图以确保其可伸缩性和可靠性的方式封装其组织的关键功能。 微服务对应于公司IT组件的重要功能元素。 但这只是成功的一半。 还必须弄清楚如何提供这些机会,以便在它们的帮助下可以方便地解决您的企业当前面临的挑战。 这就是API发挥作用的地方。

对于公司信息系统的用户,API(应用程序编程接口)在计算机中的作用与图形界面相同。 通常,API用于将不同的功能混合到一个一致且负担得起的解决方案中。 例如,您的公司可能使用服务来处理与客户,帐户和销售有关的交易。 这些服务中的每一个都经过精心设计,编程,测试,然后将其发布并构建到您公司的基础架构中。 该服务提供对您的业务至关重要的功能。 一旦您需要创建一个新的解决方案以向用户介绍事物的发展过程,并且该解决方案就可以在各种设备和平台上运行。 因此,我们开始充分利用API。

可以设计一个针对解决方案进行了优化的单个API(例如,一个使用户熟悉系统的API),以便在这种熟悉阶段至关重要的最重要的交互和任务流浮出水面。 在这里,我们需要一个API,该API允许您将与客户,客户和销售相关的各种功能元素混合到安全,强大和负担得起的用户界面中,以供公司内的各种目标受众使用。 例如,销售人员可以从浏览器登录,办公室管理员可以从PC应用程序登录,而潜在客户可以从智能手机和平板电脑登录。

我们可以说API是一种“胶水”,它将程序元素结合在一起,是一个中间层,您的内部服务和外部服务使用者可以通过该中间层进行交互。 API是一种用于分发关键功能的工具,使服务使用者可以使用它,其任务是创建重要的机制,以便在各种硬件平台上与用户进行交互。 这些消费者可能包括在您的办公室工作的其他团队,与您进行远程通信的同事,重要的业务合作伙伴,甚至是参与客户端开发或设计的远程员工。

设计思维与API

大多数公司都知道,花时间为他们的应用程序开发用户界面非常重要。 因为众所周知,良好的设计会受到用户的喜爱,因此可以提高品牌忠诚度,并可以促进新业务。 同时,设计不当的界面设计可能会惹恼客户,损害品牌,减少收入并选择机会。 API设计也是如此。

如果API做得不好,那么开发人员将很难理解它,因为这样他们会在系统中引入错误并招致不必要的费用来修复错误和修改基础结构。 但是,如果API运作良好,则员工可以更轻松地有效地使用它。 创建稳定解决方案所需的时间减少了,团队甚至获得了激励,他们可以发布新颖,创新的解决方案来为客户和同事提供帮助。 API设计是如此重要的工作领域,亚马逊首席技术官沃纳·沃格斯(Werner Vogels)甚至表示:

我们立即意识到,设计API是一项非常重要的任务,因为我们只有一次尝试来正确解决它。


高质量的API可帮助吸引合作伙伴加入您的数字生态系统,并简化企业内部的企业转型。 花时间去做正确的事情的能力,从长远来看,这是一项重要技能,我们只是从那些已经学会了如何充分利用其API的公司中汲取经验。

基本的API设计技巧

正确设置API非常重要-原因很多。 发布后,将无法回滚该API。 当客户和关键业务结构依赖于您的API时,更改依赖关系可能会损坏系统的其他元素,破坏重要的功能并使您的投资和花费的时间归零。 实施API程序时,您需要牢记其他重要事项。 我只会提及少数几个。

规范API不存在

尝试“提前”为整个公司选择规范的API设计是错误的。 仅尝试在整个企业中实现一些对象和数据模型,即尝试创建一个将现在和将来无一例外地考虑到组织各个方面的API,这很可能是死路一条。 最好向开发人员提供建议并指出限制条件,以帮助他们避免错误,创造性地揭示和应用领域知识以创建对同事和合作伙伴都有吸引力的出色API。

实施过程:切断所有不必要的东西

由于API只是一个接口,而不是功能本身,因此您需要能够在几天和几周内(而不是几个月内)设计,实施,测试和部署API。 我们知道公司如何尝试降低创建API的风险,确保API可以方便地进行预先测试,自动化发布过程,从而使API本身的成本更低且更易于编写。

专注于互动,而不是整合

成功的公司可以应对的另一个关键方面是,能够教导开发团队将在设计阶段就已经与其他元素进行交互的功能集成到API中。 这些组织解释了如何使用其API;因此,此类API不仅易于理解,而且易于与该公司的其他API链接。 专注于广泛的交互比设计狭窄和紧密的集成更为重要。

您今天可以做的三件事

像进行任何重要的更改一样,此类工作也需要时间。 但是,等待成功不会花很长时间。 我将告诉您一些我必须在各家公司中遵守的三项措施,您今天就可以采取这些措施。

进行自己的API练习

API程序取得长期成功的关键因素是开发特定于技术的API设计实践。 确保此类程序不会完全依赖于使用库或平台进行编程的最新方式。 为此,依靠“第一步-API”范例是最方便的。

“第一件事就是API”意味着我们首先设计API,然后再考虑其实现细节。 原则上,无论您使用哪种技术来实现API,业务组件都是相同的:SOAP,CRUD,REST,gRPC,GraphQL或任何其他流行的东西。 实际上,一个设计良好的程序很可能使您能够分别制定与不同技术栈相关的建议,从而帮助您的团队并评估可能的节省,并使决策与平台的未来版本保持一致。

创建API时我们保证低风险

设计了高质量的API之后,就该将其变为现实了。 同时,我建议从草图开始,然后继续进行原型设计和装配模式。

大纲API就是“草图”。 较小的近似“图形”有助于给人以该API如何从开发人员的位置变成“味道和颜色”的印象。 API草图应在几小时内完成,而不是几天。 而且,在此基础上,应该获得一个可以向同事和利益相关者展示的项目,这样,第一轮讨论和第一次修改几乎不会花费任何成本。 我喜欢为此使用Apiary API模板。 它使用一种简单的标记语言,使您可以在几分钟内模拟一个正常工作的API服务器。 具体工具不是那么重要,实践很重要。 概述可帮助您进行廉价的研究,然后才开始准备完整的API。

我注意到在进行原型制作时,诸如Swagger / OpenAPI之类的工具很受欢迎。 原型是最终产品的详尽模型。 它们类似于电影的风景。 如果您不仔细看,您会看到一个真实的场景! 该团队应该能够在短短几天内准备出详细的原型。 这样的原型应自由连接到测试仪器,虚拟化服务和其他平台元素,以便您可以直接观察它如何与系统交互。 需要原型来测试它们。 在您不得不花钱创建一个真正有效的API之前,它们是您的最后一道防线。

组装阶段到此完成。 接下来,我们必须制定工作计划,确定截止日期,并开始将原型转化为产品。 我们需要一个草图和原型来确定细节,识别错误等。 构建过程本身并不那么有趣。 您只需要每天显示完成的结果,逐步实施API,直到工作准备就绪即可。 许多公司努力构建API的时间不超过90天。

三鲸管理API

最后,如果要比在特定API的设计和实现级别上更广泛地考虑这种情况,则需要遵循一个可行的程序来与组织中的API一起使用,并应用通用建议来开发所有团队都知道的API。 明确的规定使您可以控制整个企业内API的开发,而无需过多地监督实施细节。
我在API Academy的同事Eric Wilde强调了“管理API的格局”的重要性,也就是说,规范API程序的三个关键要素:协议,格式和术语。

协议规范清楚地表明了API团队在准备新版本时应支持哪些应用程序级协议。 大多数公司认为所有新的API必须支持HTTP。 一些还指示其他可选协议,例如MQTT,Thrift和其他二进制协议。 在这里,最重要的是提前通知所有团队:“如果要保证将来API的互操作性,则必须使用这些协议。” 要实施此规则,建议使用连续交付管道。

格式规范意味着您需要同意在服务之间发送数据的格式。 几乎所有浏览器都期望HTML格式的响应-就像那样,在您的API级别上,您需要确定将以哪种格式与整个生态系统进行交互。 大多数公司都喜欢简单的格式,例如JSON,XML或CSV,但是它们的消息模型缺少关键的元数据,特别是对象名称,链接和输入形式-它们对于长期交互是必需的。 另一方面,我也知道一些公司使用更高级的格式,例如HAL,Siren和基于HTTP的API的Collection + JSON。 对于服务之间的二进制交互,许多组织都以protobuf和类似格式为基础。 无论选择哪种格式,都必须在装配线中进行检查,确保只有完全符合规定的API才能投入生产,这一点很重要。

第三个API管理工具包是术语。 在这种情况下,我们正在讨论对在服务之间交换消息时使用的数据点名称和操作标识符的控制。 遵循术语,组织可能毫无疑问地认为新服务将通常被现有服务接受。 回顾Eric Evans提出的面向主题的设计(DDD)的“通用语言”,我注意到,为了讨论最关键的业务运营,需要使用您选择的术语。 在生产中使用“全新”名称表示数据字段和操作标识符的服务应该很困难。 相反,应该检查流水线中的元素是否符合整个公司所接受的通用术语,并且退出该术语的API不应投入生产。

掌握了以下这些原则:“首先-API”,“草图原型组装”和“三个API控制工具包”,您的团队将能够充分利用其API,而不会在执行过程中冒其稳定性的风险。

Source: https://habr.com/ru/post/zh-CN431176/


All Articles