В этом документе описан ряд реальных сценариев, в которых API проверки адресов выдаёт сигналы, которые могут потребовать исправления ошибок в вашей системе. См. примеры рабочих процессов в разделе «Создание логики проверки» для получения более подробной информации.
Распространенные примеры: исправить
В этом разделе описываются типичные примеры, когда API проверки адресов выдает ответные сигналы, указывающие на низкое качество адресной информации.
Отсутствует город и почтовый индекс
В этом примере показана запись, содержащая только почтовый адрес, без города или почтового индекса.
| Адрес введен | Область | 
|---|---|
| 21 45 40-я улица | США | 
Вердикт по отсутствующему городу и почтовому индексу
В примере ниже подчеркиваются важные сигналы ответа.
{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "FIX"
}
 Действие possibleNextAction даёт первоначальное указание на то, что адрес может быть недоступен для доставки. Другие выделенные компоненты также поддерживают эту возможность, поэтому вы можете запросить addressComponents , чтобы узнать больше:
{
  "componentName": {
    "text": "21",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "45 40th street",
    "languageCode": "en"
  },
  "componentType": "route",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "United States",
    "languageCode": "en"
  },
  "componentType": "country",
  "confirmationLevel": "CONFIRMED"
}
 API проверки адреса возвращает только страну (США) как CONFIRMED . Все остальные компоненты адреса возвращаются как UNCONFIRMED_BUT_PLAUSIBLE , с некоторыми важными пропусками данных, такими как местоположение и почтовый индекс.
Отсутствует номер улицы
В этом примере показан отсутствующий номер дома.
| Адрес введен | Область | 
|---|---|
| Букингем-Пэлас-роуд, SW1W 9TQ, Лондон | Великобритания | 
Вердикт по делу об отсутствии номера улицы
{
    "inputGranularity": "PREMISE_PROXIMITY",
    "validationGranularity": "ROUTE",
    "geocodeGranularity": "ROUTE",
    "possibleNextAction": "FIX"
}
 И снова, possibleNextAction даёт первоначальное указание на то, что адрес, возможно, не может быть доставлен. Более того, значение validationGranularity равно ROUTE , что указывает на соответствие улице, но недостаточно информации для достижения объекта. Кроме того, свойство addressComplete отсутствует в вердикте, поэтому оно равно false . Дальнейший запрос к объекту address обнаруживает отсутствующий тип компонента:
"missingComponentTypes": [
        "street_number"
      ]
Примеры пограничных случаев: исправление
В некоторых ситуациях решение о том, исправить, подтвердить или принять адрес, зависит от конкретного бизнес-сценария. Приведённые ниже примеры иллюстрируют ситуации, которые могут не полностью подпадать под категорию исправления.
Неподтвержденный номер дома
В этом сценарии API проверки адреса не может подтвердить предоставленный номер дома, но при этом указывает, что адрес полный.
| Адрес введен | Область | 
|---|---|
| 84 Букингем Пэлас Роуд, SW1W 9TQ, Лондон | Великобритания | 
Вердикт по неподтвержденному номеру улицы
В приведенном ниже примере подчеркнуты важные сигналы.
{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete" : true,
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "ACCEPT"
}
 Стоит рассмотреть сочетание детализации валидации только до уровня аппроксимации на уровне предпосылок с неподтверждёнными компонентами. Запрос к свойству addressComponents показывает следующий неподтверждённый componentType :
{
  "componentName": {
    "text": "84",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}
 Здесь значение confirmation_level для street_number равно UNCONFIRMED_BUT_PLAUSIBLE . Значение Unfirmed означает, что сервис не может сопоставить номер улицы 84 со своим набором данных, а значение plausible означает, что данные компонента всё ещё могут быть действительными.
Отсутствует подпредпосылка
 В этом сценарии описывается адрес, в котором отсутствует только один элемент, например, номер квартиры или отдела. В противном случае API проверки адреса может полностью проверить адрес. Как и в случае отсутствия любого компонента адреса, addressComplete имеет значение false и, следовательно, не отображается при ручной проверке вердикта.
Для иллюстрации предположим, что клиент вводит действительный адрес офиса оценщика города Сан-Франциско, но пропускает номер комнаты во входных данных.
| Адрес введен | Область | 
|---|---|
| 1 Доктор Карлтон Б. Гудлетт Плейс, Сан-Франциско, Калифорния 94102 | США | 
Вердикт об отсутствии подпосылки
 В этом примере вердикт не отображает свойство addressComplete , поэтому он имеет false . Это означает, что по крайней мере один элемент address непредвиденный, неразрешённый или отсутствует.
{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "hasInferredComponents": true,
  "possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
 Запрос address показывает следующее:
"missingComponentTypes": [
        "subpremise"
      ]
 При дальнейшем запросе данные USPS предоставили код dpvConfirmation D , который также указывает на отсутствующую подпосылку.