一、介面版本化

    生產環境中，如果沒有版本控制的程式變更會導致呼叫介面的相關方頻繁的跟著變更，假設相關方沒有及時的跟著變更，那麼系統就會報錯，從而影響到使用者的使用及體驗，使其對整個系統的運營都是不利的，介面對接的難度也會不斷的加大。

    如果介面能夠有版本的控制，則升級系統的主動權就掌握在相關方，這樣當有新版本的程式釋出時舊版本的業務邏輯不會受到影響，從使用者感知上也受到的影響就比較小，相關方也可以根據自身的條件是否要升級版本。

二、介面面向的應用場景

    在對介面進行設計時，我們還要考慮介面是面向web前端開發還是手機app開發，或者服務端開發。不同的應用場景介面總體規劃是不同的（例如：當我們的介面是提供給web前端或APP端使用時，介面安全驗證我們可以採用jwt、oauth2.0等，如果我們的介面是提供給後端服務使用時，那麼我可以採用token機制）。

三、請求引數的規範性及處理的統一性

    請求引數的規範性意思就是說，介面要以什麼樣的方式來接收引數。是統一使用json的方式接收呢還是xml或者form表單方式接收。

    在開發介面應該統一在一個地方進行對引數的接收、校驗等操作。為了保證引數的完整性，我們可以考慮新增簽名驗證等處理。

四、返回資料型別、返回碼及資訊提示的規範性

    返回給客戶端的資料型別應該要統一化（例如：我們統一以json的形式進行返回，或者是統一以xml的形式返回）。

    不同的介面設計模式返回碼也會不同，如果使用現在非常火也比較流行的restfull風格那麼就應該要准許restfull風格的返回碼規定。如果是統一採用自定返回碼的話在設計返回碼時，應該要學會針對不同的業務處理模組對返回碼進行分段處理（例如：系統基礎管理我們使用10000-10050，使用者管理則就應該要從10051到10100，……），針對不同業務模組我們要預留足夠的返回碼，因為後期針對該模組的開發可能還會有其它業務的擴充套件或者調整等問題。返回碼分段處理的一個好處就是方便呼叫介面的相關方能夠很快的定位到錯誤是屬於哪一個部分，同時也方便介面開發人員定位介面錯誤在哪個地方。

    除了返回碼，我們對介面返回的錯誤提示資訊和介面呼叫成功的提示資訊都應該明確，提示到點上。當然有些錯誤資訊可能是自身API的bug或者伺服器的問題等因素，這樣的話我們就應該要轉化一下提示不能把API自身問題暴露給介面呼叫相關方，這樣會導致介面的安全性等問題。

五、介面安全驗證及許可權的控制

    介面並不是每個操作者都能請求訪問的，所以我們要為介面提供一個安全驗證，就像使用者登入系統一樣，沒有在我們系統註冊的合法使用者我們是不允許請求訪問的。那麼我們要如何對介面進行安全驗證呢？其實針對不同的應用場景我們的介面安全驗證也不一樣（例如：當我們的介面是提供給web前端或APP端使用時，介面安全驗證我們可以採用jwt、oauth2.0等，如果我們的介面是提供給後端服務使用時，那麼我可以採用token機制）。

    許可權的控制是指標對不同的使用者群體，我們要分配不同的許可權（例如：超級管理員可以操作所有介面，普通使用者只允許操作部分介面），這裡除了針對使用者群體我們可以針對不同的呼叫介面的相關方（這裡的相關方是指呼叫介面的應用）進行許可權控制。

六、介面呼叫頻率的控制

    對介面的呼叫頻率進行控制從另一方面來講也是為了介面的安全性及介面的可維護性，當然這裡是否要對介面訪問次數進行控制還是取決於介面針對不同的應用場景，有些介面的設計是不需要限制呼叫頻率的，而有些介面則對介面呼叫是要進行嚴格控制的（例如：大家熟知的微信公眾號的開發就是對介面的呼叫頻率進行限制，並且針對不同的場景及使用者群體限制的頻率也不一樣）。

七、請求介面日誌的記錄

    我們應該要為介面請求做一下日誌的記錄，這樣我們後期維護介面時則會大大降低維護成本。而且還可以針對日誌進行相關的統計處理。

八、介面文件的可讀性

    介面文件的可讀性非常重要，一個介面開發出來並不是真正的完成，如果別人不會使用你的介面，那麼你的介面開發出來也是沒有用的，好多程式設計師非常的不重視介面文件撰寫及介面文件可讀性，寫出來的文件就像一本天書看著就頭大。好的文件應該讓人一看就知道如何呼叫，如何規避一些坑，簡單明瞭等等。這裡我介紹兩個比較好的介面管理視覺化工具給大家參考一下swagger和阿里巴巴的rap。