日产精品卡2卡3卡4卡免费,日本老妇人乱xxy

REST 客戶端可以通過(guò)發(fā)送 HTTP 請(qǐng)求來(lái)與每個(gè)資源進(jìn)行交互

REST API 概念

REST API 范例的關(guān)鍵元素是

在用戶的計(jì)算機(jī)或智能手機(jī)上運(yùn)行并啟動(dòng)通信的客戶端或軟件;
提供 API 作為訪問(wèn)其數(shù)據(jù)或功能的手段的服務(wù)器;
資源，即服務(wù)器可以提供給客戶端的任何內(nèi)容（例如，視頻或文本文件）。

為了訪問(wèn)資源，客戶端會(huì)發(fā)送一個(gè) HTTP 請(qǐng)求。作為回報(bào)，服務(wù)器會(huì)生成一個(gè) HTTP 響應(yīng)，其中包含資源上的編碼數(shù)據(jù)。這兩種類型的 REST 消息都是自描述的，這意味著它們包含有關(guān)如何解釋和處理它們的信息。

REST API 方法和請(qǐng)求結(jié)構(gòu)

任何 REST 請(qǐng)求都包括四個(gè)基本部分：HTTP 方法、端點(diǎn)、標(biāo)頭和正文。

HTTP 方法描述要對(duì)資源執(zhí)行的操作。有四種基本方法也稱為 CRUD 操作：

POST 創(chuàng)建資源，
GET 檢索資源，
PUT 更新資源，使用 PUT
DELETE 刪除資源。

終端節(jié)點(diǎn)包含統(tǒng)一資源標(biāo)識(shí)符（URI），用于指示在 Internet 上查找資源的位置和方式。最常見(jiàn)的 URI 類型是?Unique Resource Location?（URL），用作完整的 Web 地址。

標(biāo)頭存儲(chǔ)與 Client 端和服務(wù)器相關(guān)的信息。標(biāo)頭主要提供身份驗(yàn)證數(shù)據(jù)，例如 API 密鑰、安裝服務(wù)器的計(jì)算機(jī)的名稱或 IP 地址，以及有關(guān)響應(yīng)格式的信息。

正文用于將其他信息傳送到服務(wù)器。例如，它可能是您要添加或替換的一段數(shù)據(jù)。

創(chuàng)建新用戶的 REST 請(qǐng)求，其中響應(yīng)將返回已創(chuàng)建資源的 ID。來(lái)源：Tableau API

REST 響應(yīng)結(jié)構(gòu)

服務(wù)器在響應(yīng)請(qǐng)求時(shí)，并不直接發(fā)送資源本身，而是發(fā)送該資源的表示，即一種描述其當(dāng)前狀態(tài)的機(jī)器可讀格式。資源可以以多種格式呈現(xiàn)，但XML和JSON是最普遍使用的兩種。

服務(wù)器在響應(yīng)中還會(huì)包含指向其他相關(guān)資源的鏈接或超媒體元素，前提是這些內(nèi)容與請(qǐng)求相關(guān)。這種做法為客戶端提供了指導(dǎo)，告訴它們接下來(lái)可以采取哪些操作，以及可以發(fā)起哪些額外的請(qǐng)求。

使用超媒體的自描述性服務(wù)器響應(yīng)的示例。源：勞倫·朗

REST 最佳實(shí)踐：API 的 RESTful

REST 不與任何特定技術(shù)或平臺(tái)相關(guān)聯(lián)。它也沒(méi)有規(guī)定如何構(gòu)建 API。相反，它引入了稱為約束的最佳實(shí)踐。它們描述了服務(wù)器如何處理請(qǐng)求并響應(yīng)它們。在這些約束下運(yùn)行，系統(tǒng)將獲得理想的特性。

客戶端-服務(wù)器自主性

獲得的屬性：可修改性、更好的系統(tǒng)可靠性

