Membuat logika validasi

Dokumen ini menjelaskan proses pembuatan sistem pemeriksaan alamat untuk menangani berbagai respons dari Address Validation API. Panduan ini mencakup cara membangun logika agar dapat menggunakan respons dengan benar, menyelidiki sinyal lain dari API, serta waktu dan cara meminta informasi lebih lanjut kepada pelanggan.

Secara umum, respons API menentukan cara berikut yang harus dilakukan sistem Anda untuk menangani alamat:

• handyman Perbaiki—alamat berkualitas rendah. Anda harus meminta informasi lebih lanjut.
• edit Konfirmasi—alamat berkualitas tinggi, tetapi memiliki perubahan dari alamat input. Anda mungkin meminta konfirmasi.
• check Terima—alamat berkualitas tinggi. Anda dapat menerima alamat yang diberikan.

Tujuan utama

Dokumen ini membantu Anda memodifikasi sistem untuk menganalisis respons API dengan sebaik-baiknya dan menentukan tindakan berikutnya yang akan diambil dengan alamat yang diberikan. Pseudocode berikut menggambarkan kemungkinan alur.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

Logika tepatnya bergantung pada situasi Anda - lihat Panduan penerapan untuk detail selengkapnya. Anda juga dapat menggunakan implementasi open source kami untuk logika ini, yang ada di Extended Component Library.

Ringkasan alur kerja

Tabel di bawah merangkum dua tindakan untuk sistem Anda:

1. Alur kerja yang akan digunakan berdasarkan perilaku perbaiki, konfirmasi, terima.
2. Sinyal pertama yang akan diperiksa dari respons. Sinyal yang dijelaskan di sini berasal dari properti verdict dan bukan satu-satunya sinyal yang perlu diperiksa, tetapi memberikan indikator awal kualitas alamat. Setiap jenis perilaku sesuai dengan bagian dalam dokumen ini yang menjelaskan sinyal lebih lanjut yang mungkin juga perlu Anda selidiki.

Perilaku sistem Anda
handyman Perbaiki alamat	Respons dari verdict menunjukkan informasi penting yang hilang yang harus diberikan. Alamat yang ditampilkan oleh Address Validation API mungkin tidak memiliki kualitas yang dapat dikirimkan. Alur kerja Selidiki komponen alamat jika perlu. Minta pelanggan untuk memperbaiki masalah alamat. Minta validasi untuk alamat yang diperbarui. (Opsional) Kirim permintaan ke endpoint masukan untuk API. Baca bagian Menangani alamat yang diperbarui. Lanjutkan dengan alamat. Sinyal verdict Salah satu dari hal berikut berlaku: validationGranularity disetel ke OTHER. Lihat nilai tingkat perincian. addressComplete adalah false.
edit Konfirmasi alamat	Respons dari verdict menunjukkan alamat yang dapat dikirim, tetapi telah membuat perubahan pada input asli: menyimpulkan data yang telah dikoreksi ejaan, atau data yang dapat dikonfirmasi. Alur kerja Koreksi yang diperlukan: Selidiki komponen alamat jika perlu. Minta validasi untuk alamat yang diperbarui. (Opsional) Kirim permintaan ke endpoint masukan untuk API. Lihat Menangani alamat yang diperbarui. Lanjutkan dengan alamat. Tidak perlu koreksi: (Opsional) Kirim permintaan ke endpoint masukan untuk API. Lihat Menangani alamat yang diperbarui. Lanjutkan dengan alamat. Sinyal verdict Semua hal berikut berlaku: validationGranularity berisi ROUTE atau yang lebih baik. Lihat nilai tingkat perincian. addressComplete adalah true. Kolom hasInferredComponents adalah true ATAU kolom hasReplacedComponents adalah true.
check Terima alamat	Respons Address Validation API menunjukkan alamat dengan kualitas yang sangat baik. Alur kerja Lanjutkan dengan alamat yang dikembalikan. Sinyal verdict Semua hal berikut berlaku: validationGranularity berisi PREMISE atau lebih baik. Lihat nilai tingkat perincian. addressComplete adalah true. Tidak ada komponen yang disimpulkan atau diganti.

Panduan implementasi

Saat mendesain cara sistem Anda merespons sinyal dari Address Validation API, rekomendasi berikut dapat membantu Anda membuat model respons yang lebih efektif. Namun, ini hanyalah rekomendasi, jadi perlu diingat bahwa penerapan Anda harus sesuai dengan model bisnis Anda.

	Panduan	Detail
Tingkat risiko	Pertimbangkan tingkat toleransi untuk situasi Anda saat menyeimbangkan antara meminta koreksi dan menerima alamat seperti yang dimasukkan.	Address Validation API menampilkan berbagai sinyal yang dapat Anda gabungkan dengan tingkat risiko untuk mengoptimalkan proses validasi. Misalnya, jika alamat memiliki nomor jalan yang belum dikonfirmasi, Anda tetap dapat menerimanya. Di sisi lain, jika operasi bisnis Anda memerlukan presisi alamat yang lebih besar, Anda dapat meminta pengguna. Untuk contoh yang dapat termasuk dalam salah satu kategori tersebut, lihat Nomor jalan non-AS yang tidak dikonfirmasi di Menerima alamat - contoh.
Menerima alamat	Sebaiknya izinkan sistem Anda menerima entri asli jika pelanggan tidak merespons perintah.	Dalam kasus ini, pelanggan mungkin telah memasukkan alamat yang tidak ada dalam sistem, seperti untuk bangunan baru.
Berikan masukan	Saat menerbitkan ulang permintaan validasi alamat, Anda juga dapat mengirim permintaan ke endpoint provideValidationFeedback.	Hal ini memberi tahu Google bagaimana Anda pada akhirnya menangani respons akhir. Baca bagian Menangani alamat yang diperbarui.

