WordPress 4.4のREST API基盤は導入済みpluginとの互換性を先に確かめる
公開日: 執筆:佐藤
WordPress 4.4へ更新する前に、REST APIプラグインや独自の外部連携を使っているサイトは、プラグインの版と連携の入口を確認します。4.4へ入るのはREST APIの基盤であって、投稿や利用者などを読み書きするためのエンドポイント一式ではありません。基盤がコアへ入ることと、既存のAPI連携が動き続けること、新しい連携をすぐ作れることは別の話です。
更新の対象をWordPress本体だけと考えると、管理画面に入れた時点で終わりにしがちです。APIを使うサイトでは、WordPress側のプラグイン、外部サービスの受け口、認証情報、送受信するデータ、確認できる担当者がそろって初めて連携が動きます。更新前に全体を一枚へ書き出し、どの操作で確認するかを決めます。
4.4へ入るのは作るための基盤である
WordPress公式のREST API案内によれば、4.4のコアへ入るのは、ルーティング、引数の扱い、JSONの変換、ステータスコードなどを扱う基盤です。独自のREST APIを作る人にとっては土台になりますが、標準データを利用するためのエンドポイントは引き続きプラグインで提供されます。
この区別は、発注時にも重要です。「WordPress 4.4ならREST APIが使える」という説明だけでは、何を取り出せるのか、どのURLへ送るのか、外部の画面を誰が確認するのかが分かりません。投稿を外部アプリへ渡したいのか、外部の在庫を表示したいのか、社内の画面からWordPressを更新したいのかで、必要なエンドポイントと認証は変わります。基盤があることは出発点であって、連携の完成ではありません。
4.4の投稿埋め込み機能も、この基盤を使います。しかし、投稿を埋め込めるようになったことと、自社の独自データを外部サービスと連携できることも別です。テーマの表示確認と、独自連携の送受信確認を、同じ「REST API対応」という言葉でまとめない方が安全です。
先に確認するのはREST APIプラグインの版である
4.4の公式資料では、REST APIプラグインの2.0 beta 1からbeta 4は4.4と互換ではなく、beta 5以降へ更新してから4.4へ進むよう案内しています。古い2.0 betaを残したまま4.4へ上げると致命的なエラーになるとされています。バージョン1を使うサイトも、エンドポイントが動かなくなる可能性があるため、プラグイン側の互換版と移行方針を確認する必要があります。
ここで見るのは、プラグイン名だけではありません。管理画面のプラグイン一覧で、次を記録します。
| 記録するもの | 確認する理由 |
|---|---|
| REST APIプラグインの名称と版 | 4.4と組み合わせられる版かを判断するため |
| 有効化の有無 | 有効なコードだけでなく、停止中の連携設定も確認するため |
| 独自プラグインとテーマの名称 | APIを呼ぶ処理や独自エンドポイントの所在を探すため |
| 使うURLと認証の種類 | 更新後に同じ入口へ送受信できるか確かめるため |
| 連携先の管理者 | 障害時に相手側の受信結果を確認できるようにするため |
認証も一括りにしません。4.4の基盤だけで使えるのは、ログイン中の利用者を前提にしたcookie認証です。外部から使う認証は、OAuth 1プラグインや、ローカル開発用のBasic Authプラグインなど、別の仕組みを使います。認証の情報を更新作業者だけが持ち、サイト側に残さない状態では、動作確認も引継ぎもできません。どのアカウントで管理し、誰が更新できるかを確認します。
動くかどうかは、一往復のデータで確かめる
更新後に管理画面を開けても、外部連携が正常とは限りません。連携の目的に応じて、一件だけ実際に往復させます。たとえば、WordPressの投稿を外部サービスへ送る連携なら、下書きか確認用の記事を一件用意し、WordPressでの操作、送信記録、相手側で受け取った題名と本文を順に確かめます。
外部からWordPressへデータを入れる連携なら、確認用の値がどの投稿、商品、利用者へ反映されるかを先に決めます。実運用のデータをいきなり使わず、元へ戻せる対象を選びます。結果を見る担当者は、WordPress側だけでは足りません。受け取る側の画面またはログを見られる人を、更新前に決めます。
| 連携の種類 | 更新後に確かめる一往復 |
|---|---|
| WordPressから外部へ送る | 確認用の投稿または問い合わせを送り、相手側の受信内容を確かめる |
| 外部からWordPressへ入れる | 確認用の値を送り、保存先と公開画面を確かめる |
| WordPress内の独自エンドポイント | 指定したURL、返るJSON、画面で使う値を確かめる |
| 埋め込み表示 | 埋め込み元と表示先を開き、本文とリンクが意図どおりかを見る |
送受信を試せない事情があるなら、何を確認できていないかを残します。その状態で「更新完了」とは扱いません。止めてよい連携と止められない連携を分け、復旧できるバックアップと戻す担当者を決めてから更新します。
新しい基盤を理由に連携を増やさない
REST APIの基盤が入ったことを機に、連携を増やしたくなるかもしれません。ただし、APIを増やすと、URL、認証、入力内容、障害時の連絡先、更新責任も増えます。既存の連携を確認できていない段階で、新しい連携まで同時に始めると、問題が4.4の更新によるものか、新しい実装によるものかを分けられません。
まずは使っている連携を一つずつ動かし、管理するアカウントとデータの保存先を明らかにします。新規のAPIは、その後に目的、必要なデータ、公開範囲、更新する人を決めて作ります。
最初の一手は、管理画面のプラグイン一覧でREST APIに関係するプラグインを探し、名称、版、連携先、確認担当者を一行ずつ書き出すことです。
関連記事