在 REST API 系統(tǒng)中，客戶端和服務(wù)器使用不同的技術(shù)堆棧獨(dú)立工作?？蛻舳瞬恍枰私馊魏侮P(guān)于業(yè)務(wù)邏輯的信息，而服務(wù)器對(duì)用戶界面一無(wú)所知。職責(zé)分離意味著API提供者和API使用者可以各自進(jìn)行修改，而不會(huì)相互產(chǎn)生不利影響或?qū)е虏涣己蠊?/p>

統(tǒng)一接口

獲得的屬性：易于使用、共同理解

統(tǒng)一接口是區(qū)分 REST API 與非 REST API 的關(guān)鍵屬性。它規(guī)定了與特定服務(wù)器進(jìn)行通信的標(biāo)準(zhǔn)化方法，這種標(biāo)準(zhǔn)化方式不依賴于運(yùn)行該服務(wù)器的客戶端應(yīng)用程序或設(shè)備的類型。我們已經(jīng)提到了支持這種做法的一些基本原則，它們是

分配給每個(gè)資源的唯一標(biāo)識(shí)符（URI），
解釋如何解釋它們以及下一步做什么的自描述性消息，
能夠通過(guò) JSON 或 XML 中的表示形式來(lái)操作資源，
超媒體鏈接到相關(guān)資源。

無(wú)論客戶端如何，服務(wù)器都使用相同的接口

統(tǒng)一的接口有助于開(kāi)發(fā)人員輕松掌握 API 的邏輯。Envysion 的軟件開(kāi)發(fā)總監(jiān) Todd Main 承認(rèn)，如果合作伙伴公司選擇了 REST 方法，他會(huì)松一口氣：“我知道我只需瀏覽一個(gè)對(duì)象列表，我通常已經(jīng)熟悉這些對(duì)象，然后查看我可以獲得或提供哪些屬性。 Todd 補(bǔ)充說(shuō)，使用 RESTful API 實(shí)現(xiàn)代碼也很容易：“在我的編程語(yǔ)言中，傳遞的對(duì)象直接轉(zhuǎn)換為數(shù)據(jù)結(jié)構(gòu)。

分層架構(gòu)

獲得的屬性：改進(jìn)的系統(tǒng)可擴(kuò)展性和安全性

RESTful架構(gòu)的系統(tǒng)呈現(xiàn)出分層的特性，其中每一層都獨(dú)立運(yùn)作，并且僅與直接相鄰的層進(jìn)行交互。當(dāng)客戶端請(qǐng)求服務(wù)器時(shí)，它并不需要了解請(qǐng)求路徑上是否存在任何中間層。

正是這種分層的設(shè)計(jì)使得在客戶端和服務(wù)器之間部署代理服務(wù)器或負(fù)載均衡器成為可能，進(jìn)而增強(qiáng)了系統(tǒng)的可擴(kuò)展性。將安全作為一個(gè)獨(dú)立的層添加到架構(gòu)中，可以提升整個(gè)系統(tǒng)的安全性。盡管這些服務(wù)負(fù)責(zé)生成響應(yīng)，但客戶端無(wú)需了解后端接口的具體實(shí)現(xiàn)細(xì)節(jié)。

客戶端與 API 層交互，通過(guò)代理到達(dá)服務(wù)器

緩存

獲得的屬性：低服務(wù)器延遲、提高應(yīng)用程序速度和響應(yīng)能力

REST API 允許客戶端在其本地存儲(chǔ)經(jīng)常訪問(wèn)的數(shù)據(jù)，從而減少重復(fù)請(qǐng)求的次數(shù)。因此，應(yīng)用程序進(jìn)行的調(diào)用更少，從而減少了服務(wù)器上的負(fù)載及其延遲。反過(guò)來(lái)，應(yīng)用程序會(huì)變得更加響應(yīng)和可靠。

無(wú)狀態(tài)交互

獲得的屬性：增強(qiáng)的性能、應(yīng)用程序可靠性

無(wú)狀態(tài)一詞表示 API 不存儲(chǔ)與先前會(huì)話相關(guān)的任何信息，而是獨(dú)立處理每個(gè)請(qǐng)求。有關(guān)當(dāng)前客戶端狀態(tài)的所有數(shù)據(jù)都包含在請(qǐng)求正文中。

