RESTful_基礎知識

目錄

目錄

前言

RESTful

REST原則

REST的Web原則

分層系統原則

RESTful的實現

SOA 面向服務的體系結構

RPC樣式 Web服務

RPC的實現過程

SOAP 簡單對象訪問協議

RPC樣式架構構建的基于SOAP的Web服務傳輸信封

RESTful Web服務

REST-RPC Web服務

RESTful Web服務的多層架構

Web服務的自動化客戶端和表示層處理程序

Web應用程序的客戶端和表示層處理程序

業務邏輯層

數據訪問層

數據存儲層

最后

前言

本篇主要是RESTful的基礎知識整理，主要是為了將要開始的Openstack架構主題做知識積累。理解好RESTful的設計思想無論是對學習Openstack架構還是Openstack Dashboard實現都是一件事半功倍的事情。

RESTful

REST(Representational State Transfer)：是一種軟件架構的設計風格，而不是一種標準。主要用于C/S架構的軟件設計，也能很好的支持B/S架構，為軟件設計提供了一組原則和約束條件，但這是原則和約束的條件均不具有標準性。

所以也可以將REST理解為是一組沒有嚴格標準的架構約束條件和設計原則。能夠使設計出來的軟件簡潔、可擴展、安全可靠、更有層次、更易于實現緩存機制。REST的軟件設計傾向于簡單輕量的方法設計和實現，以及REST具有通過HTTP直接傳輸數據的特性。

注意：REST并沒有一個明確的標準，更像是一種設計的風格。

RESTful：即滿足REST約束條件和原則的應用程式或設計，就是RESTful

REST原則

REST的Web原則

無狀態原則：

在Web應用程序中，最重要的REST原則是：Client和Server間的交互請求是無狀態的。在REST中，每一個對象都是通過URL來表示，對象用戶負責將狀態信息打包進每一條信息內，保證對象的處理總是無狀態的。

交互原則：

而且從Client到Serser的每一個請求都必須包含理解請求所需要的信息，如果Server在Client的請求過程中重啟了，Client不會得到Server的響應通知。但是，無狀態的請求可以由任何可用Server來響應。使用REST架構設計的系統，可以擴展到大量的Client中，并且降低了Client與Server之間的交互延遲。這十分合適云計算的環境。客戶端也可以緩存數據來改進其性能。

資源：

在Server端中的應用程序狀態和功能都可以抽象為一種資源，如：應用程序對象、數據庫記錄、算法等，這些資源以URI(Universal Resource Identifier)的方式向Client公開。每一個資源映射到一個URI，URI作為資源的唯一標識。

HTTP標準方法：

因為所有的資源又都共享統一的接口，便于Client和Server之間使用標準的HTTP方法(GET、PUT、POST、DELETE)來傳輸信息。

分層系統原則

分層系統：

為了使得系統中的組件無法了解除了與它自身交互的中間件之外的任何組件。通過將不同的組件分別限制在各自的層面上，可以限制整個系統的復雜性，促進了底層的獨立性。并且使用統一的Dashboard可以簡化整個系統的后端架構，改進子系統之間交互的可見性。即：簡化了Client和Server的實現。

中間件：

中間件是一種獨立的系統軟件或服務程序，能夠連接兩個獨立軟件或系統。分布式應用軟件借助于中間件能夠在不同的技術之間共享資源。即：中間件使得若干個相互獨立的系統，在各自都擁有著不同的接口的情況下，仍然能通過中間件來實現通信。執行中間件的一個關鍵途徑是信息的傳遞。通過中間件，應用程序可以工作在多個平臺及OS環境中。簡而言之，中間件即橋梁。

RESTful的實現

在理解RESTful的Web服務之前，首先來了解了解與之相似的另外一種實現方法—— RPC樣式 Web服務

SOA 面向服務的體系結構

SOA(面向服務的體系結構)：是一個組件模型，它通過在應用程序中不同的服務(功能單元)之間定義良好的接口和契約，使得不同的服務之間可以聯系起來。這些接口是采用中立的方式進行定義的，接口獨立于實現服務的硬件平臺、OS和編程語言。

