成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

理解 RESTful

MkkHou / 2893人閱讀

摘要：表形容詞，意為的具有的。指的是一組架構(gòu)約束條件和原則。協(xié)議要優(yōu)于協(xié)議。的操作方法在中有各自的語(yǔ)義，理解它們的語(yǔ)義至為重要。返回結(jié)果對(duì)于不同操作方法和操作對(duì)象集合或個(gè)體，服務(wù)器返回的結(jié)果應(yīng)該符合以下規(guī)范。附錄該文主要參考理解架構(gòu)設(shè)計(jì)指南

前言

近十年，前端高速發(fā)展，整個(gè)互聯(lián)網(wǎng)應(yīng)用經(jīng)歷了從輕客戶端到重客戶端的變化，隨著前端規(guī)模越來(lái)越大，交互越來(lái)越復(fù)雜，前后端分離的設(shè)計(jì)開始流行。

移動(dòng)互聯(lián)網(wǎng)時(shí)代的到來(lái)，前端開始泛指各種終端和 web 前端，服務(wù)端為多終端提供服務(wù)已然成常態(tài)。

前后端分離后，前端和后端通過雙方協(xié)商好的 API 進(jìn)行交互，所以設(shè)計(jì)一套友好的 API 尤其重要。

RESTful 就是目前最流行的前后端交互 API 設(shè)計(jì)范式。

RESTful 釋義

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

RESTful  =  Resources + Representation + State + Transfer + ful

我的理解是， RESTful 是指具有 資源表現(xiàn)層 和 狀態(tài)轉(zhuǎn)換 的架構(gòu)設(shè)計(jì)。

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

資源是一個(gè)抽象的概念，可以是應(yīng)用程序?qū)ο?、?shù)據(jù)庫(kù)記錄、算法等等。每一個(gè)資源用一個(gè) URI 來(lái)唯一標(biāo)識(shí)，客戶端通過這個(gè)標(biāo)識(shí)對(duì)資源進(jìn)行訪問、操作或請(qǐng)求服務(wù)。

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

一個(gè)資源可以有多種表現(xiàn)形式。例如，文本數(shù)據(jù)可以用 XML 格式、JSON 格式表現(xiàn)，甚至可以用二進(jìn)制格式表示；圖片可以用 JPG 格式表現(xiàn)，也可以用 PNG 格式表現(xiàn)。

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

一個(gè)資源可能有多種狀態(tài)。例如，資源空閑的、占用的、共享的、存在的、不存在的等。

轉(zhuǎn)化(Transfer) 
轉(zhuǎn)化，是指對(duì)資源的操作行為。

轉(zhuǎn)化的行為包括兩種:

資源表現(xiàn)層的轉(zhuǎn)化

資源狀態(tài)的轉(zhuǎn)化

ful 
后綴是英文的一種重要構(gòu)詞法，通過后綴常?？梢耘袛喑鲆粋€(gè)詞的詞性。

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

小結(jié)

RESTful 是一種抽象的、與具體程序語(yǔ)言和網(wǎng)絡(luò)協(xié)議無(wú)關(guān)的網(wǎng)絡(luò)服務(wù)系統(tǒng)的架構(gòu)樣式。

它把在服務(wù)器端的數(shù)據(jù)和功能設(shè)計(jì)成各種的資源，并且通過 URI 定位資源、轉(zhuǎn)化資源表現(xiàn)和狀態(tài)的一種服務(wù)架構(gòu)設(shè)計(jì)。

RESTful WEB 
REST 指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是 RESTful。

目前 RESTful 應(yīng)用最多的是在 web 服務(wù)，在 RESTful Web 服務(wù)中，每個(gè)資源都有一個(gè)地址(URL)。資源是方法調(diào)用的目標(biāo)，方法列表對(duì)所有資源都是一樣的。這些方法是 Http 標(biāo)準(zhǔn)方法，如 HTTP GET、POST、PUT、DELETE 等。

下面來(lái)描述一下 RESTful Web API 的一些設(shè)計(jì)原則。

通信協(xié)議 
數(shù)據(jù)傳輸，安全第一。

HTTPS 協(xié)議要優(yōu)于 HTTP 協(xié)議。

API 的根 URL 
API 的根 URL 很重要，它應(yīng)該設(shè)計(jì)成可以輕松區(qū)別于其他非 API 的 URL。

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

https://api.example.com

退而求其次，分配一個(gè)域名一級(jí)目錄給 API。

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

應(yīng)該為 API 設(shè)定版本號(hào)，并把版本號(hào)信息加入到 API 的根 URL 的下一級(jí)路徑。

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

或

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

URL 末端最終明確指定了一個(gè)資源或一種資源的集合。URL 末端中不應(yīng)該出現(xiàn)動(dòng)詞，只能是名詞。如果該資源可以取其集合，對(duì)應(yīng)的名詞應(yīng)該采用復(fù)數(shù)形式。

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

那么，獲取所有員工信息，末端應(yīng)該設(shè)計(jì)成 /employees, 即:

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

獲取員工編號(hào) 007 員工的信息，末端應(yīng)該設(shè)計(jì)成 /employees/007, 即:

https://api.example.com/v1/employees/007
操作資源 
資源的操作無(wú)外乎增、刪、改、查，對(duì)應(yīng)即是 HTTP 的各個(gè)操作方法。

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

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

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

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