由于REST API是無(wú)狀態(tài)的，因此它無(wú)需處理服務(wù)器端的狀態(tài)同步邏輯。會(huì)話獨(dú)立性的另一個(gè)優(yōu)點(diǎn)是任何服務(wù)器都可以處理請(qǐng)求。這可以提高應(yīng)用程序的性能并降低宕機(jī)的風(fēng)險(xiǎn)。

“無(wú)狀態(tài)意味著副作用更少，”Hanna Instruments 的開(kāi)發(fā)人員 Pál Váradi Nagy 認(rèn)為。“例如，在 FTP 中，我們有一個(gè)正在進(jìn)行的會(huì)話，其中包含修改會(huì)話狀態(tài)的命令。此狀態(tài)可能會(huì)丟失，有時(shí)也會(huì)丟失。因此，對(duì)于 REST 來(lái)說(shuō)，我們決定盡可能地純粹。這意味著它依賴于 PURE 函數(shù)，當(dāng)給定相同的輸入時(shí)，這些函數(shù)總是返回相同的輸出，并且不會(huì)影響其他任何內(nèi)容。

按需代碼（CoD）

獲得的屬性：功能定制、擴(kuò)展功能

服務(wù)器可以根據(jù)客戶端的要求返回一段可執(zhí)行代碼，而不是發(fā)回 JSON 表示。CoD 實(shí)踐讓客戶對(duì)功能有更多控制權(quán)，并允許擴(kuò)展功能。

REST API 原則：業(yè)務(wù)需求的優(yōu)先

獲得的屬性：靈活性

REST仍然與靈活性有關(guān)。實(shí)施 REST 架構(gòu)，開(kāi)發(fā)人員可以偏離、擴(kuò)展或僅部分覆蓋其標(biāo)準(zhǔn)約束集。將一個(gè)基本約束視為無(wú)狀態(tài)交互。您可以忽略它，轉(zhuǎn)而采用其他機(jī)制來(lái)在服務(wù)器端存儲(chǔ)會(huì)話信息，以保持應(yīng)用程序的狀態(tài)。

這就是為什么你可以聽(tīng)到人們說(shuō)幾乎沒(méi)有 REST API 真正遵循 Fielding 的工作。

高級(jí)軟件開(kāi)發(fā)人員兼技術(shù)顧問(wèn) Garry Taylor 表示：“對(duì)我來(lái)說(shuō)，一些約束，比如客戶端-服務(wù)器架構(gòu)或無(wú)狀態(tài)，只是很標(biāo)準(zhǔn)且不錯(cuò)的應(yīng)用程序設(shè)計(jì)，但另一些約束則是我會(huì)極力避免的，就像避開(kāi)瘟疫一樣！特別是，他認(rèn)為按需代碼是個(gè)壞主意：‘安全隱患極大，而且服務(wù)器必須基于客戶端的性質(zhì)及其執(zhí)行任何傳遞代碼的能力來(lái)做出假設(shè)?！?/p>

REST API 示例

REST API 概念和原則可能感覺(jué)很抽象，直到您嘗試使用它們。下面，我們提供了真實(shí) API 的示例，這些 API 將有助于理解 RESTful 方法并了解如何編寫(xiě) API 文檔。

1、RESTful API：Trello API

一個(gè)廣泛使用的項(xiàng)目管理工具提供了一個(gè)簡(jiǎn)單的 API，可讓您快速了解 REST 資源和應(yīng)用于它們的 HTTP 方法。

Trello 的 API 介紹提供的第一件事是向他們最基本的資源 — Boards 發(fā)出 GET 請(qǐng)求。

Trello API 請(qǐng)求

使用 cURL 獲取 Board 消息 — 一個(gè)客戶端程序，用于對(duì)給定 URL 發(fā)出 HTTP 請(qǐng)求

