首先，我這裡說明介面，不是程式碼裡的介面，而是介面專案，如果想錯了就不用往下看了。

在手機廣泛流行的今天，手機應用也隨之越來越多，而且成長的速度也非常快。手機應用軟體開發實現方式同普通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. 有意義的命名

無論是介面還是引數，名稱都應該是有意義的，讓人能看明白的。

總之，介面設計是一個細緻的工作，設計時也會有很多矛盾，但個人傾向於粗粒度設計方向（即內聚性更高一些），這樣不僅給客戶端瀏覽介面方便明確，維護也輕鬆些，這麼做的缺點就是某一介面擴充套件時不是很靈活，但可以通過重新定義一個介面來彌補，但正如上所說，新增介面還是要三思而後行的。以上很多雖然都是理論性講解，但牢牢記住這些，並結合實際工作，就會慢慢深刻的體會到其中的含義。即理論指導實踐，實踐來驗證理論。