用node.js和express代碼您的第一個API：了解REST API

REST 和RESTful API 簡介

在現代Web 開發中，你一定經常遇到REST 和API 這些術語。如果你聽說過這些術語或使用過API，但並不完全了解它們的工作原理或如何構建自己的API，那麼本系列教程正適合你。

本教程系列將首先概述REST 原則和概念。然後，我們將創建一個在Node.js Express 服務器上運行並連接到MySQL 數據庫的完整API。完成本系列教程後，你應該能夠自信地構建自己的API 或深入研究現有API 的文檔。

先決條件

為了充分利用本教程，你應該具備一些基本的命令行知識，了解JavaScript 的基礎知識，並在全局安裝了Node.js。

REST 和RESTful API 是什麼？

表述性狀態轉移( REST ) 描述了一種Web 服務的架構風格。 REST 包含一組用於在不同系統之間共享數據的標准或約束，實現REST 的系統被稱為RESTful。 REST 是一個抽象概念，而不是一種語言、框架或軟件類型。

一個關於REST 的鬆散類比是：保留黑膠唱片收藏與使用流媒體音樂服務。對於物理黑膠唱片收藏，必須完整復制每張唱片才能共享和分發副本。然而，對於流媒體服務，可以通過對某些數據（例如歌曲標題）的引用來永久共享相同的音樂。在這種情況下，流媒體音樂是一種RESTful 服務，而黑膠唱片收藏是一種非RESTful 服務。

API是應用程序編程接口，它是一個允許軟件程序相互通信的接口。 RESTful API只是一個遵循REST 原則和約束的API。在Web API 中，服務器通過URL 端點接收請求，並返回響應，響應通常是JSON 格式的數據。

REST 原則

六個指導性約束定義了REST 架構，如下所示：

1. 統一接口: 組件的接口必須相同。這意味著使用URI 標準來標識資源——換句話說，可以輸入到瀏覽器地址欄中的路徑。
2. 客戶端-服務器: 服務器（存儲和操作數據）和客戶端（請求和顯示響應）之間存在關注點分離。
3. 無狀態交互: 關於每個請求的所有信息都包含在每個單獨的請求中，並且不依賴於會話狀態。
4. 可緩存: 客戶端和服務器可以緩存資源。
5. 分層系統: 客戶端可以連接到最終服務器，或中間層，例如負載均衡器。
6. 按需代碼(可選) : 客戶端可以下載代碼，從而減少外部可見性。

請求和響應

你可能已經熟悉了所有網站的URL 都以https 開頭（安全版本）。超文本傳輸協議( HTTP ) 是互聯網上客戶端和服務器之間通信的方法。

我們最明顯地看到它在瀏覽器的URL 欄中，但HTTP 不僅可以用於從服務器請求網站。當你訪問Web 上的URL 時，你實際上是在執行GET 和其他類型的請求。

HTTP 通過打開到服務器端口(http、https) 的TCP (傳輸控制協議) 連接來發出請求，監聽服務器會返回狀態和正文。

請求必須包含URL、方法、標頭信息和正文。

請求方法

有四種主要的HTTP 方法，也稱為HTTP 動詞，通常用於與Web API 交互。這些方法定義了將對任何給定資源執行的操作。

HTTP 請求方法大致對應於CRUD範例，CRUD 代表創建、更新、讀取、刪除。儘管CRUD 指的是數據庫操作中使用的函數，但我們可以將這些設計原則應用於RESTful API 中的HTTP 動詞。

 <code>curl -i https://www.google.com</code>

Google 的服務器將返回以下內容：

 <code>HTTP/2 200 date: Sun, 21 Aug 2022 19:06:22 GMT expires: -1 cache-control: private, max-age=0 content-type: text/html; charset=ISO-8859-1 ...</code>

我們可以看到200 狀態代碼，以及HTTP 的版本（這將是HTTP/1.1、HTTP/2 或HTTP/3）。

由於此特定請求返回的是網站，因此為text/html。在RESTful API 中，你可能會看到對Google 的curl 請求（不包含google.com）返回301 響應，以指示應重定向資源。

REST API 端點

當在服務器上創建API 時，它包含的數據可以通過端點訪問。端點是可以接受和處理POST、DELETE 請求的請求的URL。

API URL 將由根、路徑和可選查詢字符串組成。

• 根例如https://www.php.cn/link/9efa87e164995a7743eca9ad63029fa4的根，可能包含協議、域名和版本。
• 路徑例如/users/5：特定資源的唯一位置。
• 查詢參數(可選)例如limit=10，用於將響應過濾為僅包含十個結果。

例如，要獲取ID 為5 的用戶，我們將使用/user/5。

REST API 約定

以下是構建RESTful API 時應遵循的一些約定：

• 端點不應顯示文件擴展名: 儘管API 最有可能返回JSON，但URL 不應以.json 結尾。
• 使用名詞而不是動詞: 例如，要添加用戶，我們應該使用/users 端點並使用POST 請求，而不是使用/users/add 端點。 API 應該開發為能夠處理對同一URL 的多種類型的請求。
• 路徑區分大小寫，應使用小寫字母和連字符而不是下劃線: 例如，/users-list 比/users_list 更可取。

所有這些約定都是指導原則，因為沒有嚴格的REST 標準可供遵循。但是，使用這些指導原則將使你的API 一致、熟悉且易於閱讀和理解。

REST 的替代方案

REST 是一種很棒的工具，但有一些替代方案可以在某些情況下提供幫助。

SOAP

SOAP（簡單對象訪問協議）是1998 年創建的API，在REST 之前非常流行。它們之間存在一些主要區別。首先，SOAP 對響應格式的限制要嚴格得多。其次，SOAP 使用XML 而不是JSON，這對於遺留應用程序可能很有用，但通常比等效的JSON 更大更複雜。最後，雖然SOAP 可以很好地與HTTP 配合使用，但它也支持SMTP 等協議。

GraphQL

GraphQL 是Facebook 創建的一種較新的API 格式，它旨在通過允許客戶端準確地告訴服務器它需要什麼數據來減少獲取數據所需的HTTP 請求數量。 GraphQL 不使用URL 路徑，而是具有自定義語法來定義客戶端需要什麼數據，以便客戶端在一個請求中獲得所需的一切。

有關GraphQL 的精彩介紹，請查看本GraphQL 教程。

結論

在本文中，我們學習了REST 和RESTful API 是什麼，HTTP 請求方法和響應代碼如何工作，API URL 的結構以及常見的RESTful API 約定。在下一教程中，我們將學習如何通過使用Node.js 設置Express 服務器並構建我們自己的API 來將所有這些理論付諸實踐。

本文已更新，並包含Jacob Jackson 的貢獻。 Jacob 是一位Web 開發人員、技術作家、自由職業者和開源貢獻者。

以上是用node.js和express代碼您的第一個API：了解REST API的詳細內容。更多資訊請關注PHP中文網其他相關文章！