這使您更好地了解如何使用適用于其他基本資源（如 Lists、Cards 和 Actions）的方法進(jìn)行操作。例如，有兩種類型的 POST 請(qǐng)求可用于卡片：

POST /1/cards/[卡片 ID 或短鏈接]/actions/comments 表示“向卡片

添加評(píng)論 POST /1/cards/[卡片 ID 或短鏈接]/actions/idMembers 表示”向卡片添加成員“

資源的完整列表包含 18 個(gè)可通過(guò) API 訪問(wèn)的對(duì)象。每個(gè)請(qǐng)求都附帶詳細(xì)說(shuō)明，其中包括所有請(qǐng)求類型的參數(shù)和查詢示例。

2、RESTful API：Stripe API

最受歡迎的在線支付解決方案之一可能擁有您可以在 Internet 上找到的最好的 API 文檔。Stripe 有一個(gè)專門(mén)的團(tuán)隊(duì)，他們?yōu)槊總€(gè)資源編寫(xiě)詳盡的指南，其中包含代碼片段以及 API 請(qǐng)求和響應(yīng)的示例。“我們的理念是使文檔適應(yīng)如何使用 API，而不是如何構(gòu)建，” Stripe 前支付和平臺(tái)合作伙伴關(guān)系主管 Cristina Cordova 解釋說(shuō)。

Stripe API 請(qǐng)求和響應(yīng)示例

余額交易的 Stripe Rest API 請(qǐng)求和響應(yīng)

首先，有一個(gè)分步開(kāi)發(fā)快速入門(mén)指南。喜歡通過(guò)示例學(xué)習(xí)的工程師可以利用 Stripe Samples。

3、RESTful API：Twilio API

Twilio 是一個(gè) API 驅(qū)動(dòng)的平臺(tái)，用于將語(yǔ)音和視頻通話以及 SMS、MMS 和其他信息集成到 Web 和移動(dòng)應(yīng)用程序中。為了鼓勵(lì)任何級(jí)別的開(kāi)發(fā)人員使用 Twilio 創(chuàng)建通信工具，該公司提出了全面的 REST API 最佳實(shí)踐。此外，在開(kāi)始之前，初學(xué)者可以閱讀有關(guān)“什么是 REST API”的簡(jiǎn)要說(shuō)明。

Twilio 提供免費(fèi)試用賬戶來(lái)試用和測(cè)試 API 集成。為了更方便，代碼片段支持分步指南。

Twilio API 文檔

有關(guān)如何發(fā)送 SMS 的文本說(shuō)明，并通過(guò) API 請(qǐng)求和 JSON API 響應(yīng)的示例進(jìn)行說(shuō)明

4、RESTful API：Jira? REST API

Jira 是全球超過(guò) 65,000 個(gè)團(tuán)隊(duì)使用的項(xiàng)目經(jīng)理中最受歡迎的工具之一。其 REST API 使公司能夠以編程方式與儀器交互，將其功能集成到企業(yè)軟件或其他應(yīng)用程序中，構(gòu)建附加組件或自動(dòng)與 Jira 交互。有一個(gè)關(guān)于可用資源以及如何通過(guò) API 訪問(wèn)它們的全面指南。

用于創(chuàng)建新 Scrum 板的 Jira REST API 響應(yīng)

5、RESTful API：Power BI REST API

據(jù) Gartner 稱，Microsoft Power BI 已連續(xù)五年在分析和商業(yè)智能領(lǐng)域處于領(lǐng)先地位。這個(gè)自助服務(wù)平臺(tái)是各行各業(yè)的數(shù)據(jù)分析師、BI 開(kāi)發(fā)人員和決策者的首選。Power BI REST API 套件使所有類型的客戶都可以將交互式數(shù)據(jù)可視化、儀表板和報(bào)表直接添加到其現(xiàn)有應(yīng)用程序中。

