API设计不等于REST
在Web API(2000-2010)的早期,API设计的概念
与Roy Fielding关于建筑风格和
基于网络的软件体系结构设计的论文非常相关。如果您正在讨论API设计,那么所有对话都很快就会
使用HTTP,制作您的URI以及使用您的HTTP动词 - 早期的RESTafarians确保了这一点。
超媒体设计模式
除了以HTTP为中心进行API设计对话的讨论外,一小部分API架构师正在推动我们如何制作API的请求和响应,这些API是根据网络建模并称为超媒体。这个新的API技术人员专注于应用RESTful设计原则,同时还深入考虑了他们提供的资源之间的结构和关系,并且深入地考虑了如何在客户端级使用这些资源。
即使对于API的技术细节以及对API请求和响应的精心制作提出了强烈的意见,对话也主要在一组独立的开发人员中进行。更广泛的商业和企业开发人员团队往往不了解设计的细微差别,需要更多的文档才能理解并使API设计实践在他们的世界中发挥作用。一种名为Swagger的新的API文档工具即将出现,这将有助于通过对最新API文档的需求向开发人员介绍API设计。
定义通用设计模式
2012年,随着API空间的不断涌现,API定义格式(以前称为Swagger(现在称为OpenAPI))正在帮助我们标准化我们如何围绕API进行通信。但另一个API服务提供商出现了一种定义API的新方法,其重点在于设计而不仅仅是生成文档。Apiary以他们定义称为API Blueprint的API的新方式来到现场,该API强调了模拟,测试,文档甚至部署API的设计。在开发的艰辛工作之前,这种设计API的新方法将开启API设计的新时代,在这个时代,它不仅仅是REST或超媒体,而且正在迅速成为沟通,协作和共享您的整个API生命周期中的API设计。
Swagger和API Blueprint开启了一个全新的API设计世界,使得开发人员之间可以进行更加标准化和共享的对话,了解API设计不仅仅是REST和超媒体。老实说,我不觉得大多数开发人员甚至都准备好了超媒体,API定义格式允许一些关键的网络素养教给大批开发人员,让每个人都为超媒体设计的未来做好准备。我们现在有一个共同的语言来定义,协作和共享API设计惯例,为API增长创造了不仅仅是API数量的阶段,包括我们对API的期望以及最终我们应用(或不是) 。
提供完整的API生命周期
正在使用API定义来设计API,可能会考虑其他现有的API设计模式,所有这些都可以与其他利益相关方共享,从而将API设计过程演变为一组工作。生成的API定义可以用作模拟,部署,管理,测试,监控,发现和生成代码的中心事实。这种开发软件的新方法不仅仅是推动网络和移动应用程序,还包括越来越多的
个人和职业生活中的设备。API设计不再是一套设计模式,现在可以包含更广泛的实践和规范,为新的思维方式打开了大门。
运行时设计解决方案
许多API只是后端数据库的一个外观,因此,随着API驱动更多的Web和移动应用程序,前端开发人员需要更多的访问和控制后端资源是很自然的。现代的Web API设计方法在为后端数据库提供查询,过滤和发送指令的访问方面表现不错,但访问大型,非常复杂的数据和内容后端的新方法已经出现,并且被采用。GraphQL由Facebook开发,现在由GitHub和其他公司使用,让开发人员能够更好地控制他们访问的数据,从而允许他们在运行时为任何应用程序设计确切的API响应 - 将API设计卸载到前端开发人员,共享后端开发人员的负担。
性能设计
除了GraphQL,由于它正在为大数据问题提供API解决方案,谷歌一直在制定自己的API交付方法,但这次侧重于性能和大批量API的交付。Google采用gRPC交付高容量,高性能API的方法不断增长,允许开发人员使用名为Protobuf的描述格式设计新一代API。在谷歌,RESTful API和gRPC并肩共存,共享一个通用的API定义,设定一套协调的API设计目标,允许部署两种截然不同的设计模式来实现不断变化的目标。
多样的API设计工具箱
API设计工具箱已经扩展。在我们看到的大多数API中,RESTful方法仍然是首选的设计模式。然而,越来越多的超媒体API出现,帮助提供更多基于体验的API,其行为与客户端应用程序中的Web非常相似。GraphQL在单页应用程序使用以及服务大数据和复杂内容应用程序的应用程序之间不断增长。再加上专业的API设计工具集,gRPC正在数据中心和大型企业中获得更多关注,并且正在推动像Spanner数据库平台这样的新一代工具。一个真正强大的API设计工具箱已经出现,帮助API设计人员和架构师准确地提供他们在各种用例中所需的解决方案。
设计物联网
有迹象表明,领先的API设计模式已经超越了网络和移动设备,并被应用于物联网(IoT)这个日益增长的世界。我们已经开始将REST和超媒体模式应用于设备API,作为IoT平台和服务工程的一部分。API设计已经摆脱了其教条式的RESTful根源,并且越来越关注如何准确找到工作所需的设计蓝图。配备API设计模式的移动设备在为消费者,商业和工业IoT实施提供数字资源时提供了相当广泛的门。
沟通对于设计至关重要
事实证明,API设计不仅仅是技术细节,而且所有这些动作都必须具备的基本要素之一是能够围绕通用的API设计模式进行交流 - 如果我们无法共享,交流和协作一套共同的设计规则,这个概念永远不会获得牵引力并且会被采纳。这就是为什么像OpenAPI这样的API定义在API设计对话中扮演着重要的角色,因为它们允许我们围绕一组通用的设计模式进行通信。这种沟通是API数量增长的关键,也是开发人员在通用API设计模式中意识到和了解的人数的关键。
API设计是API合同
在过去的五年中,API设计很快成为定义API操作的技术,业务和政治方面的合同,这反过来又推动了网络,移动和设备应用。API设计使用API定义格式进行量化,这些格式已经从XML演变到JSON,变成更易于理解的YAML,从而使API设计成为更易于使用的规则。业务利益相关者现在可以在帮助敲定API合约的细节,可用的数据以及如何在API中访问和使其可用中发挥作用。
API设计不仅仅是REST。这不仅仅是开发者的领域。API设计涉及所有参与者,围绕着讨论驱动网络,移动设备,网络和设备应用程序所需的内容。在这种环境下,API合同可以用简单的英文打包,定义使数据,内容和算法可用于跨分布式应用程序的技术,业务和法律方面。API设计已经成为遵循一套共同的,明确定义的最佳实践,同时能够沟通,协作,共享并最终实现设计策略的。最重要的是,API设计已经超越了单一方法的成熟,允许出现一个强大的工具箱,并且可以在几乎任何情况下应用各种蓝图。