軟件接口的定義

??在我們日常工作中，提到“接口”這兩個字時，一般有兩種眾所周知的含義：其一是指軟件本身的狹義“接口”，比如各種軟件開發API等。其二則指的是人與軟件之間的交互界面,稱作“用戶界面”,也就是“UI”。
??本文中主要闡述的是第一種接口，也就是軟件接口，也稱為應用程序接口（API，Application Programming Interface），它的定義是：在規則（通訊協議）下使用某種工具（交互方式）達到軟件間的數據信息傳遞。軟件接口一般由請求協議、請求服務器地址、請求服務器地址的端口、接口地址、接口參數等幾部分構成。根據軟件接口的技術實現方式，可以將API分為以下幾種類型：RESTful接口、GraphQL接口、SOAP接口、gRPC接口、消息隊列接口、FTP接口等等。

接口的技術實現詳解

RESTful接口

??RESTful是一種架構的規范與約束、原則，符合這種規范的架構就是RESTful架構，RESTful 架構的核心規范與約束：統一接口。
??一次RESTful接口請求的消息格式樣例如下：

??在樣例中，包含以下RESTful接口相關協議信息。
??資源URL格式為 schema://host[:port]/version/path ，其中schema是指定使用的應用層協議，比如HTTP、HTTPS、FTP等；host是API服務器的IP地址或域名；port是指API服務器的端口；version是指API請求的版本；path是指API請求的資源路徑。
??資源請求分配的HTTP請求方法，除了樣例中的GET方法外，常用的請求方法還有用于服務器新增數據或資源的POST方法，用于獲取資源請求的元數據HEAD方法，用于更新服務器資源的PUT方法，用于刪除服務器資源的DELETE方法以及查詢與資源相關選項的OPTIONS方法等。不同HTTP請求方法的調用樣例如下：
GET /v1/api----獲取資源對象的集合 GET /v1/api/resource----獲取單個資源對象 POST /v1/api/resource----創建新的資源對象 PUT /v1/api/resource----更新資源對象 DELETE /v1/api/resource----刪除資源對象 ??在實際應用中，對于API請求路徑的命名通常遵循一定的規范或規律，比如將功能相近的API端點放在一起（如下所示），通過這些接口規范性的特征，讀者很容易識別出RESTful接口類的接口。 https://api.example.com/v1/model/action1 https://api.example.com/v1/model/action2 https://api.example.com/v1/model/action3

GraphQL接口

??GraphQL是Facebook推出的一種基于用戶自定義數據類型的API查詢語言和現代應用程序對接云服務的全面解決方案，我們可以理解為GraphQL是基于API之上的一層封裝，目的是為了更好，更靈活的適用于業務的需求變化，在很多場景下，可以作為REST、SOAP或gRPC的替代方案。
??下圖是一個GraphQL應用的基本架構，其中前端只和GraphQL服務層進行API交互，而GraphQL層再往后接入各種數據源。

??一個典型的GraphQL服務是通過定義類型、類型上的字段、字段的解析函數來對外部提供能力服務的。這里，以用戶admin的查詢為樣例，描述其交互過程。當請求GraphQL服務時，其查詢結構為： GET /graphql?query= {userByName(name:"admin"){idnameaddress{firstAddresssecondAddress}} } ??這不是JSON格式的數據，但它們很相似，此GraphQL查詢的表達含義如下：

• 通過用戶名admin來查詢用戶信息；
• 僅查詢id、name、address三個字段的信息；
• 對于通信地址address，需要查詢首選地址和備用地址。

??與上述請求參數對應的服務器響應為：

{"userByName":{"id":"123","name":"admin","address":{"firstaddress":"杭州","secondaddress":"寧波"}} }

SOAP接口

??SOAP API相對于其它的API技術來說，已進入了衰退期，但在企業級應用中，因歷史遺留問題仍在普遍使用著。通俗的講，SOAP接口是基于HTTP協議的XML通信技術，主要應用于Webservice接口通信。在技術實現上，一個完整的SOAP API由三部分組成：SOAP（簡單對象訪問協議）、UDDI（Web Services提供信息注冊中心的實現標準范圍）、WSDL（描述Web Services以及如何對它們進行訪問），它們之間的相互關系如下圖所示：

??WSDL為服務消費者提供了Web Services接口的詳細描述，通過解析WSDL獲取調用參數的詳細描述后，使用XML格式的數據與服務提供者進行數據交互。
??一個典型的SOAP消息，其基本格式如下所示： <?xml version="0.1"?> <soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <!--soap消息頭部--> </soap:Header> <soap:Body> <!--soap消息體--> <soap:Fault> <!--soap消息錯誤提示--> </soap:Fault> </soap:Body> </soap:Envelope> ??其中Envelope和Body為必選節點，Envelope用于標識此消息為SOAP消息，Body包含所有調用和響應的必須信息。

gRPC接口