在進(jìn)一步討論之前，Microsoft 使客戶能夠探索通過(guò) API 提供的功能。它還提供了一個(gè)帶有代碼編輯器和示例數(shù)據(jù)的開(kāi)發(fā)人員沙箱。您可以在此處找到有關(guān)如何使用 Power BI REST API 的文檔。如果您不確定此工具是否滿足您的要求，請(qǐng)閱讀我們關(guān)于 Power BI 優(yōu)點(diǎn)和缺點(diǎn)的文章。

REST 與其他 API 范例的比較

構(gòu)建 API 的方法之間的直接比較是值得商榷的。這就是為什么我們選擇回顧使 REST 在面向命令的遠(yuǎn)程過(guò)程調(diào)用（RPC）、標(biāo)準(zhǔn)化 SOAP 和基于架構(gòu)的 GraphQL 中脫穎而出的關(guān)鍵功能。

四種主要 API 范式比較

REST 與 RPC

RPC 已經(jīng)存在了很長(zhǎng)時(shí)間，可以公平地認(rèn)為是 REST 的核心。Pál Váradi Nagy 將 REST?視為“已經(jīng)發(fā)生的事物的受限子集語(yǔ)義 — 遠(yuǎn)程過(guò)程調(diào)用”。

RPC 中的過(guò)程部分是在 input 上執(zhí)行函數(shù)并返回 output。因此，RPC 在網(wǎng)絡(luò)上很容易實(shí)現(xiàn)，從而獲得高性能。這就是為什么它成為了大規(guī)模微服務(wù)系統(tǒng)的首選，因?yàn)樗軌虼龠M(jìn)內(nèi)部通信的簡(jiǎn)潔與清晰。RPC 也非常適合?IoT 應(yīng)用程序，尤其是低功耗應(yīng)用程序。

最新的 RPC 版本是?gRPC。使用二進(jìn)制數(shù)據(jù)而不是文本，其通信比使用 REST?更緊湊、更高效。gRPC 也是類型安全的，這意味著它只會(huì)發(fā)送預(yù)期的數(shù)據(jù)類型。

但是，gRPC 需要設(shè)置客戶端 — 將 gRPC 生成的代碼合并到客戶端進(jìn)程中。對(duì)于構(gòu)建過(guò)程可能不存在的動(dòng)態(tài)語(yǔ)言（例如 JavaScript、Python）來(lái)說(shuō)，這很麻煩。REST 不需要這些。只需在瀏覽器中鍵入 URL 即可進(jìn)行 API 調(diào)用。使用瀏覽器就能輕松測(cè)試API的基本功能，這使得測(cè)試工作變得非常方便。

此外，REST 允許比 RPC 更好的抽象。遵循 RESTful 約束，您可以盡可能地分離客戶端和服務(wù)器。RESTful 連接不依賴于預(yù)先存在的狀態(tài)，而 RPC 中沒(méi)有這樣的要求。

請(qǐng)閱讀我們的文章什么是?gRPC?以了解更多信息。

REST 與 SOAP

根據(jù) Cloud Elements 的 2017 年?API 集成現(xiàn)狀報(bào)告，使用 REST 的 API 占 83%，而使用 SOAP的 API 占 15%。這恰恰證明了 SOAP 還沒(méi)有消亡。

自 80 年代以來(lái)一直從事軟件開(kāi)發(fā)的?Rob James?指出，盡管存在缺點(diǎn)，但 SOAP 具有一些重要的優(yōu)勢(shì)：“封裝比更常見(jiàn)的 REST/JSON 解決方案更容易。Web 服務(wù)描述語(yǔ)言（或簡(jiǎn)稱 WSDL，其中編寫(xiě)了 SOAP API 邏輯）提供的信息比典型的 JSON 對(duì)象提供的信息多。

SOAP API?與 WS-Security 協(xié)議集成，以高級(jí)別的隱私和完整性傳輸消息。這就是為什么它仍然是金融服務(wù)、支付網(wǎng)關(guān)（PayPal 公共 API）、CRM 軟件、身份管理和電信服務(wù)的最佳選擇。

