API 回傳一坨垃圾?資深工程師教你用 JSON Schema 打造 WordPress 滴水不漏的數據防火牆

2025/09/15 | API 串接與自動化

API 回傳一坨垃圾?資深工程師教你用 JSON Schema 打造 WordPress 滴水不漏的數據防火牆

嗨,我是浪花科技的 Eric。身為一個有點龜毛的資深工程師,我看過太多因為「資料格式」問題而引發的災難。前端送來的資料缺東缺西、後端 API 回傳的格式變來變去,這種「溝通全靠心電感應」的開發模式,簡直是專案管理的惡夢,更別提後續維護要花多少時間去 debug 了。

「Garbage in, garbage out.」(垃圾進,垃圾出)這句古老的程式諺語,在 API 串接的世界裡尤其真實。如果你的 WordPress 網站需要跟外部服務、手機 App 或前端框架(像是 React / Vue)溝通,那麼你一定對處理各種奇形怪狀的 JSON 資料感到頭痛。今天,我就要來跟你分享一個能從根本解決這個問題的神兵利器:JSON Schema 設計與驗證

什麼是 JSON Schema?為什麼你的 WordPress 專案需要它?

在我們深入探討之前,先來個快速複習。JSON (JavaScript Object Notation) 是一種輕量級的資料交換格式,因為易於閱讀和撰寫,已經成為現代 API 的標準格式。但 JSON 本身只定義了資料的「長相」,卻沒有定義「規則」。

這就像是你拿到一張履歷表,你知道上面有姓名、電話、Email,但你無法保證:

  • Email 欄位是不是真的是一個有效的 Email 格式?
  • 年齡欄位會不會被填入「祕密」這兩個字?
  • 必填的電話號碼是不是被漏掉了?

JSON Schema 就是為了解決這個問題而生的。它本身也是一個 JSON 檔案,但它的用途是去「描述」另一個 JSON 檔案的結構和規則。你可以把它想像成是:

  • JSON 資料的「藍圖」或「說明書」:它清楚定義了每個欄位的名稱、資料型別(字串、數字、布林值…)、是否為必填,以及更複雜的驗證規則。
  • 一份開發團隊之間的「合約」:前端工程師和後端工程師不用再猜來猜去,只要看著這份 Schema,就知道資料該長什麼樣子。
  • 一個自動化的「數據守門員」:在資料進入你的 WordPress 資料庫之前,先用 Schema 這道防火牆過濾掉所有不符合規範的「垃圾資料」。

對 WordPress 開發者來說,導入 JSON Schema 設計與驗證 帶來的好處是顯而易見的:

  1. 提升 REST API 的穩健性:確保所有寫入你自訂端點 (Custom Endpoint) 的資料都是乾淨、有效、且符合預期的,大幅減少因為髒資料造成的 bug。
  2. 增強網站安全性:防止惡意使用者透過 API 傳送非預期的資料結構或型別,這也是一種基礎的安全性防護,避免潛在的注入攻擊。
  3. 加速開發與協作:Schema 本身就是最好的 API 文件。前端不用再苦苦等待後端完成 API 才能開始開發,他們可以根據 Schema 產生的假資料 (mock data) 先行作業。
  4. 簡化 Debug 過程:當資料驗證失敗時,你可以立刻回傳一個明確的錯誤訊息,告訴呼叫方「哪個欄位錯了」、「為什麼錯」,而不是讓程式在後續流程中因為一個 `null` 或非預期的資料型別而莫名其妙地崩潰。

JSON Schema 核心概念:打造你的第一份數據藍圖

講了這麼多好處,我們來實際看看 JSON Schema 長什麼樣子。假設我們要為一個產品評論的 API 設計一個 Schema,我們期望收到的 JSON 資料如下:


{
  "product_id": 123,
  "rating": 5,
  "comment": "這真是太棒了!",
  "reviewer_name": "Eric",
  "reviewer_email": "eric@roamer-tech.com"
}

對應的 JSON Schema 可能會這樣設計:


{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Product Review",
  "description": "Schema for a product review submission",
  "type": "object",
  "properties": {
    "product_id": {
      "description": "The unique identifier for the product",
      "type": "integer",
      "minimum": 1
    },
    "rating": {
      "description": "The rating given by the reviewer, from 1 to 5",
      "type": "integer",
      "minimum": 1,
      "maximum": 5
    },
    "comment": {
      "description": "The review text",
      "type": "string",
      "maxLength": 500
    },
    "reviewer_name": {
      "description": "Name of the reviewer",
      "type": "string",
      "minLength": 2
    },
    "reviewer_email": {
      "description": "Email address of the reviewer",
      "type": "string",
      "format": "email"
    }
  },
  "required": ["product_id", "rating", "comment", "reviewer_name", "reviewer_email"]
}

重點關鍵字解析:

  • $schema: 指定你使用的 Schema 版本,通常照抄即可。
  • title / description: 不影響驗證,但對文件化非常有幫助。
  • type: 定義資料的型別,最外層通常是 objectarray
  • properties: 這是 object 型別的核心,用來定義物件內每個屬性(key)的規則。
  • required: 一個陣列,列出所有必填的屬性名稱。如果請求中缺少了 `required` 裡的任何一個欄位,驗證就會失敗。
  • 驗證關鍵字:像是 minimum, maximum, minLength, maxLength, format (例如 email, date-time) 等,這些都是用來加上更細緻的規則,確保資料不只「存在」,更是「正確」。

實戰!在 WordPress REST API 中導入 JSON Schema 驗證

理論講完了,我們工程師還是得看 code 才踏實。WordPress 核心本身沒有內建 JSON Schema 驗證器,但我們可以很輕易地透過 Composer 整合第三方 PHP 套件來完成這項工作。我個人推薦 justinrainbow/json-schema 這個老牌又穩定的函式庫。

