作為前端開發(fā)者，你是否曾對著陌生 API 反復(fù)調(diào)試：這個接口支持 POST 嗎？傳 JSON 還是表單數(shù)據(jù)？其實 HTTP 早就內(nèi)置了「接口說明書」——OPTIONS 方法，它能動態(tài)告訴你「在這個端點能做什么」。今天我們就深入拆解這個被忽視的實用工具，讓 API 對接效率翻倍。

一、OPTIONS 不止于 CORS 的接口探測

提到 OPTIONS 方法，多數(shù)人第一反應(yīng)是「CORS 預(yù)檢請求」。但鮮有人知，它的核心設(shè)計初衷是被動式接口能力發(fā)現(xiàn)——讓客戶端無需嘗試調(diào)用，就能明確知道目標(biāo)端點支持的操作。

所有主流 HTTP 客戶端都原生支持 OPTIONS 請求，比如用瀏覽器的 fetch() 就能輕松發(fā)起：

const response = await fetch('https://example.org', { 
  method: 'OPTIONS' 
});

發(fā)起請求后，服務(wù)器會返回簡潔的響應(yīng)。一個基礎(chǔ)的 OPTIONS 響應(yīng)長這樣：

HTTP/1.1 204 No Content
Date: Mon, 23 Sep 2024 02:57:38 GMT
Server: KKachel/1.2
Allow: GET, PUT, POST, DELETE, OPTIONS

其中最關(guān)鍵的是 Allow 頭，它直接列出了端點支持的所有 HTTP 方法。更省心的是，Express、Koa 等主流 Web 框架會自動根據(jù)路由配置生成這個列表，開發(fā)者幾乎無需額外編碼。

想快速驗證你的服務(wù)器是否支持？終端執(zhí)行這條 curl 命令即可（替換成你的接口地址）：

curl -X OPTIONS http://localhost:3000/some/endpoint/

Allow 頭還有個實用技巧：結(jié)合權(quán)限動態(tài)返回。比如僅當(dāng)用戶有資源寫入權(quán)限時，才在 Allow 中包含 DELETE 和 PUT，實現(xiàn)基礎(chǔ)的權(quán)限可視化。

二、核心響應(yīng)頭：解鎖接口細(xì)節(jié)

除了 Allow 頭，OPTIONS 響應(yīng)中還有多個標(biāo)準(zhǔn)化頭，能精準(zhǔn)傳遞接口的格式、編碼等關(guān)鍵信息。

1. 數(shù)據(jù)格式與壓縮：Accept 與 Accept-Encoding

你可能在請求頭中常用 Accept（告訴服務(wù)器想要什么格式數(shù)據(jù)）和 Accept-Encoding（告訴服務(wù)器支持什么壓縮方式），但它們在 OPTIONS 響應(yīng)中同樣重要——此時是服務(wù)器主動告知客戶端「我能提供什么」。

看這個示例響應(yīng)：

HTTP/1.1 204 No Content
Date: Mon, 23 Sep 2024 02:57:38 GMT
Server: KKachel/1.2
Allow: GET, PUT, POST, DELETE, OPTIONS
Accept: application/vnd.my-company-api+json, application/json, text/html
Accept-Encoding: gzip,brotli,identity

• Accept 響應(yīng)頭：明確端點支持的 MIME 類型。比如上面的配置中，接口既支持自定義格式 application/vnd.my-company-api+json，也支持標(biāo)準(zhǔn) JSON 和 HTML。前端開發(fā)者可以利用這一點：給 JSON API 端點加上 text/html 支持，這樣直接在瀏覽器打開接口 URL 就能看到調(diào)試頁面，方便團隊共享調(diào)試。
• Accept-Encoding 響應(yīng)頭：告知客戶端可使用的請求體壓縮方式。gzip 和 brotli 是常見的高效壓縮算法，而 identity 表示不壓縮。前端請求時按此配置壓縮數(shù)據(jù)，能大幅減少傳輸體積。

2. 方法專屬格式：Accept-Patch/Post/Query

針對 PATCH、POST、QUERY 這三個高頻方法，HTTP 提供了專門的響應(yīng)頭，精準(zhǔn)說明每種方法支持的請求體格式——其值直接對應(yīng)請求時 Content-Type 頭的合法取值。

示例如下：

HTTP/1.1 204 No Content
Date: Mon, 23 Sep 2024 02:57:38 GMT
Server: KKachel/1.2
Allow: OPTIONS, QUERY, POST, PATCH
Accept-Patch: application/json-patch+json, application/merge-patch+json
Accept-Query: application/graphql
Accept-Post: multipart/form-data, application/vnd.custom.rpc+json

每個頭的作用清晰明確：

• Accept-Patch：PATCH 請求支持的格式。上面的配置表示接口接受「JSON Patch」和「JSON Merge Patch」兩種標(biāo)準(zhǔn)補丁格式，前端可按需選擇部分更新的實現(xiàn)方式。
• Accept-Query：QUERY 方法支持的格式。這里指定為 application/graphql，說明該端點可直接接收 GraphQL 查詢語句。
• Accept-Post：POST 請求支持的格式。示例中既支持 multipart/form-data（用于文件上傳），也支持自定義的 JSON-RPC 格式，前端無需猜測上傳或提交數(shù)據(jù)的方式。