盡管如此，Rob James 承認(rèn)他的首選是 REST，因?yàn)?SOAP 不容易更改，而且?guī)缀醪豢赡芙鉀Q：“我遇到過(guò)無(wú)法使用通用工具解決 WSDL 的情況，因?yàn)樗鞘褂锰囟üぞ吆吞囟ㄓ诠?yīng)商的標(biāo)記生成的。

SOAP 主要基于 RPC 的第一個(gè)版本 — XML。因此，REST 相對(duì)于 XML 綁定的 SOAP 的最大優(yōu)點(diǎn)是它支持多種格式。

閱讀我們的文章什么是?SOAP?以了解更多信息。

REST 與 GraphQL

要獲取其請(qǐng)求的信息，REST API 客戶端必須混合和匹配多個(gè)終端節(jié)點(diǎn)。這滾雪球式地演變成另一個(gè)問(wèn)題 — 數(shù)據(jù)過(guò)度獲取，這意味著響應(yīng)包含不必要的信息。這可能會(huì)減慢請(qǐng)求處理速度。

GraphQL?于 2015 年出現(xiàn)，提出了自定義終端節(jié)點(diǎn)的新理念。GraphQL API 首先會(huì)定義一個(gè)架構(gòu)，這個(gè)架構(gòu)詳細(xì)描述了數(shù)據(jù)在服務(wù)器上的組織結(jié)構(gòu)。有了這個(gè)架構(gòu)作為基礎(chǔ)，客戶端就能清楚地知道如何構(gòu)建查詢語(yǔ)句，并準(zhǔn)確地獲取到所需的響應(yīng)數(shù)據(jù)。

移動(dòng)設(shè)備是不可靠的網(wǎng)絡(luò)。因此，當(dāng) RESTful API 必須發(fā)出多個(gè)請(qǐng)求時(shí)，失敗的可能性要高得多。這就是為什么 GraphQL 的高效查詢與移動(dòng) API 非常相關(guān)。

RESTful 還是 RESTish，這是個(gè)問(wèn)題？

機(jī)器對(duì)機(jī)器交互的基本思想和語(yǔ)義已經(jīng)存在了很長(zhǎng)時(shí)間。但是當(dāng) REST 出現(xiàn)時(shí)，它為 Web API 帶來(lái)了秩序。

“REST 服務(wù)之所以重要，是因?yàn)樗鼈儑L試標(biāo)準(zhǔn)化接口，”Todd Main 說(shuō)。他強(qiáng)調(diào)，無(wú)論是普通的舊 RPC 調(diào)用還是 SOAP 都沒(méi)有這種結(jié)構(gòu)：“這些實(shí)際上是遠(yuǎn)程可用的函數(shù)調(diào)用。相反，REST 帶來(lái)了一種更標(biāo)準(zhǔn)的方式，以編程方式瀏覽系統(tǒng)，或者至少無(wú)需在每一步都查閱手冊(cè)即可與系統(tǒng)交互。

在 RPC 中，URL 表示操作，因?yàn)槠渲饕康氖菫檎?qǐng)求提供服務(wù)。REST背后的理念更為宏大——它旨在組織獨(dú)立系統(tǒng)之間的交互。

REST 的意義遠(yuǎn)不止使用 HTTP?！?em>您甚至不需要使用 HTTP 來(lái)實(shí)現(xiàn) REST 架構(gòu)，盡管它確實(shí)使它變得更容易，”擁有 30 多年編程經(jīng)驗(yàn)的?Claude Wilbur?說(shuō)。

但是，如果開(kāi)發(fā)人員無(wú)法理解它的整個(gè)概念，我們可能會(huì)得到比 RPC 多一點(diǎn)的系統(tǒng)，帶有 HTTP 動(dòng)詞和漂亮的 URL。沒(méi)有可緩存性、古怪的約定或零鏈接來(lái)發(fā)現(xiàn)下一個(gè)可用的操作（超媒體）。意識(shí)到這種差異的人將這些 API 稱為 RESTish。

