初見微服務之RESTful API

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可讓這些拆分後的服務風格統1、便於維護和管理，目前我所參與設計和開發的系統存在100+的服務接口，若是不統一風格、調用方式，想必將是一場災難。服務層次化的前提是組件的拆分，如用戶組件URI前綴須要以 /user 開頭，配置系統的前綴須要以 /configuration開頭，用程序自動對前綴校驗。

    RESTful API的入參、出參，均已Java Bean的形式提現，稱之爲接口協議。業務接口協議能夠繼承用戶組件協議，各業務接口協議之間不能夠繼承和聚合，這些規則的設定，用冗餘的思想達到解耦的目的。

    固然微服務歷來不是銀彈，REST也不是救世主，這是一個發現問題、解決問題的過程，歷來沒有最完美的，只有最合適的。