3. 特殊說明：PUT 與 DELETE 

細(xì)心的開發(fā)者可能會發(fā)現(xiàn)：沒有專門針對 PUT 方法的格式頭（如 Accept-Put）。這是因為 HTTP 規(guī)范中 GET 和 PUT 被設(shè)計為「對稱操作」，理論上可通過 Accept 頭間接推斷 PUT 支持的格式，但規(guī)范并未明確這一點。

而 DELETE 方法則更簡單：HTTP 標(biāo)準(zhǔn)規(guī)定 DELETE 請求不應(yīng)包含請求體，因此只需通過 Allow 頭判斷是否支持刪除操作即可，無需額外格式說明。

三、進階用法：從文檔鏈接到全服探測

OPTIONS 的能力遠(yuǎn)不止于方法和格式說明，它還能承擔(dān)文檔指引、協(xié)議擴展等重要角色。

1. 嵌入文檔鏈接：接口的「說明書」

OPTIONS 響應(yīng)是銜接接口與文檔的最佳載體。你可以在響應(yīng)中加入 Link 頭，指向機器可讀的 OpenAPI 定義和人類可閱讀的文檔頁面，甚至在響應(yīng)體中添加友好提示。

示例響應(yīng)：

HTTP/1.1 200 OK
Date: Mon, 23 Sep 2024 04:45:38 GMT
Allow: GET, QUERY, OPTIONS
Link: <https://docs.example.org/api/some-endpoint>; rel="service-doc"
Link: <https://api.example.org/openapi.yml>; rel="service-desc" type="application/openapi+yaml"
Content-Type: text/plain

Hey there!
Thanks for checking out this API. You can find the docs for this
specific endpoint at: https://docs.example.org/api/some-endpoint
Cheers,
The dev team

其中 rel="service-doc" 表示人類可讀文檔，rel="service-desc" 表示機器可讀的服務(wù)描述（如 OpenAPI），這些都是 IANA 標(biāo)準(zhǔn)化的鏈接關(guān)系類型，兼容性有保障。建議響應(yīng)體保持簡潔，核心信息都通過鏈接指向獨立文檔頁面。

2. 協(xié)議擴展支持：WebDAV 中的實踐

在 WebDAV（基于 HTTP 的文件管理協(xié)議）、CalDAV（日歷同步）等擴展協(xié)議中，OPTIONS 是標(biāo)準(zhǔn)的能力探測工具。例如 WebDAV 服務(wù)器的 OPTIONS 響應(yīng)：

HTTP/1.1 204 No Content
Date: Mon, 23 Sep 2024 05:01:50 GMT
Allow: GET, PROPFIND, ACL, PROPPATCH, MKCOL, LOCK, UNLOCK
DAV: 1, 2, 3, access-control, addressbook, calendar-access

通過 DAV 頭，客戶端能立即知道服務(wù)器支持的 WebDAV 版本和擴展功能（如地址簿、日歷訪問），這對開發(fā)網(wǎng)盤、日歷同步等工具的前端開發(fā)者尤其有用。

3. 全服能力探測：星號請求

通常 HTTP 請求針對服務(wù)器上的具體路徑（如 GET /path HTTP/1.1），但 OPTIONS 支持一種特殊的「全服探測」——用星號代替路徑：

OPTIONS * HTTP/1.1

這里的星號不是 URI 路徑，而是表示「查詢整個服務(wù)器的能力」。不過需要注意，很多客戶端（包括瀏覽器的 fetch()）不支持這種請求格式，但 Apache、Nginx 等經(jīng)典服務(wù)器都能響應(yīng)。

想嘗試的話，用 curl 執(zhí)行以下命令：

curl -vX OPTIONS --request-target '*' http://example.org

四、前端實踐建議：讓 OPTIONS 成為開發(fā)利器

1. 對接新 API 先查 OPTIONS：拿到陌生接口時，第一步發(fā)起 OPTIONS 請求，快速掌握支持的方法、格式和文檔位置，避免盲目調(diào)試。
2. 結(jié)合 OpenAPI 提升體驗：如果后端同時提供 OpenAPI 文檔，可通過 OPTIONS 的 Link 頭指向文檔地址，前端工具（如 Swagger UI）能自動加載文檔。
3. 處理權(quán)限動態(tài)反饋：通過 Allow 頭的動態(tài)變化，前端可實時更新 UI 交互（如無刪除權(quán)限則隱藏刪除按鈕），提升用戶體驗。
4. 避免自定義方案：不要自己設(shè)計「/api/meta」這類接口來返回能力信息，OPTIONS 是 HTTP 標(biāo)準(zhǔn)方案，兼容性和可讀性更優(yōu)。

HTTP OPTIONS 用標(biāo)準(zhǔn)化的方式解決了「接口能做什么」的核心問題。對于前端開發(fā)者而言，善用 OPTIONS 能大幅減少對接 API 時的試錯成本，讓接口交互更高效、更規(guī)范。 下次遇到陌生接口，不妨先問一句：「你的 OPTIONS 響應(yīng)里有答案嗎？」