Restful 表象性狀態轉移 的理解

2021-08-15 15:34:37 字數 3622 閱讀 8896

rest – representational state transfer直接翻譯:表現層狀態轉移。這個中文直譯經常出現在很多部落格中。尼瑪誰聽得懂「表現層狀態轉移」?這是人話嗎?我自己也困惑了很久,查詢了很多資料,花了差不多一年有個還算清晰的理解。

分享如下:@ivony 老師的一句話概括很精闢:url定位資源,用http動詞(get,post,delete,detc)描述操作。

— 簡潔版 —

0. rest不是」rest」這個單詞,而是幾個單詞縮寫。但即使那幾個單詞說出來,也無法理解在說什麼 -_-!! (不是要貶低人,是我自己也理解困難);

1. rest描述的是在網路中client和server的一種互動形式;rest本身不實用,實用的是如何設計 restful api(rest風格的網路介面);

2. server提供的restful api中,url中只使用名詞來指定資源,原則上不使用動詞。「資源」是rest架構或者說整個網路處理的核心。

比如:

獲取某人的新鮮;

獲取某人的好友列表;

3. 用http協議裡的動詞來實現資源的新增,修改,刪除等操作。即通過http動詞來實現資源的狀態扭**

get 用來獲取資源,

post 用來新建資源(也可以用於更新資源),

put 用來更新資源,

delete 用來刪除資源。

比如:delete 刪除某人的好友 (在http parameter指定好友id)

post 新增好友

update 更新個人資料禁止使用:

get 圖例:

4. server和client之間傳遞某資源的乙個表現形式,比如用json,xml傳輸文字,或者用jpg,webp傳輸等。當然還可以壓縮http傳輸時的資料(on-wire data compression) 。

5. 用 http status code傳遞server的狀態資訊。比如最常用的 200 表示成功,500 表示server內部錯誤等。主要資訊就這麼點。最後是要解放思想,web端不再用之前典型的php或jsp架構,而是改為前段渲染和附帶處理簡單的商務邏輯(比如angularjs或者backbone的一些樣例)。

web端和server只使用上述定義的api來傳遞資料和改變資料狀態。格式一般是json。ios和android同理可得。由此可見,web,ios,android和第三方開發者變為平等的角色通過一套api來共同消費server提供的服務。

— 詳細版 —

先說rest名稱rest – representational state transfer首先,之所以晦澀是因為前面主語被去掉了,全稱是 resource representational state transfer:

通俗來講就是:資源在網路中以某種表現形式進行狀態轉移。

分解開來:resource:資源,即資料(前面說過網路的核心)。比如 newsfeed,friends等;representational:某種表現形式,比如用json,xml,jpeg等;state transfer:狀態變化。通過http動詞實現。

rest的出處roy fielding的畢業**。這哥們參與設計http協議,也是apache web server專案(可惜現在已經是 nginx 的天下)的co-founder。phd的畢業學校是 uc irvine,irvine在加州,有著充裕的陽光和美麗的海灘,是著名的富人區。oculus vr 的總部就坐落於此(虛擬實境眼鏡,被fb收購,cto為quake和doom的作者 john carmack)。

眾說周知,**都是晦澀難懂的。當年在cmu讀書的時候,很多課程都會安排每週兩篇的***** review。現在回想起來每次寫***** review都是我最為痛苦的時候。rest這篇博士**毫無疑問更甚。

實用的是如何正確地理解 restful架構和設計好restful api。

首先為什麼要用restful結構呢?

首先是簡潔版裡面的那幾點。外加一些附帶的 best practices:

1.url root:

/v1/*

2.api versioning:

可以放在url裡面,也可以用http的header:

/api/v1/
3.uri使用名詞而不是動詞,且推薦用複數。

bad

/getproducts

/listorders

/retrieveclientbyorder?orderid=1

good

get /products : will return

the list of all products

post /products : will add

a product to

the collection

get /products/4 : will retrieve product #4

put /products/4 : will update product #4

4.保證 head 和 get 方法是安全的,不會對資源狀態有所改變(汙染)。比如嚴格杜絕如下情況:

get /deleteproduct?id=1
get /friends/10375923/profileupdate /profile/primaryaddress/city
6.警惕返回結果的大小。如果過大,及時進行分頁(pagination)或者加入限制(limit)。http協議支援分頁(pagination)操作,在header中使用 link 即可。

7.使用正確的http status code表示訪問狀態:

http/1.1: status code definitions
各端的具體實現如上面的圖所示,server統一提供一套restful api,web+ios+android作為同等公民呼叫api。各端發展到現在,都有一套比較成熟的框架來幫開發者事半功倍。

– server –

推薦: spring mvc 或者 jersey 或者 play framework

– android –

retrofit ( retrofit ) 或者 volley

– ios –

推薦:restkit ( restkit/restkit · github )

– web –

推薦隨便搞!可以用重量級的angularjs,也可以用輕量級 backbone + jquery 等。

restful的無狀態理解

所謂無狀態 就是資源可以通過uri來指定,就像是乙個蘿蔔乙個坑的意思。而且定位與其他資源無關,也不會因為其他資源的變化而變化。有狀態和無狀態的區別,有狀態是指 比如乙個資產應用系統,你想看下報廢的台式電腦有多少,是什麼型號,你得在登入介面登進去,然後點開資產維護功能,檢視報廢的相關資訊,選中台式電腦...

摘錄 Restful 的無狀態原則

無狀態 的概念逐漸流行,得益於分布式系統的發展。首先,無狀態請求易於實現負載均衡。在分布式web系統下,有多個可用伺服器,每個伺服器都可以處理客戶端請求。傳統的有狀態請求,因為狀態資訊只儲存在第一次發起請求的那台伺服器上,之後的請求都只能由這台伺服器來處理,伺服器無法自由排程請求。無狀態請求則完全沒...

01揹包的狀態轉移方程

這類問題算是再普通不過了,但是,我忘了。特別是狀態轉移方程,記不清怎麼推導的了,於是在這裡做一下回顧吧 設物品個數為n,每件物品的重量為w i 價值為v i 揹包承重w,我們用乙個二維陣列來表示最大收益,於是得到了方程 if w i 揹包承重j,無法入包 f i j f i 1 j else f i...