REST描述的是在網絡中client和server的一種交互形式；REST本身不實用，實用的是如何設計RESTful API（REST風格的網絡接口）
RESTful的4種層次
Representational status transfer
個人理解為：表現形式的狀態傳遞
1、只有一個接口交換xml來實現整個服務
目前我們的移動站點的服務就是類似的結構，我們有兩個URI接口/mapp/lead和/msdk/safepay
2、每一個資源對應一個具體的URI，比1好維護，但是問題依然很明顯，資源版本更新會引入時間戳維護，資源的獲取和更新修改必須對應不同的URI
目前PC主站和移動站點的靜態內容（包括html文件）都是這種形式
3、在2的基礎上使用了http verb，每個URI可以有不同的動作，充分利用了http協議，所以自然居然http協議的完整優勢，比如緩存和健壯性
HTML4.0只支持POST和GET，所以無論DELETE還是PUT操作，都用POST去模擬了
在WEB開發者看來，就是如果有數據變動，就用POST，如果沒有，就用GET
所以目前中國用戶來看，PC端實現RESTful很困難，只有移動端支持Html5的瀏覽器，才能讓前端做出嘗試
4、現在似乎更加無法實際應用，Hypemedia control，也就是RESTful的本意，合理的架構原理和以網絡為基礎的設計相結合，帶來一個更加方便、功能強大的通信架構
HTTP動詞
對於資源的具體操作類型，由HTTP動詞表示。
常用的HTTP動詞有下面五個（括號裡是對應的SQL命令）。
GET（SELECT）：從服務器取出資源（一項或多項）。
POST（CREATE）：在服務器新建一個資源。
PUT（UPDATE）：在服務器更新資源（客戶端提供改變後的完整資源）。
PATCH（UPDATE）：在服務器更新資源（客戶端提供改變的屬性）。
DELETE（DELETE）：從服務器刪除資源。
還有兩個不常用的HTTP動詞。
HEAD：獲取資源的元數據。
OPTIONS：獲取信息，關於資源的哪些屬性是客戶端可以改變的。
下面是一些例子。
GET /zoos：列出所有動物園
POST /zoos：新建一個動物園
GET /zoos/ID：獲取某個指定動物園的信息
PUT /zoos/ID：更新某個指定動物園的信息（提供該動物園的全部信息）
PATCH /zoos/ID：更新某個指定動物園的信息（提供該動物園的部分信息）
DELETE /zoos/ID：刪除某個動物園
GET /zoos/ID/animals：列出某個指定動物園的所有動物
DELETE /zoos/ID/animals/ID：刪除某個指定動物園的指定動物
狀態碼（Status Codes）
服務器向用戶返回的狀態碼和提示信息，常見的有以下一些（方括號中是該狀態碼對應的HTTP動詞）。
200 OK - [GET]：服務器成功返回用戶請求的數據，該操作是冪等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數據成功。
202 Accepted - [*]：表示一個請求已經進入後台排隊（異步任務）
204 NO CONTENT - [DELETE]：用戶刪除數據成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發出的請求有錯誤，服務器沒有進行新建或修改數據的操作，該操作是冪等的。
401 Unauthorized - [*]：表示用戶沒有權限（令牌、用戶名、密碼錯誤）。
403 Forbidden - [*] 表示用戶得到授權（與401錯誤相對），但是訪問是被禁止的。
404 NOT FOUND - [*]：用戶發出的請求針對的是不存在的記錄，服務器沒有進行操作，該操作是冪等的。
406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 當創建一個對象時，發生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]：服務器發生錯誤，用戶將無法判斷發出的請求是否成功。
當我們被問及HTTP的GET與POST兩種請求方式的區別的時候，很多答案是說GET的數據須通過URL以查詢參數來傳送，而POST可以通過請求體來發送數據，所以因URL的受限，往往GET無法發送太多的字符。這個回答好比在啟用了HTTPS時，GET請求URL中的參數仍然是明文傳輸的一樣。
GET果真不能通過Request Body來傳送數據嗎？非也。如此想法多半是因循著網頁中形式的方法屬性只有get與post兩種而來。因為把形式的方法設置為post，表單數據會放在body中，而方法為get（默認值）時，提交時瀏覽器會把表單中的字符拼接到動作的URL後作為查詢參數傳送。於是偶乎就有了這麼一種假像：HTTP GET必須通過URL的查詢參數來發送數據。
HTML Form 表單有兩種資料傳遞方式，分別為 GET 與 PSOT 這兩種，當網有填好表單資料並按下送出表單的按鈕之後，必須透過這兩種方式將資料送出到伺服器（Web Server），以下為兩種方式的 HTML Code 寫法。
| GET | POST | |
| 網址差異 | 網址會帶有 HTML Form 表單的參數與資料。 | 資料傳遞時，網址並不會改變。 |
| 資料傳遞量 | 由於是透過 URL 帶資料，所以有長度限制。 | 由於不透過 URL 帶參數，所以不受限於 URL 長度限制。 |
| 安全性 | 表單參數與填寫內容可在 URL 看到。 | 透過 HTTP Request 方式，故參數與填寫內容不會顯示於 URL。 |
沒有留言:
張貼留言