一些REST架構設計模式的理解
最近在做的方向是o2o架構的一個網站設計,在這其中我們cto經常提出一個理念REST(你的介面不夠REST啊!)所以我在網上查了一些關於
REST文章,就把一些自己的理解,加上專案中的一些應用記在這裡吧。如果有大佬看到有問題請指正。
首先解釋一下那幾個單詞吧。
REST :全稱我把他稱為資源表述性狀態轉移!
RE : Resource ,Representational 首先說一下什麼叫做資源,你通過網際網路能夠請求到的東西就是一個資源,比如你的一個請求服務,你請求觀看的一張圖片,你看小說的txt文件,這些都是一個網路資源。 資源是一個抽象的概念,每一個資源都會有一種表述的形式可以是json,xml ,html,簡單的講就是一種資源的表現形式。
S: State 狀態我理解指的就是一個http返回狀態,更為具體的就是http的幾種狀態碼,404,200,505.用這些狀態碼來修飾。
T:Transfer
伺服器生成包含狀態轉移的表徵資料,用來響應客戶端對於一個資源的請求
REST 和REST API :
REST 並不是一種什麼技術,他是一種基於http的一種網路設計模式。RESTful API 實現了 REST規範的WEB API, 就是RESTful API客戶端藉助這份表徵資料,記錄了當前的應用狀態以及對應可轉移狀態的方式。
RESt的url必須使用名詞:
通常在設計URL時可能會根據你的url的功能加上一些動詞
post /users/getUser
post /users/creatUser
post /users/updateUser
post /users/deleteUser
這是通常的一種傳統請求設計,為什麼會這麼設計呢,url統一資源定位符,通過url來定位到一個資源,並不涉及對資源的操作,
所以操作要通過http動詞來實現.
而REST是面向資源的,一般url設計會是面向一種物件的設計,比如說會定位到user的這個資源(就是這個bean)然後他的
CRUD是使用http 四種請求方式來體現的所以就不需要動詞了。
get /users/{userId} 獲取userId對應的user資訊post /users 建立一個新的user
put /users/{userId} 更改userId對應的user資訊
delete /users/{userId} 刪除userId對應的user。
分層系統(Layered System),伺服器和客戶之間的通訊必須被這樣標準化。 統一介面(Uniform Interface),客戶和伺服器之間通訊的方法必須是統一化的。 支援按需程式碼(Code-On-Demand,可選),伺服器可以提供一些程式碼或者指令碼
URI 和表示符:
URI定義到你當前的操作物件(資源),更細緻的mapping(表示符)的是定義到每一個操作。
耦合型的網站架構:
我是做java的,java比較耦合的模式就是jsp設計,這種就是前後端耦合在一起開發。這是比較傳統的
pc端設計,但是在移動網際網路時代各種藉口層出不窮,這種傳統的mvc設計模式就很尷尬了,只能應用
pc端,但是如果Android,ios怎麼辦,還有微信公眾號,智慧手錶,平板都是訪問客戶端,這個時候對每
一個客戶端都有一套設計,這顯然是不可能的。這個時候就需要解耦的方式進行設計,將前端分離出來,
這裡的前端分和傳統的前端又不太一樣,不是簡單的靜態頁面的設計,是指client對統一的介面進行渲染
處理。
各端的具體實現:
server端提供一套統一的API,web+android+ios作為同等公民呼叫同等API,一般springmvc 或者是springboot
Android:
IOS:
移動端菜雞不做描述
web前端:
推薦隨便搞!可以用重量級的AngularJS,也可以用輕量級 Backbone + jQuery