上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
チェックアウトフォームは、他のどの入力欄よりも住所欄で失敗することが多く、その原因はたいてい顧客が通りの名前を打ち間違えたり、部屋番号を書き忘れたりすることです。入力中に実在する住所を候補として表示すれば、その大半は配送失敗になる前に解決できます。
/v1/autocompleteエンドポイントは、部分的なテキストと、返す候補の数の上限を受け取ります。顧客が数文字入力したら、入力に合わせて呼び出します。
GET /v1/autocomplete?q=221B Baker&limit=5{
"status": "ok",
"query": "221B Baker",
"suggestions": [
{"text": "221B Baker Street, London, UK", "place_id": "abc123"},
{"text": "221B Baker Avenue, Springfield", "place_id": "abc124"}
]
}候補は短いラベルとplace_idであり、完全な住所レコードではありません。顧客が候補を選んだら、その候補のテキストを/v1/forwardに渡して、構成要素と座標を含む完全な住所に解決します。フォームの通り、市区町村、地域、郵便番号の欄を埋めるのは、この2回目の呼び出しです。
GET /v1/forward?q=221B Baker Street, London, UK&limit=1componentsオブジェクトが実際に現れるのはこの2回目のリクエストです。/v1/autocompleteが返すのは常にテキストラベルとplace_idだけで、通り、市区町村、郵便番号の内訳は返さないからです。この手順を省いて候補のテキストを自分で解析しようとするのは、見た目以上に壊れやすい方法です。書式は国によって異なるためです。
キーを押すたびにリクエストを送ると、混雑したチェックアウトページではすぐに件数が膨らみます。入力欄にデバウンスを設定して、顧客が少し入力を止めたときだけリクエストを送るようにし、候補がどのみち役に立たない3〜4文字未満の入力ではリクエストを省いてください。オートコンプリートの呼び出しと、その後のジオコーディングの呼び出しは、それぞれ1日の割り当てに対して1リクエストとしてカウントされます。そのため、デバウンスを設定した入力欄であれば、混雑したストアでも、すべてのキーに含まれる1日あたりの無料リクエスト2,500件の範囲内に十分収まります。
空のsuggestions配列は正常なレスポンスであり、エラーではありません。候補が選ばれるまでフォーム送信をブロックするのではなく、顧客にそのまま入力を続けてもらい、数文字入力しても有用な候補が返らなければ、通常のテキストの住所欄にフォールバックしてください。
クリックされた候補を、完成した検証済みの住所として扱うのはよくある手抜きですが、後で問題の原因になります。顧客は候補を選んだ後も入力欄を編集し続け、番地を変えたり、元の候補になかった部屋番号を追加したりすることがあります。候補がクリックされた時点だけでなく、送信時に必ず入力欄の最終的なテキストを/v1/forwardで解決してください。そうすれば、保存する住所は実際に入力欄に残った内容を反映します。
チェックアウトフォームで郵便番号も別に入力してもらう場合は、住所が解決された時点で/v1/postcodeを一度呼び出すと、住所の他の部分と一致しない郵便番号を低コストで見つけられます。両方がそのまま送信されて、後で配送の不一致を引き起こす前に対処できます。
オートコンプリートは検証の代わりにはなりません。そもそも誤った住所が注文システムに届く可能性を下げるだけです。チェックアウトの流れに組み込む前に、住所オートコンプリートのドキュメントでパラメーターの一覧を確認してください。