国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

理解 RESTful

MkkHou / 2882人閱讀

摘要：表形容詞，意為的具有的。指的是一組架構約束條件和原則。協議要優于協議。的操作方法在中有各自的語義，理解它們的語義至為重要。返回結果對于不同操作方法和操作對象集合或個體，服務器返回的結果應該符合以下規范。附錄該文主要參考理解架構設計指南

前言

近十年，前端高速發展，整個互聯網應用經歷了從輕客戶端到重客戶端的變化，隨著前端規模越來越大，交互越來越復雜，前后端分離的設計開始流行。

移動互聯網時代的到來，前端開始泛指各種終端和 web 前端，服務端為多終端提供服務已然成常態。

前后端分離后，前端和后端通過雙方協商好的 API 進行交互，所以設計一套友好的 API 尤其重要。

RESTful 就是目前最流行的前后端交互 API 設計范式。

RESTful 釋義

顧名思義，先看一下 RESTful 的單詞拆解:

RESTful  =  Resources + Representation + State + Transfer + ful

我的理解是， RESTful 是指具有 資源表現層 和 狀態轉換 的架構設計。

資源(Resources) 
資源，是指服務端向外提供的服務實體。

資源是一個抽象的概念，可以是應用程序對象、數據庫記錄、算法等等。每一個資源用一個 URI 來唯一標識，客戶端通過這個標識對資源進行訪問、操作或請求服務。

表現層(Representation) 
表現層，是指資源的表現形式。

一個資源可以有多種表現形式。例如，文本數據可以用 XML 格式、JSON 格式表現，甚至可以用二進制格式表示；圖片可以用 JPG 格式表現，也可以用 PNG 格式表現。

狀態(State) 
狀態，是指資源的某種狀態。

一個資源可能有多種狀態。例如，資源空閑的、占用的、共享的、存在的、不存在的等。

轉化(Transfer) 
轉化，是指對資源的操作行為。

轉化的行為包括兩種:

資源表現層的轉化

資源狀態的轉化

ful 
后綴是英文的一種重要構詞法，通過后綴常常可以判斷出一個詞的詞性。

ful 表形容詞，意為“... 的”、“具有 ... 的”。

小結

RESTful 是一種抽象的、與具體程序語言和網絡協議無關的網絡服務系統的架構樣式。

它把在服務器端的數據和功能設計成各種的資源，并且通過 URI 定位資源、轉化資源表現和狀態的一種服務架構設計。

RESTful WEB 
REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。

目前 RESTful 應用最多的是在 web 服務，在 RESTful Web 服務中，每個資源都有一個地址(URL)。資源是方法調用的目標，方法列表對所有資源都是一樣的。這些方法是 Http 標準方法，如 HTTP GET、POST、PUT、DELETE 等。

下面來描述一下 RESTful Web API 的一些設計原則。

通信協議 
數據傳輸，安全第一。

HTTPS 協議要優于 HTTP 協議。

API 的根 URL 
API 的根 URL 很重要，它應該設計成可以輕松區別于其他非 API 的 URL。

最好的做法是將 API 部署在專有的域名下。

https://api.example.com

退而求其次，分配一個域名一級目錄給 API。

https://example.org/api/
版本信息 
為了 API 演變和兼容，為 API 加入版本信息是明智之舉。

應該為 API 設定版本號，并把版本號信息加入到 API 的根 URL 的下一級路徑。

https://api.example.com/v1/

或

https://example.org/api/v1/
URL 末端 
API 的根 URL + 版本信息 + URL 末端 = 資源位置

URL 末端最終明確指定了一個資源或一種資源的集合。URL 末端中不應該出現動詞，只能是名詞。如果該資源可以取其集合，對應的名詞應該采用復數形式。

舉個例子，有一組 API 提供公司員工的信息。

那么，獲取所有員工信息，末端應該設計成 /employees, 即:

https://api.example.com/v1/employees

獲取員工編號 007 員工的信息，末端應該設計成 /employees/007, 即:

https://api.example.com/v1/employees/007
操作資源 
資源的操作無外乎增、刪、改、查，對應即是 HTTP 的各個操作方法。

HTTP的操作方法在 RESTful 中有各自的語義，理解它們的語義至為重要。

方法 語義 例子 說明
GET 選擇、獲取 GET /employees/007 獲取編號 007 員工的信息
POST 新建 POST /employees 新建一個員工的信息
PUT 更新(完整) PUT /employees/007 更新編號 007 員工的全部信息，客戶端提供該員工的全部信息
PATCH 更新(局部) PATCH /employees/007 更新編號 007 員工的部分信息，客戶端只提供該員工的部分信息
DELETE 刪除 DELETE /employees/007 刪除編號 007 員工的信息
HEAD 獲取(元數據) HEAD /employees/007 獲取編號 007 員工的元數據，如員工數據的哈希值或最后修改時間
OPTIONS 獲取(權限信息) OPTIONS /employees/007 獲取客戶端能編號 007 員工進行哪些操作，即操作的權限

