哪些能夠落實到自己的**裡面？
介面設計應該考慮哪些問題或者說考慮到哪些方面？
你設計的介面，夠優雅嗎？在設計介面時，有很多因素要考慮：
一 規範性建議
1.職責原則
在設計介面時，必須明確介面的職責，即介面型別，介面應解決什麼業務問題等，當前介面是解決什麼業務問題的?
2.單一性原則（單一職責原則）
在明確介面職責的條件下，盡量做到介面單一，即乙個介面只做一件事，而非兩件以上。
很多非資深介面設計者，在設計介面時，總認為介面所做的事越多，越牛叉，這是非常嚴重的錯誤認識。
單一職責原則和介面復用會衝突麼？
3.協議規範
在設計介面時，應明確介面協議，是採用 http 協議,https 協議還是 ftp 協議，要根據具體情況來定，當前介面採用的哪種協議型別？
(1)ftp 協議(file transfer protocol，簡稱 ftp)，是一套標準的檔案傳輸協議，用於傳輸檔案，如 .txt，.csv 等，一般檔案傳輸，採用 ftp 協議。
(2)http 協議，適用一般對安全性要求比較低或沒要求的業務情景。
(3)https=http+ssl，適用於對安全性要求較高的業務情景。
4.路徑規則
由於api 獲取的是一種資源，所以**中盡量為名詞，而非動詞。
/api/v1.0/product/2019
/api/v1.0/users/2019
5.http請求方式
介面基本訪問協議：get(獲取)，post(新增)，put(修改)和 delete(刪除)。
get /users：列出所有使用者
get /users/id：根據id獲取使用者
post /user：新增使用者
put /user/id：根據使用者id更新使用者
delete /user/id：根據使用者id刪除使用者
6.網域名稱
一般的，網域名稱分為主網域名稱和專有網域名稱，主網域名稱適合 api 長期不變或變化較少的業務，專有網域名稱是解決具體的專有業務的。
(1)主網域名稱:www.baidu.com
(2)產品服務類
7.跨域考慮
在明確網域名稱的情況下，一定要考慮介面是否跨域，以及跨域應採用的技術手段等。
8.api版本
對於介面的url，應加版本號 其中d表示版本號,如 v1.0,v2.0。
例子：獲取產品號為 2019，版本號為 v1.0 的版本號的產品資訊 /api/v1.0/pruducts/2019。
9.適度過濾資訊
當記錄數比較多時(如 select * from tbname)，應適當新增一些條件對資料進行過濾，如 top，分頁，分組，排序和 where 條件等
下面是一些常見的引數。
?limit=100：返回 100 條資料
?offset=101：從第 101 條資料開始返回
?page=10：指第 10 頁
?per_page=100：每頁 100 條資料
?sortby=name：排序字段
?order=desc：降序
?group=groupname:分組
?producy_type=1：篩選條件
10.返回資料格式
返回資料格式，一般包括三個字段：
(1)失敗情況(標識fail、錯誤碼-1和錯誤描述message)
(2)成功情況(標識success，資料物件data，狀態碼000000)
11.安全性原則
介面暴露的考慮，介面併發量的考慮，介面防攻擊的考慮，介面跨域的考慮等。
12.可擴充套件性原則
在設計介面時，充分考慮介面的可擴充套件性。
13.定義api訪問許可權
任何 api，從許可權上，可歸結為匿名api和非匿名api，前者不需要驗證，後者需要驗證。
14.定義api返回碼
在 api 設計時，要定好 api 返回碼，如
1）1 --授權過期
2）404--未找到資源
3）500--內部伺服器錯誤
4）600--賬號被鎖
二 反規範性建議
存在這樣一種業務場景：某個介面需要返回多個 api 介面組合的結果 ，在類似的業務場景下，所設計的介面，具有一定的反規範性（某個介面需要組合多個介面的資料）。
假設存在這樣乙個乙個業務：乙個erp系統，需要提供兩個介面，乙個是使用者訪問介面(需要驗證)，另乙個是使用者註冊介面(不需要驗證)。
根據本篇文章一，二部分的建議，我們來設計滿足該業務需求的介面
介面許可權類別，統一錯誤碼的定義，統一輸出引數的定義；
介面文件裡面需要的這些內容，如果需要些介面文件必須按照這種規範來寫；
介面定義：介面名，描述資訊，請求方式，校驗方式(是否匿名訪問)，code示例
請求引數：引數名，資料型別，是否必須，描述資訊
介面命名規範：
1. 拼寫要準確(單詞不能拼寫錯誤)
介面函式一旦發布就不能改了，要保持相容性，拼寫錯誤也不能改了，所以要仔細檢查拼寫，否則會被同行嘲笑很多年。
2. 不僅是英文單詞不要拼錯，時態也不要錯。
比如：返回bool的判斷函式，單數要用 is,複數要用are，這樣你的命名就和文件中的描述保持了一致性。表示狀態的變數或者函式要注意時態，比如 on***xchanged 表示***已經變化了，isconnecting表示正在連線。正確的時態可以給使用者傳遞更豐富的資訊(ing和ed)。
3. 函式最好是動賓結構(做什麼事情，方法名以動詞開頭)
動賓結構就是 dosomething，這樣的函式命名含義明確
比如： openfile, allocbuffer, setname
如果這個函式的動詞賓語就是這個物件本身，那麼可以省略掉賓語
4. 屬性命名最好是定語+名詞 （全域性變數或者說區域性變數，兩個單詞）
比如 filename, maxsize, textcolor
5. 不要用生僻單詞，這不是秀英語的地方，也不要用漢語拼音
比如：rendezvous，估計大多數人要去查詞典才知道什麼意思，這個詞源自法語，是約會的意思。
symbian os裡有個用它命名的函式，開發symbian的是英國人，也許人家覺得很平常吧，反正我是查了詞典才知道的。
6. 不要自己發明縮寫
除非是約定俗成已經被廣泛使用的縮寫，否則老老實實用完整拼寫。
壞例子: count->cnt, manager->mngr password->pw button->btn
現代的ide都有很好的自動完成功能，名字長一點沒關係的，可讀性更重要。
7. 保持方法的對稱性，有些方法一旦出現就應該是成對的，
比如 有open就要有close，有alloc就要有free，有add就要有remove，這些單詞基本是固定搭配的，使用者就很容易理解。
如果open對應clear就有點讓人困惑了。
8. 站在使用者的角度去思考，api設計也要講究使用者體驗。
好的api設計應該是符合直覺，能望文生義的，讓使用者能用盡量簡潔的**完成呼叫。
為了效能而犧牲介面設計可維護性的誤區，最終往往在效能上提公升很少，甚至沒有提高，程式可維護性也大大降低，這是我們都不希望看到的結果。
如何優雅的定義 App 的介面設計
使用者體驗設計的概念非常廣泛，包含了使用者 挖掘使用者潛在動機和實用性 視覺沒感體驗等等，通俗來講，如何讓你乙個產品給使用者很爽的感覺，其中包含的知識和方法都是使用者體驗的一部分。1，擬定你的設計範圍 2，整理你的資訊架構 3，考慮資訊的不同狀態 4，考慮資訊的多樣性 5，考慮產品的視覺美感 下面還...
UI介面設計 介面設計流程
人類社會逐步向非物質社會邁進，網際網路資訊產業已經走入我們的生活。在這樣乙個非物質社會中，與軟體這些非物質產品再也不象過去那樣緊緊靠技術就能處於不敗之地。工業設計開始關注非物質產品。但是在國內依然普遍存在這樣乙個稱呼 美工 工 的意思就是沒有思想緊緊靠體力工作的人。這是乙個很愚昧的做法，愚昧在於稱呼...
介面設計文件 介面設計的五點建議！
介面是目前 前後端互動 rest 系統互動 rpc 最普遍的一種方式。乙個好的介面，應該清晰易懂，職責明確，易於維護。反之，則會造成很多困擾。特別是open api，誰做誰知道。基於這樣的前提以及自己之前踩過的坑，就成了這篇文章的由來。文件與程式設計師之間有著一種非常奇妙的關係。一句話概括就是 寫之...