摘要

Web API 是一種在 Web 應(yīng)用程序之間交換數(shù)據(jù)的機(jī)制，它使得開發(fā)者可以輕松地在應(yīng)用程序之間共享數(shù)據(jù)和服務(wù)。而 Web API 規(guī)范則是指定 Web API 的開發(fā)方式和數(shù)據(jù)交換方式的標(biāo)準(zhǔn)化規(guī)范。常用的 Web API 規(guī)范包括面向過程的 RPC、面向 RESTful 的 Web API 和 GraphQL 等。

RPC

Remote Procedure Call (RPC)是一種常用的計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)，用于在遠(yuǎn)程計(jì)算機(jī)上執(zhí)行本地方法或函數(shù)。與傳統(tǒng)的本地方法調(diào)用不同，RPC允許客戶端在與遠(yuǎn)程服務(wù)器進(jìn)行通信時(shí)直接執(zhí)行遠(yuǎn)程方法，而不需要在本地進(jìn)行額外的編譯和安裝。

在RPC里，客戶端通常是把方法名和參數(shù)傳遞給服務(wù)器，然后服務(wù)器返回JSON或XML。

• 端點(diǎn)要包含被執(zhí)行操作的名字

• 使用合理的HTTP動(dòng)詞，GET用于讀取，POST用于其它類型。

REST

Representational State Transfer (REST) 是一種現(xiàn)今廣泛使用的 Web API 設(shè)計(jì)風(fēng)格。REST 是指通過使用表述性狀態(tài)傳遞來管理 Web 應(yīng)用程序中的狀態(tài)。

REST（Representational State Transfer）的核心是資源，它是一個(gè)可以被標(biāo)識(shí)的實(shí)體，通常有一個(gè)名稱和地址。每個(gè)資源都可以被獨(dú)立地識(shí)別、描述和操作，而不必知道它所屬的系統(tǒng)或應(yīng)用程序。因此，資源是REST架構(gòu)的基礎(chǔ)，是REST API設(shè)計(jì)和實(shí)現(xiàn)的核心概念。

REST API就是把數(shù)據(jù)以資源的形式暴露出來，并使用標(biāo)準(zhǔn)的HTTP方法來代表創(chuàng)建、讀取、更新和刪除資源等事務(wù)。

• 資源都是URL的一部分，例如/persons

• 針對(duì)每個(gè)資源通常都會(huì)有兩個(gè)URL被實(shí)現(xiàn)：“/persons”表示資源的集合，“/person/321”表示特定的一個(gè)資源

• 在資源里，使用名詞而不是動(dòng)詞，例如 /getUserInfo/123 這就不對(duì)了，應(yīng)該是 /users/123

• HTTP方法表明了要執(zhí)行的動(dòng)作，不同的HTTP方法作用于同一個(gè)URL上可實(shí)現(xiàn)不同的功能：

• 創(chuàng)建 -- POST

• 讀取 -- GET

• 整體更新 -- PUT

• 局部更新 -- PATCH

• 刪除 -- DELETE

• 服務(wù)器會(huì)以HTTP狀態(tài)碼來響應(yīng)請(qǐng)求，狀態(tài)碼分為2xx、3xx、4xx和5xx四類，分別表示成功、重定向、客戶端錯(cuò)誤和服務(wù)器端錯(cuò)誤。其中2xx表示成功，3xx表示重定向，4xx表示客戶端錯(cuò)誤，5xx表示服務(wù)器端錯(cuò)誤。

REST與RPC區(qū)別

REST和RPC都是用于實(shí)現(xiàn)客戶端與服務(wù)器之間的通信的架構(gòu)模式。但是它們的關(guān)注點(diǎn)不同。REST是一種基于資源的架構(gòu)模式，強(qiáng)調(diào)在Web上通過URI定位資源，通過HTTP協(xié)議進(jìn)行資源的讀寫操作。而RPC是一種基于動(dòng)作的架構(gòu)模式，強(qiáng)調(diào)在客戶端和服務(wù)器之間傳遞請(qǐng)求和響應(yīng)的過程，包括請(qǐng)求參數(shù)、返回值、錯(cuò)誤信息等。簡(jiǎn)單來說，REST關(guān)注的是資源，而RPC關(guān)注的是請(qǐng)求和響應(yīng)。

GraphQL

GraphQL 是一種現(xiàn)代化的 API 查詢語(yǔ)言，它于2014年由 Facebook 推出。GraphQL 是一種用于創(chuàng)建 RESTful 服務(wù)的查詢語(yǔ)言，它可以通過請(qǐng)求一個(gè) API 而獲得需要的所有數(shù)據(jù)，而不是像 RESTful API 一樣請(qǐng)求單個(gè)資源。

GraphQL為客戶端提供了更大的控制權(quán)，使得客戶端能夠明確指定需要獲取的數(shù)據(jù)結(jié)構(gòu)。而服務(wù)器則會(huì)根據(jù)客戶端的請(qǐng)求，返回完全匹配的數(shù)據(jù)結(jié)構(gòu)。這種靈活的方式能夠更有效地減少數(shù)據(jù)冗余，并且能夠幫助開發(fā)者更快速地構(gòu)建高質(zhì)量的應(yīng)用程序。

與REST和RPC不同，GraphQL API只需要一個(gè)端點(diǎn)來提供數(shù)據(jù)。它也不需要使用不同的HTTP動(dòng)詞，只需要使用POST方法。在JSON的body中，你需要明確指定要執(zhí)行查詢還是修改操作。

什么時(shí)候應(yīng)該用哪種Web API呢？

• 針對(duì)CRUD類的API，使用REST

• 針對(duì)暴露很多動(dòng)作的API，使用RPC

• 當(dāng)你需要查詢的靈活性以及維護(hù)的連續(xù)性時(shí)，使用GraphQL

  
  

HTTP協(xié)議規(guī)范

常見狀態(tài)碼及含義

200 - 請(qǐng)求成功，已經(jīng)正常處理完畢

201 - 創(chuàng)建成功

301 - 請(qǐng)求永久重定向，轉(zhuǎn)移到其它URL

302 - 請(qǐng)求臨時(shí)重定向

304 - 請(qǐng)求被重定向到客戶端本地緩存

400 - 客戶端請(qǐng)求存在語(yǔ)法錯(cuò)誤

401 - 客戶端請(qǐng)求沒有經(jīng)過授權(quán)

403 - 客戶端的請(qǐng)求被服務(wù)器拒絕，一般為客戶端沒有訪問權(quán)限

404 - 資源未找到，客戶端請(qǐng)求的URL在服務(wù)端不存在

500 - 服務(wù)端出現(xiàn)異常

MIME類型對(duì)應(yīng)列表

GET和POST的區(qū)別

• GET在瀏覽器回退時(shí)是無害的，而POST會(huì)再次提交請(qǐng)求。

• GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。

• GET請(qǐng)求會(huì)被瀏覽器主動(dòng)cache，而POST不會(huì)，除非手動(dòng)設(shè)置。

• GET請(qǐng)求只能進(jìn)行url編碼，而POST支持多種編碼方式。

• GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留。

• GET請(qǐng)求在URL中傳送的參數(shù)是有長(zhǎng)度限制的，而POST則沒有。對(duì)參數(shù)的數(shù)據(jù)類型GET只接受ASCII字符，而POST即可是字符也可是字節(jié)。

• GET比POST更不安全，因?yàn)閰?shù)直接暴露在URL上，所以不能用來傳遞敏感信息。

• GET參數(shù)通過URL傳遞，POST放在Request body中。

RESTful URL請(qǐng)求格式與傳統(tǒng)請(qǐng)求格式比較如下