一、什麼是rest？而什麼又是rest的web服務？

rest（Representational State Transfer，表述性狀態轉移）是一種跨平臺的架構風格，不是一種新的技術，也不是一個標準。而常常提及的rest的web服務，是rest作為在web領域的一種實現方式。例如：簡約是一種設計風格，而metro就是簡約風作為在PC領域的展現。可能這個例子不太合適，但不難理解應該能說明這個問題。常說的JAX-RS標準則是java專案在實現rest風格的標準之一，簡單來說就是按照這個JAX-RS標準就可以來取實現一個rest風格服務。而Jersey則是GlassFish其中一個實現了JAX-RS標準的子專案。在胡亂灌了很多的概念之後，到底什麼是rest服務？怎麼去實現才能是一個rest風格的服務呢？作者Roy Thomas Fieding在他的論文裡面，提出了對於rest風格服務的幾點約束。

• 客戶-伺服器（Client-Server）

通訊發生在客戶端和伺服器之間，由客戶端發起，伺服器端響應。

• 無狀態（Stateless）

所有的狀態由客戶端來維護，伺服器端不維護或儲存通訊過程中的資料。

• 快取（Cache）

在通訊過程中的資料能夠被可選的中介軟體快取，以此來提高web服務效能，更友好的服務體驗。

• 分層系統（Layered System）

系統之間應該是分層的，降低層之間的耦合性。

• 按需編碼

這個約束是可選的，在rest服務中支援JavaScript等Rich client語言。

說了很多，從上面幾點來簡單總結下rest是為解決web應用在網際網路環境中出現的可伸縮性差（如：併發量增高），安全性，冪等性等問題而出現的一種分散式應用架構風格。而滿足這些約束的應用程式或架構，就可以稱之為restful。

二、為什麼要使用rest？

說了很多，似乎有這麼一種趕腳。rest的概念都這麼多，為什麼要拋棄之前已經相對成熟的soap（簡單物件訪問協議）？在這之前有必要去了解一下其他幾個概念，URI,資源，統一介面標準這樣些概念。

1.資源

這個概念讓我想起在初次接觸OO（面向物件）程式設計時的場景。在web中的應用中的伺服器上的文件、資料、表、甚至於一條資料都可以被抽象成一個資源。具體到什麼程度，只要開發者能夠理解並實現就可以。只要你的想象力足夠，天空才是你的極限。

2.uri（Uniform Resource Identifier）

統一資源識別符號，用來標識存在於web應用或者本地的資源。

3.UI（uniform Interface）

統一介面，在rest風格中，使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 來抽象所有 Web 系統的服務。對於一個資源來講，這種簡單明瞭的設計一下子解放了開發者的負擔。無論是客戶端和伺服器端，在程式設計上就更加的明瞭減少了開發的難度。這種簡單對應CRUD的操作，對於一個資源來講顯然是足以了。當然在現實生產中遠遠比這來的更加凶猛，這也導致了一些rest設計時出現的一些限制或者出現一些不倫不類的架構設計。既不是rest，也非soap。

4.rest和soap

首先來講rest和soap都是用來實現企業內部webservices來暴露內部API的一種方式。從rest和soap的風格上來說，rest更強調把內部的資源暴露，並提供簡單明瞭的API（PUT,DELETE,GET, POST)來簡化操作。而soap更貼近於RPC的實現方式，強調動作操作來暴露內部API。例如：getUserInfoByUserId，我們會經常看到這樣的介面設計。另外，soap在互動過程中，使用的為XML的方式來進行介面的描述和response的定義。而rest除了xml之外，也支援json、html的方式。

5.rest如何實現？

如今實現rest除了上面說的Jersey，還有一些廠商基於了JAX-RS標準的實現。比較為大家所熟知的有JBoss社群的RestEasy和Apache的CXF。上面說過JAX-RS標準只是作為實現rest風格的一種方式，而比較火熱的Spring MVC 則是區別於Jersey、RestEasy的另一種rest實現。

三、寫在後面

綜上。並不是說rest就一定是優於soap的一種webservices實現，因為根據相對論來說，任何事物都不是放之四海而皆準的。簡單來說，rest更貼近於以資源來定義應用的架構。更加輕便和高效是rest的特點，而soap在面對更多的業務邏輯複雜的介面設計中更加有優勢。如果一味的追逐rest風格，只會本末倒置、適得其反。

參考資料：