現(xiàn)在web前端也是一個(gè)非常熱門(mén)的行業(yè)，想要學(xué)習(xí)web前端開(kāi)發(fā)的同學(xué)請(qǐng)看這里北京web前端調(diào)用restful ，通過(guò)對(duì)十萬(wàn)個(gè)Web前端面試題之RESTful API等?? 的了解，希望以上信息可以幫助到您

1.十萬(wàn)個(gè)Web前端面試題之RESTful API等

來(lái)自靈魂的拷問(wèn)你知道RESTful API嗎？他的優(yōu)點(diǎn)和缺點(diǎn)是啥？有沒(méi)有替換方案？小白回答RESTful API我知道，就是服務(wù)端接口，替換方案？這不是標(biāo)準(zhǔn)嗎？還替換啥？你是太閑了吧。老鳥(niǎo)回答早期Web是通過(guò)服務(wù)端生成頁(yè)面的，Web間的數(shù)據(jù)傳輸比較簡(jiǎn)單，后來(lái)，隨著企業(yè)業(yè)務(wù)的不斷發(fā)展，出現(xiàn)了技術(shù)。早期的技術(shù)異常繁瑣，基本都是使用XML，基于SOAP協(xié)議進(jìn)行通訊。隨著技術(shù)的發(fā)展，有一種技術(shù)，受到了大家的喜愛(ài)，他就是RESTful API API2000年時(shí)，Roy Thomas Fielding在他的博士論文中，首先提出了REST這個(gè)詞，我在鏈接里面放了他論文的地址，有興趣的可以看下。Fielding是個(gè)牛人，他是HTTP協(xié)議的主要設(shè)計(jì)者，Apache服務(wù)器軟件的作者之一、Apache基金會(huì)的*任主席，這邊不展開(kāi)講他了，我們講下RESTful的概念。Fielding對(duì)互聯(lián)網(wǎng)軟件的架構(gòu)原則，定義為REST，即 State Transfer的縮寫(xiě)，中文是表現(xiàn)層狀態(tài)轉(zhuǎn)化。如果一個(gè)架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)。REST包含三要求，即資源（Resources）、表現(xiàn)層（）、狀態(tài)轉(zhuǎn)化（State Transfer）資源：就是一個(gè)網(wǎng)絡(luò)上的實(shí)體，一個(gè)鏈接，一個(gè)圖片，一個(gè)視頻，任務(wù)網(wǎng)絡(luò)上的東西，都可以確定為一個(gè)資源，URI就是它的地址表現(xiàn)層：把資源具體展現(xiàn)中的形式，就叫表現(xiàn)層，比如文本使用txt、html、xml、json格式表現(xiàn)，圖片使用jpg、gif、png格式表現(xiàn)狀態(tài)轉(zhuǎn)化：通過(guò)操作，使得客戶端和服務(wù)端對(duì)某個(gè)資源在表現(xiàn)層上展現(xiàn)出來(lái)的不同狀態(tài)，叫狀態(tài)轉(zhuǎn)化，而操作的手段，只能是通過(guò)HTTP協(xié)議，比如用GET、POST、PUT、DELETE請(qǐng)求狀態(tài)總之，RESTful API是通過(guò)只使用HTTP協(xié)議，對(duì)網(wǎng)絡(luò)進(jìn)行資源化定義，非常簡(jiǎn)單直觀的描述和定義了資源這個(gè)概念，你只需要了解HTTP，就可以很快速的學(xué)習(xí)和使用，不需要額外的配置和協(xié)議。完整的RESTful API組成和定義1、協(xié)議一般是指HTTP或HTTPS協(xié)議2、域名如： OK - [GET]：服務(wù)器成功返回用戶請(qǐng)求的數(shù)據(jù)，該操作是冪等的（）。 201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功。 202 Accepted - [*]：表示一個(gè)請(qǐng)求已經(jīng)進(jìn)入后臺(tái)排隊(duì)（異步任務(wù)） 204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功。 400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請(qǐng)求有錯(cuò)誤，服務(wù)器沒(méi)有進(jìn)行新建或修改數(shù)據(jù)的操作，該操作是冪等的。 401 - [*]：表示用戶沒(méi)有權(quán)限（令牌、用戶名、密碼錯(cuò)誤）。 403 Forbidden - [*] 表示用戶得到授權(quán)（與401錯(cuò)誤相對(duì)），但是訪問(wèn)是被禁止的。 404 NOT FOUND - [*]：用戶發(fā)出的請(qǐng)求針對(duì)的是不存在的記錄，服務(wù)器沒(méi)有進(jìn)行操作，該操作是冪等的。 406 Not - [GET]：用戶請(qǐng)求的格式不可得（比如用戶請(qǐng)求JSON格式，但是只有XML格式）。 410 Gone -[GET]：用戶請(qǐng)求的資源被永久刪除，且不會(huì)再得到的。 422 entity - [POST/PUT/PATCH] 當(dāng)創(chuàng)建一個(gè)對(duì)象時(shí)，發(fā)生一個(gè)驗(yàn)證錯(cuò)誤。 500 INTERNAL SERVER ERROR - [*]：服務(wù)器發(fā)生錯(cuò)誤，用戶將無(wú)法判斷發(fā)出的請(qǐng)求是否成功。8、返回結(jié)果根據(jù)上面的請(qǐng)求操作與URL，返回特定的JSON結(jié)果RESTful的缺點(diǎn)RESTful API毋庸置疑，非常好用、簡(jiǎn)單且強(qiáng)大，它把任何當(dāng)成一個(gè)資源，非常適合微服務(wù)提供的請(qǐng)求返回。但隨著接口的增多，它也導(dǎo)致了一個(gè)問(wèn)題：過(guò)多的接口，就導(dǎo)致接口爆炸，過(guò)少的接口，就導(dǎo)致信息臃腫。前端在請(qǐng)求數(shù)據(jù)時(shí)，其實(shí)有時(shí)候，需要多個(gè)資源的集合，有時(shí)候又不需要單個(gè)資源的所有數(shù)據(jù)，前端希望能根據(jù)我的請(qǐng)求，返回特定的資源數(shù)，這時(shí)候，RESTful API明顯就力不從心了。GraphQL API這時(shí)，GraphQL API就派上用場(chǎng)了，完美的解決了上面RESTful API的缺點(diǎn)，我們下次再細(xì)說(shuō)GraphQL API

看了以上有關(guān)十萬(wàn)個(gè)Web前端面試題之RESTful API等??的講解，如果還有什么疑問(wèn)可以直接來(lái)電咨詢