目錄
概述
技術方案
接口
消息服務傳輸
文件共享
socket傳輸
數(shù)據(jù)庫傳輸
數(shù)據(jù)爬取
IT系統(tǒng)對接是很多企業(yè)、項目必須面對的問題；通常，多個系統(tǒng)之間如果完全企業(yè)自主定制開發(fā)，且有源代碼、服務器的所有權，可以選擇數(shù)據(jù)庫直傳的方式，方便快捷。如果系統(tǒng)之間存在權限限制或技術限制，可采用接口以保證數(shù)據(jù)的安全和對接的規(guī)范性等等，不同的場景下有不同的對接方案，以下對常用的對接方案做出匯總。
接口對接方式是比較常用，且安全規(guī)范的傳輸方式，一般需要根據(jù)詳細需求開發(fā)定制接口，以滿足系統(tǒng)間信息的對接。
一、傳統(tǒng)WebService與Restful
接口一般可分為兩種方式實現(xiàn)，一是傳統(tǒng)web service接口，二是restful 風格的web service接口，二者區(qū)別主要由以下幾點：
1. Restful Web Service的開發(fā)是面向資源的，而WebService則是面向方法。
2. Restful Web Service以Http協(xié)議作為應用協(xié)議，對資源的操作基于Http協(xié)議的幾個關鍵方法“Get，Post，Put，Delete（204），Head，Patch，Options”，而Web Service則將方法信息封裝在SOAP信封里經由Http的Post方法發(fā)送給服務端。這一區(qū)別的結果就是Restful Web Service利于緩沖（符合Web方式，利于GET緩沖），而Web Service在緩沖方面則表現(xiàn)出了極大的短板，因為緩沖服務器根本不知道SOAP里邊的方法是不是Get，以及真實的請求資源是什么。
3.有關安全控制方面，對于基于代理服務器實現(xiàn)的安全控制，一般代理服務器是根據(jù)URL以及請求方法來確定該用戶是否擁有相關操作權限的，很明顯Restful Web Service貼近Web方式滿足要求，而基于SOAP的Web Service實際的方法信息無從知曉，不具備實現(xiàn)安全控制的條件。
總結：WebService比較成熟，在涉及到復雜的業(yè)務邏輯，事務例如轉賬，用戶等級劃分等業(yè)務邏輯的處理上要優(yōu)于Restful Service。而Restful Web Service由于是無狀態(tài)的，在構建分布式應用的時候不用考慮用戶Session，所以在構建分布式應用時靈活度更高，但在涉及到授權方面則略遜于前者（借助OAuth實現(xiàn)授權）。此外由于Restful Web Service以Http為應用協(xié)議其資源狀態(tài)的轉變方法有限（Http的七種方法），如果需要其他的方法只能借助已經實現(xiàn)方法擴展的第三方框架實現(xiàn)復雜操作而Web Service則可以定義自己的方法。總體來看Restful Web Service更易于構建簡單的基于資源的分布式應用，而Web Service則適用于業(yè)務邏輯復雜，對系統(tǒng)安全性要求更高的大型企業(yè)級應用構建。
二、接口設計-共通
如果采用SOA體系架構，通過服務總線技術實現(xiàn)數(shù)據(jù)交換以及實現(xiàn)各業(yè)務子系統(tǒng)間、外部業(yè)務系統(tǒng)之間的信息共享和集成，因此SOA體系標準可作為采用的接口核心標準。主要包括：
服務目錄標準
服務目錄API接口格式參考國家以及關于服務目錄的元數(shù)據(jù)指導規(guī)范，對于W3C UDDI v2 API結構規(guī)范，采取UDDI v2 的API的模型，定義UDDI的查詢和發(fā)布服務接口，定制基于Java和SOAP的訪問接口。除了基于SOAP1.2的Web Service接口方式，對于基于消息的接口采用JMS或者MQ的方式。
交換標準
基于服務的交換，采用HTTP/HTTPS作為傳輸協(xié)議，而其消息體存放基于SOAP1.2協(xié)議的SOAP消息格式。SOAP的消息體包括服務數(shù)據(jù)以及服務操作，服務數(shù)據(jù)和服務操作采用WSDL進行描述。
Web服務標準
用WSDL描述業(yè)務服務，將WSDL發(fā)布到UDDI用以設計/創(chuàng)建服務，SOAP/HTTP服務遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs 實現(xiàn)新的業(yè)務服務，根據(jù)需求提供SOAP/HTTP or JMS and RMI/IIOP接口。
業(yè)務流程標準
使用沒有擴展的標準的BPEL4WS，對于業(yè)務流程以SOAP服務形式進行訪問，業(yè)務流程之間的調用通過SOAP。
數(shù)據(jù)交換安全
與外部系統(tǒng)對接需考慮外部訪問的安全性，通過IP白名單、SSL認證等方式保證集成互訪的合法性與安全性。
數(shù)據(jù)交換標準
制定適合雙方系統(tǒng)統(tǒng)一的數(shù)據(jù)交換數(shù)據(jù)標準，支持對增量的數(shù)據(jù)自動進行數(shù)據(jù)同步，避免人工重復錄入的工作。
2.1接口規(guī)范性設計
系統(tǒng)平臺中的接口眾多，依賴關系復雜，通過接口交換的數(shù)據(jù)與接口調用必須遵循統(tǒng)一的接口模型進行設計。接口模型除了遵循工程統(tǒng)一的數(shù)據(jù)標準和接口規(guī)范標準，實現(xiàn)接口規(guī)范定義的功能外，需要從數(shù)據(jù)管理、完整性管理、接口安全、接口的訪問效率、性能以及可擴展性多個方面設計接口規(guī)格。
1）接口定義約定
客戶端與系統(tǒng)平臺以及系統(tǒng)平臺間的接口消息協(xié)議，本次以基于HTTP協(xié)議的REST風格接口實現(xiàn)為例，如下圖-接口消息協(xié)議棧示意圖：
系統(tǒng)在http協(xié)議中傳輸?shù)膽脭?shù)據(jù)采用具有自解釋、自包含特征的JSON數(shù)據(jù)格式，通過配置數(shù)據(jù)對象的序列化和反序列化的實現(xiàn)組件來實現(xiàn)通信數(shù)據(jù)包的編碼和解碼。
在接口協(xié)議中，包含接口的版本信息，通過協(xié)議版本約束服務功能規(guī)范，支持服務平臺間接口協(xié)作的升級和擴展。一個服務提供者可通過版本區(qū)別同時支持多個版本的客戶端，從而使得組件服務的提供者和使用者根據(jù)實際的需要，獨立演進，降低系統(tǒng)升級的復雜度，保證系統(tǒng)具備靈活的擴展和持續(xù)演進的能力。
2）業(yè)務消息約定
請求消息URI中的參數(shù)采用UTF-8編碼并經過URLEncode編碼。
請求接口URL格式：{http|https}://{host}:{port}/
{app name}/{business component name}/{action} ；其中：
協(xié)議：HTTP REST形式接口
host：應用支撐平臺交互通信服務的IP地址或域名
port：應用支撐平臺交互通信服務的端口
app name：應用支撐平臺交互通信服務部署的應用名稱
business component name：業(yè)務組件名稱
action：業(yè)務操作請求的接口名稱，接口名字可配置
應答的消息體采用JSON數(shù)據(jù)格式編碼，字符編碼采用UTF-8。
應答消息根節(jié)點為“response”，每個響應包含固定的兩個屬性節(jié)點：“status”和“message”。它們分別表示操作的返回值和返回消息描述，其他的同級子節(jié)點為業(yè)務返回對象屬性，根據(jù)業(yè)務類型的不同，有不同的屬性名稱。
當客戶端支持數(shù)據(jù)壓縮傳輸時，需要在請求的消息頭的“Accept-Encoding”字段中指定壓縮方式(gzip)，如消息可以被壓縮傳輸則平臺將應答的數(shù)據(jù)報文進行壓縮作為應答數(shù)據(jù)返回，Content-Length為壓縮后的數(shù)據(jù)長度。詳細參見HTTP/1.1 RFC2616。
應答消息根節(jié)點為“response”，每個響應包含固定的兩個屬性節(jié)點：“status”和“message”。它們分別表示操作的返回值和返回消息描述，其他的同級子節(jié)點為業(yè)務返回對象屬性，根據(jù)業(yè)務類型的不同，有不同的屬性名稱。
當客戶端支持數(shù)據(jù)壓縮傳輸時，需要在請求的消息頭的“Accept-Encoding”字段中指定壓縮方式(gzip)，如消息可以被壓縮傳輸則平臺將應答的數(shù)據(jù)報文進行壓縮作為應答數(shù)據(jù)返回，Content-Length為壓縮后的數(shù)據(jù)長度。詳細參見HTTP/1.1 RFC2616。
3）響應碼規(guī)則約定
響應結果碼在響應消息的“status”屬性中，相應的解釋信息在響應消息的“message”屬性中。解釋消息為終端用戶可讀的消息，終端應用不需要解析可直接呈現(xiàn)給最終用戶。響應結果碼為6位數(shù)字串。根據(jù)響應類型，包括以下幾類響應碼。如下表中的定義。
| 響應碼 | 描述 |
| 0 | 成功 |
| 1XXXXX | 系統(tǒng)錯誤 |
| 2XXXXX | 輸入參數(shù)不合法錯誤 |
| 3XXXXX | 應用級返回碼，定義應用級的異常返回。 |
| 4XXXXX | 正常的應用級返回碼，定義特定場景的應用級返回說明。 |
4）數(shù)據(jù)管理
①業(yè)務數(shù)據(jù)檢查
接口應提供業(yè)務數(shù)據(jù)檢查功能，即對接收的數(shù)據(jù)進行合法性檢查，對非法數(shù)據(jù)和錯誤數(shù)據(jù)則拒絕接收，以防止外來數(shù)據(jù)非法入侵，減輕應用支撐平臺系統(tǒng)主機處理負荷。
對于接口，其業(yè)務數(shù)據(jù)檢查的主要內容有以下幾個方面：
·數(shù)據(jù)格式的合法性：如接收到非預期格式的數(shù)據(jù)。包括接收的數(shù)據(jù)長度，類型，開始結束標志等。
·數(shù)據(jù)來源的合法性：如接收到非授權接口的數(shù)據(jù)。
·業(yè)務類型的合法性：如接收到接口指定業(yè)務類型外的接入請求。
對于業(yè)務數(shù)據(jù)檢查中解析出非法數(shù)據(jù)應提供以下幾種處理方式：
·事件報警：在出現(xiàn)異常情況時自動報警，以便系統(tǒng)管理員及時進行處理。
·分析原因：在出現(xiàn)異常情況時，可自動分析其出錯原因。如是數(shù)據(jù)來源非法和業(yè)務類型非法，本地記錄并做后續(xù)管理，如是數(shù)據(jù)格式非法，分析網絡傳輸原因或對端數(shù)據(jù)處理原因，并做相應處理。
·統(tǒng)計分析：定期對所有的非法記錄做統(tǒng)計分析，分析非法數(shù)據(jù)的各種來源是否具有惡意，并做相應處理。
②數(shù)據(jù)壓縮/解壓
接口根據(jù)具體的需求應提供數(shù)據(jù)壓縮/解壓功能，以減輕網絡傳輸壓力，提高傳輸效率，從而使整個系統(tǒng)能夠快速響應并發(fā)請求，高效率運行。
在使用數(shù)據(jù)壓縮/解壓功能時，應具體分析每一類業(yè)務的傳輸過程、處理過程、傳輸?shù)木W絡介質、處理的主機系統(tǒng)和該類業(yè)務的并發(fā)量、峰值及對于所有業(yè)務的比例關系等，從而確定該類業(yè)務是否需要壓縮/解壓處理。對于傳輸文件的業(yè)務，必須壓縮后傳輸，以減輕網絡壓力，提高傳輸速度。
在接口中所使用的壓縮工具必須基于通用無損壓縮技術，壓縮算法的模型和編碼必須符合標準且高效，壓縮算法的工具函數(shù)必須是面向流的函數(shù)，并且提供校驗檢查功能。
5）完整性管理
根據(jù)業(yè)務處理和接口服務的特點，應用系統(tǒng)的業(yè)務主要為實時請求業(yè)務和批量傳輸業(yè)務。兩類業(yè)務的特點分別如下：
1.實時請求業(yè)務：
(1)采用基于事務處理機制實現(xiàn)
(2)業(yè)務傳輸以數(shù)據(jù)包的方式進行
(3)對傳輸和處理的實時性要求很高
(4)對數(shù)據(jù)的一致性和完整性有很高的要求
(5)應保證高效地處理大量并發(fā)的請求
2.批量傳輸業(yè)務：
(1)業(yè)務傳輸主要是數(shù)據(jù)文件的形式
(2)業(yè)務接收點可并發(fā)處理大量傳輸，可適應高峰期的傳輸和處理
(3)要求傳輸?shù)目煽啃愿?/p>
根據(jù)上述特點，完整性管理對于實時交易業(yè)務，要保證交易的完整性；對于批量傳輸業(yè)務，要保證數(shù)據(jù)傳輸?shù)耐暾浴?/p>
2.2接口雙方責任
1）消息發(fā)送方
遵循本接口規(guī)范中規(guī)定的驗證規(guī)則，對接口數(shù)據(jù)提供相關的驗證功能，保證數(shù)據(jù)的完整性、準確性；
消息發(fā)起的平臺支持超時重發(fā)機制，重發(fā)次數(shù)和重發(fā)間隔可配置。
提供接口元數(shù)據(jù)信息，包括接口數(shù)據(jù)結構、實體間依賴關系、計算關系、關聯(lián)關系及接口數(shù)據(jù)傳輸過程中的各類管理規(guī)則等信息；
提供對敏感數(shù)據(jù)的加密功能；
及時解決接口數(shù)據(jù)提供過程中數(shù)據(jù)提供方一側出現(xiàn)的問題；
2）消息響應方
遵循本接口規(guī)范中規(guī)定的驗證規(guī)則，對接收的數(shù)據(jù)進行驗證，保證數(shù)據(jù)的完整性、準確性。
及時按照消息發(fā)送方提供的變更說明進行本系統(tǒng)的相關改造。
及時響應并解決接口數(shù)據(jù)接收過程中出現(xiàn)的問題。
3）異常處理
對接口流程調用過程中發(fā)生的異常情況，如流程異常、數(shù)據(jù)異常、會話傳輸異常、重發(fā)異常等，進行相應的異常處理，包括：
·對產生異常的記錄生成異常記錄文件。
·針對可以回收處理的異常記錄，進行自動或者人工的回收處理。
·記錄有關異常事件的日志，包含異常類別、發(fā)生時間、異常描述等信息。
·當接口調用異常時，根據(jù)預先配置的規(guī)則進行相關異常處理，并進行自動告警。
2.3接口可擴展性規(guī)劃與設計
各個系統(tǒng)間的通信接口版本信息限定了各個系統(tǒng)平臺間交互的數(shù)據(jù)協(xié)議類型、特定版本發(fā)布的系統(tǒng)接口功能特征、特定功能的訪問參數(shù)等接口規(guī)格。通過接口協(xié)議的版本劃分，為客戶端升級、其他被集成系統(tǒng)的升級、以及系統(tǒng)的部署提供了較高的自由度和靈活性。
系統(tǒng)可根據(jù)接口請求中包含的接口協(xié)議版本實現(xiàn)對接口的向下兼容。系統(tǒng)平臺可根據(jù)系統(tǒng)的集群策略，按協(xié)議版本分別部署，也可多版本并存部署。由于系統(tǒng)平臺可同時支持多版本的外部系統(tǒng)及客戶端應用訪問系統(tǒng)，特別是新版本客戶端發(fā)布時，不要求用戶強制升級，也可降低強制升級安裝包發(fā)布的幾率。從而支持系統(tǒng)的客戶端與系統(tǒng)平臺分離的持續(xù)演進。
2.4接口安全性設計
為了保證系統(tǒng)平臺的安全運行，各種集成的外部系統(tǒng)都應該保證其接入的安全性。
接口的安全是平臺系統(tǒng)安全的一個重要組成部分。保證接口的自身安全，通過接口實現(xiàn)技術上的安全控制，做到對安全事件的“可知、可控、可預測”，是實現(xiàn)系統(tǒng)安全的一個重要基礎。
根據(jù)接口連接特點與業(yè)務特色，制定專門的安全技術實施策略，保證接口的數(shù)據(jù)傳輸和數(shù)據(jù)處理的安全性。
系統(tǒng)應在接口的接入點的網絡邊界實施接口安全控制。
接口的安全控制在邏輯上包括：安全評估、訪問控制、入侵檢測、口令認證、安全審計、防(毒)惡意代碼、加密等內容。
1）安全評估
安全管理人員利用網絡掃描器定期(每周)/不定期(當發(fā)現(xiàn)新的安全漏洞時)地進行接口的漏洞掃描與風險評估。掃描對象包括接口通信服務器本身以及與之關聯(lián)的交換機、防火墻等，要求通過掃描器的掃描和評估，發(fā)現(xiàn)能被入侵者利用的網絡漏洞，并給出檢測到漏洞的全面信息，包括位置、詳細描述和建議改進方案，以便及時完善安全策略，降低安全風險。
安全管理人員利用系統(tǒng)掃描器對接口通信服務器操作系統(tǒng)定期(每周)/不定期(當發(fā)現(xiàn)新的安全漏洞時)地進行安全漏洞掃描和風險評估。在接口通信服務器操作系統(tǒng)上，通過依附于服務器上的掃描器代理偵測服務器內部的漏洞，包括缺少安全補丁、詞典中可猜中的口令、不適當?shù)挠脩魴嘞?、不正確的系統(tǒng)登錄權限、操作系統(tǒng)內部是否有黑客程序駐留，安全服務配置等。系統(tǒng)掃描器的應用除了實現(xiàn)操作系統(tǒng)級的安全掃描和風險評估之外還需要實現(xiàn)文件基線控制。
接口的配置文件包括接口服務間相互協(xié)調作業(yè)的配置文件、系統(tǒng)平臺與接口對端系統(tǒng)之間協(xié)調作業(yè)的配置文件，對接口服務應用的配置文件進行嚴格控制，并且配置文件中不應出現(xiàn)口令明文，對系統(tǒng)權限配置限制到能滿足要求的最小權限，關鍵配置文件加密保存。為了防止對配置文件的非法修改或刪除，要求對配置文件進行文件級的基線控制。
2）訪問控制
訪問控制主要通過防火墻控制接口對端系統(tǒng)與應用支撐平臺之間的相互訪問，避免系統(tǒng)間非正常訪問，保證接口交互信息的可用性、完整性和保密性。訪問控制除了保證接口本身的安全之外，還進一步保證應用支撐平臺的安全。
為了有效抵御威脅，應采用異構的雙防火墻結構，提高對防火墻安全訪問控制機制的破壞難度。雙防火墻在選型上采用異構方式，即采用不同生產廠家不同品牌的完全異構防火墻。同時，雙防火墻中的至少一個應具有與實時入侵檢測系統(tǒng)可進行互動的能力。當發(fā)生攻擊事件或不正當訪問時，實時入侵檢測系統(tǒng)檢測到相關信息，及時通知防火墻，防火墻能夠自動進行動態(tài)配置，在定義的時間段內自動阻斷源地址的正常訪問。
系統(tǒng)對接口被集成系統(tǒng)只開放應用定義的特定端口。
采用防火墻的地址翻譯功能，隱藏系統(tǒng)內部網絡，向代理系統(tǒng)提供翻譯后的接口通信服務器地址及端口，禁止接口對端系統(tǒng)對其它地址及端口的訪問。
對通過/未通過防火墻的所有訪問記錄日志。
3）入侵檢測
接口安全機制應具有入侵檢測(IDS)功能，實時監(jiān)控可疑連接和非法訪問等安全事件。一旦發(fā)現(xiàn)對網絡或主機的入侵行為，應報警并采取相應安全措施，包括自動阻斷通信連接或者執(zhí)行用戶自定義的安全策略。
實施基于網絡和主機的入侵檢測。檢測攻擊行為和非法訪問行為，自動中斷其連接，并通知防火墻在指定時間段內阻斷源地址的訪問，記錄日志并按不同級別報警，對重要系統(tǒng)文件實施自動恢復策略。
4）口令認證
對于需經接口安全控制系統(tǒng)對相關集成系統(tǒng)進行業(yè)務操作的請求，實行一次性口令認證。
為保證接口的自身安全，對接口通信服務器和其它設備的操作和管理要求采用強口令的認證機制，即采用動態(tài)的口令認證機制。
5）安全審計
為了保證接口的安全，要求對接口通信服務器的系統(tǒng)日志、接口應用服務器的應用日志進行實時收集、整理和統(tǒng)計分析，采用不同的介質存檔。
6）防惡意代碼或病毒
由于Internet為客戶提WEB服務，因此，對于Internet接口要在網絡分界點建立一個功能強大的防惡意代碼系統(tǒng)，該系統(tǒng)能實時地進行基于網絡的惡意代碼過濾。建立集中的防惡意代碼系統(tǒng)控制管理中心。
7）加密
為了提高接口通信信息的保密性，同時保證應用支撐平臺的安全性，可以對系統(tǒng)平臺與接口集成系統(tǒng)間的相關通信實施鏈路加密、網絡加密或應用加密，保證無關人員以及無關應用不能通過網絡鏈路監(jiān)聽獲得關鍵業(yè)務信息，充分保證業(yè)務信息的安全。
三、wsdl接口設計
WSDL是一個用于精確描述Web服務的文檔，WSDL文檔是一個遵循WSDL-XML模式的XML文檔。WSDL 文檔將Web服務定義為服務訪問點或端口的集合。在 WSDL 中，由于服務訪問點和消息的抽象定義已從具體的服務部署或數(shù)據(jù)格式綁定中分離出來，因此可以對抽象定義進行再次使用。消息，指對交換數(shù)據(jù)的抽象描述；而端口類型，指操作的抽象集合。用于特定端口類型的具體協(xié)議和數(shù)據(jù)格式規(guī)范構成了可以再次使用的綁定。將Web訪問地址與可再次使用的綁定相關聯(lián)，可以定義一個端口，而端口的集合則定義為服務。
一個WSDL文檔通常包含8個重要的元素，即definitions、types、import、message、portType、operation、binding、service元素。這些元素嵌套在definitions元素中，definitions是WSDL文檔的根元素。
WSDL文檔外層結構圖示：
WSDL 服務進行交互的基本元素：
Types（消息類型）：數(shù)據(jù)類型定義的容器，它使用某種類型系統(tǒng)（如 XSD）。
Message（消息）：通信數(shù)據(jù)的抽象類型化定義，它由一個或者多個 part 組成。
Part：消息參數(shù)
PortType（端口類型）：特定端口類型的具體協(xié)議和數(shù)據(jù)格式規(guī)范。，它由一個或者多個 Operation組成。
Operation（操作）：對服務所支持的操作進行抽象描述，WSDL定義了四種操作：
1.單向（one-way）：端點接受信息；
3.要求-響應（solicit-response）：端點發(fā)送消息，然后接受相關消息；
4.通知（notification[2] ）：端點發(fā)送消息。
Binding：特定端口類型的具體協(xié)議和數(shù)據(jù)格式規(guī)范。
Port：定義為綁定和網絡地址組合的單個端點。
Service：相關端口的集合，包括其關聯(lián)的接口、操作、消息等。
外層結構里面也可能有多層結構。
四、Restful風格接口設計
4.1協(xié)議
API與用戶的通信協(xié)議，通常使用HTTP/HTTPs協(xié)議(特別是web)
4.2域名
應該盡量將API部署在專用域名之下。
https://api.example.com
如果確定API很簡單，不會有進一步擴展，可以考慮放在主域名下。
https://example.org/api/
4.3版本
API的版本號放入URL
https://api.example.com/v1/
另一種設計方式將版本號放在HTTP頭信息中，但不如放入URL方便和直觀，Github采用這種做法。
4.4路徑
路徑又稱"終點"（endpoint），表示API的具體網址。
在RESTful架構中，每個網址代表一種資源（resource），所以網址中不能有動詞，只能有名詞，而且所用的名詞往往與數(shù)據(jù)庫的表格名對應。一般來說，數(shù)據(jù)庫中的表都是同種記錄的"集合"（collection），所以API中的名詞也應該使用復數(shù)。
舉例來說，有一個API提供動物園（zoo）的信息，還包括各種動物和雇員的信息，則它的路徑應該設計成下面這樣。
4.5HTTP動詞
對于資源的具體操作類型，由HTTP動詞表示，常用的HTTP動詞有下面五個（括號里是對應的SQL命令）。
兩個不常用的HTTP動詞：
舉例如下：
4.6過濾信息
如果記錄數(shù)量很多，服務器不可能都將它們返回給用戶。API應該提供參數(shù)，過濾返回結果，常見的參數(shù)如下：
參數(shù)設計允許存在冗余，即允許API路徑和URL參數(shù)偶爾有重復。比如，GET /zoo/ID/animals 與 GET /animals?zoo_id=ID 的含義是相同的。
4.7狀態(tài)碼
服務器向用戶返回的狀態(tài)碼和提示信息，常見的有以下一些（方括號中是該狀態(tài)碼對應的HTTP動詞）。
200 OK - [GET]：服務器成功返回用戶請求的數(shù)據(jù)，該操作是冪等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功。
202 Accepted - [*]：表示一個請求已經進入后臺排隊（異步任務）
204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請求有錯誤，服務器沒有進行新建或修改數(shù)據(jù)的操作，該操作是冪等的。
401 Unauthorized - [*]：表示用戶沒有權限（令牌、用戶名、密碼錯誤）。
403 Forbidden - [*] 表示用戶得到授權（與401錯誤相對），但是訪問是被禁止的。
404 NOT FOUND - [*]：用戶發(fā)出的請求針對的是不存在的記錄，服務器沒有進行操作，該操作是冪等的。
406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當創(chuàng)建一個對象時，發(fā)生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]：服務器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功。
4.8錯誤處理
如果狀態(tài)碼是4xx，就應該向用戶返回出錯信息。一般來說，返回的信息中將error作為鍵名，出錯信息作為鍵值即可。
{
error: "Invalid API key"
}
4.9返回結果
針對不同操作，服務器向用戶返回的結果應該符合以下規(guī)范：
GET /collection：返回資源對象的列表（數(shù)組）
GET /collection/resource：返回單個資源對象
POST /collection：返回新生成的資源對象
PUT /collection/resource：返回完整的資源對象
PATCH /collection/resource：返回完整的資源對象
DELETE /collection/resource：返回一個空文檔
4.10Hypermedia API
RESTful API最好做到Hypermedia，即返回結果中提供鏈接，連向其他API方法，使得用戶不查文檔，也知道下一步應該做什么。
比如，當用戶向api.example.com的根目錄發(fā)出請求，會得到如下文檔：
{"link": {
"rel": "collection https://www.example.com/zoos",
"href": "https://api.example.com/zoos",
"title": "List of zoos",
"type": "application/vnd.yourformat+json"
}}
文檔中有一個link屬性，用戶讀取這個屬性就知道下一步該調用什么API了。rel表示這個API與當前網址的關系（collection關系，并給出該collection的網址），href表示API的路徑，title表示API的標題，type表示返回類型。
Hypermedia API的設計被稱為HATEOAS。Github的API采用次設計方式，訪問api.github.com會得到一個所有可用API的網址列表。
{
"current_user_url": "https://api.github.com/user",
"authorizations_url": "https://api.github.com/authorizations",
// ...
}
如果想獲取當前用戶的信息，應該去訪問api.github.com/user，然后就得到了下面結果：
{
"message": "Requires authentication",
"documentation_url": "https://developer.github.com/v3"
}
上面代碼表示，服務器給出了提示信息，以及文檔的網址。
4.11其它
1）API的身份認證應該使用OAuth 2.0框架。
2）服務器返回的數(shù)據(jù)格式，應該盡量使用JSON，避免使用XML。
Java消息服務（Java Message Service）是message數(shù)據(jù)傳輸?shù)牡湫偷膶崿F(xiàn)方式。系統(tǒng)A和系統(tǒng)B通過一個消息服務器進行數(shù)據(jù)交換。系統(tǒng)A發(fā)送消息到消息服務器，如果系統(tǒng)B訂 閱系統(tǒng)A發(fā)送過來的消息，消息服務器會消息推送給B。雙方約定消息格式即可。目前市場上有很多開源的jms消息中間件，比如 kafka，ActiveMQ, OpenJMS。
一、消息服務設計
目前需要導入一個大文件到系統(tǒng)A，系統(tǒng)A保存文件信息，而文件里面的明細信息需要導入到系統(tǒng)B進行分析，當系統(tǒng)B分析完成之后，需要把分析結果通知系統(tǒng)A。
1）系統(tǒng)A先保存文件到文件服務器。
2）系統(tǒng)A 通過webservice 調用系統(tǒng)B提供的服務器，把需要處理的文件名發(fā)送到系統(tǒng)B。由于文件很大，需要處理很長時間，所以B不及時處理文件，而是保存需要處理的文件名到數(shù)據(jù)庫，通過后臺定時調度機制去處理。所以B接收請求成功，立刻返回系統(tǒng)A成功。
3）系統(tǒng)B定時查詢數(shù)據(jù)庫記錄，通過記錄查找文件路徑，找到文件進行處理。這個過程很長。
4）系統(tǒng)B處理完成之后發(fā)送消息給系統(tǒng)A，告知系統(tǒng)A文件處理完成。
5）系統(tǒng)A 接收到系統(tǒng)B請求來的消息，進行展示任務結果。
二、消息服務優(yōu)缺點
消息服務優(yōu)點
1）由于jms定義了規(guī)范，有很多的開源的消息中間件可以選擇，而且比較通用。接入起來相對也比較簡單
2）通過消息方式比較靈活，可以采取同步，異步，可靠性的消息處理，消息中間件也可以獨立出來部署。
消息服務缺點
1）學習jms相關的基礎知識，消息中間件的具體配置，以及實現(xiàn)的細節(jié)對于開發(fā)人員來說還是有一點學習成本的
2）在大數(shù)據(jù)量的情況下，消息可能會產生積壓，導致消息延遲，消息丟失，甚至消息中間件崩潰。
對于大數(shù)據(jù)量的交互，采用文件的交互方式是最佳方式之一。
一、文件共享設計
系統(tǒng)A和系統(tǒng)B約定文件服務器地址，文件命名規(guī)則,文件內容格式等內容，通過上傳文件到文件服務器進行數(shù)據(jù)交互。
最典型的應用場景是批量處理數(shù)據(jù)：例如系統(tǒng)A把今天12點之前把要處理的數(shù)據(jù)生成到一個文件，系統(tǒng)B第二天凌晨1點進行處理，處理完成之后，把處理 結果生成到一個文件，系統(tǒng)A 12點在進行結果處理。這種狀況經常發(fā)生在A是事物處理型系統(tǒng)，對響應要求比較高，不適合做數(shù)據(jù)分析型的工作，而系統(tǒng)B是后臺系統(tǒng)，對處理能力要求比較 高，適合做批量任務系統(tǒng)。
以上只是說明通過文件方式的數(shù)據(jù)交互，實際情況B完成任務之后，可能通過socket的方式通知A，不一定是通過文件方式。
二、文件共享優(yōu)缺點
優(yōu)點：
1 在數(shù)據(jù)量大的情況下，可以通過文件傳輸，不會超時，不占用網絡帶寬。
2 方案簡單，避免了網絡傳輸，網絡協(xié)議相關的概念。
缺點：
1 不太適合做實時類的業(yè)務
2 必須有共同的文件服務器，文件服務器這里面存在風險。因為文件可能被篡改，刪除，或者存在泄密等。
3 必須約定文件數(shù)據(jù)的格式，當改變文件格式的時候，需要各個系統(tǒng)都同步做修改。
Socket方式是最簡單的交互方式，適用于c/s 交互模式，一臺客戶機，一臺服務器。
一、socket傳輸設計
服務器提供服務，通過ip地址和端口進行服務訪問。而客戶機通過連接服務器指定的端口進行消息交互。其中傳輸協(xié)議可以 是tcp/UDP 協(xié)議。而服務器和約定了請求報文格式和響應報文格式。如下圖所示：
目前常用的http調用，java遠程調用，webserivces 都是采用的這種方式，只不過不同的就是傳輸協(xié)議以及報文格式。
二、socket傳輸優(yōu)缺點
優(yōu)點：
1）易于編程，目前java提供了多種框架，屏蔽了底層通信細節(jié)以及數(shù)據(jù)傳輸轉換細節(jié)。
2）容易控制權限。通過傳輸層協(xié)議https，加密傳輸?shù)臄?shù)據(jù)，使得安全性提高
3）通用性比較強，無論客戶端是.net架構，java，python 都是可以的。尤其是webservice規(guī)范，使得服務變得通用
缺點：
1）服務器和客戶端必須同時工作，當服務器端不可用的時候，整個數(shù)據(jù)交互是不可進行。
2）當傳輸數(shù)據(jù)量比較大的時候，嚴重占用網絡帶寬，可能導致連接超時。使得在數(shù)據(jù)量交互的時候，服務變的很不可靠。
一、數(shù)據(jù)庫傳輸設計
系統(tǒng)A和系統(tǒng)B通過連接同一個數(shù)據(jù)庫服務器的同一張表進行數(shù)據(jù)交換。當系統(tǒng)A請求系統(tǒng)B處理數(shù)據(jù)的時候，系統(tǒng)A Insert一條數(shù)據(jù)，系統(tǒng)B select 系統(tǒng)A插入的數(shù)據(jù)進行處理。
二、數(shù)據(jù)庫傳輸優(yōu)缺點
優(yōu)點：
1）相比文件方式傳輸來說，因為使用的同一個數(shù)據(jù)庫，交互更加簡單。
2）由于數(shù)據(jù)庫提供相當做的操作，比如更新，回滾等。交互方式比較靈活,而且通過數(shù)據(jù)庫的事務機制，可以做成可靠性的數(shù)據(jù)交換。
缺點：
1）當連接B的系統(tǒng)越來越多的時候，由于數(shù)據(jù)庫的連接池是有限的，導致每個系統(tǒng)分配到的連接不會很多，當系統(tǒng)越來越多的時候，可能導致無可用的數(shù)據(jù)庫連接
2）一般情況，來自兩個不同公司的系統(tǒng)，不太會開放自己的數(shù)據(jù)庫給對方連接，因為這樣會有安全性影響
數(shù)據(jù)爬取可根據(jù)不同環(huán)境做不同方案，C/S模式可用數(shù)據(jù)抓包工具進行抓包數(shù)據(jù)，B/S模式可定制開發(fā)網絡爬蟲實現(xiàn)數(shù)據(jù)爬取。獲取到的數(shù)據(jù)傳輸?shù)街付ㄎ恢?，再進行使用處理。不過爬取的數(shù)據(jù)獲取方式比較“非主流”，并且存在安全問題及對服務器的壓力，不建議使用此種方式。
聯(lián)系客服
