前言：

架构师的架构主要活动是做出正确的技术决策。选择合适的师该API是一项重要的技术决策。那么今天就看看API的何为合适选择问题。

应用程序编程接口(API)是应用一种计算接口，它定义了多个软件中介之间的选择交互。它定义了可以进行的架构调用或请求的类型，如何进行调用，师该应使用的何为合适数据格式，遵循的应用约定等。它还可以提供扩展机制，选择以便用户可以以各种方式扩展现有功能。架构在不同程度上。师该API可以是何为合适完全定制的，特定于组件，应用也可以基于行业标准进行设计以确保互操作性。选择有些API必须记录在案，而其它API则经过设计，以便可以“查询”它们以确定支持的功能。云南idc服务商由于其他组件/系统仅依赖于API，因此提供API的系统可以(理想地)在API的“后面”更改其内部详细信息，而不会影响其用户。

正如上述的定义所述，API提供了多个软件之间的交互。所以我们这里强调的是交互性。我们在使用任何的语言开发一个应用的时候，都会提供内部的基于该语言的API，这种内部的API不是我们今天要讨论的内容，因为这种内部的交互不涉及到软件之间。我们今天要讨论的API主要要涉及到系统之间的交互。对于具体应用而言，更多是进程之间(本机)，主机之间(本网络)，服务之间(可能跨域广域网)的交互。亿华云计算

目录：

1、CORBA

2、XML-RPC / SOAP

3、REST

4、GraphQL

5、gRPC

最早在Unix/Linux的编程领域，提供了进程间通信的手段，例如：管道，信号量，消息队列，套接字(Socket)等。如果你的应用是由不同语言编写的，那么这里只能选择Socket通信作为应用之间的API手段。但是Socket通信是一种非常低Level的通信手段，它以底层的数据包作为抽象和通信内容，很难维护和使用。当然还有一些其它的系统间通信的手段例如通过共享文件或者FTP的方式，同样面临着各种不便。我们希望提供一种更高级的交互手段，源码库直接和我的应用的抽象交互，这些抽象可能是方法，函数和对象。于是就有了各种支撑这些需求的API技术。

早期的进程间通信技术包括：

DCOM ( Distributed Component Object Model )分布式组件对象模型，这个是微软的技术，只能用于Windows平台， 通过网络实现远程对象间的通信 RMI ( Remote Method Call) Java的远程方法调用，这个是Java自己的RPC，只能用于Java应用之间的远程调用。 JNI Java的本地接口， 支持Java应用调用本地方法，这个是跨越语言障碍的，但是仅仅局限于Java应用调用其它的本地应用，不具备互操作性，是个单向通道。

1.CORBA

在1991年一种名叫CORBA ( Common Object Request Broker Architecture ) 的技术出现了，我记得我的第一份工作是一个电信网管系统的开发，我们就是利用CORBA来实现不同的系统之间的通信。主要涉及C++和Java。

CORBA和之前提到的DCOM和RMI类似，都提供了远程的对象/方法调用，但是CORBA是一种与语言和实现无关的技术，我记得我们当时的测试脚本使用了TCL，也有CORBA的实现，也就是说CORBA定了与语言解耦的系统间通信的标准。这个是它的最大的优势。那个年代的应用，采用CORBA作为系统间的通信手段非常普遍。

开发CORAB的过程从IDL的定义开始，用户通过IDL定义了对象，然后在Server端实现该对象的应用逻辑，在Client端调用该对象。

但是CORBA并非没有缺点，否则我们也不会很少再看见今天的应用用CORAB作为API的了。他的主要问题是：

对象的生命周期管理比较复杂。远程对象的发现，创建和销毁都会带来问题 整个CORAB的架构比较复杂，看看它的架构图就知道了

总之，今天你要开发一个引用，除非要个已有系统交互，你应该不会选择CORBA。

2.XML-RPC / SOAP

XML-RPC发表于1998年，由UserLand Software(UserLand Software)的Dave Winer及Microsoft共同发表。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协议

下面是一个 XML-RPC的请求/响应的例子：