當前的互聯網生態系統已被 API 徹底改變,這是有充分理由的。通過在產品或服務中使用第三方 API,您可以訪問大量有用的功能——例如身份驗證或存儲服務——這些功能對您和您的用戶都有利。通過公開您自己的 API,您的應用程序將成為“組合的一部分”,並以您從未想過的方式使用……當然,如果您以正確的方式這樣做。在這個由兩部分組成的系列文章中,我將向您展示如何使用一系列真實的最佳實踐為您的 PHP 應用程序創建 RESTful API 層。本項目完整的源代碼將在第 2 部分的結尾提供。
關鍵要點
REST:開發人員友好的 UI
首先,API 是開發人員的用戶界面,因此它必須友好、簡單、易於使用,當然也要令人愉快;否則,它最終將成為另一個數字垃圾。即使只是一個簡單但寫得很好的 README 文件,文檔也是一個良好的開端。我們需要最少的信息是服務範圍的摘要以及方法和訪問點的列表。一個好的摘要可以是:> 我們的應用程序是一個簡單的聯繫人列表服務,用於管理具有關聯筆記的聯繫人。它有兩種對像類型,聯繫人(contacts)和筆記(notes)。每個聯繫人都有基本屬性,例如名字、姓氏和電子郵件地址。此外,每個聯繫人可以有多個與之關聯的 Markdown 格式的筆記。
然後,最好列出我們將要實現的所有資源和操作。這可以被視為可視化應用程序線框圖的等效項。遵循 REST 的關鍵原則,每個資源都由一個 URL 表示,其中操作是用於訪問它的 HTTP 方法。例如,GET /api/contacts/12 將檢索 ID 為 12 的聯繫人,而 PUT /api/contacts/12 將更新相同的聯繫人。完整的 method 列表如下所示:
<code>URL HTTP Method Operation /api/contacts GET 返回联系人数组 /api/contacts/:id GET 返回 ID 为 :id 的联系人 /api/contacts POST 添加一个新联系人并返回它(添加了 id 属性) /api/contacts/:id PUT 更新 ID 为 :id 的联系人 /api/contacts/:id PATCH 部分更新 ID 为 :id 的联系人 /api/contacts/:id DELETE 删除 ID 为 :id 的联系人 /api/contacts/:id/star PUT 将 ID 为 :id 的联系人添加到收藏夹 /api/contacts/:id/star DELETE 从收藏夹中删除 ID 为 :id 的联系人 /api/contacts/:id/notes GET 返回 ID 为 :id 的联系人的笔记 /api/contacts/:id/notes/:nid GET 返回 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes POST 为 ID 为 :id 的联系人添加新笔记 /api/contacts/:id/notes/:nid PUT 更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid PATCH 部分更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid DELETE 删除 ID 为 :id 的联系人的 ID 为 :nid 的笔记</code>
對於更完整和專業的文檔,您可以考慮使用 Swagger、apiDoc 或 Google APIs Discovery Service 等工具:您的用戶會喜歡您的!
工具和設置
我將用來構建 API 的主要工具是 Slim Framework。為什麼? > [它] 幫助您快速編寫簡單而強大的 Web 應用程序和 API。
這是真的。其強大的路由功能使使用GET 和POST 以外的方法變得容易,它提供對HTTP 方法覆蓋的內置支持(通過HTTP 標頭和隱藏的POST 字段),並且可以與中間件和額外功能掛鉤,使應用程序和API 開發真正變得容易。與 Slim 一起,我使用 Idiorm 訪問數據庫層,使用 Monolog 進行日誌記錄。因此,我們的 composer.json 文件將如下所示:
{ "name": "yourname/my-contacts", "description": "Simple RESTful API for contacts management", "license": "MIT", "authors": [ { "name": "Your Name", "email": "you@yourdomain.com" } ], "require": { "slim/slim": "*", "slim/extras": "*", "slim/middleware": "*", "monolog/monolog": "*", "j4mie/paris": "*", "flynsarmy/slim-monolog": "*" }, "archive": { "exclude": ["vendor", ".DS_Store", "*.log"] }, "autoload": { "psr-0": { "API": "lib/" } } }
slim/extras 和 slim/middleware 包提供了諸如內容類型解析和基本身份驗證之類的有用功能。我們的自定義類位於 API 命名空間下,位於 lib 目錄中。此時,我們的工作目錄結構如下所示:
<code>bootstrap.php composer.json README.md bin/ import install lib/ API/ public/ .htaccess index.php share/ config/ default.php db/ logs/ sql/ data/ contacts.sql users.sql tables/ contacts.sql notes.sql users.sql ssl/ mysitename.crt mysitename.key</code>
我們的應用程序的前端控制器是 public/index.php,所有非文件或目錄流量都通過標準 URL 重寫規則重定向到此處。然後,我將所有初始化代碼放在 bootstrap.php 中,我們稍後會看到。 share 目錄包含數據,例如日誌、配置文件、SQLite 數據庫和轉儲文件以及 SSL 證書。 bin 目錄包含使用提供的 .sql 文件創建數據庫和導入一些數據的實用程序腳本。
我們的 API 只能在 HTTPS 模式下訪問,無需重定向。這簡化了身份驗證邏輯並防止配置不當的客戶端訪問未加密的端點。設置此方法最簡單和最合乎邏輯的方法是直接作用於 Web 服務器或通過代理服務器。我使用舊的可靠的 Apache 來執行此操作,我的虛擬主機文件如下所示:
<Directory> # Required for mod_rewrite in .htaccess AllowOverride FileInfo Options All -Indexes DirectoryIndex index.php index.shtml index.html <IfModule php5_module=""> # For Development only! php_flag display_errors On </IfModule> # Enable gzip compression <IfModule filter_module=""> AddOutputFilterByType DEFLATE application/json </IfModule> Order deny,allow Deny from all Allow from 127.0.0.1 </Directory> <VirtualHost *:80> ServerAdmin you@yourdomain.com DocumentRoot "/path/to/MyApp/public" ServerName myapp.dev <IfModule rewrite_module=""> RewriteEngine on ## Throw a 403 (forbidden) status for non secure requests RewriteCond %{HTTPS} off RewriteRule ^.*$ - [L,R=403] </IfModule> </VirtualHost> <IfModule ssl_module=""> NameVirtualHost *:443 Listen 443 SSLRandomSeed startup builtin SSLRandomSeed connect builtin <VirtualHost *:443> ServerAdmin you@yourdomain.com DocumentRoot "/path/to/MyApp/public" ServerName myapp.dev SSLEngine on SSLCertificateFile /path/to/MyApp/share/ssl/mysitename.crt SSLCertificateKeyFile /path/to/MyApp/share/ssl/mysitename.key SetEnv SLIM_MODE development </VirtualHost> </IfModule>
首先定義目錄設置,以便它們與我們站點的 HTTP 和 HTTPS 版本通用。在非安全主機配置中,我使用 mod_rewrite 為任何非安全連接發出 403 禁止錯誤,然後在安全部分中,我使用我的自簽名證書設置 SSL,以及告訴 Slim 當前應用程序模式的 SLIM_ENV 變量。有關如何在 Apache 上創建自簽名證書並安裝它的更多信息,請參閱 SSLShopper 上的這篇文章。現在我們有了明確的目標、基本目錄結構和服務器設置,讓我們運行 composer.phar install 並開始編寫一些代碼。
引導程序和前端控制器
如前所述,bootstrap.php 文件負責加載我們的應用程序設置和自動加載器設置。
<code>URL HTTP Method Operation /api/contacts GET 返回联系人数组 /api/contacts/:id GET 返回 ID 为 :id 的联系人 /api/contacts POST 添加一个新联系人并返回它(添加了 id 属性) /api/contacts/:id PUT 更新 ID 为 :id 的联系人 /api/contacts/:id PATCH 部分更新 ID 为 :id 的联系人 /api/contacts/:id DELETE 删除 ID 为 :id 的联系人 /api/contacts/:id/star PUT 将 ID 为 :id 的联系人添加到收藏夹 /api/contacts/:id/star DELETE 从收藏夹中删除 ID 为 :id 的联系人 /api/contacts/:id/notes GET 返回 ID 为 :id 的联系人的笔记 /api/contacts/:id/notes/:nid GET 返回 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes POST 为 ID 为 :id 的联系人添加新笔记 /api/contacts/:id/notes/:nid PUT 更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid PATCH 部分更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid DELETE 删除 ID 为 :id 的联系人的 ID 为 :nid 的笔记</code>
首先,我獲取當前環境。如果存在名為
{ "name": "yourname/my-contacts", "description": "Simple RESTful API for contacts management", "license": "MIT", "authors": [ { "name": "Your Name", "email": "you@yourdomain.com" } ], "require": { "slim/slim": "*", "slim/extras": "*", "slim/middleware": "*", "monolog/monolog": "*", "j4mie/paris": "*", "flynsarmy/slim-monolog": "*" }, "archive": { "exclude": ["vendor", ".DS_Store", "*.log"] }, "autoload": { "psr-0": { "API": "lib/" } } }
配置一個 Monolog 記錄器,該記錄器寫入 app/path/share/logs/EnvName_YYYY-mm-dd.log 的文件。然後,在一些改進之後(您可以在源代碼中看到它們),我獲取生成的日誌寫入器並嘗試連接到數據庫:
<code>bootstrap.php composer.json README.md bin/ import install lib/ API/ public/ .htaccess index.php share/ config/ default.php db/ logs/ sql/ data/ contacts.sql users.sql tables/ contacts.sql notes.sql users.sql ssl/ mysitename.crt mysitename.key</code>
最後,我將所需的中間件添加到我的應用程序實例中。 Slim 的中間件就像洋蔥的層一樣,您添加的第一個中間件將是最內層的,因此我們中間件的順序很重要。我在我們的API 中使用以下中間件:- 緩存(最內層);- ContentTypes:解析來自客戶端的JSON 格式的正文;- RateLimit:管理用戶的API 限制;- JSON:“僅JSON 響應”和“ JSON 編碼正文”最佳實踐的實用程序中間件;- 身份驗證(最外層)。我們將編寫所有這些,除了預先存在的 ContentTypes。在 bootstrap 文件的末尾,我定義了兩個全局變量 $app(應用程序實例)和 $log(日誌寫入器)。該文件由我們的前端控制器 index.php 加載,在該文件中發生神奇的事情。
路由結構
Slim 有一個名為 Route Groups 的不錯的功能。使用此功能,我們可以像這樣定義我們的應用程序路由:
<Directory> # Required for mod_rewrite in .htaccess AllowOverride FileInfo Options All -Indexes DirectoryIndex index.php index.shtml index.html <IfModule php5_module=""> # For Development only! php_flag display_errors On </IfModule> # Enable gzip compression <IfModule filter_module=""> AddOutputFilterByType DEFLATE application/json </IfModule> Order deny,allow Deny from all Allow from 127.0.0.1 </Directory> <VirtualHost *:80> ServerAdmin you@yourdomain.com DocumentRoot "/path/to/MyApp/public" ServerName myapp.dev <IfModule rewrite_module=""> RewriteEngine on ## Throw a 403 (forbidden) status for non secure requests RewriteCond %{HTTPS} off RewriteRule ^.*$ - [L,R=403] </IfModule> </VirtualHost> <IfModule ssl_module=""> NameVirtualHost *:443 Listen 443 SSLRandomSeed startup builtin SSLRandomSeed connect builtin <VirtualHost *:443> ServerAdmin you@yourdomain.com DocumentRoot "/path/to/MyApp/public" ServerName myapp.dev SSLEngine on SSLCertificateFile /path/to/MyApp/share/ssl/mysitename.crt SSLCertificateKeyFile /path/to/MyApp/share/ssl/mysitename.key SetEnv SLIM_MODE development </VirtualHost> </IfModule>
我創建了兩個嵌套組 /api 和 /v1,因此我們可以輕鬆遵守“URL 中的版本控制”最佳實踐。我還為 /api/ 創建了一些可選路由,其中可能包含用戶可讀的內容,以及一個通用的根 URL(/)URL,在現實世界中,該 URL 可能包含應用程序的公共用戶界面。
我最初的方法是在 /v1 組內使用路由中間件(另一種 Slim 中間件),用於身份驗證和 JSON 請求/響應,但我發現使用經典中間件更實用和簡潔。如前所述,中間件是繼承自 SlimMiddleware 的類的實例。 Slim 中間件的 call() 方法是操作發生的地方,當中間件作為全局中間件鏈接時,它會自動執行,使用 $app->add() 方法。
// Init application mode if (empty($_ENV['SLIM_MODE'])) { $_ENV['SLIM_MODE'] = (getenv('SLIM_MODE')) ? getenv('SLIM_MODE') : 'development'; } // Init and load configuration $config = array(); $configFile = dirname(__FILE__) . '/share/config/' . $_ENV['SLIM_MODE'] . '.php'; if (is_readable($configFile)) { require_once $configFile; } else { require_once dirname(__FILE__) . '/share/config/default.php'; } // Create Application $app = new API\Application($config['app']);
我們的 JSON 中間件實現了兩個最佳實踐:“僅 JSON 響應”和“JSON 編碼正文”。方法如下:
<code>URL HTTP Method Operation /api/contacts GET 返回联系人数组 /api/contacts/:id GET 返回 ID 为 :id 的联系人 /api/contacts POST 添加一个新联系人并返回它(添加了 id 属性) /api/contacts/:id PUT 更新 ID 为 :id 的联系人 /api/contacts/:id PATCH 部分更新 ID 为 :id 的联系人 /api/contacts/:id DELETE 删除 ID 为 :id 的联系人 /api/contacts/:id/star PUT 将 ID 为 :id 的联系人添加到收藏夹 /api/contacts/:id/star DELETE 从收藏夹中删除 ID 为 :id 的联系人 /api/contacts/:id/notes GET 返回 ID 为 :id 的联系人的笔记 /api/contacts/:id/notes/:nid GET 返回 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes POST 为 ID 为 :id 的联系人添加新笔记 /api/contacts/:id/notes/:nid PUT 更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid PATCH 部分更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid DELETE 删除 ID 为 :id 的联系人的 ID 为 :nid 的笔记</code>
我們可以將根路徑傳遞給中間件構造函數。在這種情況下,我傳遞 /api/v1,以便我們的中間件僅應用於我們站點的 API 部分。如果當前路徑與響應內容類型標頭匹配,則強制響應內容類型標頭為 application/json,然後我檢查請求方法。如果請求方法是啟用寫入的請求方法之一(PUT、POST、PATCH),則請求內容類型標頭必須為 application/json,否則應用程序將退出並顯示 415 Unsupported Media Type HTTP 狀態代碼。如果一切正常,語句 $this->next->call() 將運行鏈中的下一個中間件。
身份驗證
由於我們的應用程序默認情況下將在HTTPS 上運行,因此我決定使用令牌優先於基本身份驗證的方法:API 密鑰發送到基本HTTP AUTH 標頭的用戶名字段中(不需要密碼)。為此,我編寫了一個名為 TokenOverBasicAuth 的 Slim 中間件類,方法是修改現有的 Slim HttpBasicAuth。此中間件首先在鏈中運行,因此它作為最後一個添加,並且它在構造函數中採用可選的根路徑參數。
{ "name": "yourname/my-contacts", "description": "Simple RESTful API for contacts management", "license": "MIT", "authors": [ { "name": "Your Name", "email": "you@yourdomain.com" } ], "require": { "slim/slim": "*", "slim/extras": "*", "slim/middleware": "*", "monolog/monolog": "*", "j4mie/paris": "*", "flynsarmy/slim-monolog": "*" }, "archive": { "exclude": ["vendor", ".DS_Store", "*.log"] }, "autoload": { "psr-0": { "API": "lib/" } } }
該方法在 PHP_AUTH_USER 請求標頭中搜索 auth 令牌,如果它不存在或無效,則將 401 禁止狀態和身份驗證標頭傳遞給客戶端。 verify() 方法是受保護的,因此可以由子類覆蓋;我在這裡的版本很簡單:
<code>bootstrap.php composer.json README.md bin/ import install lib/ API/ public/ .htaccess index.php share/ config/ default.php db/ logs/ sql/ data/ contacts.sql users.sql tables/ contacts.sql notes.sql users.sql ssl/ mysitename.crt mysitename.key</code>
在這裡,我只是檢查 users 表中 API 密鑰的存在,如果我找到一個有效的用戶,則將其添加到應用程序上下文中,以便與下一層(RateLimit)一起使用。您可以修改或擴展此類以注入您自己的身份驗證邏輯或使用 OAuth 模塊。有關 OAuth 的更多信息,請參閱 Jamie Munro 的文章。
可使用的錯誤有效負載
如果可能的話,我們的 API 應該以可使用的格式顯示有用的錯誤消息,最好以 JSON 表示形式。我們需要一個包含錯誤代碼和消息的最小有效負載。此外,驗證錯誤需要更多細分。使用 Slim,我們可以分別使用 $app->notFound() 和 $app->error() 方法重新定義 404 錯誤和服務器錯誤。
<code>URL HTTP Method Operation /api/contacts GET 返回联系人数组 /api/contacts/:id GET 返回 ID 为 :id 的联系人 /api/contacts POST 添加一个新联系人并返回它(添加了 id 属性) /api/contacts/:id PUT 更新 ID 为 :id 的联系人 /api/contacts/:id PATCH 部分更新 ID 为 :id 的联系人 /api/contacts/:id DELETE 删除 ID 为 :id 的联系人 /api/contacts/:id/star PUT 将 ID 为 :id 的联系人添加到收藏夹 /api/contacts/:id/star DELETE 从收藏夹中删除 ID 为 :id 的联系人 /api/contacts/:id/notes GET 返回 ID 为 :id 的联系人的笔记 /api/contacts/:id/notes/:nid GET 返回 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes POST 为 ID 为 :id 的联系人添加新笔记 /api/contacts/:id/notes/:nid PUT 更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid PATCH 部分更新 ID 为 :id 的联系人的 ID 为 :nid 的笔记 /api/contacts/:id/notes/:nid DELETE 删除 ID 为 :id 的联系人的 ID 为 :nid 的笔记</code>
找不到錯誤更簡單:首先我獲取請求的媒體類型,然後 $isAPI 標誌告訴我當前 URL 是否位於 /api/v* 組下。如果客戶端請求 API URL 或發送 JSON 內容類型標頭,我將返回 JSON 輸出,否則我可以呈現模板或簡單地打印一些靜態 HTML,如本例所示。其他錯誤有點棘手,當出現異常時會觸發 $app->error() 方法,Slim 將標準 PHP 錯誤轉換為 ErrorException 對象。我們需要一種方法向客戶端提供有用的錯誤,而不會為了避免安全漏洞而暴露太多內部機制。為此應用程序,我創建了兩個自定義異常,APIException 和 APIExceptionValidationException,它們向公眾公開,所有其他異常類型都記錄在日誌中,並且僅在開發模式下顯示。
{ "name": "yourname/my-contacts", "description": "Simple RESTful API for contacts management", "license": "MIT", "authors": [ { "name": "Your Name", "email": "you@yourdomain.com" } ], "require": { "slim/slim": "*", "slim/extras": "*", "slim/middleware": "*", "monolog/monolog": "*", "j4mie/paris": "*", "flynsarmy/slim-monolog": "*" }, "archive": { "exclude": ["vendor", ".DS_Store", "*.log"] }, "autoload": { "psr-0": { "API": "lib/" } } }
$app->error() 方法接收拋出的異常作為參數。默認情況下,我獲取所需的所有數據並填充 $error 數組,然後如果我在生產模式下,我將取消設置私有數據並使用通用數據重寫消息。自定義 ValidationException 類具有自定義 getData() 方法,該方法返回添加到最終有效負載的驗證錯誤數組。然後,根據請求以 JSON 或 HTML 顯示錯誤。在 API 端,我們可以有一個簡單的錯誤,如下所示:
<code>bootstrap.php composer.json README.md bin/ import install lib/ API/ public/ .htaccess index.php share/ config/ default.php db/ logs/ sql/ data/ contacts.sql users.sql tables/ contacts.sql notes.sql users.sql ssl/ mysitename.crt mysitename.key</code>
或完整的驗證錯誤,如下所示:
<Directory> # Required for mod_rewrite in .htaccess AllowOverride FileInfo Options All -Indexes DirectoryIndex index.php index.shtml index.html <IfModule php5_module=""> # For Development only! php_flag display_errors On </IfModule> # Enable gzip compression <IfModule filter_module=""> AddOutputFilterByType DEFLATE application/json </IfModule> Order deny,allow Deny from all Allow from 127.0.0.1 </Directory> <VirtualHost *:80> ServerAdmin you@yourdomain.com DocumentRoot "/path/to/MyApp/public" ServerName myapp.dev <IfModule rewrite_module=""> RewriteEngine on ## Throw a 403 (forbidden) status for non secure requests RewriteCond %{HTTPS} off RewriteRule ^.*$ - [L,R=403] </IfModule> </VirtualHost> <IfModule ssl_module=""> NameVirtualHost *:443 Listen 443 SSLRandomSeed startup builtin SSLRandomSeed connect builtin <VirtualHost *:443> ServerAdmin you@yourdomain.com DocumentRoot "/path/to/MyApp/public" ServerName myapp.dev SSLEngine on SSLCertificateFile /path/to/MyApp/share/ssl/mysitename.crt SSLCertificateKeyFile /path/to/MyApp/share/ssl/mysitename.key SetEnv SLIM_MODE development </VirtualHost> </IfModule>
結論
我們現在已經有了 API 的核心。在下一部分中,我們將添加一些內容,以便擁有一個功能齊全的服務。在此期間,請隨時閱讀本部分中鏈接的文章——它們是關於有用 API 設計原則的寶庫。
關於從頭開始構建 REST API 的常見問題解答 (FAQ)
REST API 由幾個關鍵組件組成。首先是 HTTP 方法,它定義要執行的操作類型。這些包括 GET、POST、PUT、DELETE 等。第二個組件是 URL 或 URI,它是資源標識符。第三個組件是 HTTP 標頭,它承載 HTTP 請求和響應的元數據。第四個組件是正文或有效負載,它承載要傳輸的實際數據。最後,狀態代碼指示 HTTP 請求的成功或失敗。
保護您的 REST API 對於保護敏感數據至關重要。您可以使用各種方法,例如 API 密鑰、OAuth 或 JWT 進行身份驗證和授權。此外,始終使用 HTTPS 進行數據傳輸,以確保數據完整性和機密性。定期更新和修補您的 API 及其依賴項,以防範漏洞。
對您的 REST API 進行版本控制允許您引入非破壞性更改,而不會影響現有客戶端。您可以通過在 URL 中包含版本號或使用自定義請求標頭來對 API 進行版本控制。請記住記錄所有更改並告知您的 API 使用者新版本及其功能。
REST API 中正確的錯誤處理提高了其可用性和可靠性。使用 HTTP 狀態代碼指示錯誤類型。在響應正文中包含錯誤消息,以獲取有關錯誤的更多詳細信息。這有助於客戶端了解出了什麼問題以及如何解決問題。
測試您的 REST API 可確保其按預期工作並可以處理各種場景。您可以使用 Postman 或 curl 等工具進行手動測試。對於自動化測試,請考慮使用單元測試、集成測試和端到端測試。使用模擬服務器來模擬 API 響應並測試您的 API 如何處理不同類型的響應。
良好的文檔使您的 REST API 易於理解和使用。包括有關端點、請求方法、請求參數、請求示例、響應狀態代碼和響應示例的詳細信息。您可以使用 Swagger 或 Postman 等工具來生成和託管您的 API 文檔。
設計 RESTful API 涉及規劃資源、端點和方法。對資源使用名詞,對操作使用 HTTP 方法。保持 API 簡單直觀。使用狀態代碼指示請求的結果。使您的 API 無狀態,這意味著每個請求都應包含處理請求所需的所有信息。
分頁有助於限制單個響應中返回的數據量。您可以使用諸如“page”和“limit”之類的查詢參數來實現分頁。在響應標頭或正文中包含元數據,以指示當前頁、總頁數、總項目數等。
速率限制可保護您的 REST API 免受濫用並確保公平使用。您可以根據 IP 地址、API 密鑰或用戶帳戶限制請求數量。使用 HTTP 標頭將速率限制狀態傳達給客戶端。
您可以將您的 REST API 部署到服務器或云平台上。在選擇部署選項時,請考慮成本、可擴展性和安全性等因素。使用持續集成和持續交付 (CI/CD) 工具來自動化部署過程。監控您的 API 性能和使用情況,以確保它滿足用戶的需求。
以上是從頭開始構建REST API:簡介的詳細內容。更多資訊請關注PHP中文網其他相關文章!