身為一個現代化的 WordPress 開發者,你應該要在你的外掛或主題專案中使用 Composer。如果你還在手動 `require` 檔案,那真的該花點時間看看 如何打造現代化的開發環境了,這會讓你的專案管理提升好幾個檔次。

步驟一:使用 Composer 安裝驗證函式庫

在你的外掛或主題根目錄下,打開終端機,執行:

composer require justinrainbow/json-schema

步驟二:建立自訂 REST API 端點

我們在 `functions.php` 或是一個自訂外掛中,註冊一個新的 API 路由來接收產品評論。


<?php
add_action('rest_api_init', function () {
    register_rest_route('my-awesome-plugin/v1', '/reviews', [
        'methods' => 'POST',
        'callback' => 'handle_submit_review',
        // 我們等等會在這裡加上權限檢查
        'permission_callback' => '__return_true', 
    ]);
});

步驟三:撰寫驗證與處理邏輯

現在,最關鍵的部分來了。我們要在 `handle_submit_review` 這個 callback function 裡,用剛剛安裝的函式庫來驗證傳入的請求 body。


<?php
use JsonSchema\Validator;

function handle_submit_review(WP_REST_Request $request) {
    // 1. 取得請求的 JSON body
    $data = $request->get_json_params();

    // 2. 定義我們的 JSON Schema (實務上建議存在一個 .json 檔裡)
    $schema = json_decode(file_get_contents(__DIR__ . '/schemas/review.json'));

    // 3. 建立驗證器
    $validator = new Validator();
    $validator->validate($data, $schema);

    // 4. 檢查驗證結果
    if (!$validator->isValid()) {
        // 驗證失敗,回傳一個帶有詳細錯誤資訊的 WP_Error 物件
        $errors = [];
        foreach ($validator->getErrors() as $error) {
            $errors[] = sprintf('[%s] %s', $error['property'], $error['message']);
        }

        return new WP_Error(
            'rest_invalid_payload',
            'The submitted data is invalid.',
            ['status' => 400, 'errors' => $errors]
        );
    }

    // 5. 驗證通過!可以安心地處理資料了
    // 例如:將評論寫入資料庫
    $product_id = sanitize_text_field($data['product_id']);
    $rating = intval($data['rating']);
    // ... 其他處理邏輯 ...

    // 回傳成功的響應
    return new WP_REST_Response(['message' => 'Review submitted successfully!'], 201);
}

看到了嗎?在我們真正開始處理資料(步驟 5)之前,我們用 Schema 建立了一道堅固的防線。任何不符合 `review.json` 裡面規則的請求,都會在步驟 4 被擋下來,並且回傳一個 400 Bad Request 的 HTTP 狀態碼,以及清楚的錯誤訊息。這就是專業級 API 該有的樣子!

結論:不只是驗證,更是專業開發的基石

導入 JSON Schema 設計與驗證,初期看起來可能會增加一點點工作量,需要你額外定義 Schema 檔案。但相信我,這是一項非常值得的投資。它能為你的 WordPress 專案帶來更強的健壯性、更高的安全性,並大幅改善團隊協作的效率。

別再讓你的 API 像個沒有警衛的大門,任由各種來路不明的資料闖入。從今天起,為你的資料建立一份清晰的藍圖,用 JSON Schema 打造一個讓自己和同事都能安心的開發流程吧!

延伸閱讀

如果你對於如何在現有專案中導入 JSON Schema,或是對於 WordPress API 開發、自動化串接有任何疑問,浪花科技的團隊擁有豐富的實戰經驗。我們不只會寫 code,更專注於打造穩健、可擴展的系統架構。

歡迎點擊這裡,填寫表單與我們的專家聊聊,讓我們幫助你打造更專業、更可靠的 WordPress 應用!

常見問題 (FAQ)

Q1: 到底什麼是 JSON Schema?可以吃嗎?

A: JSON Schema 不能吃,但它能讓你的專案「體質」更好!簡單來說,它是一個用來定義和驗證 JSON 資料結構與格式的「規則說明書」。透過它,你可以確保所有進到你系統的資料都符合你預設的規範,就像一個自動化的數據品管員。

Q2: 為什麼 WordPress REST API 特別需要 JSON Schema 驗證?

A: 因為 WordPress 的 REST API 是對外開放的窗口,任何前端應用或第三方服務都可以呼叫它。如果沒有嚴格的驗證,就等於門戶大開,很容易收到格式錯誤、缺少欄位甚至惡意的資料,導致系統出錯或產生安全漏洞。JSON Schema 就是這道門最重要的警衛。

Q3: 我一定要用 Composer 跟外部函式庫才能在 WordPress 裡做 JSON Schema 驗證嗎?

A: 雖然你可以自己手刻驗證邏輯,但這非常耗時且容易出錯。JSON Schema 規範本身有很多細節,使用像 `justinrainbow/json-schema` 這樣經過社群考驗的成熟函式庫,是最有效率且最穩健的做法。而 Composer 是現代 PHP 開發管理相依性的標準工具,強烈建議所有 WordPress 開發者都應該學習使用。

Q4: JSON Schema 可以用在 Gutenberg 區塊開發上嗎?

A: 絕佳的問題!當然可以。Gutenberg 區塊的屬性 (attributes) 定義,其概念就和 JSON Schema 非常相似。雖然 `block.json` 裡的 `attributes` 語法不完全等同於 JSON Schema,但其精神是相通的:預先定義資料的型別與結構。你可以在儲存區塊資料時,或透過 API 傳遞區塊資料時,使用 JSON Schema 來做一層額外的驗證,確保資料的完整性。

 
立即諮詢,索取免費1年網站保固