SOA能夠讓這些構建在各種系統中的服務可以使用一種統一和通用的方式進行交互。

SOA可以根據需求通過網絡對松耦合的粗粒度應用組件進行分布式部署、組合和使用。服務之間通過簡單、精確定義的接口進行通信，不需要了解底層編程接口和通信模型。服務層是SOA的基礎，可以直接被應用程序調用，從而有效的控制系統中與軟件代理交互的人為依賴性。

SOA能夠讓軟件工程師們站在一個新的高度去理解企業級架構中的各種組件的開發、部署形式，它將有利于企業系統架構師更迅速、可靠、更具重用性的架構整個業務系統。

RPC樣式 Web服務

RPC的實現過程

RPC(Remote Procedure Call Protocol 遠程過程調用協議)，是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議(TCP/UDP)的存在，為程序的通信攜帶信息數據。

RPC采用C/S架構，Client請求服務，Server提供服務。Client的調用進程發送一個有進程參數的信封(包含參數的調用信息)到Server的服務進程，然后等待回應。Server的服務進程會保持睡眠狀態來等待Client發送的調用信息，當一個調用信息到達Server后，Server的服務程序就會獲得參數、并將執行后的結果響應給Client，然后返回睡眠狀態等待下一個調用信息。最后Client調用進程接收到響應信息后，得以繼續執行程序。

SOAP 簡單對象訪問協議

SOAP(簡單對象訪問協議)：是交換數據的一種協議規范，是一種輕量級的、簡單的、基于XML的協議，SOAP被設計成在Web上交換結構化和固化的信息。與WADL(Web Services Descruption Language)、UDDI(Universal Description Discovery and Integration)并稱為Web Servicve三要素。SOAP可以和HTTP(超文本傳輸協議)、SMTP(簡單郵件傳輸協議)等，現存的許多Internat協議和格式結合使用。而且還支持從消息系統到RPC(遠程過程調用)等應用程序。SOAP使用了基于XML的數據結構和HTTP(超文本傳輸協議)的組合來定義一個標準的方法，并以這種方法來使用Internat上各種不同操作環境中的分布式對象。

WADL：描述如何訪問具體的接口

UDDI：管理、分發、查詢Web Services

RPC樣式架構構建的基于SOAP的Web服務(傳輸”信封”)

這是實現SOA最常用的方法，RPC樣式的Web服務Client將一個包含了數據(方法、參數信息)的信封通過HTTP協議發送到Server，Server將信封打開并接收傳入的參數、執行指定的方法，然后將方法執行后的結果再次打包成一個信封返回到Client。最后Client接收到來自Server的響應。在PRC樣式的架構中，每一個對象都有自己獨特的方法，且僅會公開一個URI來標識。

注意：RPC架構忽略了HTTP大部分特性且僅支持POST方法。

RESTful Web服務

RESTful Web服務通常可以通過自動客戶端或代表用戶的應用程序直接訪問，在REST樣式的Web服務中，每個資源都有一個地址URI(統一資源表示符)。而資源的本身就是方法調用的目標，方法列表對所有的資源都是一樣的，這些方法都是標準方法，包括HTTP GET、PUT、POST、DELETE、HEADER、OPTIONS。

自動客戶端：

自動化使得應用程序能夠對在另一個應用程序中實現的對象進行操作，或者會將對象公開以便可以對其進行操作。自動客戶端是可以對屬于另一個應用程序公開的對象進行操作的應用程序。而公開對象的應用程序也被稱之為自動服務器。自動客戶端通過訪問自動服務器中對象的屬性和方法對這些對象進行操作。有下面兩種類型：

1. 運行時：動態的獲取相關服務屬性和操作信息的Client

2. 編譯時：擁有指定服務器屬性個操作的靜態信息的Client

在RPC樣式的Web服務中關注的是方法，而在RESTRful樣式的Web服務中關注的是資源。

REST-RPC Web服務

REST-RPC混合樣式Web服務不使用信封來包裝方法、參數、數據，是通過直接的HTTP傳輸數據，這一點與REST樣式的Web服務是類似的。但這種混合樣式不使用標準的HTTP方法來操作資源，它在HTTP請求的URI中就已經存儲了方法信息。