另一方面，與 SOAP 不同，REST 不是一個(gè)刻板的規(guī)范。它在一定程度上實(shí)現(xiàn)了標(biāo)準(zhǔn)化，這樣的實(shí)現(xiàn)可以客觀地被稱為RESTful。因此，為了安全起見(jiàn)，開(kāi)發(fā)人員可以將其 API 描述為符合 REST 架構(gòu)，而不是 RESTful。

RESTful API常見(jiàn)FAQ有哪些？

1、什么是RESTful API？
答：RESTful API是一種基于REST（Representational State Transfer，表現(xiàn)層狀態(tài)轉(zhuǎn)移）架構(gòu)風(fēng)格的API，它使用HTTP請(qǐng)求來(lái)處理數(shù)據(jù)和交互，使得系統(tǒng)更加輕量級(jí)和可擴(kuò)展。

2、RESTful API有哪些主要特點(diǎn)？
答：RESTful API的主要特點(diǎn)包括使用HTTP方法（如GET、POST、PUT、DELETE）、無(wú)狀態(tài)操作、分層系統(tǒng)架構(gòu)、以及通過(guò)URI定位資源。

3、為什么選擇RESTful API而不是其他類型的API？
答：RESTful API因其簡(jiǎn)單性、可擴(kuò)展性和廣泛的工具支持而受到青睞。它利用現(xiàn)有的HTTP基礎(chǔ)設(shè)施，易于理解和實(shí)現(xiàn)，并且與多種編程語(yǔ)言兼容。

4、RESTful API如何實(shí)現(xiàn)安全性？
答：RESTful API可以通過(guò)使用OAuth、API密鑰、JWT（JSON Web Tokens）等機(jī)制來(lái)實(shí)現(xiàn)安全性，確保只有授權(quán)用戶才能訪問(wèn)資源。

5、RESTful API中的GET和POST請(qǐng)求有什么區(qū)別？
答：GET請(qǐng)求用于檢索資源，應(yīng)該是冪等的，意味著多次執(zhí)行相同的GET請(qǐng)求應(yīng)該得到相同的結(jié)果。POST請(qǐng)求用于創(chuàng)建新資源，是非冪等的，每次請(qǐng)求都可能產(chǎn)生不同的結(jié)果。

6、什么是狀態(tài)碼，RESTful API中常用的狀態(tài)碼有哪些？
答：狀態(tài)碼是服務(wù)器響應(yīng)的一部分，用于告知客戶端請(qǐng)求的結(jié)果。常用的狀態(tài)碼包括200（成功）、201（創(chuàng)建成功）、400（客戶端錯(cuò)誤）、401（未授權(quán)）、403（禁止訪問(wèn)）、404（未找到）和500（服務(wù)器錯(cuò)誤）。

7、RESTful API如何支持分頁(yè)？
答：RESTful API可以通過(guò)在請(qǐng)求中添加查詢參數(shù)來(lái)支持分頁(yè)，例如?page=2&limit=10，這樣客戶端可以請(qǐng)求特定頁(yè)面的數(shù)據(jù)以及每頁(yè)顯示的記錄數(shù)。

8、什么是HATEOAS，它在RESTful API中扮演什么角色？
答：HATEOAS（Hypermedia as the Engine of Application State）是一種約束，要求RESTful API使用超媒體作為應(yīng)用狀態(tài)的引擎。這意味著API響應(yīng)應(yīng)該包含鏈接到其他資源的超媒體，指導(dǎo)客戶端如何與API進(jìn)行交互。

9、RESTful API如何處理版本控制？
答：RESTful API可以通過(guò)在URL中包含版本號(hào)（如/api/v1/resource）或使用請(qǐng)求頭（如Accept: application/vnd.myapp.v1+json）來(lái)處理版本控制，以確保向后兼容性。

10、如何測(cè)試RESTful API？
答：RESTful API可以通過(guò)使用Postman、Swagger、Curl等工具進(jìn)行測(cè)試。這些工具允許開(kāi)發(fā)者發(fā)送HTTP請(qǐng)求并查看響應(yīng)，以驗(yàn)證API的功能和性能。

原文鏈接：https://www.altexsoft.com/blog/rest-api-design/