摘要：?總結一下API接口開發過程中的注意事項 1、跨平臺性 所謂跨平臺是指我們的接口要能夠支持不同的終端，比如Android、iOS、windowsphone以及桌面軟件、網站等。如：不同的終端每頁顯示的記錄數不同 采用通用的解決方案，比如通信協議就采用最常用的HTTP協議，如果是即時通信，可以采用開放的XMPP協議，做游戲的可以采用可靠的TCP協議，除非TCP不夠用了，再采用定制的UDP協議。

總結一下API接口開發過程中的注意事項

1、跨平臺性

所謂跨平臺是指我們的接口要能夠支持不同的終端，比如Android、iOS、windowsphone以及桌面軟件、網站等。如：不同的終端每頁顯示的記錄數不同

采用通用的解決方案，比如通信協議就采用最常用的HTTP協議，如果是即時通信，可以采用開放的XMPP協議，做游戲的可以采用可靠的TCP協議，除非TCP不夠用了，再采用定制的UDP協議。
數據交換采用xml或者json格式或者webservice等等。總之，要達到的目標就是讓不同的端能夠很方便的使用你的接口。

2、良好的響應速度

接口應該以最快的速度將數據返回給請求者,要達到的目標就是快，一個頁面，秒開最好，超過三秒就需要找找原因了。數據量按需分配，APP客戶端需要什么數據就返回什么數據，過多的數據量影響處理速度，最重要的是影響傳輸效率

3、接口要為移動客戶端考慮

比如，在移動端里，下拉刷新和上拉加載更多是很常見的功能，如果接口仍然按照傳統的web思路，
只提供按頁讀取的話，就會造成移動端的額外的數據請求和計算。 這時，接口就應該針對這兩種類型的操作提供額外的支持。

4、考慮移動端的網絡情況和耗電量
如果讓我們說出哪類app比較好，可能還不大好說，但是如果讓我們說出哪些app很差，我們肯定會說出那些體積很大、占用內存多、界面很卡、費電的app 不好。對于網絡情況，接口應該具備為不同的網絡提供不同的內容的能力如果我們能夠知道用戶的網絡情況，只有在wifi的情況下才給用戶傳輸封面圖、縮略圖 之類的，
是不是可以幫用戶節省很多流量呢

?5、通用的數據交換格式

目前，對于接口和客戶端的數據交換格式，基本上就是三種，xml和json和webservice，而現在使用json的應該占大多數最麻煩的就是處理Date類型，因為JSON本身沒有Date類型，因此，JSON庫將Date類型的數據序列化時會轉為String。這時，不同環境， 不同平臺，以及用不同的JSON解析庫，轉換后的結果經常會不同。比如，你在開發機上可能得到的結果是”2016-1-1 17:11:11”，但放到服務器后結果卻變成了“Jan 1,2016 5:11:11 PM” ，客戶端進行反序列化時無疑會失敗。后來，我取消了所有Date類型，統一采用時間戳表示，就再沒有轉化的煩惱了。 另外，接口的開發人員有時候會將一些數據錯誤地轉換為了String，導致客戶端使用時因類型錯誤而異常。例如，本來是數字的1，被轉成 了"1"，客戶端做運算時就會出錯，或用switch判斷時也會出錯，或其他無法轉換的情況發生時；例如，為空時JSON正確地表示應該是null，但如 果轉為了String就變成了"null"，那問題就來了，我遇到的因為這個錯誤的轉換導致的程序奔潰已經好幾次了，第一次的時候，查了一整天才定位到問題所在

6、接口統計功能

在做PC端網站的時候，我們都會給我們的網站加上個統計功能，要么自己寫統計系統，要么使用第三方的比如GA

移 動端接口API則需要我們自己實現統計功能，這時就需要我們盡可能多的收集客戶端的信息，除了傳統的IP、User-Agent之外，還應該收集一些移動 相關的信息，比如手機操作系統，是android還是ios，都是什么版本，用戶使用的網絡狀況，是2G、3G、4G還是WIFI。客戶端APP是什么版 本信息。

7、客戶端與服務端的肥瘦平衡

在移動開發中，由于客戶端的修改會很費時費力，特 別是IOS應用還要經過Apple審核，另外，當前IOS開發人員、Android開發人員的人工成本普遍較高，人才緊缺，基于這兩點，能在服務器端實現 的功能就不要放在客戶端，畢竟服務器端程序的修改要比客戶端方便、靈活、快捷的多。

8、隱式用戶與顯式用戶