過濾資源 
如果資源很多，通常你不會(huì)希望服務(wù)端一次性全部的數(shù)據(jù)，API 應(yīng)該提供過濾資源的能力。

這里資源過濾依靠 URL 的查詢參數(shù)，通常放置在 GET 請(qǐng)求的URL中。

?limit=10: 限制返回的資源數(shù)量

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

?sortby=name&order=asc: 對(duì)資源按特定屬性進(jìn)行排序

狀態(tài)碼 
狀態(tài)碼用以反映資源的操作結(jié)果或所處狀態(tài)。

HTTP 狀態(tài)碼本身是具有語(yǔ)義的，這剛好配對(duì)了 RESTful 的狀態(tài)。

以下列舉常用的狀態(tài)碼:

狀態(tài)碼 語(yǔ)義 HTTP 方法 說明
200 OK GET 成功返回用戶請(qǐng)求的數(shù)據(jù)
201 Created POST/PUT/PATCH 用戶新建或修改資源成功
202 Accepted * 成功發(fā)起一個(gè)異步任務(wù)
204 No Content DELETE 刪除資源成功
400 INVALID REQUEST POST/PUT/PATCH 請(qǐng)求有錯(cuò)誤，服務(wù)端沒有對(duì)資源進(jìn)行任何操作
401 Unauthorized * 表示用戶沒有權(quán)限（令牌、用戶名、密碼錯(cuò)誤）
403 Forbidden * 表示用戶得到授權(quán)（與401錯(cuò)誤相對(duì)），但是訪問是被禁止的
404 NOT FOUND * 請(qǐng)求對(duì)應(yīng)的資源不存在
406 Not Acceptable GET 用戶請(qǐng)求的格式不可得（比如用戶請(qǐng)求JSON格式，但是只有XML格式）, 即未支持的表現(xiàn)層
410 Gone GET 用戶請(qǐng)求的資源被永久刪除，且不會(huì)再得到的
422 Unprocesable entity POST/PUT/PATCH 當(dāng)創(chuàng)建一個(gè)對(duì)象時(shí)，發(fā)生一個(gè)驗(yàn)證錯(cuò)誤
錯(cuò)誤處理

如果狀態(tài)碼是4xx，就應(yīng)該向用戶返回出錯(cuò)信息。一般來(lái)說，返回的信息中將error作為鍵名，出錯(cuò)信息作為鍵值。

{
    error: "param error"
}
返回結(jié)果

對(duì)于不同操作方法和操作對(duì)象(集合或個(gè)體)，服務(wù)器返回的結(jié)果應(yīng)該符合以下規(guī)范。

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

另外，返回的數(shù)據(jù)格式(Representation)應(yīng)該盡量使用JSON。

最后

在 RESTful WEB 的實(shí)現(xiàn)中，使用 URL 定位資源，HTTP 方法操作資源，使得語(yǔ)義明確、結(jié)構(gòu)清晰、易于理解和擴(kuò)展。

RESTful 的這些優(yōu)勢(shì)，使得它成為了目前最流行的一種互聯(lián)網(wǎng)服務(wù)架構(gòu)。

附錄

該文主要參考:

Principles of good RESTful API Design

理解RESTful架構(gòu)

RESTful API 設(shè)計(jì)指南

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/11772.html

相關(guān)文章

  • 理解 RESTful

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

    Drummor 評(píng)論0 收藏0

  • RESTful實(shí)踐（具體應(yīng)用）思考

    摘要：其他交互一般會(huì)遵循一些數(shù)據(jù)結(jié)構(gòu)協(xié)議或者狀態(tài)值，比如不同的操作結(jié)果對(duì)應(yīng)不同的狀態(tài)值，且出錯(cuò)會(huì)返回指定的錯(cuò)誤信息方便前端進(jìn)行提示等。 RESTful這種架構(gòu)已經(jīng)具有很長(zhǎng)的時(shí)間和歷程了，但似乎最近restful這個(gè)詞出現(xiàn)的頻率特別高，目前不是很清楚是因?yàn)槲易詡€(gè)兒現(xiàn)在是以restful風(fēng)格寫程序產(chǎn)生的孕婦效應(yīng)，還是單頁(yè)面程序開發(fā)的流行造成的。 其實(shí)一開始我也是不想寫這篇文章的，因?yàn)榫W(wǎng)絡(luò)上與re...

    myshell 評(píng)論0 收藏0

  • RESTful API的理解

    摘要：它的理論比較抽象不太具體，理解它主要在于理解這些概念資源表現(xiàn)層狀態(tài)轉(zhuǎn)換?；谠瓌t設(shè)計(jì)的，一般稱為，需要遵守以下這些原則。返回結(jié)果，結(jié)果應(yīng)該包括多種情況，異常錯(cuò)誤信息正確結(jié)果目前而言最好使用格式傳輸數(shù)據(jù)。參考的理解，阮一峰 RESTful API 目前的異步加載橫行的時(shí)候，異步請(qǐng)求已經(jīng)遍地都是，而規(guī)定請(qǐng)求接口的時(shí)候，如果不能有很好的風(fēng)格的話，很多時(shí)候會(huì)讓開發(fā)者誤解，一個(gè)好的API接口 設(shè)...

    willin 評(píng)論0 收藏0

  • PHP / Laravel API 開發(fā)推薦閱讀清單

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

    shmily 評(píng)論0 收藏0

  • 理解RESTful架構(gòu)與json-server模擬REST api的使用

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

    Atom 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<