WordPress 4.7のREST APIは外部アプリを作る前に公開するdataと更新する権限を分ける
公開日： 執筆：佐藤
WordPress 4.7には、投稿、固定page、media、comment、term、userなどのcontentを外部のprogramから扱うためのREST API content endpointが入っています。連携を作る前に、何を公開してよいかと、誰が更新できるかを分けて決めてください。dataを読めるようにすることと、dataを書き換えられるようにすることは、同じ作業ではありません。
REST APIは、WordPressの投稿dataを別の画面やapplicationで使えるようにする基盤です。便利に見えるため、まず画面を作りたくなります。しかし、公開範囲、更新権限、dataの正本、連携を止めたときの扱いが決まっていなければ、外部画面を増やしても運用できません。siteを更新する人が何を承認し、外部の制作者がどこまで操作できるかを先に決めます。
content endpointで扱うdataと公開してよいdataは別である
WordPressの公式開発資料では、4.7のcontent endpointがpost-based data、page、media、comment、term、userを扱うことを説明しています。これは、全てのdataを誰でも公開してよいという意味ではありません。WordPressが扱えるdataの種類と、事業者が外部へ見せると決めたdataを分けます。
たとえば、会社案内の固定pageと、公開済みのお知らせを別のapplicationへ表示する場合を考えます。title、本文、公開URL、掲載日を読むだけなら、外部画面でどの情報を見せるかを決めれば足ります。一方、下書き、社内用のメモ、非公開の連絡先、編集途中の画像まで同じように表示してよいとは限りません。外部画面が表示できることを理由に、公開範囲を広げません。
| data | 外部表示を検討する前に決めること | 直接結び付けないもの |
|---|---|---|
| 公開済みの投稿 | どのcategory、title、本文、URLを出すか | 下書きや非公開の編集情報 |
| 固定page | 会社案内やサービス説明の正本がどこか | 編集途中の文章 |
| media | 表示する画像と利用範囲 | 原fileや管理用の説明 |
| comment | 外部表示が必要か、承認済みか | 問い合わせ内容や削除済みの記録 |
| user | 著者として出す名前と説明 | loginに使う情報や管理上の情報 |
説明用の仮例として、WordPressで更新するお知らせを店舗の案内用applicationへ表示する場合を考えます。application側は公開済みのお知らせのtitle、本文、URLだけを表示します。投稿の下書きや、管理画面で入力した補足メモを表示する必要はありません。どのdataが必要かを一行で書き、そのdataだけを扱う設計にします。
dataを絞る理由は、securityだけではありません。外部画面へ出すdataが増えるほど、更新したときの確認範囲も増えます。お知らせの本文だけを表示するなら、投稿を更新したあとにapplication側の見出し、本文、linkを見れば確認できます。category、著者、画像、関連商品、在庫情報まで出すなら、それぞれの更新元と表示の確認が必要です。必要なdataから始めます。
読み取りと更新は権限の考え方が違う
外部applicationが公開済みのcontentを読むことと、WordPressのcontentを作成または更新することは別です。更新する連携には、誰の権限で何を変更するかという問題があります。WordPressの公式資料も、pluginやthemeからcontent endpointを使う場合にcookieとnonceへのアクセスを扱っています。外部のserverやapplicationから更新させる方法まで、4.7で一つに決まるわけではありません。
そのため、外部applicationを作るときは、最初から更新機能を入れません。まずWordPressを正本にし、外部applicationは公開済みdataを読むだけにします。読み取りで必要な画面とdataの関係が確認できたら、更新する必要が本当にあるかを検討します。WordPressの編集画面で十分に更新できるなら、別の編集画面を作ることは、作業を二重にするだけの場合があります。
更新が必要な場合は、次の四つを別々に決めます。
- 更新できる人。担当者の個人accountを共有せず、誰が操作したか分かる状態にする。
- 更新できるdata。お知らせのtitleと本文だけなのか、mediaやcategoryまで含むのかを決める。
- 公開する人。入力した内容をそのまま公開するのか、WordPress側で確認して公開するのかを決める。
- 連携を止める人。委託やapplicationの利用を終えたとき、どの権限を外し、dataをどこに残すかを決める。
外部の制作会社へapplicationを頼む場合も、WordPressの管理者passwordを渡して終わりにしません。制作会社がcodeを直すための権限と、投稿を公開する権限は別です。domain、hosting、WordPressの管理者、外部applicationのsource code、連携に使う設定を、誰が所有し、誰が管理するかを記録します。連携を作る仕事と、WordPressのdataを所有することを混同しません。
dataの正本をWordPressへ残す
お知らせをWordPressと外部applicationの両方で編集できるようにすると、どちらの文章が正しいか分からなくなります。WordPressで電話番号を更新し、application側に古い番号が残れば、利用者は二つの案内を見ます。REST APIを使う場合も、dataを入力する正本を一つに決めます。
通常の会社siteなら、WordPressの投稿または固定pageを正本にし、外部applicationは表示用に読む形から始める方が管理しやすくなります。営業時間、料金、受付条件のように間違えると利用者の行動が変わる情報は、更新する場所を増やしません。どうしても二か所へ入力するなら、どちらを先に直すか、差が出たときにどちらを正しいものとして直すかを決めます。
公開済みdataを取得するapplicationでも、更新の反映時刻を確認します。WordPressで投稿を直した直後に、外部画面が古い内容を表示するなら、利用者へ案内を出す前に反映を待つ必要があります。これはREST APIが使えないという問題ではなく、取得するdata、cache、更新確認の順序を決めていない問題です。実際に投稿を一つ更新し、WordPressの公開URLと外部画面を並べて確認します。
最初の連携は一つの公開dataから始める
最初に作るなら、公開済みのお知らせ一覧のように、dataと表示の関係が単純なものを選びます。title、公開日、本文の一部、WordPressの記事URLを表示し、link先ではWordPressの本文を読めるようにします。この範囲なら、外部applicationへ載せる情報、更新元、利用者が最終的に読むpageを確認できます。
表示が確認できたあとで、画像、category、検索、更新機能を足すかを判断します。画面に多くのdataを出すことは目的ではありません。利用者が必要な案内へ進め、site側が内容を更新できることが目的です。外部applicationを止めても、WordPressの投稿と固定pageが残り、siteを続けられる状態を保ちます。
最初の一手は、外部applicationへ出したいdataを五項目以内で書き、そのdataの正本がWordPressのどの投稿typeにあるかを確認することです。表示するdataと更新する権限を分けてから、endpointを選びます。
関連記事
