總結一下api介面開發過程中的注意事項
所謂跨平台是指我們的介面要能夠支援不同的終端，比如android、ios、windowsphone以及桌面軟體、**等。如：不同的終端每頁顯示的記錄數不同
採用通用的解決方案，比如通訊協議就採用最常用的http/rpc協議，如果是即時通訊，可以採用開放的xmpp協議，做遊戲的可以採用可靠的tcp協議，除非tcp不夠用了，再採用定製的udp協議。資料交換採用xml或者json格式等。總之，要達到的目標就是讓不同的端能夠很方便的使用你的介面。
function ajaxjson($data, $jsoncallback = '', $fromcode = "utf-8") else
exit($output);
}function apireturn($data, $type = 'json')
//內部程式呼叫
if (strtoupper($type) == 'json') elseif (strtoupper($type) == 'xml') elseif(strtoupper($type) == 'eval')
}
目前，對於介面和客戶端的資料交換格式，基本上就是三種，xml和json，而現在使用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"，那問題就來了，我遇到的因為這個錯誤的轉換導致的程式奔潰已經好幾次了，第一次的時候，查了一整天才定位到問題所在
設計api第乙個需要考慮的是api的安全機制。我負責的上乙個專案，因為api的安全問題，就被人攻擊了兩次。之後經過分析，主要存在兩個漏洞： 一是因為缺少對呼叫者進行安全驗證的方式，二是因為資料傳輸不夠安全。那麼，制定api的安全機制，主要就是為了解決這兩個問題：
保證資料傳輸的安全。
第二個問題的解決方案，主要就是採用 https了。https因為新增了ssl安全協議，自動對請求資料進行了壓縮加密，在一定程式可以防止監聽、防止劫持、防止重發，主要就是防止中間人攻擊。因此，為了安全考慮，建議對ssl證書進行強校驗，包括簽名ca是否合法、網域名稱是否匹配、是不是自簽名證書、證書是否過期等。
介面安全：oauth認證，ip白名單，vpn通道。介面的安全工作不能馬虎，暴力破解啊、sql injection啊、偽造請求和資料啊、重複提交啊也要考慮到。如果資料特別敏感，可以考慮採用ssl/tls等加密傳輸，或者客戶端、伺服器端約定乙個加密演算法和金鑰(rsa)，對來往傳輸的資料進行加密解密。
介面文件要清晰、明了，包含多少個介面，每個介面的位址、引數、請求方式、資料交換格式、引數是否必填、編碼格式utf8，返回值等都要寫清楚。介面測試程式，有條件的話，也可以提供，方便前後端的除錯
無論是介面還是引數，命名都應該有意義，讓人一目了然。
對於某些資料更新後，第三方的資料要保持通過更新（insert,update），可以採用推送介面將最新的資料推送第三方。優點：第三方不需要高頻度的輪詢查詢去更新，減輕伺服器壓力。（第三方需提供通知位址，即介面服務端，我方更新後呼叫即可）
實現訪問者ip在一定的時間內只能訪問次數.
介面除錯技巧前提必須放在外網上
1》服務端return 除錯資訊，客戶端呼叫並顯示結果，
2》在服務端將結果儲存成檔案在開啟檔案檢視，即日誌型除錯（或建臨時表放在資料庫表裡）
考慮突然斷網或介面資訊返回超時異常情況的業務處理（先扣金額再呼叫介面，如有問題，金額原路返回）
支付寶
$alipaysubmit = new alipaysubmit($alipay_config);
$url = $alipaysubmit->alipay_gateway_new.$alipaysubmit->buildrequestparatostring($parameter);
header("location: ");
api介面設計
請求模式也可以說是動作 資料傳輸方式，通常我們在web中的form有get post兩種，而在http中，存在下發這幾種。get 選擇 從伺服器上獲取乙個具體的資源或者乙個資源列表。post 建立 在伺服器上建立乙個新的資源。put 更新 以整體的方式更新伺服器上的乙個資源。patch 更新 只更新...
API介面設計
請求模式也可以說是動作 資料傳輸方式，通常我們在web中的form有get post兩種，而在http中，存在下發這幾種。get 選擇 從伺服器上獲取乙個具體的資源或者乙個資源列表。post 建立 在伺服器上建立乙個新的資源。put 更新 以整體的方式更新伺服器上的乙個資源。patch 更新 只更新...
API介面設計
目前 基本都是前後端分離的模式,如果前端使用vue等框架會產生跨域的問題,當產生跨域的時候,乙個介面會被訪問兩次,第一次會使用options訪問來判斷介面是否通,接下來才會使用指定的請求方式來訪問,那麼這樣怎麼辦呢?我們的共有controller就派上用場了,共有控制器裡面的建構函式 public ...