RESTful Web服務的多層架構

RESTful Web服務的多層架構與動態Web應用程序的多層架構在許多方面上是類似的。參照下面的多層架構圖。Web服務與Web應用程序的不同在于客戶端的本質(自動化/GUI)和表示層(Presentation layer)處理程序。Web服務讓業務邏輯(Business logic layer)和數據可以由自動客戶端(由自動化腳本支持的WebServicesClient)和GUI客戶端(BrowserClient)共享。

從數據訪問中分離業務邏輯可以實現數據庫的獨立性，并且能夠為各種類型的數據存儲提供插件能力。

Web服務的自動化客戶端和表示層處理程序

在自動化客戶端(Web服務的客戶端)中，包括了Python、Java等語言編寫的腳本，它們代表用戶以自動化樣式來運行。自動化客戶端在Web層向Resource Request Handler(資源請求處理程序，使用Jersey或Restlet框架實現)發送HTTP請求。自動客戶端的無狀態請求在頭部包含了方法信息，即POST、GET、PUT、DELETE等方法的信息，這又將映射到Resource Request Handler中資源的相應操作。每個無狀態請求都包含了理解請求所需要的信息，包括Resource Request Handler用來處理請求的憑據。從Web服務的客戶端接收到請求后，Resource Request Handler會從業務邏輯層請求服務。Resource Request Handler會確定所有概念性的實體，系統將這些實體作為資源公開出去的同時為每一個資源分配唯一的一個URI。但是，概念性的實體在表示層是不存在的，它存在于業務邏輯層。Resource Request Handler使用Jersey或Restlet框架來實現，所以它是輕量級的，會將大量的工作委托給業務邏輯層。

Web應用程序的客戶端和表示層處理程序

Web瀏覽器客戶端(GUI客戶端)，使用表示層中的Browser Request Handler(瀏覽器請求處理程序)生成的HTML來提供顯示功能。Browser Request Handler可以使用MVC、MTV模型。它從瀏覽器接受請求，從業務邏輯層請求服務，再生成表示視圖并對瀏覽器做出響應，表示視圖提供給用戶在瀏覽器中顯示。表示視圖不僅包含了內容，而且還包含了顯示的屬性，如HTML、CSS。在瀏覽器中運行且作為RESTful Web服務消費者的角色的Ajax、Flash等等都屬于Web服務的客戶端。Ajax和RESTful Web服務本質上是互補的，而且RESTful Web服務為Ajax提供了非常簡單的API來處理服務器上資源之間交互。

業務邏輯層

業務邏輯層充當著數據訪問層(Data access layer)和表示層之間數據交換的中間層，數據經過業務邏輯層的處理后以域對象或值對象的形式提供給表示層。從業務邏輯層中解耦Browser Request Handler和Resource Request Handler有助于促進代碼的重用，并能實現靈活和可擴展的架構。

數據訪問層

數據訪問層提供了與數據存儲層(Data store layer)的交互，數據訪問層可以使用DAO設計模式或對象-關系映射解決方案來實現。數據訪問層的作用在于針對不用的數據存儲技術，都能夠從業務邏輯層中分離數據訪問代碼。數據訪問層還可以作為連接其他系統的集成點，可以成為其他Web服務的客戶端。

DAO(Data Access Object)：數據訪問對象。是一個面對對象的數據訪問接口(API)，即連接數據庫的接口。夾在業務邏輯層和數據庫資源中間。

數據存儲層

數據存儲層包括了數據庫系統、LDAP服務器、文件系統和企業信息系統。使用該架構，你可以看到RESTful Web服務能夠靈活的成為任何企業數據存儲統一的API，從而向以用戶為中心的Web應用程序公開垂直數據，并部署自動化批量報告腳本。

最后

可能對于剛開始接觸RESTful的小伙伴們不能太理解上面的內容，不過大可以放心本篇是作為一個概括性的文章，以后還會反復的對其中的內容做出擴充。

Jmilk

RPC web前端

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。