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