一、介面版本化
生產環境中，如果沒有版本控制的程式變更會導致呼叫介面的相關方頻繁的跟著變更，假設相關方沒有及時的跟著變更，那麼系統就會報錯，從而影響到使用者的使用及體驗，使其對整個系統的運營都是不利的，介面對接的難度也會不斷的加大。
如果介面能夠有版本的控制，則公升級系統的主動權就掌握在相關方，這樣當有新版本的程式發布時舊版本的業務邏輯不會受到影響，從使用者感知上也受到的影響就比較小，相關方也可以根據自身的條件是否要公升級版本。
二、介面面向的應用場景
三、請求引數的規範性及處理的統一性
請求引數的規範性意思就是說，介面要以什麼樣的方式來接收引數。是統一使用json的方式接收呢還是xml或者form表單方式接收。
在開發介面應該統一在乙個地方進行對引數的接收、校驗等操作。為了保證引數的完整性，我們可以考慮新增簽名驗證等處理。
四、返回資料型別、返回碼及資訊提示的規範性
返回給客戶端的資料型別應該要統一化（例如：我們統一以json的形式進行返回，或者是統一以xml的形式返回）。
不同的介面設計模式返回碼也會不同，如果使用現在非常火也比較流行的restfull風格那麼就應該要准許restfull風格的返回碼規定。如果是統一採用自定返回碼的話在設計返回碼時，應該要學會針對不同的業務處理模組對返回碼進行分段處理（例如：系統基礎管理我們使用10000-10050，使用者管理則就應該要從10051到10100，……），針對不同業務模組我們要預留足夠的返回碼，因為後期針對該模組的開發可能還會有其它業務的擴充套件或者調整等問題。
返回碼分段處理的乙個好處就是方便呼叫介面的相關方能夠很快的定位到錯誤是屬於哪乙個部分，同時也方便介面開發人員定位介面錯誤在哪個地方。
除了返回碼，我們對介面返回的錯誤提示資訊和介面呼叫成功的提示資訊都應該明確，提示到點上。當然有些錯誤資訊可能是自身api的bug或者伺服器的問題等因素，這樣的話我們就應該要轉化一下提示不能把api自身問題暴露給介面呼叫相關方，這樣會導致介面的安全性等問題。
五、介面安全驗證及許可權的控制
許可權的控制是指針對不同的使用者群體，我們要分配不同的許可權（例如：超級管理員可以操作所有介面，普通使用者只允許操作部分介面），這裡除了針對使用者群體我們可以針對不同的呼叫介面的相關方（這裡的相關方是指呼叫介面的應用）進行許可權控制。
六、介面呼叫頻率的控制
七、請求介面日誌的記錄
我們應該要為介面請求做一下日誌的記錄，這樣我們後期維護介面時則會大大降低維護成本。而且還可以針對日誌進行相關的統計處理。
八、介面文件的可讀性
介面文件的可讀性非常重要，乙個介面開發出來並不是真正的完成，如果別人不會使用你的介面，那麼你的介面開發出來也是沒有用的，好多程式設計師非常的不重視介面文件撰寫及介面文件可讀性，寫出來的文件就像一本天書看著就頭大。好的文件應該讓人一看就知道如何呼叫，如何規避一些坑，簡單明瞭等等。
九、介面的反映速度
十、 客戶端與服務端的肥瘦平衡
十一、隱式使用者與顯式使用者
API介面設計要考慮的因素
一 介面版本化 生產環境中，如果沒有版本控制的程式變更會導致呼叫介面的相關方頻繁的跟著變更，假設相關方沒有及時的跟著變更，那麼系統就會報錯，從而影響到使用者的使用及體驗，使其對整個系統的運營都是不利的，介面對接的難度也會不斷的加大。如果介面能夠有版本的控制，則公升級系統的主動權就掌握在相關方，這樣當...
概要設計中的介面設計
介面在開發過程中可以快速分離工作內容。比如呼叫者在寫業務邏輯的時候需要乙個功能，可能是資料庫訪問，或者複雜計算，但是他的工作專注於實現業務邏輯，不想分開精力去做底層實現，那麼他只需要先實現乙個介面，定義了規範，然後就可以繼續他的業務邏輯 了。而實現者可以根據這個介面規範，做具體的實現。這樣通過使用介...
優秀的API介面設計原則及方法
一旦api發生變化，就可能對相關的呼叫者帶來巨大的代價，使用者需要排查所有呼叫的 需要調整所有與之相關的部分，這些工作對他們來說都是額外的。如果辛辛苦苦完成這些以後，還發現了相關的bug，那對使用者的打擊就更大。如果api經常發生變化，使用者就會失去對提供方失去信心，從而也會影響目前的業務。但是我們...