Perbaiki alamat

Perbaiki alamat jika hasilnya menunjukkan dengan jelas bahwa alamat tersebut tidak dapat dikirim. Sistem Anda kemudian dapat meminta pelanggan untuk memberikan informasi yang diperlukan, setelah itu Anda menerbitkan ulang alur kerja untuk mendapatkan alamat yang dapat dikirim.

Memperbaiki sinyal

Address Validation API memberikan sejumlah sinyal untuk memberi tahu Anda apakah alamat harus diperbaiki.

1. Tingkat perincian validasi dan komponen yang hilang

Kedua sinyal ini memberikan indikasi terbaik tentang alamat yang bermasalah:

• Setiap kali kolom validationGranularity adalah OTHER, sistem Anda harus menyelidiki sinyal komponen alamat untuk mempelajari lebih lanjut tempat terjadinya error dan cara memperbaikinya.
• Setiap kali objek address pasca-pemrosesan menampilkan kolom missingComponentTypes, sistem Anda harus memeriksa komponen tersebut. Komponen yang tidak ada juga akan membuat alamat tidak lengkap dan tidak dapat dikirim.

2. Sinyal lainnya

Address Validation API juga memberikan sinyal lain untuk membantu mendiagnosis masalah tertentu:

Komponen yang mencurigakan	Jika enum tingkat konfirmasi untuk komponen adalah UNCOMFIRMED_AND_SUSPICIOUS, kemungkinan komponen tersebut salah.
Komponen yang tidak terselesaikan	unresolvedToken adalah bagian dari input yang tidak dikenali sebagai bagian alamat yang valid.

3. Sinyal alamat AS

Kolom tertentu yang hanya berlaku untuk alamat AS memberikan sinyal yang berguna bahwa alamat tersebut tidak dapat dikirim dan harus diperbaiki. Untuk alamat yang memerlukan perbaikan, Anda akan melihat hal berikut:

dpvConfirmation	Berupa N, D, atau kosong.

Untuk mengetahui detail tentang dpvConfirmation, lihat Menangani alamat Amerika Serikat.

Memperbaiki contoh alamat

Mengonfirmasi alamat

Anda mengonfirmasi alamat saat verdict menunjukkan bahwa Address Validation API menyimpulkan atau membuat perubahan pada komponen alamat untuk menghasilkan alamat yang divalidasi. Dalam hal ini, Anda memiliki alamat tujuan, tetapi lebih memilih bahwa alamat yang dihasilkan adalah alamat yang dituju pelanggan.

Untuk memberikan perintah yang benar kepada pelanggan, logika Anda akan mengidentifikasi komponen yang ditandai oleh layanan untuk menentukan tindakan atau tanda yang diterapkan API ke komponen, seperti inferred, replaced, atau spellCorrected. Lihat AddressComponent dalam referensi.

Konfirmasi sinyal

Address Validation API memberikan sejumlah sinyal untuk memberi tahu Anda apakah alamat harus dikonfirmasi.

1. Tingkat Perincian Validasi

validationGranularity ROUTE atau yang lebih baik dapat diterima, tetapi PREMISE atau SUBPREMISE memberikan sinyal pengiriman yang lebih kuat.

2. Sinyal lainnya

Saat memutuskan untuk mengonfirmasi entri alamat dengan pelanggan, verdict tersebut juga memberikan hal berikut untuk menentukan komponen yang harus diselidiki:

Data yang disimpulkan	Jika kolom hasInferredComponents adalah true, Anda tahu bahwa API mengisi informasi yang diperoleh dari komponen alamat lainnya.
Data yang diganti	Jika kolom hasReplacedComponents adalah true, API akan mengganti data yang dimasukkan dengan data yang dianggapnya membuat alamat valid.

3. Sinyal alamat AS

Beberapa kolom tertentu yang hanya berlaku untuk alamat di AS menunjukkan bahwa logika Anda harus mengonfirmasi detail dengan pelanggan. Salah satu dari hal berikut berlaku:

dpvConfirmation	S Untuk mengetahui detail tentang dpvConfirmation, lihat Menangani alamat Amerika Serikat.
Respons alamat	Berisi kolom missingComponentType dengan nilai subpremise.

Mengonfirmasi contoh alamat

Menerima alamat

Anda menerima alamat saat verdict tersebut memberikan tingkat keyakinan tinggi bahwa alamat tersebut dapat dikirim dan dapat digunakan tanpa interaksi pelanggan lebih lanjut dalam proses downstream.

Terima sinyal

Address Validation API memberikan sejumlah sinyal untuk memberi tahu Anda apakah alamat harus dikonfirmasi.

1. Tingkat Perincian Validasi

validationGranularity PREMISE atau lebih baik dapat diterima, tetapi dalam beberapa kasus, ROUTE masih menunjukkan alamat yang dapat dikirim.

2. Sinyal lainnya

Putusan untuk alamat berkualitas tinggi juga harus menampilkan hal berikut:

• Tidak ada data yang diganti. Dalam hal ini, hasReplacedComponents: FALSE.
• Tidak ada komponen yang disimpulkan. Dalam kasus ini, hasInferredComponents: FALSE.

3. Sinyal alamat AS

Kolom tertentu yang hanya berlaku untuk alamat AS menunjukkan alamat berkualitas tinggi yang dapat dikirimi. Untuk alamat AS yang dapat diterima, Anda akan melihat hal berikut:

dpvConfirmation	Y Untuk mengetahui detail tentang dpvConfirmation, lihat Menangani alamat Amerika Serikat.

Menerima contoh alamat