WordPress 4.6のHTTP APIはresponse headerの表記に頼らず取得結果を確認する

themeやpluginが外部serviceから情報を取るとき、取得に成功したかどうかは、画面へ文字が出たかだけでは判断できません。WordPress 4.6ではHTTP APIがRequests libraryを使うようになります。response headerの大文字小文字、通信error、返ってきた内容、表示する値を分けて確認します。

4.6のHTTP APIはHTTP standardの対応を改善し、case-insensitive headers、parallel HTTP requests、internationalized domain namesを扱います。headerのContent-Typeをcontent-typeとして返すserverもあります。特定の表記だけを前提にしたthemeやpluginは、更新後にheaderを読めず、外部情報が取れないように見えることがあります。

外部serviceの値を表示する機能では、通信の失敗が利用者の判断に直結します。予約状況が取れなければ、空きがあると案内してよいのかを決める必要があります。価格が取れなければ、古い価格を残すのか、確認中と出すのかを決めます。HTTP APIの更新を確認するときは、requestが通るかだけでなく、値を取れないときに何を表示するかまで見ます。

通信の成功と表示する内容を分ける

外部serviceを使う機能は、少なくとも四段階に分けて確認します。

説明用の仮例として、外部の予約状況をWordPressへ表示する場合を考えます。HTTP requestが200で返っても、bodyが空、形式が違う、古い値のままなら、予約可能と案内してはいけません。通信の結果、読み取ったdata、表示する案内、更新できなかった場合の表示を別に決めます。

たとえば、外部serviceが予約件数を返し、themeが「残り3枠」と表示する場合を考えます。status codeが200でも、bodyの中に値がなければ三枠とは書けません。値が文字列として返り、数字として読めなければ、計算に使う前に止めます。前回取得した値を表示し続けるなら、それがいつの値かを利用者へ示すか、担当者だけが確認できるようにするかを決めます。

response headerは、bodyをどう読むか、更新時刻をどう扱うかを判断する手掛かりになることがあります。しかし、headerがあることと、本文の値が正しいことは別です。Content-Typeの表記が大文字でも小文字でも読めるかを確認し、期待する形式でないbodyが返った場合の処理も試します。header名の文字列だけを比較して、bodyを確認しない状態にしません。

外部URLが別のURLへ移る場合もあります。古いendpointから新しいendpointへredirectされても、最終的に期待したserviceの値を取れているかを確認します。ログイン画面やerror pageのHTMLを200として受け取る場合もあるため、status codeだけで成功と決めません。request先、最終的に読んだbody、表示した値を同じ記録で確認します。

internationalized domain namesを使う外部URLでは、管理画面へ入力したURLと通信時に扱う名前の違いが問題になることがあります。URLを貼り付けて一度成功したからといって、別のserver環境でも同じとは限りません。対象のURL、利用する環境、成功した時刻、失敗したときの表示を残します。外部serviceの名称とURLの表記を混ぜずに管理します。

header名を文字列で決め打ちしない

response headerを読む処理は、serverが返す大文字小文字だけへ依存しません。4.6の更新前に、次の順で確認します。sourceの中でwp_remote_get()を探すときは、themeだけでなくplugin、独自のwidget、cronで動く処理も確認します。公開pageに見えない処理でも、外部dataを保存したりmailを送ったりしている場合があります。

1. themeとpluginでwp_remote_get()などHTTP APIを使う箇所を探す。
2. 外部URL、request method、必要なheaderを一覧にする。
3. status code、body、必要なresponse headerを別に確認する。
4. header名の表記が違っても処理できるかtestする。
5. 通信errorまたは予想外のdataが返ったとき、公開画面で何を表示するか決める。

説明用の仮例として、weather dataと予約状況を同じpageへ出す場合を考えます。一方のrequestが成功し、もう一方が失敗することがあります。二つをまとめて「更新失敗」とだけ出すと、どちらの案内を止めるべきか分かりません。requestごとにURL、期待するbody、失敗時の表示を持ち、公開pageでは必要な案内だけを変えます。複数の外部serviceを一つの成功表示へまとめません。

同時に複数requestを扱えることは、無制限に外部serviceへ問い合わせてよい理由にはなりません。外部側の利用条件、失敗時の待ち時間、cacheする値、利用者へ出す案内を決めます。pageを開くたびに外部serviceへ問い合わせると、相手の応答が遅いときに自分のpageも遅くなります。cacheを使うなら、保存期間と古い値を表示する条件を決め、更新できなかった場合を確認します。

testでは、成功するresponseだけを用意して終わりにしません。networkがつながらない場合、status codeが期待と違う場合、bodyが空の場合、headerの表記が違う場合、値が欠けている場合を分けて試します。画面にtechnicalなerrorをそのまま出す必要はありませんが、利用者が誤った行動を取らない案内を出します。管理者が原因を調べるための記録と、公開画面の文言を同じにしません。

更新後に表示が空になった場合、すぐにbodyの解析処理を書き替える前に、requestがどこまで届いたかを見ます。request URL、status code、header、body、dataの読み取り、画面表示の順に確認すると、問題の場所を絞れます。外部serviceが値を変えたのか、WordPress側のheader処理が変わったのか、themeの表示条件が違うのかを、一つずつ分けます。

通信処理の実装と外部情報の承認を分ける

制作側はHTTP APIの呼び出しを修正できます。しかし、外部serviceから得た営業時間、在庫、価格、予約状況をsiteへ表示してよいか、更新できなかったときどう案内するかは、事業側が決めます。通信できることと、外部情報を現在の案内として出せることは別です。外部dataを自動で表示するほど、更新できなかったときの説明を事前に決めます。

制作側へ頼むときは、外部URL、requestの目的、期待するresponse、表示する値、cache、失敗時の表示、確認する公開URLを渡します。制作側はrequestとresponse、dataの処理、公開画面を確認します。事業側は、値が古いときに表示を続けるか、受付を止めるか、利用者へ何を案内するかを決めます。外部serviceの条件が変わったとき、誰が確認するかも残します。

最初の一手は、外部URLを一つ選び、request、期待するresponse、表示する値、cache、失敗時の表示を五行に分けることです。次に、正常なresponse、header表記が違うresponse、空のbody、通信errorを用意し、公開画面がどう変わるかを確認します。五つが決まってから更新後のtestを行います。WordPress 4.6のHTTP API対応は通信を成功させるだけでなく、外部dataを誤った案内に変えないための確認です。