WordPress REST APIは公開するdataと認証が必要なdataを分けて設計する

WordPress REST APIを使うときは、外部から読めるdataと、認証した利用者だけが読んだり更新したりできるdataを分けます。APIを有効にすることは、投稿や設定を誰でも変更できるようにすることではありません。先に決めるのは、何を公開済みの情報として渡すか、誰がどの変更を行えるかです。

WordPress 4.7へ提案されているContent APIは、投稿、固定page、media、comment、term、利用者などを扱います。公開アクセスで読めるのは、すでに公開されているdataです。認証した利用者は、自分が持つWordPressの権限に応じて読取りと更新を行います。利用者dataもすべてを公開するのではなく、公開記事の著者に関する一部のdataが対象になります。

APIのURLを知っている人が何でもできる、という考え方は正しくありません。読む操作と書き替える操作では、必要な認証とWordPress側の権限が違います。ただし、認証を使う外部appを作るなら、誰の利用者として接続するかを決める必要があります。管理者の認証を使えば作業は早く見えるかもしれませんが、記事を読むだけのappに管理画面全体の権限まで渡す理由はありません。

公開記事のdataを別画面へ使う場合も、公開画面から読める内容だから無条件に使ってよい、とは限りません。記事一覧を表示する目的なら、title、URL、公開日で足りるかもしれません。著者名を出すなら、記事の責任者を示すためなのか、連絡先まで表示するためなのかを分けます。取得できるdataの量ではなく、利用者へ何を伝えるために必要かで項目を選びます。

読ませるdataと変更させるdataを同じ依頼にしない

説明用の仮例として、会社siteの記事一覧を別の画面へ表示する場合を考えます。公開済みの記事titleとURLを読む機能と、記事本文を更新する機能は同じではありません。前者だけが必要なら、更新するための権限まで外部appへ渡す理由はありません。

反対に、外部appから下書きを更新する必要があるなら、単に「APIを使う」と決めるだけでは足りません。誰の認証で接続するか、どの記事を直せるか、公開まで行えるかを決めます。作成と公開を同じ権限にする必要があるかも別に考えます。下書きを作れる人へ、公開を決める権限まで渡すとは限りません。

説明用の仮例として、営業担当が外出先から記事の下書きを作り、編集担当が公開する仕事を考えます。この場合、下書きの作成と修正に必要な権限と、公開日時を決める権限は分けられます。外部appが下書き作成だけを担当するなら、公開済み記事を上書きする操作まで許可する必要はありません。便利な画面を作ることと、公開の責任を渡すことは別です。

更新を許可するなら、間違って書き替えたときに何を確認するかも決めます。どの記事を変更したか、誰の認証で操作したか、公開前に誰が内容を読むかを残します。API経由の操作は画面上の編集と違って見えても、siteの内容を変える作業であることは同じです。更新できる範囲を広げる前に、少ない対象で作成、確認、公開の順が守れるかを試します。

公開済みだから何でも出してよいわけではない

公開記事の本文がサイト上で読めることと、別の画面でどの項目まで使うかは別です。たとえば、記事一覧を作るなら、記事title、URL、公開日だけで足りる場合があります。著者の詳細、comment、meta dataまで必要かは、表示する目的に応じて決めます。取得できる項目をそのまま使わず、必要なdataだけを選びます。

APIを使う担当者、siteのdataを所有する人、公開を承認する人が別なら、その区別を先に残します。外部appを作る作業と、投稿を公開できる権限を渡すことも別です。接続をやめる場合に誰が権限を取り消すかまで決めれば、使わなくなったappへ権限が残ることを避けられます。

この区別は、外部の制作会社へ依頼するときにも必要です。制作会社がAPIで記事一覧を表示する機能を作る場合、必要なのは公開記事を読む確認かもしれません。記事を更新する機能まで依頼するなら、どの利用者を使うか、納品後に誰が認証を管理するかを確認します。制作を任せても、siteにあるdataと公開の決定まで依頼先だけのものにはなりません。

使わなくなった接続を残すと、後から何のための認証かを判断しにくくなります。外部appの名前、用途、使うdata、接続を管理する人、停止する方法を短く残します。これは難しいセキュリティ手順を増やすためではありません。不要な権限を残したまま、問題が起きたときに誰が止めるか分からなくしないためです。

最初は一つの読み取り用途から始める

REST APIを初めて使うなら、最初は公開記事を読む用途など、一つの目的へ絞ります。

1. 表示したい画面と、外部へ渡す項目を一つずつ決める。
2. その用途に更新権限が必要かを分ける。
3. 更新が不要なら、読み取りだけで動くことを確認する。
4. 更新が必要になったときだけ、認証する利用者、扱う投稿、公開権限を決める。
5. 接続の所有者と、不要になったときの取り消し方法を残す。

WordPress 4.7のContent APIは提案段階です。正式版へ入る前の実装や外部appは、公開範囲、認証、更新権限をtest環境で確認します。最初の一手は、外部へ渡す公開dataを一つ選び、更新が必要かどうかを分けることです。

test環境では、公開記事を読む操作と、下書きを更新する操作を別々に試します。公開記事が取れたからといって、認証した更新が正しく制限されているとは限りません。逆に更新ができないからといって、公開dataまで使えないとは限りません。目的ごとに確認し、必要な操作だけを追加します。一度に投稿、media、利用者情報をつなごうとせず、一つの用途から始めれば、公開範囲と責任を確認しやすくなります。