Создайте свою логику проверки

В этом документе описывается процесс создания системы проверки адресов для обработки различных ответов от API проверки адреса. В нем рассказывается, как построить логику для правильного использования ответа, исследовать другие сигналы API, а также когда и как запрашивать у клиентов дополнительную информацию.

В общем случае ответ API определяет следующие способы обработки адреса вашей системой:

• handyman Исправление — адрес некачественный. Вам следует запросить дополнительную информацию.
• edit Confirm — адрес высокого качества, но имеет изменения по сравнению с входным адресом. Вы можете запросить подтверждение.
• check Accept — адрес высокого качества. Вы можете принять предоставленный адрес.

Основная цель

Этот документ поможет вам изменить вашу систему, чтобы лучше анализировать ответ API и определять следующие действия, которые следует предпринять с предоставленными адресами. Следующий псевдокод иллюстрирует возможный поток.

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.

Точная логика зависит от вашей ситуации — более подробную информацию см . в руководстве по внедрению . Вы также можете использовать нашу реализацию этой логики с открытым исходным кодом, которая находится в расширенной библиотеке компонентов .

Обзор рабочего процесса

В таблице ниже приведены два действия для вашей системы:

1. Используемый рабочий процесс основан на поведении «исправить, подтвердить, принять».
2. Первые сигналы, которые следует проверить из ответа. Описанные здесь сигналы исходят из свойства verdict и не являются единственными сигналами, которые необходимо проверить, они предоставляют начальный индикатор качества адреса. Каждому типу поведения соответствует раздел в этом документе, описывающий дополнительные сигналы, которые вам также может потребоваться изучить.

Руководство по внедрению

При проектировании реакции вашей системы на сигналы API проверки адреса следующие рекомендации помогут вам построить более эффективную модель ответа. Однако это всего лишь рекомендации, поэтому имейте в виду, что ваша реализация должна соответствовать вашей бизнес-модели.

Исправить адрес

Исправьте адрес, если результаты ясно показывают, что адрес не может быть доставлен. Затем ваша система может предложить клиенту предоставить необходимую информацию, после чего вы повторно запускаете рабочий процесс, чтобы получить адрес доставки.

Фиксировать сигналы

API проверки адреса предоставляет ряд сигналов, позволяющих узнать, следует ли исправить адрес.

1. Детализация валидации и недостающие компоненты

Эти два сигнала лучше всего указывают на проблемный адрес:

• Если поле validationGranularity имеет значение OTHER , ваша система должна изучить сигналы компонентов адреса, чтобы узнать больше о том, где произошла ошибка и как ее исправить.
• Всякий раз, когда объект address после постобработки возвращает отсутствующее поле missingComponentTypes , ваша система должна проверить наличие этого компонента. Отсутствие компонентов также делает адрес неполным и невозможным для доставки.

2. Другие сигналы

API проверки адреса также предоставляет другие сигналы, помогающие диагностировать конкретные проблемы:

3. Сигналы адреса США

Некоторые поля, применимые только к адресам в США, дают полезный сигнал о том, что адрес недоступен и его следует исправить. Для адреса, который требует исправления, вы должны увидеть следующее:

Дополнительные сведения о dpvConfirmation см. в разделе Обработка адресов в США .

Примеры исправленных адресов

Подтвердить адрес

Вы подтверждаете адрес, когда вердикт указывает, что API проверки адреса либо вывел, либо внес изменения в компоненты адреса, чтобы создать проверенный адрес. В этих случаях у вас есть адрес доставки, но вы предпочитаете большую уверенность в том, что полученный адрес соответствует замыслу клиента.

Чтобы предоставить клиенту правильные подсказки, ваша логика будет идентифицировать компоненты, помеченные службой, чтобы определить, какое действие или флаг API применил к компоненту, например inferred , replaced или spellCorrected . См. AddressComponent в справочнике.

Подтвердить сигналы

API проверки адреса предоставляет ряд сигналов, позволяющих узнать, следует ли подтвердить адрес.

1. Детализация проверки

Гранулярность validationGranularity ROUTE или выше приемлема, но PREMISE или SUBPREMISE обеспечивают более сильный сигнал о доставляемости.

2. Другие сигналы

При принятии решения о подтверждении ввода адреса у клиента в вердикте также предусмотрено следующее, чтобы определить, какие компоненты следует исследовать:

3. Сигналы адреса США

Некоторые поля, применимые только к адресам в США, указывают, что ваша логика должна подтвердить детали с клиентом. Применяется одно из следующих условий:

Примеры подтверждения адреса

Принять адрес

Вы принимаете адрес, если вердикт обеспечивает высокую степень уверенности в том, что адрес доставлен и может быть использован без дальнейшего взаимодействия с клиентом в последующем процессе.

Принимать сигналы

API проверки адреса предоставляет ряд сигналов, позволяющих узнать, следует ли подтвердить адрес.

1. Детализация проверки

Гранулярность validationGranularity PREMISE или выше приемлема, но в некоторых случаях ROUTE по-прежнему указывает адрес доставки.

2. Другие сигналы

В вердикте о качестве адреса также должно быть указано следующее:

• Никаких замененных данных . В данном случае hasReplacedComponents: FALSE .
• Никаких предполагаемых компонентов . В данном случае hasInferredComponents: FALSE .

3. Сигналы адреса США

Некоторые поля, применимые только к адресам в США, указывают адрес высокого качества, на который можно доставить. Для приемлемого адреса в США вы должны увидеть следующее:

