這裡**的 api 均為系統邊界的api設計，而對於內部 api 來說不在**範圍之內。
變動困難
api 就像乙個人一樣，我們和乙個api打交道的時候需要了解這個人的特性偏好等，
有的人很好相處，而有的人讓人很頭疼，尤其是你不得不和他打交道的時候。
和人一樣，如果你不得不和他打交道，要改變他的秉性是很痛苦的，人的「本性難移」, api 也一樣，一旦發布了，要改變的成本就很大很大。
好的 api 應該具有：
易於學習
即使沒有文件也易於使用
不易誤用：這一點很重要，要減少使用者的心智負擔
使用 api 的**易於維護。這個有點不一樣，不是 api 本身易於維護，而是 api 的友好度。
比如介面功能單一，使用簡單，使用者的**也會相應的更易於維護
易於滿足需求：api 的完備性和正交性。能夠容易的滿足需求，完備性保證功能完整，
正交性保證介面的簡潔性，不需要為所有的需求提供介面，而是由使用者去組合。
易於擴充套件
基本原則：
專一：乙個 api 的功能應該是單一的，需要能夠很容易的解釋和理解，也就會更好用。
盡可能的小：小有很多的優勢，易於理解和維護。
盡量少的外部依賴：減少使用者的成本
設計不被實現影響:不要暴漏實現細節給使用者
竟可能少的暴露，不止是內部細節，對於不必要的介面盡量不要發布，比如使用不多的功能，
可以暫時不暴露介面。
良好的命名:盡量做到自描述。
完善的文件
考慮效能
服務API設計 之 API設計原則
對接xx業務時，xx業務具備的功能和api全靠跑業務負責人那反覆逐個詢問 確認。用哪個api 怎麼用 有沒有限制 等等 各個業務間，甚至同一業務內，api風格不統一。xx業務api效能方面未知。隨著業務的演進，開放的api持續在增加，但類同的很多 api編碼規範迫在眉睫 自解釋 易學習 易使用 難誤...
開放api設計
博主不大擅長寫作，但看了 高效能程式設計師的修煉 一書，不得不改變下自己。本文是對最近使用web service做專案時，討論的總結。如有錯誤，歡迎勘正，共同提高。第一次寫技術部落格，難免邏輯和條理不清，也請指點。本著分享和學習的目的，歡迎拍磚！主要分次三部分 restful風格 開放api的技術要...
學習設計API
介紹 其實對於我們接觸的web端開發而說，api就是協商好的一種規範，大家都按這個規範做事，這裡主要針對前 後端互動的介面進行說明 返回值約定 返回值是指當前端返回後端給出的介面時返回的資料格式，常見的有這麼幾種 text,json,xml，現在大多數會用json，因為她傳輸資料少，可擴充套件性強，...