WordPressのカスタムフィールドをREST APIで安全に扱う設計ガイド

投稿に「開催日」や「外部サービスの識別子」など、標準項目だけでは足りない情報を持たせたいことがあります。カスタムフィールドをREST APIから使えるようにすれば、編集画面や外部の表示システムとの連携にも役立ちます。ただし、登録すれば自動で安全に使えるわけではありません。保存場所と公開範囲を先に決めておくのがポイントです。

機能はテーマではなくプラグインに置く

独自の投稿タイプや、サイト固有のデータ構造は、テーマではなく専用プラグインに登録するのがおすすめです。テーマを変更しても、投稿タイプや保存データを引き続き扱えるためです。デザインや表示方法に限る処理はテーマ側、コンテンツの仕組みはプラグイン側、と分けると保守しやすくなります。

カスタム投稿タイプはWordPressの標準APIで登録し、REST APIから扱う場合は、投稿タイプ自体をREST APIに公開する設定が必要です。REST APIに出すことは、誰にでも編集を許すこととは別です。公開・閲覧・編集の権限は、それぞれ分けて考えます。

メタ情報は型と権限をセットで登録する

既存のカスタムフィールドをREST APIに公開するなら、メタ情報を登録するWordPress標準APIを使い、データ型や単一値かどうか、REST APIでのスキーマを明示します。スキーマは、たとえば日付を文字列として扱うのか、数値として扱うのかをAPI側に伝える設計情報です。値の形式が決まっていると、入力ミスや連携先との解釈違いを減らせます。

更新できるメタ情報には、ユーザー権限を確認する処理も必要です。ログインしていることだけを理由に更新を許可せず、その投稿を編集できる利用者かどうかを確認します。読み取りだけを公開する情報と、編集可能な情報を混在させないようにしましょう。

また、投稿タイプをREST APIで扱えるようにしただけで、独自メタ情報も自動で利用できるとは限りません。メタ情報の登録内容、投稿タイプの設定、利用者の権限を一緒に確認するのが近道です。

サニタイズとエスケープは役割が違う

入力時には、受け付ける値の形式を検証し、保存に適した形へ整えます。これが検証・サニタイズです。一方、画面に表示するときは、HTMLなど出力先に合わせてエスケープします。保存時に整えたから表示時の対策は不要、というわけではありません。

REST APIのCookie認証を使う管理画面では、ログインCookieに加えてnonceを送信します。ただし、nonceは操作権限の確認を代替しません。nonceの検証と、編集権限の確認を両方行う設計にしてください。公開情報を取得するだけのAPIと、データを変更するAPIも分けて検討します。

実装後は編集画面とAPIの両方を試す

開発時は、まず検証環境で次の項目を確かめます。

想定した投稿タイプだけがREST APIに表示されるか
カスタムフィールドの値が指定した型で読み書きできるか
権限のない利用者が値を変更できないか
空欄や不正な形式の値を送ったとき、適切に拒否または処理されるか
テーマを切り替えても投稿タイプと保存データを維持できるか

設定変更やデータ移行を伴う場合は、事前にバックアップを取り、本番環境へ直接適用する前に検証してください。REST API連携は、独自の画面や外部サービスにデータを渡す便利な土台になります。投稿タイプ、メタ情報、権限をひとまとまりで設計し、必要な情報だけを必要な相手に公開することが、安全で長持ちする実装につながります。