REST風格的應用程式實現

2022-02-12 21:03:03 字數 2525 閱讀 7315

莫笑我老土,因為我確實是最近才聽說rest風格的,以前就是覺得 /category/product/pid

這樣的位址非常的漂亮,但是那只是表象罷了,了解深入以後,發現必須有乙個客戶端的ajax engine和server端的服務配合,才能實現乙個rest風格的應用,下面就是我的實驗。

問題?

要對外提供哪些服務。伺服器端的服務可能會被眾多的瀏覽器請求,也可能被第三方應用程式所呼叫,所以需要從總體上來考慮這個對外的「應用程式介面」(api),盡量保持介面的穩定性。rest是一種風格,並且形成了自己的規則,構建這樣的應用,應盡量遵循rest的原則。

以乙個足球服務為例,眾多的觀眾會要求**比賽的記錄,上傳新比賽記錄,更新比賽記錄,更正現有的比賽或者刪除比賽等等。像這樣描述的話,我們需要提供眾多不同的服務,並且最終會倒在維護一致性的工作上。那麼應該怎麼做呢,考慮一下客戶可能的請求方式:

get方式請求乙個新建比賽服務:

post或put方式請求乙個新建比賽服務:

附加的xml為:

150 60

cgi風格的post或put請求:

請求體:

id=995&bluebaggers=150&redlegs=60

或者乙個維護服務的get請求:

或者post請求

15060

以此類推,可以有很多這樣的功能。有些人覺得這並不是什麼問題,對越來越多的請求,我們只要建立服務,然後給出相應的說明就可以了。但是,他還是存在缺點的。

也許我們會假設訪問只是來自指令碼,那麼這種情況可能會簡單一點。但實際上,還有很多的因素會涉及到,例如網頁瀏覽器(會存在後撤和重新整理按鈕的問題)、web伺服器(可能會有快取和編譯問題)、網路路由和快取問題、應對爬蟲的騷擾、一些個人站點對**內容的抓取。如果我們考慮這些不同的請求,我們的程式就可以表現的更健壯。

理想的情況下,乙個服務應該有自我說明的能力。如果乙個服務建立在一種約定俗成的條件下,那麼大家就很容易適應並且進行後續的開發。

rest就是考慮了這些因素,可以使用restful api來實現上面的服務。

restful 原則介紹

rest的主要原則有:

用url表示資源。資源就像商業實體一樣,是我們希望作為api實體呈現的一部分。通常是乙個名詞,每個資源都用乙個獨一無二的url來表示。

http方法表示操作。rest充分利用了http的方法,特別是get、post、put和delete。注意xmlhttprequest物件實現了全部的方法,具體可以參看w3c http 1.1 specification。

也就是說,客戶端的任何請求都包含乙個url和乙個http方法。回到上面的例子中,比賽顯然是乙個實體,那麼對於乙個特定比賽的請求就表示為:

這種方式是清晰明了的,也許和精確命名的方式有所區別,但是只要遵循這種形式,我們就能很快的進行get、delete、update和新建操作。

restful的原則:

1、url表示資源

2、http方法表示操作

3、get只是用來請求操作,get操作永遠都不應該修改伺服器的狀態。但是這個也要具體情況進行分析,例如乙個頁面中的計數器,每次訪問的時候確實引起了伺服器資料的改變,但是在商業上來說,這並不是乙個很重要的改變,所以仍然可以接收使用get的方式來修改資料。

乙個案例,使用get方式修改資料遭受損失的案例

4、服務應該是無狀態的

在有狀態的會話中,伺服器可以記錄之前的資訊。而restful風格中是不應該讓伺服器記錄狀態的,只有這樣伺服器才具備可擴充套件性。當然,我們可以在客戶端使用cookie,而且只能用在客戶端向伺服器傳送請求的時候。

5、服務應當是「冪等」的

「冪等」表示可以傳送訊息給服務,然後可以再次毫不費力的傳送同樣的訊息給服務。例如,傳送乙個「刪除第995場比賽」的訊息,可以傳送一次,也可以連續傳送十次,最後的結果都會保持一致。當然,restful的get請求通常是冪等的,因為基本上不會改變伺服器的狀態。注意:post請求不能被定義為「冪等」,特別是在建立新資源的時候,一次請求建立乙個資源,多次請求會建立多個資源。

6、擁抱超連結

7、服務應當自我說明

例如 請求了乙個具體的比賽,但是 並沒有對任何實體進行請求,因此,應當返回一些介紹資訊。

8、服務約束資料格式。資料必須符合要求的格式

在php的程式中,想要實現這種rest風格的url,僅僅依靠程式是不行的,還需要在伺服器端配置rewrite規則,例如,對於乙個rest風格的資源請求:

一般實現的指令碼為

這個是基於querystring的,也可以做乙個統一的 index.php 入口,然後通過處理uri的方式實現,例如:

這樣的url,都可以通過rewrite來實現rest風格。總之,rest是一種程式設計的風格,為我們整理自己的應用設計提供了乙個原則,在利用這些原則帶來的遍歷的同時,可以根據實際情況進行靈活的處理。

rest風格的理解

個人理解rest風格是一種規範,之前傳統的風格是將資源和對資源的操作融合在一起,而rest風格則是將資源和對資源的操作分隔開,充分發揮http動作,不是摁住post和get使勁薅。比方說庫存裡的一件商品是資源,傳統方式對這件商品進行修改,可能是http updateproduct,而rest風格則是...

讓gtk 應用程式的主題風格即時生效

主題風格似乎已是gui應用程式必不可少的元素了,不同使用者有不同的審美觀,為使用者提供多種的主題風格,或者讓使用者自己定製,都是比較好的選擇。記得win95剛出來時,很多人總會把它弄出不同的外觀,以顯示的自己的水平和與眾不同。在gtk 應用程式中,使用者可以定製主題風格 設定視窗 控制項在不同狀態下...

對REST風格的理解

1.自我理解 資源 表述性狀態轉換 轉移 將服務物件資源化,採用資源的風格來架構系統。即,把每個服務抽象為資源,通過對這個資源的curd形成統一的介面。更多情況下,體現為約定大於協議。2.統一性 每個資源只允許有curd,多個資源間的定義為資源委派 resourceassignment,對委派的資源...