??gRPC由Google開發，是一款語言中立、平臺中立、開源的 RPC 框架，通過Server/Client模式，使得通信中的各個應用之間像調用本地接口一樣調用遠程API。
??gRPC是可以在任何環境下運行的現代開源高性能RPC框架，它可以通過可插拔方式，有效支撐數據中心內和跨數據中心的服務鏈接，以實現負載平衡、跟蹤、運行狀況檢查和身份驗證。它同樣也適用于分布式計算的“最后一公里”，以將設備、移動應用程序和瀏覽器連接到后端服務。
??在gRPC API中，客戶端應用程序通過遠程方法調用在其它服務器的應用程序，多個RPC系統之間，圍繞API服務的思想，通過協議約定接口參數和返回類型，完成不同服務能力的組合。不同的客戶端和服務器端之間，無須考慮編程語言的不同，均參照協議約定遠程調用接口，它們之間的通信關系如下圖所示：

??在客戶端與服務器端之間，將數據（比如JSON格式數據）序列轉化為二進制編碼，然后使用Protobuf協議進行通信。gRPC API通常適用于對接口安全性或性能要求較高的場景，比如某個具備管理功能屬性的接口，想通過嚴格的gRPC API約束其調用者的范圍，則Protobuf協議恰好滿足此需求。
??Protobuf協議的消息結構是通過Protocol Buffer Language語言進行定義和描述的，其數據結構描述文件的拓展名是.proto，其示例結構如下： message Book{string name = "gRPC接口";int32 page =200;bool is_sale = 1; } ??在使用時，需要先將.proto的文件編譯，再序列化，才能在通信中使用。通俗的講，就是客戶端和服務器端通信時，先將JSON或XML格式的數據使用Protobuf技術轉換為二進制流的數據格式，再進行傳輸。

消息隊列接口

??消息隊列（MQ，Message queue）主要用來暫存生產者生產的消息，供后續其他消費者來消費。常見的MQ類型有：JMS（Java Message Service，Java消息服務，目前市場上有很多開源的JMS消息中間件，比如 ActiveMQ、OpenJMS、Kafka、Rabbit MQ）、AMQP（Advanced Message Queueing Protocol，高級消息隊列協議）、MQTT（Message Queueing Telemetry Transport，消息隊列遙測傳輸，該協議主要為嵌入式設備提供消息通信）。消息隊列的通信過程如下：

??消息隊列是分布式系統中重要的中間件，在高性能、高可用、低耦合等系統架構中扮演著重要作用。分布式系統可以借助消息隊列的能力，輕松實現以下功能：

• 解耦，將一個流程的上游和下游拆開，上游專注生產消息，下游專注處理消息。
• 廣播，一個上游生產的消息輕松被多個下游服務處理。
• 緩沖，應對流量突然上漲，消息隊列可以扮演一個緩沖器的作用，保護下游服務使其可以根據實際的消費能力處理消息。
• 異步，上游發送消息后可以馬上返回，下游可以異步處理消息。
• 冗余，保留歷史消息，處理失敗或當出現異常時可以進行重試或者回溯防止丟失。

FTP接口

??FTP接口指的是基于FTP協議，系統實現文件在網絡間的共享和傳輸。對于大數據量的交互，采用這種文件的交互方式最適合不過了。系統A和系統B約定文件服務器地址，文件命名規則,文件內容格式等內容，通過上傳文件到文件服務器進行數據交互。FTP接口交互過程如下圖所示：

其它相關知識

接口響應方式

??接口響應方式分為同步和異步兩種：

• 同步響應：指發送一個請求,需要等待返回,然后才能夠發送下一個請求，有個等待過程；
• 異步響應：指發送一個請求,不需要等待返回,隨時可以再發送下一個請求，即不需要等待。
  

??這兩種響應方式的區別是：一個需要等待，一個不需要等待，在部分情況下，我們的項目開發中都會優先選擇不需要等待的異步交互方式。

接口命名

• 接收XXXX：表示源系統主動推送數據信息給所屬系統；
• 請求/獲取XXXX：表示所屬系統主動抓取源系統數據信息；
• 發送/下發/廣播/上傳XXXXX：表示所屬系統作為源系統主動推送數據信息給外部系統；
• 反饋XXXX：表示所屬系統作為源系統被動推送數據信息給外部系統。

SAP系統接口——RFC

??RFC是SAP系統和其它（SAP或非SAP）系統間的一個重要而常用的雙向接口技術，也被視為SAP與外部通信的基本協議。簡單的說，RFC過程就是系統調用當前系統外的程序模塊，從而實現某個功能，而且調用系統和被調用系統中至少有一個必須是SAP ABAP系統。這種遠程功能調用也可在同一系統內部進行（如本地SAP系統內的遠程調用）；但通常情況下，調用程序和被調用程序處于不同系統。RFC和gRPC都屬于RPC（Remote Procedure Call，遠程過程調用）。

總結

以上是生活随笔為你收集整理的对于接口的一些认知的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。