Questo documento descrive una serie di scenari reali in cui l'API Address Validation fornisce indicatori di risposta per gli indirizzi che garantiscono un comportamento di conferma da parte del tuo sistema. Consulta la panoramica del flusso di lavoro in Creare la logica di convalida per il contesto.
Esempi comuni: conferma
L'esempio seguente illustra il caso di aree metropolitane con nomi di vie simili. Supponiamo che un utente intenda inserire l'indirizzo dell'edificio Google D a Kirkland, WA, Stati Uniti. Tuttavia, invece di Kirkland come città, entrano inavvertitamente a Seattle.
| Indirizzo inserito | Regione |
|---|---|
| Building D, 451 7th Avenue South, Seattle, WA 98033 | US |
Esito per i dati sostituiti
L'esempio seguente enfatizza gli indicatori importanti della risposta.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY indica l'approssimazione di un indirizzo a livello di edificio, ma
non è così dettagliato come SUB_PREMISE, che è la granularità fornita nell'input.
La risposta contiene anche componenti non confermati e sostituiti, quindi la combinazione lo inserisce nella categoria confirm.
Una query sui componenti dell'indirizzo rivela le seguenti aree di interesse:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
In questo caso, l'API Address Validation ha trovato un'approssimazione molto simile all'indirizzo fornito a Seattle e ha sostituito il codice postale, un componente di livello superiore, per risolvere un indirizzo di Seattle. Potrebbe trattarsi di una sostituzione valida, ma oltre al fatto che i componenti non sono stati confermati, ha senso assicurarsi che l'utente intenda inserire un indirizzo di Seattle e non qualcos'altro, come Kirkland.
Esempi di casi limite: conferma
I seguenti esempi illustrano i seguenti tipi di casi limite:
- Inferenze minori che SONO confermate. L'API Address Validation deduce il paese, il codice postale o lo stato, ma tutto il resto viene fornito e confermato. La combinazione di granularità e livello di conferma garantisce una minore inferenza che non richiede necessariamente un'azione di conferma.
- Componente dell'indirizzo imprevisto NON confermato. I componenti dell'indirizzo non confermato aumentano il livello di rischio dell'indirizzo. Questo potrebbe richiedere una conferma.
- Componente dell'indirizzo imprevisto che è stato confermato. L'indirizzo corretto non è strettamente necessario per il componente e l'API Address Validation lo rimuove dall'output. I problemi di formattazione generalmente non richiedono una conferma.
Inferenze minori che SONO confermate
Quando combinata con i dati confermati di un livello più granulare, l'API pu�� comunque fare un'inferenza corretta se nell'input manca solo un componente dei seguenti tipi:
- Città
- Stato
- Codice postale
- Paese
Ad esempio, un cliente fornisce un indirizzo valido per un ristorante McDonald's a Springfield, nel Massachusetts, ma dimentica di inserire la città e fornisce un codice postale senza l'estensione di 4 cifre.
| Indirizzo inserito | Regione |
|---|---|
| 1402 Allen St, MA 01118 | US |
Verdetto per la città mancante
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
Nei casi in cui l'API Address Validation deduce componenti di livello superiore per produrre un indirizzo di consegna, puoi avere un livello più elevato di certezza che i dati del sistema siano corretti. Questo perché i componenti dedotti che rappresentano un'ampia area geografica vengono abbinati più facilmente ai componenti dell'indirizzo confermato che sono più granulari. Anche nei paesi in cui i nomi delle città sono ripetuti, come Springfield negli Stati Uniti, gli altri componenti possono fornire un indirizzo univoco.
Utilizzando l'esempio precedente, un'analisi di tutti i componenti degli indirizzi mostra che ogni componente è confermato, il che significa che corrisponde ai dati archiviati dall'API Address Validation e che il servizio deduce anche due componenti di livello superiore.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
Componente dell'indirizzo imprevisto NON confermato
Questo scenario illustra l'importanza di controllare quando i componenti non vengono confermati. Se un componente dell'indirizzo è imprevisto, l'API Address Validation lo rimuove dall'output. In questi casi, puoi accettare l'indirizzo o riconfermarlo con il cliente, a seconda del livello di rischio e di confidenza.
Ad esempio, un indirizzo potrebbe provenire da una regione in cui i clienti spesso inseriscono informazioni innocue ignorate dall'autorità postale, nel qual caso accetteresti l'indirizzo. Tuttavia, in alcuni casi, un componente non confermato potrebbe non essere ciò che vuole il cliente.
| Indirizzo inserito | Regione |
|---|---|
| 1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry | Francia |
Verdetto per il componente dell'indirizzo imprevisto non confermato
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
Oltre a un esito con componenti non confermati, l'API Address Validation restituisce il seguente indirizzo formattato:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
Un'analisi dei componenti non confermati mostra che l'API ha rimosso la caritat 2 dall'indirizzo restituito:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
Componente dell'indirizzo imprevisto che è stato confermato
Questo esempio illustra l'inclusione di una contea del Regno Unito nell'indirizzo fornito, che è una pratica comune. Tuttavia, questo non è un requisito dell'autorità postale britannica ed è essenzialmente ignorato. Consulta postoffice.co.uk e come gestire la posta del Regno Unito e internazionale.
Di conseguenza, quando un cliente fornisce una contea in un indirizzo del Regno Unito, il servizio valuta come input imprevisto.
| Indirizzo inserito | Regione |
|---|---|
| 33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | Regno Unito |
Verdetto per il componente dell'indirizzo imprevisto che è stato confermato
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
In questo caso, address_complete restituisce false e un'analisi del componente dell'indirizzo rivela un flag imprevisto.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
Mentre Gloucestershire è la contea corretta per l'indirizzo inserito, l'indirizzo stesso non è formattato correttamente. Ricorda che l'API Address Validation valuta anche le informazioni per una corretta formattazione.