本文转载自 The New Stack。
特写图片来源:Pixabay。
本文是系列博文(共四篇)的第二篇。
第一篇文章介绍了企业如何为打造 API 优先文化奠定基础。API 正在革新我们的技术,调整公司发展方向,并促进重要技术变革。API 优先公司别具竞争力,可推动行业创新。因此,企业如何转向 API 优先思维模式是一个需要重点考虑的事项,即使对于非 API 即产品公司也是如此。
本系列文章的第二篇将继续介绍打造 API 优先文化流程的第二阶段(设计和创建)。API 优先文化的设计和评估方式为其在 API 经济的第三次浪潮中所发挥的效用树立了标准,在此次浪潮中,API 将继续推动企业告别单体基础设施,转而更好地利用技术。
在 API 优先文化进程的第二阶段,企业将设计并创建 API 规则手册、制定设计原则和设置基础设施,然后邀请利益相关者参与塑造新文化,并继续推进 API 优先进程。
要真正做到 API 优先,企业必须就如何设计 API 达成共识,并制定一套规则。首先,确定一般设计原则。下面列举两个示例:
其他规则可能要求节约使用字符,这意味着 API URI 结构中的每个字符都要有用,任何无关字符(如正斜杠)都会破坏 URI 调用。这些原则应以一个问题为统领,即用户将如何使用和编写此 API?按理说,内外部用户的使用和编写方式应该是一样的。尽管这些听起来像是常识性的基本设计原则,但建立基本预期和准则至关重要。
注:不妨也让安全团队参与进来,并征求他们对 API 设计模式的意见,从而减少受攻击面并降低风险。
规则虽然枯燥,但却必不可少。草率的 API 设计会带来很多问题。虽然开发人员从未打算草率设计一个 API,但时间压力或合作伙伴要求等因素可能会对设计选择产生负面影响。选择您希望企业支持的 API 类型:REST、GraphQL、gRPC 或 SOAP(一种在运行传统系统时仍然有用的旧有 API 结构)。针对您决定支持的每种 API,制定一份设计指南,列出具体的设计标准(URI 结构、模式等)。
您可以使用现有负载均衡器、反向代理或 ADC 来管理和保护 API;但这需要额外的功能。API 有别于标准流量请求,因为它是机器对机器,并有着不同的消费模式。保护外部 API 需要采用一种新的思维方式,因为默认情况下,外部 API 是通过在安全边界上“打洞”(Punch a Hole) 来开放服务,类似于通过防火墙的 Web 流量。就 API 而言,可能会有许多端口用于不同的用途和服务,每个端口都有自己的一套预期和允许的业务逻辑。对于内部 API,如果您计划将关键业务功能转移到这些 API,那么实施适当的性能管理也同样重要。内部 API 流量和管理均应在在公司网络内进行,否则会危及安全。
有目共睹的成功案例将激励人们创建和深入研究 API 文化。理想情况下,这些成功案例需要使用创新产品或特定业务日常依赖的核心功能。最好是创建一个多元化项目,其中涵盖内外部用例以及一系列具有不同要求的服务类型。
在创建该项目的同时,还要为 API 优先进程的预期发展和演进设定明确的目标,从而获得对 API 经济感兴趣并高度重视其发展的高级管理人员的支持。确保创建者和开发人员等最重要的利益相关者乐于参与其中,成为企业内部的 API 关键人物。
在开源技术方面,Comcast 和微软等公司都设立了大使计划,明确了不同开源领域的内部专家。这些专家将作为顾问,为其他希望为开源项目贡献代码的员工提供帮助。类似的大使计划广受推崇,并在数十家公司成功实施。API 大使可帮助培训刚刚接触 API 的开发人员,助力他们掌握 API 规划和构建流程。
另一种常见的策略是开办内部 API 大学和系列培训课程。理想情况下,这些课程应侧重于实际 API 项目。在这些项目中,开发人员将构建企业将于近期实际部署的方案。
遵循上述阶段和步骤可帮助您提高 API 成功几率。关键是在将技术和产品开发过渡到 API 优先思维模式和执行框架时,采取切实的全面方法。与技术采用进程一样,奖比惩更有效。类似于重大模式转变,您需要考虑如何满足面向 API 的团队的需求,包括开发人员和 DevOps 以及负责锁定 API 的基础设施和安全团队。在任何时候成为 API 优先公司都为时未晚,这样您就可以在创建产品和功能时尽享转向模块化 JTBD 方法所带来的优势。
API 优先公司不仅能够提高效率和敏捷性,而且还可增强开发人员和小团队的自主权,从而高效构建并完全拥有自己的服务。正因如此,身为原生 API 公司的科技巨头能够快速采取行动和迭代,亚马逊每年能够推出数十款全新云产品。
好消息是推动自身 API 转型并无不可告人的秘诀,唯一需要的就是明智的规划和合理的步骤。
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."