REST介面在前幾年是很火的，關於REST與SOAP有著無數的口水戰，現在隨著restful介面逐漸作為行業的事實上的標準普及開來應該已經沒有什麼異議了，這篇文章介面為什麼要使用restful風格的以及在近幾年的開發中restful介面設計的更新。

什麼是Rest

REST是“表現層狀態轉移（REpresentational State Transfer）”的縮寫。並不是一種標準或規範，實際上是一種架構和介面風格，在客戶端和服務端之間通過呈現狀態的轉移來驅動應用狀態的演進。

這麼解釋估計還是不太好理解，太學術了。
那下面的例子可以比較好的說明Rest定義，例子是轉載的哦。

Marcus是一個農民，他有4頭牛，12只雞和3頭奶牛。他現在模擬一個REST API，而我是客戶端。如果我想用REST來請求當前的農場狀態，我僅會問：“State？”Marcus會回答：“4頭豬、12只雞、3頭奶牛”。
 

這是REST最簡單的一個例子。Marcus使用表徵來傳輸農場狀態。表徵的句子很簡單：“4頭豬、12只雞、3頭奶牛”。

介面為什麼要Restful

到底什麼引起了Restful介面的流行呢？
我覺得是近幾年網際網路發展導致各個公司開發的系統規模逐步擴大，各個服務提供者越來越多的以獨立的元件或中介軟體的形式出現，各個系統之間的對接工作大幅提高，而Restful介面設計由於其輕量級、簡約的風格、效率、生產者和消費者的耦合性低受到各大公司的青睞，同時由於restful介面的無狀態特性使大規模應用的故障替換有了非常理想的解決方案，使用者不會有任何感覺，更關鍵的是熱備方案可以與業務完全隔離開，因此Restful介面風格迅速普及開來。

以下是Restful介面的幾個優點：
1. 介面的易用性，關於這一點請詳見參考資料.
2. 解耦，由於將業務都轉換為資源同時服務端不用關心客戶端之前的操作狀態，使客戶端與服務端能夠做到大幅度的設計解耦；
3. 效率與程式碼的簡潔性，如果使用SOAP介面的話，還記得WSDL2java生成的那一堆大部分沒用的程式碼麼，看著就頭疼，要是與十幾個系統進行webservice介面對接，而且各家規範還不一樣，想想就可怕。
還有其他的快取什麼就不詳細介紹了。
但是有一個問題，rest介面的安全問題並沒有在規範中提及因此各家實現的方式並不一致，因此這個問題需要注意，這也是在傳統注重安全的公司中webservice還是主流的原因。

我的Restful實踐之路

這是什麼

那是參加的第一個專案，正值2013年底，當時也是Restful介面在國內逐漸普及的時候，當時專案前天採用html+css+jquery的方式，後臺採用osgi+spring+jpa的架構。
我作為一個新手加入進來，起初看著每個介面都有一個requestmapping很奇怪，後臺做前臺時知道只要這個uri一致就能訪問到後臺服務，這背後的理論缺並不瞭解。後來我在閱讀系統方案時才瞭解到這樣的介面是符合rest風格的。當然當時主要是追時髦，我記得寫的最多的介面名就是findById，實際上有著Rest的名卻不是rest的思想。

原來是這樣

我作為專案技術負責人蔘加到了第二個專案中，此時我已經習慣了之前的介面方式。由於我們前端能力不足，我們的前端開發是外包給另一家小規模網際網路公司了，當我拿出了我設計的介面時，對方的負責人很認真的向我們介紹了他們使用rest經驗，並給出了介面的修改意見，現在回想起來確實很感謝他們，為我打開了一扇門。
之後我才去查了restful介面相關的知識，確實我們之前的介面只有rest名，經過一番大改並組織團隊一起學習和討論定下了新的介面。
當時對於rest的認識也只是停留在get是查，post建立，put和patch是修改，delete是刪除的階段。

感覺哪裡不對

但隨著專案的推進，我發現外包公司的經驗也有問題，比如最簡單的使用者登入和登出介面應該是什麼樣子的呢？是使用get方法，uri:api/user/login?username=XX&&password=123麼，但login是動詞啊，這不符合rest風格啊。還有rest介面中關於業務流程該怎麼說明呢，我怎麼知道這個資源能幹什麼啊，只能開發人員相互確定麼等等。
這方面的疑問還是很多的，後來我又找到了更多的相關資料來閱讀，疑問才逐漸的解開。最終的瞭解到了Hypermedia這個概念，介面中的_link可以新增資源相關的其他業務介面等等。

新的實踐

有了之前的經驗，我係統的查閱了rest相關資料，拜讀了Roy Fielding的論文和很多源頭性資料，發現了以前介面設計的問題，更重要的是瞭解到為什麼要restful。

Richardson成熟度模型

在這裡我只介紹這個模型關於rest應用的幾個級別，詳細資訊請參考文末的連結。
level 0：The Swamp of POX,基本是RPC的一套對接流程，需要關心對接方的業務
level 1：Resources，將業務向資源轉化，不管什麼操作都是get
level 2：HTTP Verbs，能夠通過post，put，get來進行業務操作
典型表現:
取東西就要GET（GET就是安全的，不會修改服務資源），新增就要POST（POST就是不安全的），修改就要PUT(PUT就要冪等)，刪除就是DELETE(DELETE就要冪等)….優雅的展示你的資源，甚至讓別人不看協議就能找到這個資源.
level 3:: Hypermedia Controls，通過介面的自描述來說明介面，通過_links的內容就能瞭解到相關的業務如何進行互動。
介面返回值應該差不多是這樣的：
{
“tracking_id”: “123456”,
“status”: “WAIT_PAYMENT”,
“items”: [
{
“name”: “potato”,
“quantity”: 1
}
],
“_links”: {
“self”: {
“href”: “http://localhost:57900/orders/123456”
},
“cancel”: {
“href”: “http://localhost:57900/orders/123456”
},
“payment”: {
“href”: “http://localhost:57900/orders/123456/payments”
}
}
}

Restful介面的常見設計問題

1. 介面的地址中含有動詞或方法
2. 沒有_link的相關介面連結
3. 自己造Hypermedia
4. URI要中統一使用小寫字母

關於Rest介面的設計具體規範我這裡就不一一列舉了，網上這方面的資源非常多，主要是關於URI設計，請求的方法以及HTTP標準狀態碼的應用。

參考資源