上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
郵便番号、市区町村、地域の入力欄が分かれている配送フォームは、1つの郵便番号からすでにわかることが多い情報を顧客に入力させています。
顧客が郵便番号を入力し終えて国を選択したら、またはアカウントから国がすでにわかっている場合は、その両方を/v1/postcodeに送信します。
GET /v1/postcode?code=SW1A 1AA&country=GB{
"status": "ok",
"postcode": "SW1A 1AA",
"country_code": "GB",
"results": [
{"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London", "country": "GB"}}
]
}結果のcomponentsオブジェクトから市区町村と地域の欄に直接入力し、入力欄を完全にロックするのではなく、顧客が確認または修正できるようにしてください。郵便番号がまれに境界をまたいでいたり、一般的に使われる複数の地名にまたがっていたりすることがあるためです。
同じ検索は、配送フォームだけでなく、税額計算のために顧客の地域が必要な新規登録フォームや請求フォームにも適しています。請求先の郵便番号が入力された時点で同じ郵便番号検索を実行すれば、まったく同じリクエストとレスポンスの形を使って、どちらの場面でも地域の欄を一貫して埋められます。そのため、同じクライアント側とサーバー側の処理コードで両方のフォームに対応できます。
検索は、キーを押すたびではなく、郵便番号の入力欄からフォーカスが外れたとき、または選択した国で想定される桁数に達したときに実行してください。郵便番号は完全に入力されて初めて検索する意味があるからです。こうすれば、この機能は入力した文字ごとに1リクエストではなく、入力欄の入力が完了するごとに1リクエストで済みます。
すべての国の郵便番号の形式に対して、想定する桁数を固定でハードコードしないでください。ある国では通用する5桁という前提は、桁数が異なる国や、上の例のような英数字の形式を使う国では、検索が早すぎるタイミングで実行されたり、まったく実行されなかったりする原因になります。桁数にかかわらずフォーカスが外れたときに実行するか、最もよく対応する国で早めに実行したい場合は、国ごとの桁数を記した小さな表を管理してください。
空のresults配列は、その国ではその郵便番号が認識されなかったことを意味し、原因はたいてい入力ミスです。フォーム送信をブロックするのではなく、市区町村と地域の欄を空欄のままにして、顧客に手入力してもらってください。自動入力が失敗したからといって入力欄をそのまま拒否するのは、その場合に限って手入力をお願いするよりも悪い体験になるからです。
郵便番号によっては、地元で複数の地名で呼ばれる地域を正当に含んでいたり、一般的に使われる2つの市区町村名のちょうど境界にあったりします。その場合、返された値を固定のラベルではなく編集可能な候補として表示すれば、どちらかの名前を他方より公式またはそうでないと扱うことなく、顧客が実際に使っている名前に修正できます。
郵便番号からの自動入力で得られるのは地域レベルの位置であり、市区町村と地域の欄には十分です。しかし、顧客がさらに番地まで含む住所を入力したら、その完全な住所を/v1/forwardで処理することで、配送ラベルや配送ルートのシステムが実際に必要とする正確な座標を取得できます。
郵便番号の入力欄の入力が1回完了するごとに1リクエストが発生します。1日に多くの注文を処理する配送フォームでも、この機能の利用はキーを押すたびではなく注文ごとに1回の検索という控えめなペースです。そのため、ほとんどのストアでは、すべてのキーに含まれる1日あたりの無料リクエスト2,500件の範囲内に十分収まります。
郵便番号から市区町村と地域を自動入力すれば、有効な郵便番号を入力する大多数の顧客にとって、配送フォームの入力欄が2つ減ります。フィールドの定義の詳細は郵便番号検索のドキュメントにあります。