ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
切り替える前にプロバイダー間のエラーコードを対応付ける
移行では、成功時のレスポンスが最も注目されます。デモで見せるのも、最初のテストで通常確認するのも成功時のレスポンスだからです。エラーレスポンスははるかに注目されませんが、それはまったく逆です。アプリケーションの裏でプロバイダーが変わったとき、本番環境で最初に、そして最も目に見える形で壊れるのは、多くの場合エラー処理のコードだからです。
ジオコーディングや位置データのプロバイダーには、それぞれ失敗を通知するための独自の慣習があります。HTTPステータスコードだけを使うもの、ステータス200のJSONレスポンスの中にステータスフィールドを埋め込むもの、「結果が見つからない」と「無効なリクエスト」を異なるコードで区別するもの、両方を汎用的なエラーにまとめてしまうものなどです。アプリケーションの再試行ロジック、ユーザー向けのエラーメッセージ、監視アラートは、通常すべて特定の1つのプロバイダーのエラーの慣習を前提に作られており、その依存関係を誰も明示的に文書化していないこともあります。
プロバイダーを切り替える前に、旧プロバイダーと新プロバイダーのエラーレスポンスを明示的に対応付ける表を作っておく価値があります。少なくとも次の項目を含めてください。
- 有効だが一致しないクエリで結果が見つからない場合(形式が不正なリクエストや無効なリクエストとは区別して)
- レート制限の超過と、レスポンスにいつ再試行すべきかの情報が含まれるかどうか
- 期限切れ、欠落、形式不正の認証情報を含む認証エラー
- プロバイダー側のサーバーエラー(クライアント側のリクエストエラーとは区別して)
- コードが名前や番号で明示的に確認している、プロバイダー固有のステータス値
My Geocodeは、エラーレスポンスとステータスの慣習を/docs/errors/で文書化しています。また、すべてのレスポンスには割り当てヘッダー(X-Quota-Limit、X-Quota-Used、X-Quota-Free-Remaining、X-Quota-Network-Used、X-Credits-Remaining、X-Key-IPs-Used、X-Key-IPs-Limit、X-Quota-Reset)が含まれています。これらは割り当てとレートの状況という種類の情報をカバーしており、プロバイダーによってはヘッダーで直接公開せず、エラーレスポンスの本文に埋もれさせているものです。現在の再試行ロジックが割り当て情報をレスポンス本文から解析しているのか、ヘッダーから解析しているのかを確認することは、移行チェックリストに加える具体的な項目として適しています。ヘッダーベースの割り当て情報は、実際のデータに使うレスポンスの解析処理に手を加えずに読み取れるため、一般的に扱いやすいからです。
対応表を作る実践的な方法は、ドキュメントだけに頼るのではなく、テスト環境で旧プロバイダーと新プロバイダーの両方に対して各エラー条件を意図的に発生させることです。どのプロバイダーでも、ドキュメントと実際の動作が常に完全に一致するとは限らないからです。形式が不正なリクエストを送り、小さなテスト用の割り当てを意図的に使い切り、無効なキーを送って、それぞれのケースで各プロバイダーが何を返すかを正確に記録してください。
この種のエラーの対応付け作業は、目に見える機能を生み出さないため、移行のプロジェクト計画にはほとんど登場しません。しかし、移行が後からどのように記憶されるかについては、不釣り合いなほど大きな影響を持ちます。成功時のレスポンスはきれいに切り替わったもののエラー処理が壊れたままの移行は、切り替え後の最初の数週間で、正常系が部分的にしか正しくなかった移行よりもはるかに多くのサポートチケットを生みがちです。