首先，我這裏說明接口，不是代碼裏的接口，而是接口項目，如果想錯了就不用往下看了。
在手機廣泛流行的今天，手機應用也隨之越來越多，而且成長的速度也非常快。手機應用軟件開發實現方式同普通PC軟件一樣，也分爲BS和CS方式。而採用CS方式，在服務器端大多采用接口的形式提供數據交互(主流數據交互方式有：Json、WebService等)，今天要說的就是如何設計接口。
接口作爲連通客戶端與數據庫進行數據流通的橋樑，起着舉足輕重的作用，直接影響着程序的效率性、穩定性、可靠性以及數據的正確性、完整性。客戶端注重的是界面美觀，操作方便順暢，是用戶最直接的感受體驗，而接口則是所有數據的提供者，是用戶深層的內涵體驗。
因次，設計接口在一個項目中，是非常重要的。那麼我就目前的經驗總結下如何合理設計接口。
一、 設計原理
1. 深入瞭解需求
除了設計數據庫的人最瞭解需求外，其次就是設計接口的人了，甚至有時接口開發人員還要參與到數據庫設計中。從“客戶端-接口-數據庫”的層次上看，接口明顯扮演着承上啓下的角色，一方面要明白接口要什麼數據，另一方面要考慮如何從數據庫獲取、組織數據。所以如果不瞭解需求，你就無法正確抽象對象來組織數據給客戶端，也無法驗證數據庫的數據結構能否滿足需求。數據庫設計者要了解需求中的數據結構，而接口則更多的要了解需求中的邏輯結構以及由此衍生出的邏輯數據結構。
2. 瞭解數據庫結構
既然接口要明白如何從數據庫獲取、組織數據，就當然要了解數據庫結構啦。
3. 瞭解客戶端原型
瞭解原型，其實更多是爲了幫助你設計接口時需要提供的數據和結構。但有時當你設計時並沒有原型，所以此條並不是必須要求的。但假如設計完接口後原型出來了，我們也可以拿原型還驗證接口設計是否正確、合理。
二、設計原則
1. 充分理由
不是隨便一個功能就要有個接口，也不是隨便一個需求就要加個接口。每新建一個接口，就要有充分的理由和考慮，即這個接口的存在是十分有意義額價值的，無意義的接口不僅增加了維護的難度，更重要是對於程序的可控性的大大降低，接口也會十分臃腫。因此我放在了第一條。
2. 職責明確
一個接口只負責一個業務功能，它與設計模式裏的職責單一原則類似但卻不同，因爲一個業務功能裏可能會包含多個操作，比如查詢會員，可能除了查詢會員表外還要獲取該會員的其他必要信息，但不要在查詢會員的同時還有修改權限等類似的其他業務功能，應該分成兩個接口還做。
3. 高內聚低耦合
一個接口要包含完整的業務功能，而不同接口之間的業務關聯要儘可能的小。還是查詢會員的例子，有時查詢會員的同時，可能該會員的相關信息要隨之發生變化(如狀態)，如果這時一條完整的業務流水線，那麼就應該在一個接口裏完成，而不應再單獨設立接口去操作完成。就是說一個接口不應該隨着另一個變化而變化或以某幾個接口爲前提而存在。
4. 分析角度明確
設計接口分析的角度要統一明確。否則會造成接口結構的混亂。例如，不要一會以角色的角度設計，一會兒就要以功能的角度設計。
5. 入參格式統一
所有接口的參數格式要求及風格要統一，不要一個接口參數是逗號分隔，另一個就是數組;不要一個接口日期參數是x年x月x日風格，另一個就是x-x-x。
6. 狀態及消息
提供必要的接口調用狀態信息。調用是否成功?如果失敗，那麼失敗的原因是什麼。這些必要的信息必須要告訴給客戶端。
7. 控制數據量
一個接口返回不應該包含過多的數據量，過多的數據量不僅處理複雜，對數據傳輸的壓力也非常大，會導致客戶端反應緩慢。過多的數據量很多時候都是接口劃分不明確。
8. 禁止隨意拓展參數
與第1條類似，只不過是針對參數而言了。日後拓展接口可能是難以避免的，但是不要隨意就加參數，加參數一定是必要且有意義的，需求改變前首先應考慮現有接口內部維護是否能滿足需求，而不要通過加個參數來方便自己實現需求的難度，因爲參數的更變會直接導致客戶端調用的變化，容易產生版本兼容性問題。
三、設計方法
1. 抽象業務
相比抽象對象而言，抽象業務更宏觀，我覺得相對也容易一些，但抽象尺度往往不太好把握。
2. 數據格式
接口定義的數據格式必須都經過充分考慮，否則會出現數據轉換失敗或超出長度等錯誤。如果無法確定，直接設置成字符串是最合適的。
3. 有意義的命名
無論是接口還是參數，名稱都應該是有意義的，讓人能看明白的。
總之，接口設計是一個細緻的工作，設計時也會有很多矛盾，但個人傾向於粗粒度設計方向(即內聚性更高一些)，這樣不僅給客戶端瀏覽接口方便明確，維護也輕鬆些，這麼做的缺點就是某一接口擴展時不是很靈活，但可以通過重新定義一個接口來彌補，但正如上所說，新增接口還是要三思而後行的。以上很多雖然都是理論性講解，但牢牢記住這些，並結合實際工作，就會慢慢深刻的體會到其中的含義。即理論指導實踐，實踐來驗證理論。
本文鏈接: http://www.yixieshi.com/14567.html (轉載請保留)
