1. REST名稱由來 REST全稱為Representational State Transfer，即表述性狀態轉移，最早由Roy Feilding博士在世紀之交（2000年）提出，喜歡追根溯源的朋友可以讀一下他的博士論文《Architectural Styles and the Design o ...
1. REST名稱由來
REST全稱為Representational State Transfer，即表述性狀態轉移，最早由Roy Feilding博士在世紀之交（2000年）提出，喜歡追根溯源的朋友可以讀一下他的博士論文《Architectural Styles and the Design of Network-based Software Architectures》，這時距HTTP1.1協議標準正式發佈（1999年6月）僅一年的時間。
歲月的痕跡跨越了十多年，技術的進步日新月異，所有的人都在談論著應用容器化、服務解耦、DevOps開發運維文化等等。我們變得喜新厭舊，技術成了快餐，框架是越來越多的舶來品。此時，我們是否應該靜一靜，看看技術的起源，想想我們如何成為軟體的設計師，而不是代碼的奴隸、資本的工具？REST作為歷史的寶藏，被越來越多的人挖掘、歸納、推陳出新，近幾年占領了幾乎所有的大型互聯網公司的開放API，國外如google（https://developers.google.com/apis-explorer）、facebook，國內的有豆瓣、騰訊的公眾平臺等。
在這裡，我要替SOAP說幾句話，技術的進步始終是從無到有，由繁入簡的。在一定的時間里SOAP滿足了web服務的設計要求，達到了對外提供服務的目的，儘管十分的（協議）晦澀、（解析）生硬。企業級的軟體依然有很多保留著SOAP式的服務，我工作過程中對接的一些政府如衛生計劃委員會、醫療HIS系統其實依然是保有SOAP的，它活在電腦構建的這一社會的血液里、空氣里。
2. 什麼是REST？
需要註意的是REST並不是一個標準或者協議，而是一種設計風格，或者說是一個設計web服務的最佳實踐，其要點如下：
1) 面向資源的URI設計，如user/register;
2) 對資源的操作包括增、刪、改、查（和資料庫層的操作極為相似）；
3) 連接具有無狀態性，即每一次的響應只依賴於這一次的請求；
4) 利用HTTP協議實現以上的設計思想。
非RESTful的設計示意圖如下：
RESTful的設計示意圖如下：
3. REST設計
REST的設計利用了HTTP協議的請求option，如GET、POST、PUT、DELETE。設計的簡單示意圖如下：
我工作過程中的一些最佳實踐是：
1) 對option的選擇不應過多，不應死板教條，常用的有GET、POST即可；
2) URI的設計應已名詞為主、動詞為輔，層次清晰；
3) 參數的設計應已單詞為主，少用多個詞的駝峰連接形式；
4) 功能與URI或者參數設計衝突時，應以功能實現為主。
4. REST的劣勢
a. 一千個讀者，一千個哈姆雷特，在設計評審粗糙的情況下，面向資源的URI設計五花八門；
b. URI泛濫，版本管理困難；
c. HTTP option使用不當；
d. REST API 參數、返回值設計不當；
……
5. 微服務為什麼選擇REST？
隨著組件拆分、服務解耦，各組件之間的調用均是通過介面實現，REST可以讓這些拆分後的服務風格統一、便於維護和管理，目前我所參與設計和開發的系統存在100+的服務介面，如果不統一風格、調用方式，想必將是一場災難。服務層次化的前提是組件的拆分，如用戶組件URI首碼需要以 /user 開頭，配置系統的首碼需要以 /configuration開頭，用程式自動對首碼校驗。
RESTful API的入參、出參，均已Java Bean的形式提現，稱之為介面協議。業務介面協議可以繼承用戶組件協議，各業務介面協議之間不可以繼承和聚合，這些規則的設定，用冗餘的思想達到解耦的目的。
當然微服務從來不是銀彈，REST也不是救世主，這是一個發現問題、解決問題的過程，從來沒有最完美的，只有最合適的。
