REST如何實現WebService？

全球資訊網聯盟指出，REST是Web服務構建方式的模型。 REST Web 是 WWW（基於 HTTP）的乙個子集，其中 REST Web 提供統一的介面語義，這些語義本質上是建立、檢索、更新和刪除，而不是任意介面或特定於應用程式的介面，並且僅通過交換表示來操作資源。 所以，現在我們知道了REST是什麼，作者將簡要列出Roy Fielding在他的**的第5章中提到的所有約束：

客戶端-伺服器：以這樣一種方式實現服務，即使用者介面問題（客戶端獲得可移植性）和資料儲存問題（伺服器獲得可伸縮性）。

無狀態：當客戶端和伺服器之間實現通訊時，伺服器在處理請求時從不使用儲存在伺服器上下文中的任何資訊，而與會話相關的所有資訊都儲存在客戶端中。

快取：當可以快取請求的響應（隱式或顯式）時，客戶端應獲取快取的響應。

統一介面：所有 REST 服務都應依賴於元件之間的相同統一設計。 介面應與所提供的服務解耦。

分層系統：客戶端永遠不知道它們是直接連線到伺服器還是連線到某個中間伺服器。 例如，可以通過具有負載平衡或共享快取的功能發出請求。

在基本層面上，REST 樣式和 SOAP 樣式 Web 服務之間的區別取決於應用程式是面向資源還是面向活動。 例如，在傳統的 Web 服務中，獲取天氣預報的 Web 服務公開了 Web 方法。 另一方面，Restful WebService 公開的不是方法，而是物件（資源）。

在 REST 的定義中，Web 服務始終使用固定的 URI 向外界顯示（或公開）資源。 這是一種全新的思維方式：使用唯一的資源位置 URI 和 HTTP 請求方法實現對 Internet 上發布的資源的唯一描述和操作。

REST的概念可以歸結為以下幾個關鍵點：

1 資源導向的介面設計。

所有的介面設計都是針對資源設計的，這與我們物件導向和面向過程設計的區別非常相似，只不過網路上的運營實體現在都被視為資源，URI的設計也體現了資源的定位設計。 正如後面會提到的，有一些 ** API 設計是 REST 設計，但它們實際上是 RPC-REST 的混合體，而不是 REST。

2 抽象的基於操作的CRUD

這很簡單，http get、put、post、delete 對應 read、update、create、delete 四種操作，如果只是作為對資源的操作，抽象成這四種就足夠了，但是對於一些複雜的業務服務介面設計來說，可能無法滿足這樣的抽象。 其實這也暴露了在接下來的幾個**API的設計中，如果想要完全按照REST的思想進行設計，那麼適用的環境將是有限的，而不是通用的。

3 HTTP 是一種應用程式協議，而不是傳輸協議。

這一點在後面主要**的API分析中體現得很清楚，其實有些**已經走上了SOAP的老路，說是REST的概念設計，但實際上卻是一套私有的SOAP協議，所以被稱為REST風格的自定義SOAP協議。

4 無國籍，自給自足。

這不僅適用於REST，也適用於介面設計，並且是可伸縮性和效率的最基本保證，甚至對於基於SOAP的Web服務也是如此。

REST的全稱是Representation State Transfer，它描述了一種用於設計Web應用程式的架構風格，它是一組架構約束和原則，以滿足RESTful風格的應用程式或設計的要求。 符合 RESTful 風格的 Web 服務就是我們所說的 RESTful Web 服務。

粗略理解：這只是一些介面。 您可以發布資源。

資源層面的操作介面統一，方便其他管理軟體和管理模組的訪問。 具體如下：

通過統一資源抽象模型，實現異構資源操作的規範化。

實現了資源訪問入口的統一和封裝。

實現了各類資源的集中管理;

專注於資源管理操作，以最大限度地提高模組的重用率。

不一樣 WS 有乙個 WS 客戶端呼叫 REST 是乙個簡單的 http 請求，也可以直接呼叫瀏覽器 基於REST的介面 ful 的效能比 WS 好很多 現在的 WS 系統已經非常完備了，REST 上公升的路不長，但 REST 會佔到房東的很大一部分， 毫無疑問，要採用它。