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...