前言：架构师的主要活动是做出正确的技术决策。选择正确的API是一项重要的技术决策。那么今天就来看看API的选择。应用程序编程接口(API)是一种计算接口，它定义了多个软件中介之间的交互。它定义了可以发出的调用或请求的类型、如何发出它们、应该使用的数据格式、要遵循的约定等。它还可以提供扩展机制，以便用户可以通过各种方式扩展现有功能.在不同的层次。API可以是完全自定义的、特定于组件的，或者是根据行业标准设计的，以确保互操作性。一些API必须记录在案，而其他API的设计使其可以“查询”以确定支持的功能。由于其他组件/系统仅依赖于API，因此提供API的系统可以（理想情况下）在API“背后”更改其内部细节，而不会影响其用户。如上面的定义所述，API提供了多个软件之间的交互。所以我们这里强调的是交互性。当我们使用任何一种语言开发应用程序时，我们都会提供基于该语言的内部API。这个内部的API不是我们今天要讨论的，因为这个内部的交互并不涉及软件之间。我们今天要讨论的API，主要涉及系统之间的交互。对于具体的应用，更多的是进程（本地机器）、主机（本地网络）、服务（可能是跨域WAN）之间的交互。内容：1、CORBA2、XML-RPC/SOAP3、REST4、GraphQL5、gRPC是Unix/Linux编程领域最早的，提供进程间通信的手段，如：管道、信号量、消息队列、套接字（Socket）等待。如果您的应用程序是用不同的语言编写的，您只能选择Socket通信作为应用程序之间的API方式。但是，Socket通信是一种非常底层的通信方式。它使用底层数据包作为抽象和通信内容，难以维护和使用。当然，还有其他的系统间通讯方式，比如共享文件或者FTP，同样面临着各种不便。我们希望提供一种更高级的交互方式，直接与我的应用程序的抽象交互，这些抽象可能是方法、函数和对象。所以有各种API技术支持这些需求。早期的进程间通信技术有：DCOM（DistributedComponentObjectModel）分布式组件对象模型，是微软的一项技术，只能在Windows平台上使用，通过网络实现远程对象之间的通信RMI（RemoteMethodCall)的JavaRemote方法调用，这是Java自带的RPC，只能用于Java应用程序之间的远程调用。JNIJava的本地接口支持Java应用程序调用本地方法。这跨越了语言障碍，但仅限于Java应用程序调用其他本地应用程序。它没有互操作性，是一种单向通道。1、CORBA1991年，出现了一种叫做CORBA（CommonObjectRequestBrokerArchitecture）的技术。我记得我的第一份工作是开发电信网络管理系统。我们使用CORBA来实现不同系统之间的通信。沟通。主要涉及C++和Java。CORBA类似于前面提到的DCOM和RMI，都提供远程对象/方法调用，但CORBA是一种与语言和实现无关的技术。记得当时我们的测试脚本用的是TCL，也有CORBA的实现。也就是说，CORBA为与语言解耦的系统之间的通信设定了标准。这是它最大的优势。在那个时代的应用中，使用CORBA作为系统间的通信手段是非常普遍的。开发CORAB的过程从IDL的定义开始。用户通过IDL定义对象，然后在服务器端实现对象的应用逻辑，在客户端调用对象。但是CORBA也不是没有缺点，否则我们不会很少看到今天使用CORAB作为API的应用程序。他的主要问题是：对象的生命周期管理比较复杂。远程对象的发现、创建和销毁都会带来问题。整个CORAB架构比较复杂。看看它的架构图就知道了。总之，今天如果要开发一个参考，除非你想和一个已有的系统交互，否则你不应该选择CORBA。2.XML-RPC/SOAPXML-RPC是由用户空间软件（UserLandSoftware）和微软的DaveWiner于1998年发布的。后来随着新功能的不断推出，这个标准慢慢演变成今天的SOAP协议。以下是XML-RPC请求/响应的示例：examples。getStateName40SouthDakotaSOAP是SimpleObjectAccessProtocol的缩写。SOAP为Web服务提供了Web服务协议栈的消息传递协议层。它是一个基于XML的协议，由三部分组成：一个信封，它定义了消息结构以及如何处理它一组用于表达应用程序定义的数据类型实例的编码规则用于表达过程调用和响应的约定SOAP有三个主要部分特性：可扩展性（安全性和WS-Addressing正在开发中）中立性（SOAP可以在任何协议上运行，如HTTP、SMTP、TCP、UDP等）独立性（SOAP允许任何编程语言）作为SOAP进程可以是什么的示例完成后，应用程序可以向服务器（例如，房地产价格数据库）发送SOAP请求，并为Web服务启用搜索参数。然后服务器返回SOAP响应（包含结果数据的XML格式的文档），例如价格、位置、功能。由于生成的数据采用标准化的机器可解析格式，因此可以直接由请求应用程序集成。SOAP体系结构由以下规范层组成：消息格式邮件交换模式(MEP)底层传输协议绑定消息处理模型协议可扩展性以下是SOAP消息的示例：POST/InStockHTTP/1.1Host:www.example.orgContent-Type:application/soap+xml;charset=utf-8Content-Length:299SOAPAction:"http://www.w3.org/2003/05/soap-envelope"T与XML-RPC相比，其功能更多更多，当然消息结构更复杂。SOAP是W3C推荐的Webservice标准，曾经很流行，但是我们看到基于XML的消息比较复杂，而且消息本身由于XML的原因有很多开销。所以后来就有了基于JSON的RPC格式。但总的来说，SOAP已经是过去式了，今天的应用构建你选择它的概率应该不大。3.RESTREST是当今最流行的API。因为大量的Web应用程序采用REST作为他们选择的API。REST是RepresentationalStateTransfer的缩写。它是RoyThomasFielding博士在2000年的博士论文中提出的一种万维网软件架构风格，目的是方便不同的软件/程序在网络（如Internet）中相互传递信息。表示层状态转换是基于超文本传输??协议（HTTP）确定的一组约束和属性，是一种旨在提供万维网服务的软件构造方式。符合或兼容这种架构风格（简称REST或RESTful）的网络服务允许客户端发出访问和操作具有统一资源标识符的网络资源的请求，并与一组预定义的无状态操作保持一致。因此，表示层的状态转换提供了互操作性，使得互联网的计算系统之间可以交互地使用彼此的资源。与其他类型的网络服务（如SOAP服务）相比，它们使用自己定义的一组操作来访问网络上的资源。在三大主流Web服务实现方案中，越来越多的Web服务采用REST风格设计和实现，因为REST模型比复杂的SOAP和XML-RPC更简洁。所以我们可以看到，软件的开发一般都是由复杂到简单，只有简单的东西才会变得更有生命力。为了使任何应用程序成为真正的RESTful，必须遵循六个架构约束：统一接口：意味着必须向Web应用程序中的API消费者提供API接口。客户端服务器：客户端和服务器必须相互独立，客户端应该只知道资源的URI。无状态：服务器不得存储与客户端请求相关的任何内容。客户端负责维护应用程序的状态。可缓存：资源必须是可缓存的。分层系统：架构必须是分层的，这意味着架构的组件可以位于多个服务器中。按需代码：客户端必须能够获得可执行代码作为响应。这是一个可选的约束。基于REST的Web服务称为RESTfulWeb服务。在这些应用程序中，每个组件都是一种资源，可以使用HTTP标准方法通过公共接口进行访问。以下四种HTTP方法常用于基于REST的架构：GET-对资源的只读访问。POST——创建一个新资源。DELETE-删除资源。PUT-更新现有资源/创建新资源。RESTFul风格API的所有操作都是一个动词，对应一种HTTP请求。每个操作都定义了对操作资源的特定行为。这种抽象特别适用于相当多的网络应用。后台是一个数据库，每个REST端点对应数据库中的一张表。很自然地使用REST操作来对表进行增删改查。当然，RESTFul风格也有它的缺点：并不是所有的应用操作都能对应到资源的增删改查。在实际开发中，往往需要将一个操作映射到一个资源上，这是一种不伦不类的行为。REST是一个同步服务，必要时可能会引入回调机制。例如Webhooks。REST只提供客户端调用服务端的选项，不支持服务端发起的请求。所以会出现新的API类型来解决这些问题。4.GraphQLGraphQL是一种开源的API数据查询和操作语言，并实现了相应的运行环境以实现上述操作。GraphQL于2012年由Facebook内部开发，并于2015年对外公布。2018年11月7日，Facebook将GraphQL项目转移到新成立的GraphQL基金会。GraphQL规范概述了5条设计原则，使其成为适合现代前端开发的精心设计的解决方案。让我们来看看GraphQL的设计原则。查询是分层结构的，具有分层和嵌套字段，查询与响应数据一对一匹配。查询和响应的形状像树，并且可以查询每个项目的附加嵌套字段。该结构以产品为中心，关注前端如何接收数据，并构建交付数据所需的运行时。这样你就可以向后端请求所有你需要的数据，然后让服务端按照GraphQL规范从不同端点获取数据。它使用特定于应用程序的类型系统，使开发人员能够确保查询使用有效类型并且在执行之前在语法上是正确的。GraphQL查询是在客户端指定的，因此客户端确切地知道它将以何种格式接收数据。使用GraphQL的服务器结构必须是自包含的，或者可由GraphQL本身查询。这将启用强大的开发人员工具，例如GraphiQL或GraphQLPlayground，这两种工具都将允许开发人员准确地查看服务器中哪些查询和字段对他们可用。与RESTfulAPI一样，GraphQLAPI旨在处理HTTP请求并提供对这些请求的响应。然而，相似之处仅此而已。RESTAPI建立在请求方法和端点之间的连接之上，而GraphQLAPI设计为仅使用始终通过POST请求查询的一个端点，通常使用URLyourdomain.com/graphql。一旦到达GraphQL端点，客户端请求的负担将完全在请求主体中处理。此请求主体必须遵守GraphQL规范，并且API必须具有适当的服务器端逻辑来处理这些请求并提供适当的响应。与RESTfulAPI相比，这提供了更流畅的客户端体验，RESTfulAPI可能需要客户端对多个数据发出多个请求，并在数据返回后对其进行操作。如上例所示，当用户通过RESTFulAPI请求数据时，需要两次GET请求，首先获取Assets，然后通过AssetID获取评论。使用GraphQL，用户只需要描述请求数据的结构和条件，就可以通过一次请求获取所有需要的数据，简化了客户端和服务端的交互。GraphQL提供比RESTAPI更好的性能，这可以为前端开发人员带来回报。使用GraphQL规范创建服务器可能需要更多设置和编写预测性服务器端逻辑来解析和处理请求。虽然GraphQL的安装成本可能比传统的REST架构高，但更可维护的代码、强大的开发工具和简化的客户端查询都是很好的好处。GraphQL除了灵活性的最大优势外，还有以下优势：声明式数据获取，避免客户端和服务端额外交互优秀的开发体验，不需要版本控制，因为引入新字段不会影响API查询.同时，客户端和服务器团队可以独立并行工作。强类型的GraphQL模式使代码可预测并及早发现错误。当然，GraphQL并非没有缺点：使用GraphQL，如果您需要查找有关列表或记录集合的信息，处理起来可能会很棘手。例如，如果您想获取用户列表的详细信息及其地址，那么它将执行n+1次查询。一个用于用户列表，然后n用于查询每个用户的地址。现在它会严重影响性能，因此必须非常小心地处理它。难以缓存，缓存API响应的主要目的是更快地从未来的请求中获得响应。与GraphQL不同，RESTfulAPI可以利用HTTP规范中内置的缓存。如前所述，GraphQL查询可以请求资源的任何字段，因此缓存本身就很困难。5.gRPCgRPC是一个用于服务间高性能通信的开源远程过程调用框架。这是一种连接以不同语言编写的服务的有效方式，具有对负载平衡、跟踪、健康检查和身份验证的可插入支持。默认情况下，gRPC使用Protobuf（ProtocolBuffers）来序列化结构化数据。通常，gRPC被认为是微服务架构的REST协议的更好替代方案。gRPC中的“g”可以归功于最初开发该技术的Google。gRPC是对传统RPC框架的改编。那么，它与现有的RPC框架有何不同？最重要的区别是gRPC使用protobufprotocolbuffer作为序列化和通信的接口定义语言，而不是JSON/XML。ProtocolBuffers可以描述数据的结构，并且可以从该描述生成代码来生成或解析表示结构化数据的字节流。这就是为什么gRPC是多语言（使用不同技术实现）Web应用程序的首选。二进制数据格式使通信更容易。gRPC也可以与其他数据格式一起使用，但首选protobuf。同样，gRPC构建在HTTP/2之上，它支持双向通信以及传统的请求/响应。gRPC允许服务器和客户端之间的松散耦合。实际上，客户端打开一个到gRPC服务器的长期连接，并且将为每个RPC调用打开一个新的HTTP/2流。如上图所示，gRPC支持客户端和服务端之间不同的通信方式，极大地方便了不同的互操作能力。与使用JSON（主要是JSON）的REST不同，gRPC使用Protobuf，这是一种更好的数据编码方式。由于JSON是一种基于文本的格式，因此它比protobuf格式的压缩数据重得多。gRPC相对于REST的另一个显着改进是它使用HTTP2作为其传输协议。REST使用的HTTP1.1基本上是一个请求-响应模型。gRPC利用HTTP2的双向通信功能以及传统的响应-请求结构。在HTTP1.1中，当多个请求来自多个客户端时，它们会被一个一个地处理。这会减慢系统速度。HTTP2允许多路复用，因此可以同时处理多个请求和响应。gRPC的开发模型有点类似于前面提到的CORBA。Protobuf扮演IDL的角色，然后使用工具生成各种语言的代码，最后在生成的代码上实现服务端和客户端的逻辑。gRPC的优点是：性能优异，因为它使用了protobuf编码和http/2支持服务器和客户端之间的双向通信易于使用，比REST开发需要更少的代码缺点：学习曲线更陡支持的语言类型不如休息。当然现在还在开发中，因为需要编译Protobuf，这给服务端和客户端带来了一定的耦合，因为当接口改变的时候，需要重新编译生成代码。对于REST，基于不同的工具链可能会有不同的解决方案。gRPC由于其高性能，更适用于系统内部组件的通信选型。在下图所示的微服务架构中，外部服务使用REST或GraphQLAPI，而内部微服务使用gRPC。6.总结好了，看了这么多API选项，我们来做一个总结吧。系统间的API选项已经发展了很多年，现阶段的主流是RESTfulAPI、gRPC和GraphQL。如何选择取决于您的业务环境。我的建议是：RESTFulAPI是对外提供公共服务的首选，因为它非常成熟、稳定和流行，并且有很好的语言和工具链支持。如果你想加速应用程序的客户端开发，GraphQL是一个不错的选择，它提供了良好的性能和灵活性。如果你的应用特别在意性能，主要是内部系统之间的交互，建议考虑gRPC