Принять примеры адресов

В этом документе описывается процесс создания системы проверки адресов для обработки различных ответов от API проверки адреса. В нем рассказывается, как построить логику для правильного использования ответа, исследовать другие сигналы API, а также когда и как запрашивать у клиентов дополнительную информацию.

В общем случае ответ API определяет следующие способы обработки адреса вашей системой:

• handyman Исправление — адрес некачественный. Вам следует запросить дополнительную информацию.
• edit Confirm — адрес высокого качества, но имеет изменения по сравнению с входным адресом. Вы можете запросить подтверждение.
• check Accept — адрес высокого качества. Вы можете принять предоставленный адрес.

Основная цель

Этот документ поможет вам изменить вашу систему, чтобы лучше анализировать ответ API и определять следующие действия, которые следует предпринять с предоставленными адресами. Следующий псевдокод иллюстрирует возможный поток.

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.

Точная логика зависит от вашей ситуации — более подробную информацию см . в руководстве по внедрению . Вы также можете использовать нашу реализацию этой логики с открытым исходным кодом, которая находится в расширенной библиотеке компонентов .

Обзор рабочего процесса

В таблице ниже приведены два действия для вашей системы:

1. Используемый рабочий процесс основан на поведении «исправить, подтвердить, принять».
2. Первые сигналы, которые следует проверить из ответа. Описанные здесь сигналы исходят из свойства verdict и не являются единственными сигналами, которые необходимо проверять, они предоставляют начальный индикатор качества адреса. Каждому типу поведения соответствует раздел в этом документе, описывающий дополнительные сигналы, которые вам также может потребоваться изучить.

Руководство по внедрению

При проектировании реакции вашей системы на сигналы API проверки адреса следующие рекомендации помогут вам построить более эффективную модель ответа. Однако это всего лишь рекомендации, поэтому имейте в виду, что ваша реализация должна соответствовать вашей бизнес-модели.

Исправить адрес

Исправьте адрес, если результаты ясно показывают, что адрес не может быть доставлен. Затем ваша система может предложить клиенту предоставить необходимую информацию, после чего вы повторно запускаете рабочий процесс, чтобы получить адрес доставки.

Фиксировать сигналы

API проверки адреса предоставляет ряд сигналов, позволяющих узнать, следует ли исправить адрес.

1. Детализация валидации и недостающие компоненты

Эти два сигнала лучше всего указывают на проблемный адрес:

• Если поле validationGranularity имеет значение OTHER , ваша система должна изучить сигналы компонентов адреса, чтобы узнать больше о том, где произошла ошибка и как ее исправить.
• Всякий раз, когда объект address , обработанный постобработкой, возвращает поле missingComponentTypes , ваша система должна проверить наличие этого компонента. Отсутствие компонентов также делает адрес неполным и невозможным для доставки.

2. Другие сигналы

API проверки адреса также предоставляет другие сигналы, помогающие диагностировать конкретные проблемы:

3. Сигналы адреса США

Некоторые поля, применимые только к адресам в США, дают полезный сигнал о том, что адрес недоступен и его следует исправить. Для адреса, который требует исправления, вы должны увидеть следующее:

Дополнительные сведения о dpvConfirmation см. в разделе Обработка адресов в США .

Примеры исправленных адресов

Подтвердить адрес

Вы подтверждаете адрес, когда вердикт указывает, что API проверки адреса либо вывел, либо внес изменения в компоненты адреса, чтобы создать проверенный адрес. В этих случаях у вас есть адрес доставки, но вы предпочитаете большую уверенность в том, что полученный адрес соответствует желанию клиента.

Чтобы предоставить клиенту правильные подсказки, ваша логика будет идентифицировать компоненты, помеченные службой, чтобы определить, какое действие или флаг API применил к компоненту, например inferred , replaced или spellCorrected . См. AddressComponent в справочнике.

Подтвердить сигналы

API проверки адреса предоставляет ряд сигналов, позволяющих узнать, следует ли подтвердить адрес.

1. Детализация проверки

Гранулярность validationGranularity ROUTE или выше приемлема, но PREMISE или SUBPREMISE обеспечивают более сильный сигнал о доставляемости.

2. Другие сигналы

При принятии решения о подтверждении ввода адреса у клиента в вердикте также предусмотрено следующее, чтобы определить, какие компоненты следует исследовать:

3. Сигналы адреса США

Некоторые поля, применимые только к адресам в США, указывают, что ваша логика должна подтвердить детали с клиентом. Применимо одно из следующих условий:

Примеры подтверждения адреса

Принять адрес

Вы принимаете адрес, если вердикт обеспечивает высокую степень уверенности в том, что адрес доставлен и может быть использован без дальнейшего взаимодействия с клиентом в последующем процессе.

Принимать сигналы

API проверки адреса предоставляет ряд сигналов, позволяющих узнать, следует ли подтвердить адрес.

1. Детализация проверки

Гранулярность validationGranularity PREMISE или выше приемлема, но в некоторых случаях ROUTE по-прежнему указывает адрес доставки.

2. Другие сигналы

В вердикте о качестве адреса также должно быть указано следующее:

• Никаких замененных данных . В данном случае hasReplacedComponents: FALSE .
• Никаких предполагаемых компонентов . В данном случае hasInferredComponents: FALSE .

3. Сигналы адреса США

Некоторые поля, применимые только к адресам в США, указывают адрес высокого качества, на который можно доставить. Для приемлемого адреса в США вы должны увидеть следующее:

Принять примеры адресов