多數人以為，WordPress 網站的內容只能從後台登入畫面進去碰，打開瀏覽器輸入帳號密碼，才摸得到文章跟頁面。這就像一間倉庫只留了一道大門，任何人想搬貨都得先走進去、找到貨架，親手把東西搬出來。
其實 WordPress 還另外開了一扇窗口，不需要真的走進倉庫，只要隔著窗口喊一聲要什麼，對方就用 JSON 這種雙方都看得懂的格式把貨遞出來。手機 App、別的網站，甚至現在的 AI 工具，都是靠這扇窗口在跟 WordPress 打交道，完全不必懂 WordPress 背後那套 PHP 邏輯。這扇窗口，正式的名字叫 WordPress REST API。
這扇窗口的運作邏輯，沒有想像中複雜——打開瀏覽器輸入一個網址，很快就能親眼看到它長什麼樣子。不過在動手之前，先把 REST 跟 API 這兩個字拆開來看清楚。
WordPress REST API 是什麼？
REST API 其實是兩個詞的組合，各自解決一個問題。
API（Application Programming Interface，應用程式介面）指的是讓不同程式互相溝通的窗口，一支手機 App 想跟 WordPress 網站要資料，總得有個固定的窗口可以喊話，API 就是那個窗口。REST（Representational State Transfer）則是幫這扇窗口訂規矩的一種設計風格，用網址代表你要的資源，像一篇文章、一個使用者，再用 JSON 這種通用格式把資料打包丟回去。把兩者合起來，WordPress REST API 就是把資料庫裡的文章、頁面這些內容轉換成 JSON，開放給外部程式讀取或寫入。
這不是裝了某支外掛才有的加分功能，而是 WordPress 從 4.7 版（2016 年底）起，就寫進核心程式裡的內建能力，不用另外安裝任何東西就能用。更有說服力的一個事實是，你在後台用區塊編輯器寫文章，按下發佈或更新的那一刻，瀏覽器背景其實正在打一次 REST API 請求，把你寫的內容送回資料庫。這扇窗口不是邊緣小眾的工具，而是 WordPress 現在整套後台運作的骨幹。
什麼是「路由」和「端點」？
往下讀之前，先弄懂兩個常被交替使用、但其實不一樣的詞：路由（route）和端點（endpoint）。
路由指的是一個網址本身，例如 /wp-json/wp/v2/posts 就是一個路由。端點則是某一種 HTTP 方法掛在這個路由上、實際處理請求的那個功能，同一個路由可以同時掛著好幾個端點。拿 /wp-json/wp/v2/posts 來說，用 GET 方法打這個路由，回應的端點會把現有文章清單交出來；換成 POST 方法打同一個路由，對應到的卻是另一個端點，任務是建立一篇新文章。網址沒變，你用的方法變了，實際執行的功能就跟著換。搞懂這一層，之後看到程式範例裡同一個網址搭配不同方法的寫法，才不會一頭霧水。
打開瀏覽器，看懂 wp-json/wp/v2/posts 回傳的 JSON
接下來這一步不用寫任何程式，只要打開瀏覽器，在任何一個 WordPress 網站的網址後面加上 /wp-json/，按下 Enter。
畫面會跳出一段 JSON，列出這個網站目前開放哪些路由，可以把它想成前面那間倉庫的窗口目錄，告訴你這扇窗口總共分成哪幾個小窗口、各自負責哪些內容。想再往下看某一種資料，把網址換成 /wp-json/wp/v2/posts，畫面這次會跳出更長一串 JSON，裡面塞著這個網站目前所有文章的完整內容。
第一次看到這串 JSON，大概只會覺得眼花，因為瀏覽器原生顯示的是擠成一坨、沒有任何換行的純文字。這時候借助瀏覽器的 JSON 格式化附加元件，各家瀏覽器都能找到對應工具，裝上去之後同一段內容會自動排版、上色，馬上變得好讀很多。
排版整齊之後，再逐一對照幾個最常出現的欄位：id 是這篇文章的編號、title 是標題、content 是內文、date 是發佈時間、slug 是網址裡用的英文代稱、link 則是這篇文章在前台的完整網址。對著自己的網站打開這個網址，第一次操作就能拿到真實的回饋，這些欄位正是後面串接 App、寫程式的時候會直接用到的資料。
GET、POST、PUT、DELETE：這扇窗口能做的四件事
上一段的 /wp-json/wp/v2/posts，其實只示範了這扇窗口眾多動作裡的其中一種，也就是讀取。完整攤開來看，這扇窗口總共能做四件事，分別對應四個 HTTP 方法：GET、POST、PUT、DELETE。
GET 是隔著窗口看倉庫裡有什麼，對應到讀取資料，通常不需要登入就能查看；POST 是把新貨送進倉庫，對應到新增一篇文章；PUT 是換掉架上的舊貨，對應到修改一篇已經存在的內容；DELETE 則是把貨從架上撤下來，對應到刪除，不過 WordPress 預設是先丟進垃圾桶，而不是直接從資料庫裡銷毀，誤刪了通常還救得回來。
四個方法各司其職，卻畫出一條清楚的分界線，讀取幾乎不設防，任何人都能隔著窗口看；後面三個牽涉到新增、修改、刪除的動作，不管是誰，都得先證明自己是可以動這批貨的人。這道身份驗證，靠的正是接下來要講的機制。
想新增或修改內容，為什麼一定要用「應用程式密碼」？
前面提到，POST、PUT、DELETE 都得先證明身份，問題是，證明身份要用哪一組密碼？
直覺會想到後台登入用的那組帳號密碼，但 WordPress 從 5.6 版（2020 年底）起，替這件事另外準備了一套機制，叫做應用程式密碼。它不是平常登入後台的那組主密碼，而是專門發給程式使用的一組獨立密碼，由 WordPress 自動產生，總共 24 碼、英數混合，不含任何特殊符號。
為什麼不直接拿主密碼去打 API 就好？最直接的理由是風險太集中，主密碼一旦外洩，牽動的是整個帳號，而且很難只收回其中一種用途。應用程式密碼則反過來設計，每串接一個 App、一支工具，就替它單獨開一組密碼，某一組如果外洩或不再需要，直接刪除那一組就好，其他已經連上的服務完全不受影響。這套機制還有一個前提，網站必須開著 HTTPS，沒有 HTTPS 加密，應用程式密碼預設不會啟用，避免密碼在傳輸過程被攔截。
去哪裡建立你的第一組應用程式密碼？
想實際建立一組，路徑並不深。登入後台，點選使用者裡的個人資料，往下捲到最底部，會看到一個應用程式密碼的區塊。輸入一個好辨識的名稱，例如測試用或這組密碼準備串接的工具名稱，按下新增，畫面就會顯示剛剛產生的 24 碼密碼。
這組密碼只會顯示這一次，務必當場複製保存好；離開這個畫面之後回頭再看，只會看到一筆已建立的紀錄，不會再讓你看到密碼本身。之後想撤銷某一組，直接在同一個畫面刪掉那筆紀錄，對應的密碼就立刻失效，不影響其他還在使用的密碼。
手機 App、其他網站，甚至 AI 工具，為什麼都要靠這一扇窗口？
回到最開頭的倉庫比喻，這扇窗口實際上被誰在用？
最直接的一種，是手機 App。App 想把 WordPress 網站的文章、頁面顯示在手機畫面上，靠的就是隔著這扇窗口把內容讀出來，不需要 App 自己再理解 WordPress 背後那套 PHP 邏輯。另一種常見用法，是把 WordPress 純粹當成內容倉庫，前台改用別的技術呈現，業界稱這種架構為 headless（無頭）。舉例來說，一個經營電商內容的品牌，想把商品介紹文章同步進自己開發的 App，做法就是讓 App 透過這扇窗口去讀 WordPress 裡的內容，前台畫面完全交給 App 自己決定怎麼呈現。
最新的一種用法，則是 AI 工具。WordPress 核心團隊在 6.9 版推出了 Abilities API，把新增一篇文章、讀取網站資訊這類功能，包裝成 AI 能夠理解、能夠呼叫的標準化能力；再透過一套叫做 MCP（Model Context Protocol，模型上下文協議）的開放協議，讓 Claude、Cursor 這類 AI 助手能發現、呼叫這些能力，自行架設的網站沿用的正是同一套 REST API 與應用程式密碼驗證機制。連 WordPress.com 都已經把 MCP 伺服器直接內建進服務裡，使用者只要完成授權，就能讓 AI 助手直接讀取、管理自己網站上的內容，不用再手動一篇一篇貼上後台。
不管接的是 App、另一個網站，還是 AI 工具，用的都是同一扇窗口，只是敲門的方式不一樣。
看得到 JSON，不等於任何人都能改你的網站
看到這裡，可能會冒出一個疑慮，自己網站的資料就這樣攤在網址上，任何人都能打開來看，會不會太不安全？
先說結論，這是刻意的設計，不是漏洞。已經發布的文章、頁面，本來在網站前台就是任何人都看得到的公開內容，REST API 只是換了一種格式，把同樣的公開內容用 JSON 交出去，並沒有多曝露任何原本不公開的東西。真正會動到資料庫內容的 POST、PUT、DELETE，前面已經講過，一律得先通過應用程式密碼驗證，沒有驗證通過的請求一律會被擋下來，不會因為知道網址就能直接改內容。
如果站主真的有特殊考量，不希望連 /wp-json/ 這個索引頁都被看到，WordPress 官方也提供對應的做法可以限縮公開存取。不過對一般網站來說，這不是必要的設定，公開內容本來就公開，真正該顧好的是後面那一道身份驗證的門。
下次不管是想把網站接上一支自己開發的 App、串接另一個系統，還是讓 AI 工具幫忙管理內容，都不必再把 WordPress 當成一個只能在後台點來點去的黑盒子。遇到類似的需求，不妨先問自己一句，這件事是不是也能隔著這扇取貨窗口做到。多數時候，答案是可以的。