本章中，自此以上講述的都是如何描述"資源(Resources)"，而這小節講述的是"轉化(Transfer)"，轉化資源的狀態。

另外，轉化還包括資源的"表現層(Representation)"，它是通過 HTTP 頭部 Content Type 指定的。

過濾資源 
如果資源很多，通常你不會希望服務端一次性全部的數據，API 應該提供過濾資源的能力。

這里資源過濾依靠 URL 的查詢參數，通常放置在 GET 請求的URL中。

?limit=10: 限制返回的資源數量

?offset=10: 指定返回的資源的開始位置

?sortby=name&order=asc: 對資源按特定屬性進行排序

狀態碼 
狀態碼用以反映資源的操作結果或所處狀態。

HTTP 狀態碼本身是具有語義的，這剛好配對了 RESTful 的狀態。

以下列舉常用的狀態碼:

狀態碼 語義 HTTP 方法 說明
200 OK GET 成功返回用戶請求的數據
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 當創建一個對象時，發生一個驗證錯誤
錯誤處理

如果狀態碼是4xx，就應該向用戶返回出錯信息。一般來說，返回的信息中將error作為鍵名，出錯信息作為鍵值。

{
    error: "param error"
}
返回結果

對于不同操作方法和操作對象(集合或個體)，服務器返回的結果應該符合以下規范。

示例 返回
GET /collection 返回資源對象的列表（數組）
GET /collection/resource 返回單個資源對象
POST /collection 返回新生成的資源對象
PUT /collection/resource 返回完整的資源對象
PATCH /collection/resource 返回完整的資源對象
DELETE /collection/resource 返回一個空文檔

另外，返回的數據格式(Representation)應該盡量使用JSON。

最后

在 RESTful WEB 的實現中，使用 URL 定位資源，HTTP 方法操作資源，使得語義明確、結構清晰、易于理解和擴展。

RESTful 的這些優勢，使得它成為了目前最流行的一種互聯網服務架構。

附錄

該文主要參考:

Principles of good RESTful API Design

理解RESTful架構

RESTful API 設計指南

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11772.html

相關文章

  • 理解 RESTful

    摘要：表形容詞，意為的具有的。指的是一組架構約束條件和原則。協議要優于協議。的操作方法在中有各自的語義，理解它們的語義至為重要。返回結果對于不同操作方法和操作對象集合或個體，服務器返回的結果應該符合以下規范。附錄該文主要參考理解架構設計指南 前言 近十年，前端高速發展，整個互聯網應用經歷了從輕客戶端到重客戶端的變化，隨著前端規模越來越大，交互越來越復雜，前后端分離的設計開始流行。 移動互聯網...

    Drummor 評論0 收藏0

  • RESTful實踐（具體應用）思考

    摘要：其他交互一般會遵循一些數據結構協議或者狀態值，比如不同的操作結果對應不同的狀態值，且出錯會返回指定的錯誤信息方便前端進行提示等。 RESTful這種架構已經具有很長的時間和歷程了，但似乎最近restful這個詞出現的頻率特別高，目前不是很清楚是因為我自個兒現在是以restful風格寫程序產生的孕婦效應，還是單頁面程序開發的流行造成的。 其實一開始我也是不想寫這篇文章的，因為網絡上與re...

    myshell 評論0 收藏0

  • RESTful API的理解

    摘要：它的理論比較抽象不太具體，理解它主要在于理解這些概念資源表現層狀態轉換。基于原則設計的，一般稱為，需要遵守以下這些原則。返回結果，結果應該包括多種情況，異常錯誤信息正確結果目前而言最好使用格式傳輸數據。參考的理解，阮一峰 RESTful API 目前的異步加載橫行的時候，異步請求已經遍地都是，而規定請求接口的時候，如果不能有很好的風格的話，很多時候會讓開發者誤解，一個好的API接口 設...

    willin 評論0 收藏0

  • PHP / Laravel API 開發推薦閱讀清單

    showImg(https://segmentfault.com/img/bV6aHV?w=1280&h=800); 社區優秀文章 Laravel 5.5+passport 放棄 dingo 開發 API 實戰，讓 API 開發更省心 - 自造車輪。 API 文檔神器 Swagger 介紹及在 PHP 項目中使用 - API 文檔撰寫方案 推薦 Laravel API 項目必須使用的 8 個...

    shmily 評論0 收藏0

  • 理解RESTful架構與json-server模擬REST api的使用

    摘要：一什么是架構即的縮寫，我們把他翻譯為表述性狀態傳遞，是博士在年他的博士論文中提出來的一種軟件架構風格。是個無狀態的協議，所以狀態就保存在服務器端。只要少量的數據就可使用，支持和。同時支持，同時提供一系列的查詢方法如。 一、什么是RESTful架構？ REST即Representational State Transfer的縮寫，我們把他翻譯為表述性狀態傳遞，是Roy Fielding博...

    Atom 評論0 收藏0

發表評論

0條評論

MkkHou

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<