Twitter API Key 的 OAuth 認(rèn)證與授權(quán)機(jī)制
REST 客戶端可以通過發(fā)送 HTTP 請求來與每個資源進(jìn)行交互
REST API 范例的關(guān)鍵元素是
為了訪問資源，客戶端會發(fā)送一個 HTTP 請求。作為回報(bào)，服務(wù)器會生成一個 HTTP 響應(yīng)，其中包含資源上的編碼數(shù)據(jù)。這兩種類型的 REST 消息都是自描述的，這意味著它們包含有關(guān)如何解釋和處理它們的信息。
任何 REST 請求都包括四個基本部分：HTTP 方法、端點(diǎn)、標(biāo)頭和正文。
HTTP 方法描述要對資源執(zhí)行的操作。有四種基本方法也稱為 CRUD 操作：
終端節(jié)點(diǎn)包含統(tǒng)一資源標(biāo)識符 （URI），用于指示在 Internet 上查找資源的位置和方式。最常見的 URI 類型是?Unique Resource Location?（URL），用作完整的 Web 地址。
標(biāo)頭存儲與 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 請求，其中響應(yīng)將返回已創(chuàng)建資源的 ID。來源：Tableau API
服務(wù)器在響應(yīng)請求時(shí)，并不直接發(fā)送資源本身，而是發(fā)送該資源的表示，即一種描述其當(dāng)前狀態(tài)的機(jī)器可讀格式。資源可以以多種格式呈現(xiàn)，但XML和JSON是最普遍使用的兩種。
服務(wù)器在響應(yīng)中還會包含指向其他相關(guān)資源的鏈接或超媒體元素，前提是這些內(nèi)容與請求相關(guān)。這種做法為客戶端提供了指導(dǎo)，告訴它們接下來可以采取哪些操作，以及可以發(fā)起哪些額外的請求。
使用超媒體的自描述性服務(wù)器響應(yīng)的示例。源：勞倫·朗
REST 不與任何特定技術(shù)或平臺相關(guān)聯(lián)。它也沒有規(guī)定如何構(gòu)建 API。相反，它引入了稱為約束的最佳實(shí)踐。它們描述了服務(wù)器如何處理請求并響應(yīng)它們。在這些約束下運(yùn)行，系統(tǒng)將獲得理想的特性。
獲得的屬性：可修改性、更好的系統(tǒng)可靠性
在 REST API 系統(tǒng)中，客戶端和服務(wù)器使用不同的技術(shù)堆棧獨(dú)立工作。客戶端不需要了解任何關(guān)于業(yè)務(wù)邏輯的信息，而服務(wù)器對用戶界面一無所知。職責(zé)分離意味著API提供者和API使用者可以各自進(jìn)行修改，而不會相互產(chǎn)生不利影響或?qū)е虏涣己蠊?/p>
獲得的屬性：易于使用、共同理解
統(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)提到了支持這種做法的一些基本原則，它們是
無論客戶端如何，服務(wù)器都使用相同的接口
統(tǒng)一的接口有助于開發(fā)人員輕松掌握 API 的邏輯。Envysion 的軟件開發(fā)總監(jiān) Todd Main 承認(rèn)，如果合作伙伴公司選擇了 REST 方法，他會松一口氣：“我知道我只需瀏覽一個對象列表，我通常已經(jīng)熟悉這些對象，然后查看我可以獲得或提供哪些屬性。 Todd 補(bǔ)充說，使用 RESTful API 實(shí)現(xiàn)代碼也很容易：“在我的編程語言中，傳遞的對象直接轉(zhuǎn)換為數(shù)據(jù)結(jié)構(gòu)。
獲得的屬性：改進(jìn)的系統(tǒng)可擴(kuò)展性和安全性
RESTful架構(gòu)的系統(tǒng)呈現(xiàn)出分層的特性，其中每一層都獨(dú)立運(yùn)作，并且僅與直接相鄰的層進(jìn)行交互。當(dāng)客戶端請求服務(wù)器時(shí)，它并不需要了解請求路徑上是否存在任何中間層。
正是這種分層的設(shè)計(jì)使得在客戶端和服務(wù)器之間部署代理服務(wù)器或負(fù)載均衡器成為可能，進(jìn)而增強(qiáng)了系統(tǒng)的可擴(kuò)展性。將安全作為一個獨(dú)立的層添加到架構(gòu)中，可以提升整個系統(tǒng)的安全性。盡管這些服務(wù)負(fù)責(zé)生成響應(yīng)，但客戶端無需了解后端接口的具體實(shí)現(xiàn)細(xì)節(jié)。
客戶端與 API 層交互，通過代理到達(dá)服務(wù)器
獲得的屬性：低服務(wù)器延遲、提高應(yīng)用程序速度和響應(yīng)能力
REST API 允許客戶端在其本地存儲經(jīng)常訪問的數(shù)據(jù)，從而減少重復(fù)請求的次數(shù)。因此，應(yīng)用程序進(jìn)行的調(diào)用更少，從而減少了服務(wù)器上的負(fù)載及其延遲。反過來，應(yīng)用程序會變得更加響應(yīng)和可靠。
獲得的屬性：增強(qiáng)的性能、應(yīng)用程序可靠性
無狀態(tài)一詞表示 API 不存儲與先前會話相關(guān)的任何信息，而是獨(dú)立處理每個請求。有關(guān)當(dāng)前客戶端狀態(tài)的所有數(shù)據(jù)都包含在請求正文中。
由于REST API是無狀態(tài)的，因此它無需處理服務(wù)器端的狀態(tài)同步邏輯。會話獨(dú)立性的另一個優(yōu)點(diǎn)是任何服務(wù)器都可以處理請求。這可以提高應(yīng)用程序的性能并降低宕機(jī)的風(fēng)險(xiǎn)。
“無狀態(tài)意味著副作用更少，”Hanna Instruments 的開發(fā)人員 Pál Váradi Nagy 認(rèn)為。“例如，在 FTP 中，我們有一個正在進(jìn)行的會話，其中包含修改會話狀態(tài)的命令。此狀態(tài)可能會丟失，有時(shí)也會丟失。因此，對于 REST 來說，我們決定盡可能地純粹。這意味著它依賴于 PURE 函數(shù)，當(dāng)給定相同的輸入時(shí)，這些函數(shù)總是返回相同的輸出，并且不會影響其他任何內(nèi)容。
獲得的屬性：功能定制、擴(kuò)展功能
服務(wù)器可以根據(jù)客戶端的要求返回一段可執(zhí)行代碼，而不是發(fā)回 JSON 表示。CoD 實(shí)踐讓客戶對功能有更多控制權(quán)，并允許擴(kuò)展功能。
獲得的屬性：靈活性
REST仍然與靈活性有關(guān)。實(shí)施 REST 架構(gòu)，開發(fā)人員可以偏離、擴(kuò)展或僅部分覆蓋其標(biāo)準(zhǔn)約束集。將一個基本約束視為無狀態(tài)交互。您可以忽略它，轉(zhuǎn)而采用其他機(jī)制來在服務(wù)器端存儲會話信息，以保持應(yīng)用程序的狀態(tài)。
這就是為什么你可以聽到人們說幾乎沒有 REST API 真正遵循 Fielding 的工作。
高級軟件開發(fā)人員兼技術(shù)顧問 Garry Taylor 表示：“對我來說，一些約束，比如客戶端-服務(wù)器架構(gòu)或無狀態(tài)，只是很標(biāo)準(zhǔn)且不錯的應(yīng)用程序設(shè)計(jì)，但另一些約束則是我會極力避免的，就像避開瘟疫一樣！特別是，他認(rèn)為按需代碼是個壞主意：‘安全隱患極大，而且服務(wù)器必須基于客戶端的性質(zhì)及其執(zhí)行任何傳遞代碼的能力來做出假設(shè)。”
REST API 概念和原則可能感覺很抽象，直到您嘗試使用它們。下面，我們提供了真實(shí) API 的示例，這些 API 將有助于理解 RESTful 方法并了解如何編寫 API 文檔。
一個廣泛使用的項(xiàng)目管理工具提供了一個簡單的 API，可讓您快速了解 REST 資源和應(yīng)用于它們的 HTTP 方法。
Trello 的 API 介紹提供的第一件事是向他們最基本的資源 — Boards 發(fā)出 GET 請求。
使用 cURL 獲取 Board 消息 — 一個客戶端程序，用于對給定 URL 發(fā)出 HTTP 請求
這使您更好地了解如何使用適用于其他基本資源（如 Lists、Cards 和 Actions）的方法進(jìn)行操作。例如，有兩種類型的 POST 請求可用于卡片：
POST /1/cards/[卡片 ID 或短鏈接]/actions/comments 表示“向卡片
添加評論 POST /1/cards/[卡片 ID 或短鏈接]/actions/idMembers 表示”向卡片添加成員“
資源的完整列表包含 18 個可通過 API 訪問的對象。每個請求都附帶詳細(xì)說明，其中包括所有請求類型的參數(shù)和查詢示例。
最受歡迎的在線支付解決方案之一可能擁有您可以在 Internet 上找到的最好的 API 文檔。Stripe 有一個專門的團(tuán)隊(duì)，他們?yōu)槊總€資源編寫詳盡的指南，其中包含代碼片段以及 API 請求和響應(yīng)的示例。“我們的理念是使文檔適應(yīng)如何使用 API，而不是如何構(gòu)建，” Stripe 前支付和平臺合作伙伴關(guān)系主管 Cristina Cordova 解釋說。
余額交易的 Stripe Rest API 請求和響應(yīng)
首先，有一個分步開發(fā)快速入門指南。喜歡通過示例學(xué)習(xí)的工程師可以利用 Stripe Samples。
Twilio 是一個 API 驅(qū)動的平臺，用于將語音和視頻通話以及 SMS、MMS 和其他信息集成到 Web 和移動應(yīng)用程序中。為了鼓勵任何級別的開發(fā)人員使用 Twilio 創(chuàng)建通信工具，該公司提出了全面的 REST API 最佳實(shí)踐。此外，在開始之前，初學(xué)者可以閱讀有關(guān)“什么是 REST API”的簡要說明。
Twilio 提供免費(fèi)試用賬戶來試用和測試 API 集成。為了更方便，代碼片段支持分步指南。
有關(guān)如何發(fā)送 SMS 的文本說明，并通過 API 請求和 JSON API 響應(yīng)的示例進(jìn)行說明
Jira 是全球超過 65,000 個團(tuán)隊(duì)使用的項(xiàng)目經(jīng)理中最受歡迎的工具之一。其 REST API 使公司能夠以編程方式與儀器交互，將其功能集成到企業(yè)軟件或其他應(yīng)用程序中，構(gòu)建附加組件或自動與 Jira 交互。有一個關(guān)于可用資源以及如何通過 API 訪問它們的全面指南。
用于創(chuàng)建新 Scrum 板的 Jira REST API 響應(yīng)
據(jù) Gartner 稱，Microsoft Power BI 已連續(xù)五年在分析和商業(yè)智能領(lǐng)域處于領(lǐng)先地位。這個自助服務(wù)平臺是各行各業(yè)的數(shù)據(jù)分析師、BI 開發(fā)人員和決策者的首選。Power BI REST API 套件使所有類型的客戶都可以將交互式數(shù)據(jù)可視化、儀表板和報(bào)表直接添加到其現(xiàn)有應(yīng)用程序中。
在進(jìn)一步討論之前，Microsoft 使客戶能夠探索通過 API 提供的功能。它還提供了一個帶有代碼編輯器和示例數(shù)據(jù)的開發(fā)人員沙箱。您可以在此處找到有關(guān)如何使用 Power BI REST API 的文檔。如果您不確定此工具是否滿足您的要求，請閱讀我們關(guān)于 Power BI 優(yōu)點(diǎn)和缺點(diǎn)的文章。
構(gòu)建 API 的方法之間的直接比較是值得商榷的。這就是為什么我們選擇回顧使 REST 在面向命令的遠(yuǎn)程過程調(diào)用 （RPC）、標(biāo)準(zhǔn)化 SOAP 和基于架構(gòu)的 GraphQL 中脫穎而出的關(guān)鍵功能。
四種主要 API 范式比較
RPC 已經(jīng)存在了很長時(shí)間，可以公平地認(rèn)為是 REST 的核心。Pál Váradi Nagy 將 REST?視為“已經(jīng)發(fā)生的事物的受限子集語義 — 遠(yuǎn)程過程調(diào)用”。
RPC 中的過程部分是在 input 上執(zhí)行函數(shù)并返回 output。因此，RPC 在網(wǎng)絡(luò)上很容易實(shí)現(xiàn)，從而獲得高性能。這就是為什么它成為了大規(guī)模微服務(wù)系統(tǒng)的首選，因?yàn)樗軌虼龠M(jìn)內(nèi)部通信的簡潔與清晰。RPC 也非常適合?IoT 應(yīng)用程序，尤其是低功耗應(yīng)用程序。
最新的 RPC 版本是?gRPC。使用二進(jìn)制數(shù)據(jù)而不是文本，其通信比使用 REST?更緊湊、更高效。gRPC 也是類型安全的，這意味著它只會發(fā)送預(yù)期的數(shù)據(jù)類型。
但是，gRPC 需要設(shè)置客戶端 — 將 gRPC 生成的代碼合并到客戶端進(jìn)程中。對于構(gòu)建過程可能不存在的動態(tài)語言（例如 JavaScript、Python）來說，這很麻煩。REST 不需要這些。只需在瀏覽器中鍵入 URL 即可進(jìn)行 API 調(diào)用。使用瀏覽器就能輕松測試API的基本功能，這使得測試工作變得非常方便。
此外，REST 允許比 RPC 更好的抽象。遵循 RESTful 約束，您可以盡可能地分離客戶端和服務(wù)器。RESTful 連接不依賴于預(yù)先存在的狀態(tài)，而 RPC 中沒有這樣的要求。
請閱讀我們的文章什么是?gRPC?以了解更多信息。
根據(jù) Cloud Elements 的 2017 年?API 集成現(xiàn)狀報(bào)告，使用 REST 的 API 占 83%，而使用 SOAP的 API 占 15%。這恰恰證明了 SOAP 還沒有消亡。
自 80 年代以來一直從事軟件開發(fā)的?Rob James?指出，盡管存在缺點(diǎn)，但 SOAP 具有一些重要的優(yōu)勢：“封裝比更常見的 REST/JSON 解決方案更容易。Web 服務(wù)描述語言（或簡稱 WSDL，其中編寫了 SOAP API 邏輯）提供的信息比典型的 JSON 對象提供的信息多。
SOAP API?與 WS-Security 協(xié)議集成，以高級別的隱私和完整性傳輸消息。這就是為什么它仍然是金融服務(wù)、支付網(wǎng)關(guān)（PayPal 公共 API）、CRM 軟件、身份管理和電信服務(wù)的最佳選擇。
盡管如此，Rob James 承認(rèn)他的首選是 REST，因?yàn)?SOAP 不容易更改，而且?guī)缀醪豢赡芙鉀Q：“我遇到過無法使用通用工具解決 WSDL 的情況，因?yàn)樗鞘褂锰囟üぞ吆吞囟ㄓ诠?yīng)商的標(biāo)記生成的。
SOAP 主要基于 RPC 的第一個版本 — XML。因此，REST 相對于 XML 綁定的 SOAP 的最大優(yōu)點(diǎn)是它支持多種格式。
閱讀我們的文章 什么是?SOAP?以了解更多信息。
要獲取其請求的信息，REST API 客戶端必須混合和匹配多個終端節(jié)點(diǎn)。這滾雪球式地演變成另一個問題 — 數(shù)據(jù)過度獲取，這意味著響應(yīng)包含不必要的信息。這可能會減慢請求處理速度。
GraphQL?于 2015 年出現(xiàn)，提出了自定義終端節(jié)點(diǎn)的新理念。GraphQL API 首先會定義一個架構(gòu)，這個架構(gòu)詳細(xì)描述了數(shù)據(jù)在服務(wù)器上的組織結(jié)構(gòu)。有了這個架構(gòu)作為基礎(chǔ)，客戶端就能清楚地知道如何構(gòu)建查詢語句，并準(zhǔn)確地獲取到所需的響應(yīng)數(shù)據(jù)。
移動設(shè)備是不可靠的網(wǎng)絡(luò)。因此，當(dāng) RESTful API 必須發(fā)出多個請求時(shí)，失敗的可能性要高得多。這就是為什么 GraphQL 的高效查詢與移動 API 非常相關(guān)。
機(jī)器對機(jī)器交互的基本思想和語義已經(jīng)存在了很長時(shí)間。但是當(dāng) REST 出現(xiàn)時(shí)，它為 Web API 帶來了秩序。
“REST 服務(wù)之所以重要，是因?yàn)樗鼈儑L試標(biāo)準(zhǔn)化接口，”Todd Main 說。他強(qiáng)調(diào)，無論是普通的舊 RPC 調(diào)用還是 SOAP 都沒有這種結(jié)構(gòu)：“這些實(shí)際上是遠(yuǎn)程可用的函數(shù)調(diào)用。相反，REST 帶來了一種更標(biāo)準(zhǔn)的方式，以編程方式瀏覽系統(tǒng)，或者至少無需在每一步都查閱手冊即可與系統(tǒng)交互。
在 RPC 中，URL 表示操作，因?yàn)槠渲饕康氖菫檎埱筇峁┓?wù)。REST背后的理念更為宏大——它旨在組織獨(dú)立系統(tǒng)之間的交互。
REST 的意義遠(yuǎn)不止使用 HTTP。“您甚至不需要使用 HTTP 來實(shí)現(xiàn) REST 架構(gòu)，盡管它確實(shí)使它變得更容易，”擁有 30 多年編程經(jīng)驗(yàn)的?Claude Wilbur?說。
但是，如果開發(fā)人員無法理解它的整個概念，我們可能會得到比 RPC 多一點(diǎn)的系統(tǒng)，帶有 HTTP 動詞和漂亮的 URL。沒有可緩存性、古怪的約定或零鏈接來發(fā)現(xiàn)下一個可用的操作（超媒體）。意識到這種差異的人將這些 API 稱為 RESTish。
另一方面，與 SOAP 不同，REST 不是一個刻板的規(guī)范。它在一定程度上實(shí)現(xiàn)了標(biāo)準(zhǔn)化，這樣的實(shí)現(xiàn)可以客觀地被稱為RESTful。因此，為了安全起見，開發(fā)人員可以將其 API 描述為符合 REST 架構(gòu)，而不是 RESTful。
1、什么是RESTful API？
答：RESTful API是一種基于REST（Representational State Transfer，表現(xiàn)層狀態(tài)轉(zhuǎn)移）架構(gòu)風(fēng)格的API，它使用HTTP請求來處理數(shù)據(jù)和交互，使得系統(tǒng)更加輕量級和可擴(kuò)展。
2、RESTful API有哪些主要特點(diǎn)？
答：RESTful API的主要特點(diǎn)包括使用HTTP方法（如GET、POST、PUT、DELETE）、無狀態(tài)操作、分層系統(tǒng)架構(gòu)、以及通過URI定位資源。
3、為什么選擇RESTful API而不是其他類型的API？
答：RESTful API因其簡單性、可擴(kuò)展性和廣泛的工具支持而受到青睞。它利用現(xiàn)有的HTTP基礎(chǔ)設(shè)施，易于理解和實(shí)現(xiàn)，并且與多種編程語言兼容。
4、RESTful API如何實(shí)現(xiàn)安全性？
答：RESTful API可以通過使用OAuth、API密鑰、JWT（JSON Web Tokens）等機(jī)制來實(shí)現(xiàn)安全性，確保只有授權(quán)用戶才能訪問資源。
5、RESTful API中的GET和POST請求有什么區(qū)別？
答：GET請求用于檢索資源，應(yīng)該是冪等的，意味著多次執(zhí)行相同的GET請求應(yīng)該得到相同的結(jié)果。POST請求用于創(chuàng)建新資源，是非冪等的，每次請求都可能產(chǎn)生不同的結(jié)果。
6、什么是狀態(tài)碼，RESTful API中常用的狀態(tài)碼有哪些？
答：狀態(tài)碼是服務(wù)器響應(yīng)的一部分，用于告知客戶端請求的結(jié)果。常用的狀態(tài)碼包括200（成功）、201（創(chuàng)建成功）、400（客戶端錯誤）、401（未授權(quán)）、403（禁止訪問）、404（未找到）和500（服務(wù)器錯誤）。
7、RESTful API如何支持分頁？
答：RESTful API可以通過在請求中添加查詢參數(shù)來支持分頁，例如?page=2&limit=10，這樣客戶端可以請求特定頁面的數(shù)據(jù)以及每頁顯示的記錄數(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可以通過在URL中包含版本號（如/api/v1/resource）或使用請求頭（如Accept: application/vnd.myapp.v1+json）來處理版本控制，以確保向后兼容性。
10、如何測試RESTful API？
答：RESTful API可以通過使用Postman、Swagger、Curl等工具進(jìn)行測試。這些工具允許開發(fā)者發(fā)送HTTP請求并查看響應(yīng)，以驗(yàn)證API的功能和性能。
原文鏈接：https://www.altexsoft.com/blog/rest-api-design/
微信截圖_17512625768464.png)
微信截圖_17363901826052-1.png)
微信截圖_1739008790665.png)
微信截圖_17513555554987.png)
