Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Создание проверки радиуса посадки для сервиса совместных поездок
У небольшого сервиса совместных поездок, работающего по соглашению для кампуса и прилегающих районов, было одно жёсткое правило, которое нельзя нарушать: посадка и высадка должны происходить внутри определённой зоны работы, согласованной с местными властями, которые изначально одобрили сервис. Высадка водителями за этой границей, даже на небольшом расстоянии, ставила под угрозу всё соглашение, а надеяться на то, что водители определят границу на глаз по бумажной карте, было бы ненадёжно.
Сервис построил проверку вокруг координат, а не адресов, поскольку метка посадки пассажира уже была координатой, поставленной на карте внутри приложения, а не введённым текстом. Для этой исходной координаты сервис использовал /v1/reverse, чтобы получить понятный адрес и его административную единицу. Это было удобно, чтобы показать пассажиру подтверждённое место посадки, и для сотрудников, разбирающих отмеченные поездки постфактум, ведь человеку сложно быстро проверить одну координату, а найденный адрес проверить легко.
Сама проверка границы была простым геометрическим сравнением, которое выполнял сервер приложения, между координатой пассажира и многоугольником, описывающим разрешённую зону работы. Такой расчёт не требует внешнего сервиса, если есть координата для проверки. Эндпоинты местоположения нужны были для того, чтобы у этой проверки всегда была реальная координата: если пассажир вводил адрес, а не ставил метку, введённое им сначала превращалось в координату через /v1/forward.
Запрос на посадку внутри границы обрабатывался как обычно. Запрос за её пределами, даже совсем немного, отклонялся ещё до назначения водителя с сообщением о том, что сервис не может законно работать вне разрешённой зоны, вместо того чтобы водитель приезжал и только тогда узнавал, что ему нельзя забрать пассажира. Раннее отклонение экономило время и водителя, и пассажира, а также оставляло чистую историю, показывающую, что сервис активно соблюдает собственную границу, а не обнаруживает нарушения задним числом.
Сервис также использовал адрес, полученный обратным геокодированием, для отмеченных или спорных поездок, поскольку небольшое число посадок приходилось прямо на край границы и требовало, чтобы человек подтвердил, попал ли запрос внутрь разрешённой зоны или за её пределы. Судить об этом гораздо проще по найденному адресу и названию района, чем по голой паре координат во внутренней панели.
Такое соблюдение границ не является сложной технической задачей, когда элементы определения местоположения уже на месте. Трудность была в том, чтобы каждая посадка и высадка, как бы её ни ввели в приложение, всегда превращалась в координату, которую геометрическая проверка на сервере действительно может использовать, и эту задачу решали /v1/forward и /v1/reverse совместно, в зависимости от того, с какой стороны поступали данные.
Объём напрямую зависел от числа поездок, один или два запроса на поездку, и для сервиса такого размера, работающего в одной ограниченной зоне, эта нагрузка укладывалась в бесплатную дневную квоту. Документация по обоим эндпоинтам находится по адресам /docs/forward-geocoding/ и /docs/reverse-geocoding/.