熱文索引，堅持原創不易，請小夥伴們不吝「推薦」支援：
1. 程式設計師必須掌握的效能調優 x y z
2. 程式設計師必須懂的架構入門課 1 2 3
3. 如何把單體式應用拆解成微服務？【上】
4. 如何把單體式應用拆解成微服務？【下】
5. 如何寫好產品幫助文件？
web api的應用場景非常豐富，例如：將已有系統的功能或資料開放給合作夥伴或生態圈；對外發布可嵌入到其他網頁的微件；構建前後端分離的web應用；開發跨不同終端的移動應用；整合公司內部不同系統等等。在上述場景裡，你可能是web api的使用者，也可能是設計者，但你知道如何評判web api的優劣嗎？
我們可以從三個維度來評判乙個web api的優劣：
做到了上述三個方面，我們才有底氣將乙個web api對外開放，接受公眾的檢驗。好的web api不僅方便使用，還助於提公升個人或企業的技術影響力，從而形成正向迴圈，帶來越來越多的業務價值。為了設計出優美的web api，我們需要了解與之相關的設計規範和事實標準，並且在設計開發過程中盡量遵循它們。
反例：正例：
反例：
反例：反例：
正例：
反例：
反例：獲取好友資訊，反例：傳送訊息，
正例：獲取好友資訊，
正例：傳送訊息，/messages
脊柱法：蛇形法：
駝峰法：
風格1：風格2：
完全符合：全文搜尋：
模糊搜尋：
路徑元素：按照http協議設計的本意，uri用於標識被操作的目標物件（資源），而http方法則是表示操作方法。基於http協議的簡單物件訪問協議soap逐漸被restful的原生http協議取代，我們也沒有必要畫蛇添足，最好就是吃透http協議，充分利用它的特性。查詢引數：
如果遇到上述http方法無法覆蓋的場景，那通常是資源的設計粒度太大了，我們可以把粗粒度的資源分解成多個細粒度的資源。在使用http協議設計web api的專業能力上，業界將其劃分為四個層級，level3相對較理想化，缺乏實施的基礎，level2是切實可行的：
常用的資料格式有：html、xml、json、yaml等，如果我們的服務在響應時支援不同型別的資料格式，那應用在呼叫服務時如何獲得期望格式的響應資料呢？通常我們可以考慮採用下述幾種指定資料格式的方法：
示例：
示例：
get /v1/users響應資料的結構應該盡量扁平化，不要巢狀太深，減少沒有具體含義的資訊載荷，這樣既可以壓縮報文尺寸，又可以節省頻寬的。當然，如果層級結構更具優勢，也可以採用。host: api.example.com
響應資料應該包含哪些資訊呢？是否越多越好？亦或越少越好，僅僅包含id？建議是按需返回，根據業務功能所需返回相應的資料。如果乙個web api需要提供給不同業務場景使用，不同業務場景對資料屬性資訊的要求不同，或多或少，這種情況我們可以讓使用者來選擇響應的內容，選擇方法就是通過查詢引數指定：
示例：123?fields=name,age
建議通過http協議首部的狀態碼來表示出錯資訊，而不是再封裝一層，遵守協議規範的好處是可以減少溝通的成本，也可以利用許多成熟的軟硬體產品來處理異常出錯資訊。http協議定了了五種型別的狀態碼：
我們需要每種狀態碼的使用場景，確保正確使用狀態碼。除此之外，服務還需要向客戶端返回詳細的出錯資訊，我們通常可以採用下述兩種方法來傳遞詳細的出錯資訊：
隨著業務的發展，每個發布上線的web api都存在更新修改的可能，那就需要引入版本管理的機制。業界有三種常見的標註web api版本的方法：
示例：
示例：/123?v=2按照版本編號增長的規則，web api的版本編號只需要標註主版本編號就可以了，因為次版本編號、補丁版本編號的增加都可以做到向下相容，不會影響使用者使用，唯有主版本編號增加才需要使用者更新公升級。除了標註版本資訊之外，我們在對外發布web api時還需要設計好版本變更的策略，例如：老版本提供多久的過渡期、同時相容多少個版本、特定版本的終止日期等等。
何為優美？就是符合大眾審美的，對於web api來說，就是符合標準規範的，這有利於降低使用者學習和使用的成本，便於交流，不存在隱沒成本。通常，業界存在的標準規範和事實標準都是經過實踐篩選出來的，從遵循模仿開始，然後再找機會創新，而不是一上來就重**明輪子。
關注「it老兵哥」，賦能程式人生！
「花式」裁員套路深，你知道嗎？
遭遇裁員，如何渡過心理危機？
如何在寒冬中找到好工作？
2c 還是 2b，跟找工作有什麼關係？
大公司 vs 小公司，你會選哪個？
記住這一點，不怕找不到好工作！
跳槽，跳還是不跳，該怎麼跳？
程式設計師「求包養」攻略揭秘
很努力了，為什麼我還在原地踏步？
從程式設計師到架構師，有捷徑嗎？
** spring：http 請求的處理流程與機制
** spring：http 請求的處理流程與機制
** spring：http 請求的處理流程與機制
** spring：http 請求的處理流程與機制
** spring：http 請求的處理流程與機制
如何正確使用 spring cloud？【上】
如何正確使用 spring cloud？【中】
如何正確使用 spring cloud？【下】
spring 核心技術與產品理念剖析【上】
spring 核心技術與產品理念剖析【下】
優美的配色方案設計
怎麼做好 設計配色 一直是個難題 雖然 上有各種各樣的色庫，但配色仍然至關重要，不得已的話可以親自動手，況且樂趣滿滿。這個沒有一套標準 所以看自己怎麼喜歡怎麼來 你可以使用 illustrator keynot 和你想到的其他用著順手的工具。vi設計包含的遠不止選擇顏色和字型，如果要給公司尋找一套配...
如何實現優美的骨架屏
對於前端來說，最重要的莫過於使用者體驗了，這次我們聊一聊骨架屏 skeleton screen 我們平常對於需要請求載入的內容，可能用的比較多的是loading動畫，比如在內容區域放乙個菊花圖，當請求結束，並且render tree構造完成後，將菊花圖移除，展示使用者想看的內容。雖然這種方式沒啥缺點...
資料結構 規則 技巧 優美的設計
什麼是設計？在我看來，設計者有一定的權威性，他知道如何使用標準 規則來進行必要的約束，再加上經驗對現實業務的抽象，就得到了資料庫模型 僅僅的規則 資料庫還不能稱作優美的設計，還要有一些技巧的發揮。有人要問了，你說的這些都太抽象了，根本連什麼是資料庫，什麼是規則，什麼是技巧都沒有說清楚嘛。呵呵，我覺得...