前言

本系列將是本人的一些開發經驗總結。由於身處金融IT因而因業務需求需要和銀行介面打交道，恰巧最近公司有個專案和這有很大的關係，下面我們將著重從基於HttpClient介面開發的技術點+基本業務點說起。這算是公司內部比較機密的東西因而不能做過多的說明。本系列以後牽涉到的概念的業務邏輯都將是最基本的，核心的實現的邏輯不陳述。

概述

本系列陳述的將是基於HttpClient介面開發的例項，在實際的需求中和案例中Server間介面的資料傳輸方式有很多種比如Http(HttpClient)/WebService/Socket等等。

• 使用場景
  
  • Http：介面間的資料傳輸使用Http比較多一點。即指定Protocol 為Http
  • WebService：Server與Server之間的通訊使用WebService多一點比如WSDL。
  • Socket：多數應用場景為Server 與 Client 之間的通訊，在Server和Client之間指定一對埠，然後接一個Socket再然後指定一下Protocol，然後雙方就可以通訊了。

HttpClient && JSON

首先基於HttpClient之間的介面開發需要在介面之間做一些約定，簡而言之就是一些通訊規則，若是不規範的通訊將不予以處理或者直接通訊失敗。介面間常用的規則和約定有通訊方式、規則和約定、安全方式、交易模式等等。下面我們將以一對基於HttpClient 傳輸JSON報文的例項來陳述。

• 通訊方式

  • 後臺
    雙方約定介面的通訊方式比如採取的Https Post方式來傳輸JSON資料報文。
  • 頁面
    在一些實際的業務需求中雙方可能會用到彼此的頁面或以H5的頁面展示或者其他的頁面形式展示，因而雙方約定頁面間的通訊方式比如Https。
  • 檔案
    在一些場景下Server間的可能會使用檔案傳輸協議來滿足一些實際的業務需求，因而雙方也許約定系統間的檔案傳輸協議比如Https。

• 規則及約定

  • 報文規則
    報文采用JSON格式來傳輸介面資料，對於一些必須出現的Mandatory欄位必須上送，一些可選出現的Optional欄位可上送可不上送。

  • 欄位約定
    在上送的JSON point中，需要對欄位型別做約束，比如：char、date、time、decimal…

  • 編碼方式
    需要指定報文的編碼方式比如UTF-8

  • 欄位長度計算說明
    欄位長度的計算說明：所有長度均按位元組計算，中文算三個位元組，英文、數字算一個位元組。

  • 特殊欄位說明

  • 報文結構

    • 請求報文
      一個完整的請求報文應包含頭部和報文主幹部分，我們稱之為Header和Body。

    • 應答報文
      對於一個應答報文而言，必須包含頭部，即Header部分，Body部分可有無。

  • 加簽加密,解密解籤說明
    這是介面間通訊保證資料正確完整傳輸的最最關鍵環節。很多基於HttpClient的介面通訊都必須要做到一點，處理請求報文使用祕鑰加密加簽，處理應答報文使用公鑰解密驗籤。此處便牽涉到一個非對稱加密解密的概念，對於不太瞭解非對稱加密的同學請參考官方文件。在實際的業務需求實現中我也將會詳細說明一個非對稱祕鑰在介面通訊間的使用的例子。這裡不贅述。

• 安全方式
  在實際的JSON請求或者應答報文中有一些敏感資訊是需要加密傳輸的，此外之前我提到的加簽加密，解密解籤的規則也需要雙方約定好。
  比如現在有一個完整的請求報文，我們需要對它的Body做TreeMap排序(升序或者降序)，然後通過加時間戳按一定規則生成一個明文字串A，然後將該明文字串使用我們的自己的祕鑰加簽並生成一個明文加簽之後的字串B或者陣列B，然後再對B使用一定的加密規則(一定是可逆的比如Base64)生成一個密文C，再將這個密文C放到請求報文的Header中(通常而言我們稱之為簽名)。
  對方在收到我們的請求報文之後首先會校驗報文的完整性，然後獲取Header中的簽名C1和時間戳T1，並按照雙方約定的機密演算法解密得到一個字串或者陣列B1，然後再使用我們提供的公鑰驗簽得到一個原生的明文字串A1，然後對整個請求報文的Body做逆運算，本例子：將Body做TreepMap排序，然後結合T1按一定的規則生成一個明文的字串A2，最後將A1和A2作比較，若一致則表示驗籤成功，資料正確完整地傳輸，否則表示驗籤失敗，驗籤失敗有一些原因比如生成的簽名沒有嚴格按照雙方約定執行，或者在資料in-the-fly的過程中被篡改或者丟失。只有在驗籤的成功情況下在處理該次請求，否則不處理。

• 交易模式
  在HttpClient的請求中有兩個通訊模式一個叫同步請求，另一個叫非同步請求。對於什麼是HttpClient的同步和非同步請求，網上有很多例子的說明，這裡不贅述。下面我們所說的系統間的同步交易和非同步交易將會和如上的同步非同步存在著本質的區別。下面我將討論一下三種基本的交易模式。

• 後臺同步交易
  
  說明：首先A平臺使用HttpClient通訊請求將資訊傳送至B平臺，B平臺處理並返回響應報文；若A等待響應報文超時可再次發起同步請求。

• 後臺非同步交易
  
  說明：首先A平臺發起同步請求(需要C平臺介入處理的請求)，B平臺同步響應該次請求結果，同時B會將該次請求交至第三方處理C平臺處理，第三方把處理結果返回給B，然後B將通過呼叫和A約定好的非同步回撥介面把第一步請求的介面返回給A平臺，A平臺收到請求之後將第五步的處理結果返回給B。
  在整個請求的處理過程中從第二步完成之後到第四步完成可能會需要一定的時間段，因而A/B平臺不能實時開著執行緒I/O去等待響應，於是用過非同步介面回撥的方式把非同步處理結果返回。其中1-2步和5-6使用HttpClient同步請求，3-4用一些基於protocol的方法進行資料互動，因而整個請求處理過程而言可以看做是一個非同步交易。
• 對賬類交易
  
  說明：對於對賬類交易的實現是基於HttpClient 同步請求和系統間同步請求完成的。A和B間完成檔案傳輸有兩種情況，第一種是B主動推送檔案通知訊息報文請求，A平臺同步響應，第二種是A平臺主動發起檔案狀態查詢，B平臺同步響應。雙方經過以上”握手”響應之後B向A發情Https 檔案傳輸請求。

小結

• 對於介面間資料通訊的開發，雙方需要制定一些規則以確保雙方間的通訊過程中資料的完整和可用。這些規則例如：HttpClient JSON/報文加簽/敏感資訊加密/….
• 對於實際的業務實現，可根據雙方實際情況而定，唯一可以確定的是任何一個業務邏輯的實現都是基於以上規則進行的。
• 在實際的開發過程中，建議先將整個專案的連貫起來，然後再去做逐個的實現。