顯式用戶指的是，APP程序中有用戶系統，一個username、password正確的合法用戶，稱之為顯式的用戶，
通常顯式用戶都需要注冊，登錄以后能完成一些個人相關的操作。
隱式用戶指的是，APP程序本身就沒有用戶系統，或者一個在沒有登錄的情況下，使用我們APP的用戶。
在這種情況下，可以通過客戶端生成的UDID來標識一個用戶。
有了用戶信息，我們就能夠了解不同用戶的使用習慣，而不僅僅是全體用戶的一個整體的統計信息，
有了這些個體的信息之后，就可以做一些用戶分群、個性化推薦之類的事情。

9、安全問題

設計API第一個需要考慮的是API的安全機制。我負責的上一個項目，因為API的安全問題，就被人攻擊了兩次。之后經過分析，主要存在兩個漏洞： 一是因 為缺少對調用者進行安全驗證的方式，二是因為數據傳輸不夠安全。那么，制定API的安全機制，主要就是為了解決這兩個問題：

• 保證API的調用者是經過自己授權的App；
• 保證數據傳輸的安全。

第一個問題的解決方案，我主要采用設計簽名的方式。對每個客戶端分別分配一個AppKey和AppSecret。需要調用API時，將AppKey加入請求參數列表，并將AppSecret和所有參數一起，根據某種簽名算法生成一個簽名字符串，然后調用API時把該簽名字符串也一起帶上。服務端收到請求之后，根據請求中的AppKey查詢相應的AppSecret，按照同樣的簽名算法，也生成一個簽名字符串，當服務端生成的簽名和請求帶過來的簽名一致的時候，那就表示這個請求的調用者是經過自己授權的，證明這個請求是安全的。而且，每個端都有一個Key，也方便不同端的標識和統計。為了防止AppSecret被別人獲取，這個AppSecret一般寫死在代碼里面。另外，簽名算法也需要有一定的復雜度，不能輕易被別人破解，最好是采用自己規 定的一套簽名算法，而不是采用外部公開的簽名算法。另外，在參數列表中再加入一個時間戳，還可以防止部分重放攻擊。 第二個問題的解決方案，主要就是采用 HTTPS了。HTTPS因為添加了SSL安全協議，自動對請求數據進行了壓縮加密，在一定程序可以防止監聽、防止劫持、防止重發，主要就是防止中間人攻擊。因此，為了安全考慮，建議對SSL證書進行強校驗，包括簽名CA是否合法、域名是否匹配、是不是自簽名證書、證書是否過期等。
接口不能直接調用OAuth認證（rsa加密），ip白名單

接口的安全工作不能馬虎，暴力破解啊、SQL Injection啊、偽造請求和數據啊、重復提交啊也要考慮到,

如果數據特別敏感，可以考慮采用SSL/TLS等加密傳輸，或者客戶端、服務器端約定一個加密算法和密鑰，對來往傳輸的數據進行加密、解密。如將所有參數加簽名算法得到一個簽名驗證參數signhttp://hudeyong926.iteye.com/blog/2287954

表單類接口防止重復提交：調用過的接口sign存起來，檢查sign是否存在

10、良好的接口說明文檔和測試程序

接口文檔要清晰、明了，包含多少個接口，每個接口的地址、參數、請求方式、數據交換格式、參數是否必填、編碼格式UTF8，返回值等都要寫清楚。
接口測試程序，有條件的話，也可以提供，方便前后端的調試

11、版本的維護
隨著業務的變化，客戶端APP和服務器端API都會發生變化，增加新的功能，修改已有的功能，
增加功能還好說， 如果是接口需要修改，那么就面臨著同一個接口要同時為不同版本的客戶端服務的問題。
因此，服務器端接口也要做好相應的版本維護。

主版本更新可以把版本號放入API的URL中/api-v2來指出所使用的API版本
次要版本的修改是通過客戶在API調用時發起請求的HTTP頭部做指定的頭部的版本元素看起來是這樣的：
Element-Version: 1
12、接口數據、狀態
接口必須提供明確的數據狀態信息，不管是成功的，還是失敗的，都必須返回給APP客戶端。
13、接口、參數命名準確。
無論是接口還是參數，命名都應該有意義，讓人一目了然。接口調試技巧前提必須放在外網上

1》服務端return 調試信息，客戶端調用并顯示結果，

2》在服務端將結果保存成文件在打開文件查看，即日志型調試（或建臨時表放在數據庫表里）

考慮突然斷網或接口信息返回超時異常情況的業務處理（先扣金額更新狀態，如有問題自動返回）

支付寶

Java代碼??

<span?style="font-size:?14px;">$alipaySubmit?=?new?AlipaySubmit($alipay_config);??

$url?=?$alipaySubmit->alipay_gateway_new.$alipaySubmit->buildRequestParaToString($parameter);??

header("Location:?{$url}");</span> ?

來源:http://blog.csdn.net/xiao_tommy/article/details/54864920

總結

以上是生活随笔為你收集整理的API接口设计 注意问题的全部內容，希望文章能夠幫你解決所遇到的問題。

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