一、介面版本化
生產環境中，如果沒有版本控制的程式變更會導致呼叫介面的相關方頻繁的跟著變更，假設相關方沒有及時的跟著變更，那麼系統就會報錯，從而影響到使用者的使用及體驗，使其對整個系統的運營都是不利的，介面對接的難度也會不斷的加大。
如果介面能夠有版本的控制，則公升級系統的主動權就掌握在相關方，這樣當有新版本的程式發布時舊版本的業務邏輯不會受到影響，從使用者感知上也受到的影響就比較小，相關方也可以根據自身的條件是否要公升級版本。
二、介面面向的應用場景
三、請求引數的規範性及處理的統一性
請求引數的規範性意思就是說，介面要以什麼樣的方式來接收引數。是統一使用json的方式接收呢還是xml或者form表單方式接收。
在開發介面應該統一在乙個地方進行對引數的接收、校驗等操作。為了保證引數的完整性，我們可以考慮新增簽名驗證等處理。
四、返回資料型別、返回碼及資訊提示的規範性
返回給客戶端的資料型別應該要統一化（例如：我們統一以json的形式進行返回，或者是統一以xml的形式返回）。
不同的介面設計模式返回碼也會不同，如果使用現在非常火也比較流行的restfull風格那麼就應該要准許restfull風格的返回碼規定。如果是統一採用自定返回碼的話在設計返回碼時，應該要學會針對不同的業務處理模組對返回碼進行分段處理（例如：系統基礎管理我們使用10000-10050，使用者管理則就應該要從10051到10100，……），針對不同業務模組我們要預留足夠的返回碼，因為後期針對該模組的開發可能還會有其它業務的擴充套件或者調整等問題。返回碼分段處理的乙個好處就是方便呼叫介面的相關方能夠很快的定位到錯誤是屬於哪乙個部分，同時也方便介面開發人員定位介面錯誤在哪個地方。
除了返回碼，我們對介面返回的錯誤提示資訊和介面呼叫成功的提示資訊都應該明確，提示到點上。當然有些錯誤資訊可能是自身api的bug或者伺服器的問題等因素，這樣的話我們就應該要轉化一下提示不能把api自身問題暴露給介面呼叫相關方，這樣會導致介面的安全性等問題。
五、介面安全驗證及許可權的控制
許可權的控制是指針對不同的使用者群體，我們要分配不同的許可權（例如：超級管理員可以操作所有介面，普通使用者只允許操作部分介面），這裡除了針對使用者群體我們可以針對不同的呼叫介面的相關方（這裡的相關方是指呼叫介面的應用）進行許可權控制。
六、介面呼叫頻率的控制
七、請求介面日誌的記錄
我們應該要為介面請求做一下日誌的記錄，這樣我們後期維護介面時則會大大降低維護成本。而且還可以針對日誌進行相關的統計處理。
八、介面文件的可讀性
介面文件的可讀性非常重要，乙個介面開發出來並不是真正的完成，如果別人不會使用你的介面，那麼你的介面開發出來也是沒有用的，好多程式設計師非常的不重視介面文件撰寫及介面文件可讀性，寫出來的文件就像一本天書看著就頭大。好的文件應該讓人一看就知道如何呼叫，如何規避一些坑，簡單明瞭等等。這裡我介紹兩個比較好的介面管理視覺化工具給大家參考一下swagger和阿里巴巴的rap。
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 ...