在數位世界的浩瀚森林中，WordPress 曾經是個統治一切的巨獸——既是內容的創造者，又是展示的舞台。然而，時代的風向變了。開發者們開始揮舞技術的利刃，將這頭巨獸的「頭」與「身」分離，催生出「無頭 WordPress」這一新物種。這種斷頭術並非殘忍，而是解放：後端專注於內容管理，前端則自由選擇舞蹈的舞台——React、Vue，甚至靜態生成器。這一切的魔法，仰賴兩位關鍵使者：REST API 與 WPGraphQL。本文將帶您深入這片技術叢林，揭開它們的面紗，探尋它們如何重塑網站開發的未來。
🌐 從鐵板一块到靈魂分離：無頭 CMS 的崛起
想像一下，傳統的 WordPress 就像一個全能的廚師，既負責種菜、做飯，還得親自端盤上桌。這種一條龍服務雖然方便，卻限制了靈活性——你只能吃他做的菜，盤子也只能是他挑的。然而，無頭 CMS（Headless CMS）改變了遊戲規則。它把 WordPress 變成了一個專注的「食材倉庫」，只負責儲存和管理內容，至於怎麼烹飪、怎麼擺盤，統統交給前端的「大廚」們。
這種解耦的設計並非新鮮事。早在數年前，開發者就開始探索如何讓內容與展示分離，而 WordPress 憑藉其強大的內容管理能力，順理成章地成為無頭化的熱門選擇。問題在於，如何從這個「倉庫」裡高效、安全地取出食材？答案指向了兩條路：REST API 和 WPGraphQL。
🍔 REST API：老派但可靠的快餐車
說到 REST API，它就像街邊那輛熟悉的快餐車。自 WordPress 4.7 起，這輛車就停在了每個 WordPress 網站的後門，地址很簡單：/wp-json。你只要敲敲窗戶，就能拿到一袋 JSON 格式的數據——文章、評論、媒體，應有盡有。
簡單粗暴的取貨方式
REST API 的用法直白得像點漢堡：輸入 http://yoursite.com/wp-json/wp/v2/posts，你就拿到了一堆文章數據。它內建於 WordPress，無需額外插件，對於公開內容，誰都可以來取貨；但若涉及私人數據，比如受密碼保護的文章，則需要身份驗證，這就像快餐車要求你出示會員卡。
不過，這輛快餐車有個小麻煩。如果你想要一份「文章加評論」的套餐，得分別敲兩次窗戶：
http://yoursite.com/wp-json/wp/v2/posts/123 ——拿文章。http://yoursite.com/wp/json/wp/v2/comments?post=123 ——拿評論。
這種「多跑幾趟」的模式被稱為「過度抓取」（over-fetching），有時還會順手塞給你一堆你不需要的配料，比如文章的完整元數據。效率不高，但對於簡單需求，它夠用了。
配置小貼士
如果敲窗戶時發現車門沒開（即 /wp-json 無響應），別慌。進 WordPress 的「固定連結」設置，把格式改成「文章名稱」之類的選項，車門就自動解鎖了。這招對本地和公開網站都管用。
🧙 WPGraphQL：魔法書中的精準咒語
相比 REST API 的快餐車，WPGraphQL 更像一本魔法書。2015 年，Jason Bahl 將 Facebook 於 2012 年推出的 GraphQL 引入 WordPress，打造了這款插件。它不像 REST API 那樣四處設點，而是只開一個窗口（通常是 /graphql），卻能精準滿足你的需求。
一咒搞定的藝術
GraphQL 的核心魅力在於「你想要什麼，我就給什麼」。比如，你想拿一篇 ID 為 123 的文章，連帶它的標題、內容和評論，用 WPGraphQL 只需念一句咒語：
{
post(id: "123") {
title
content
comments {
edges {
node {
content
}
}
}
}
}
這一招直接從倉庫裡取出你指定的「食材」，無需多跑腿，也不會多給你一堆沒用的東西。相比 REST API 的兩次請求，WPGraphQL 一次搞定，效率高得像魔法。
開啟魔法書的步驟
要用這本魔法書，得先裝上 WPGraphQL 插件。裝好後，WordPress 面板會多出一個 GraphQL Playground，讓你試寫咒語、測試效果。這種精準取貨的方式特別適合前端框架，像 React 或 Vue，能輕鬆把數據塞進動態界面。
⚡ 效率大對決：誰更快更聰明？
REST API 和 WPGraphQL 的差別，就像快餐車與魔法師的對決。快餐車簡單直接，但要啥給啥，沒得挑；魔法師則能根據你的口味，變出量身定制的菜單。
舉個例子，假設你只想要所有文章的標題和日期。REST API 會給你整盤數據：
http://yoursite.com/wp-json/wp/v2/posts
裡面塞滿了內容、分類等你可能不想要的東西。而 WPGraphQL 讓你輕鬆說：
{
posts {
title
date
}
}
結果乾淨俐落，數據量小到像羽毛一樣輕盈。這種「少即是多」的哲學，正是 GraphQL 擊敗 REST 的關鍵。
🌟 WPGraphQL 的多才多藝
WPGraphQL 不只擅長單點取貨，還能一次抓多種資源。比如，你想同時拿文章和頁面：
{
posts {
edges {
node {
title
}
}
}
pages {
edges {
node {
title
}
}
}
}
這就像魔法師一次召喚兩盤菜，REST API 只能望塵莫及。這種多根資源（multi-root resources）的能力，讓它在複雜項目中大放異彩。
🚀 選擇你的頭：前端的無限可能
無頭 WordPress 的美妙之處在於，你可以隨意挑選前端的「頭」。想用靜態網站生成器（SSG）像 Gatsby？免費部署到靜態托管服務，成本低到讓人偷笑。或者用 React 打造動態界面，讓 WordPress 在後台默默支援。無論哪種選擇，REST API 和 WPGraphQL 都能把數據送到你手上。
比如，用 Gatsby 時，WPGraphQL 是首選，因為它有專屬的 Gatsby 源插件，數據傳輸順暢得像高速公路。而 Next.js 這樣的框架也能輕鬆接上 WPGraphQL，打造靜態與實時兼得的網站。
🕵️ 另一位挑戰者：GraphQL API for WordPress
就在 WPGraphQL 大放光芒時，另一位選手悄悄登場——GraphQL API for WordPress。這款插件由一位熱衷於數據引擎的開發者打造，號稱「前瞻性」的 GraphQL 伺服器。它與 WPGraphQL 有何不同？
實時戰場的利器
對於靜態網站，WPGraphQL 已足夠優秀。但若涉及實時數據，比如顯示即時評論或分析數據，GraphQL API for WordPress 開始發力。它支援「持久化查詢」（persistent queries），讓響應能在多層次緩存（HTTP Cache），速度快得像閃電。此外，它預設禁用單一端點，安全性更高，適合公開的實時網站。
客製化的魔法窗口
不像 WPGraphQL 只有一個 /graphql 窗口，GraphQL API for WordPress 能開多個客製化端點，比如：
/graphql/mobile-app ——給手機應用。/graphql/pro-users ——給付費用戶。
每個端點還能搭配訪問控制列表（ACL），精準決定誰能看什麼。這就像給不同顧客發不同的魔法鑰匙，靈活性爆棚。
🛠️ 與外界聯繫：指令的魔力
GraphQL API for WordPress 還有個獨門絕技——指令（directives）。想像一下，你想把文章標題送到 Google Translate API 翻譯成西班牙語：
{
posts {
title @translate(from: "en", to: "es")
}
}
這一招讓 GraphQL 不只是取貨員，還能變身數據處理師。相比之下，WPGraphQL 在這方面的文獻較少，顯得低調許多。
📊 數據對比：誰更勝一籌？
為了直觀比較，我們來看張表格：
| 特性 | REST API | WPGraphQL | GraphQL API for WordPress |
|---|
| 端點數量 | 多個（如 /posts） | 單一（/graphql） | 可多個客製（如 /graphql/app） |
| 數據精準度 | 過度抓取 | 精準抓取 | 精準抓取 |
| 速度 | 一般 | 高 | 更高（因緩存） |
| 安全性 | 基礎驗證 | 禁用自省 | 禁用單端點 + ACL |
| 實時支援 | 有限 | 一般 | 強（持久化查詢） |
| 社區支持 | 內建，無需插件 | 強大 | 發展中 |
從中可見，REST API 適合簡單項目，WPGraphQL 是靜態網站的王者，而 GraphQL API for WordPress 在實時與客製化場景中獨領風騷。
🎨 編輯器的未來：與 Gutenberg 的對話
WordPress 的編輯器 Gutenberg 是內容創作的核心，兩款 GraphQL 插件都試圖與它握手。WPGraphQL 提議用伺服器端註冊表，讓塊與 GraphQL 模式對應；而 GraphQL API for WordPress 則用「一次創建，到處發布」的策略，直接從塊數據提取資訊。這場比賽尚未分出勝負，但後者似乎更接近實用解法。
🌍 靜態還是實時？抉擇的藝術
選擇哪條路，取決於你的目標。靜態網站像一本印刷好的書，生成後不變，WPGraphQL 是你的最佳幫手。實時網站像直播間，隨時更新，GraphQL API for WordPress 更合拍。比如，一個博客用 Next.js 靜態生成文章，再用 GraphQL API 實時拉取評論，就能完美平衡效率與互動。
🤝 社區與創新：兩者的性格
WPGraphQL 有個熱鬧的社區，像個老朋友隨時幫忙；而 GraphQL API for WordPress 像個新銳實驗家，帶來創意卻仍在聚攏人氣。如果你愛穩定，選前者；若想冒險，後者值得一試。
🎉 結語：斷頭時代的內容革命
無頭 WordPress 就像一場技術狂歡，REST API 是老牌DJ，WPGraphQL 是流行樂手，GraphQL API for WordPress 則是前衛新秀。它們聯手讓內容從 WordPress 的牢籠中解放，飛向無限可能的數位天空。無論你是靜態網站的建築師，還是實時應用的魔術師，這片王國都有適合你的魔法。拿起工具，開始你的創作吧！
參考文獻
- 《了解無頭 WordPress 的 WPGraphQL 和 REST API》，用戶提供文獻，2025 年 4 月存取。
- 《讓 GraphQL 在 WordPress 中發揮作用》，用戶提供文獻，2025 年 4 月存取。
- "WPGraphQL vs WP REST API," Wbolt, https://www.wbolt.com/wpgraphql-vs-wp-rest-api.html, 2025 年 4 月存取。
- "GraphQL 在 WordPress 中的應用," Juejin, https://juejin.cn/post/6977785754239893541, 2025 年 4 月存取。
- Bahl, J., "WPGraphQL Documentation," WPGraphQL Official Site, 2025 年 4 月存取。
