一、前言
最近公司業務需要希望能夠連接東亞銀行的接口直接對商家進行轉賬付款，但由於前期可行性研究的准備工作沒有做好，導致在開發進入兩周后才發現原先的設計存在重大安全漏洞，不得不停止項目開發。
接口開發是開發中經常遇到的問題，為避免此類問題再次發生，因而結合本次項目的經驗及網上查找到的資料整理出本文，希望能夠對以后的第三方接口開發交互提供指導。
二、接口開發流程
1.確定需要哪些接口
重點是要確定每個接口的具體功能。確保這些接口是必須的，功能相互間沒有交叉。
2.接口設計及細節分析
針對每一個接口確定如下事項
a)發送參數名、參數含義、參數數據類型、長度、精度
b)接收參數名、參數含義、參數數據類型、長度、精度
接口的使用的類型變量盡量通用，特別是對使用此接口的用戶一無所知情況下，對方可能是JAVA，也可能是VB6，也可能是C#，不要使用某種編程語言的特定類型，比較好的一種方式是，參數和返回值都使用string類型，這樣基本上的編程語言都能支持。
c)發送信息時的數據格式：xml格式還是json格式
d)網絡傳輸時的編碼格式。
雖然在網絡傳輸時均是以字節的形式進行傳輸，但不同的編碼格式生成的字節是不同的，因而需要對此進行統一。如果雙方系統的編碼格式不同則在進行數據處理時必須進行轉碼。例如我們在對接招商銀行的接口時，招商銀行采用的GBK編碼格式，而我們系統采用的是UTF-8編碼格式，導致在頁面顯示招商銀行的反饋信息均為亂碼。關於亂碼轉換請見我的另一篇博客（http://www.cnblogs.com/sunzhenchao/archive/2012/12/05/2802658.html）
在確定發送數據時，還需考慮：
對方需要的數據自己系統是否存在，如果存在這些數據的格式是否和對方要求的一致，不一致如何進行處理；
如果不存在，是在自己系統中新增這些數據還是采取什么樣的變通措施。
例子：使用東亞銀行的接口進行轉賬時需提供收款方的銀行聯行號（http://baike.baidu.com/view/3048635.htm），而我們公司的crm系統中是沒有銀行聯行號的。后來和東亞銀行溝通他們提供了一個支行名稱和銀行聯行號的對照表（下左圖），但拿到對照表發現我們crm系統中填寫的支行名稱很不規范，8萬多條收款信息沒有一條能夠直接匹配上的。比如收款銀行，在crm系統中有填工行的，也有填工商銀行的，也有填中國工商銀行（下右圖）；而在東亞銀行提供的對照表中則是“中國工商銀行股份有限公司”。還有一些支行名稱在crm系統中根本就沒有填寫，一個銀行在一個城市有多個支行，比如工行在無錫有多個支行，而crm系統中填的都是無錫支行，這樣即使使用人工也無法進行匹配。
而東亞銀行說如果銀行聯行號錯誤則可能會支付失敗，如果支付成功率比較低則會影響到用戶體驗了。再次情況下不得不對crm系統的收款方信息數據錄入進行規范，從源頭解決該問題。
注意：當接口根據實際需要進行調整，同時更新詳細設計文檔，保持接口詳細設計的可追溯性。
3.確定數據交互的安全性
交互傳輸的數據中是否有敏感數據，如果有，如何處理？如果要加密，采用何種加密方式？接口是公開的還是受限定訪問的？如果是受限定訪問的，如何確定信息的發送方或者獲取方是合法的，而不是冒仿者？
例如電子商務網站一般都會調用支付寶的接口進行付款，在傳送基本的金額、通知url、用戶名等信息外，支付寶為驗證調用的合法性還需要傳送“安全碼、加密方式”等字段進行校驗，以防止用戶將貨款付到其他人或公司的支付寶賬戶中。
在調用招商銀行的支付接口時招商銀行會限定IP，並且會用自己的客戶端將發送信息按照分配的U盾進行加密處理。
4.編碼
1).不要程序各個地方直接使用其它的系統的接口，最好是寫一個類來封裝其它系統的接口，如果其它系統的接口很多，可以專門建一個項目或包來管理這些類，這樣當接口發生變化時（如接口名，接口方式），可以集中修改找一個類中的函數，而程序的其它地方都可以不用改，將“變化”限定在最小的范圍內，將封裝的優點大大的發揮出來。切忌在程序的各個地方直接調用其它系統的接口
2）對於調用會產生數據交易的其它系統接口，一定要寫Log,這對將來數據出錯時，查找問題的根源很必要，特別是對方系統的接口沒有寫log時，一旦出現數據問題，往往會不知從何查起，是我們給的數據有問題，還是對方系統處理我們給的數據有問題？在最近的一個項目中，因為我們產生數據的邏輯很復雜，而對方接口收到我們產生的數據后，也會做一個很復雜數據交易動作，在系統上線初期，出現了很多莫名其秒的數據，而我們正是通過在調用對方接口時的寫log數據，很快查出一些是我們生成的數據有問題，一些是對方處理數據有問題
3)對接口接收過來的數據，最好進行數據效驗，因為你不能保證其它系統會傳給你完全符合標准的數據。 對數據校驗不通過的和執行失敗的，最好能有清淅明了的提示返回給調用方
5.測試
包括接口內部測試、修改，和第三方的聯調。
6.上線
接口正式上線，測試通過則上線成功，失敗則回退,並從第4步開始新一輪的測試，直到系統上線成功。
三、常見問題及注意事項
1.詳細設計文檔應付了事，甚至不寫設計文檔。
實際的開發過程中，由於時間的原因，或者開發團隊對設計文檔的不重視，造成有的開發者忽視接口設計文檔的作用，甚至不寫設計文檔。
設計文檔的缺失，往往會造成：人員流動時，系統無法順利交接；會給接口的升級，帶來重重困難。
2.接口開發過程中，發現原有功能設計有不合理的地方，應該對系統重構，還是僅僅實現功能了事？
以我的經驗而言，總的來說大多因為原有接口缺乏可擴展性，導致添加新功能或者接口更改后代碼冗余的問題。究其原因，有下面幾種情況的原因：
1）.開發周期比較緊張，來不及對原有代碼重構。
2）.開發人員懶得去重構，或者不具備重構的能力。
個人認為，這些問題歸根結底要由開發流程來約束和控制。
開發周期緊張的情況下，技術負責人一方面要爭取盡量多的開發時間，另一方面要根據開發任務的難度安排水平盡量高的人員來做；如果高水平的人員有了，時間還是緊張，可以考慮在以后某個合適的時間來重構這部分代碼,千萬不要讓這部分待重構的代碼永遠的等待下去。應該制定合理的重構時間表，作為正常的開發流程的一部分。
3.技術負責人在系統構建過程中應該擔負哪些責任？
無論系統對外接口，還是系統內部功能，都是整個系統的一部分，都是技術負責人的控制范圍。
技術負責人應該對開發流程的建立、系統質量負主要責任。能否建立合理的開發流程，能否領導開發人員產出高質量的軟件系統，是一個技術負責人是否合格的很重要的判斷標准。
就算開發團隊中，開發人員數量充足，水平夠高，但是開發流程不完善，缺乏合理的約束，往往會導致一部分人滋生得過且過的心態，編碼完了基本上就算了事。有的人爭取盡量多的空閑時間來學習新技術，為將來謀划；有的人剛接了私活，人家催的比較急，需要上班時抽空做呢；這種情況並不少見，怎樣在這中惡劣的情況下保證開發工作在規定的時間內、高質量的完成？沒有嚴謹的、合理的開發流程根本不可能領導這些"各懷心腹事"的開發人員研發出高質量的系統。
個人認為，技術負責人一定要抓住軟件開發過程中的三個關鍵點：測試、代碼復查、模塊重構，一定要重視再重視，程序員和老板講解它們的重要性，他很可能不明白其重要性，但是技術負責人千萬不能不重視這三個環節，如果您都不懂或者不重視，那最終產出的是什么樣的系統，大家可想而知了。
參考資料：http://www.iteye.com/topic/550127