Как работает REST метод для быстрого поиска адреса по полному названию

Что проверяют

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

Как отвечать

Сначала устройство. Поиск это чтение, поэтому классический вариант GET /api/addresses/suggest?query=...&count=10. Кириллица и пробелы в строке запроса кодируются в UTF-8 с процентами: «Мо» превращается в %D0%9C%D0%BE. Часть сервисов подсказок принимает POST с JSON-телом, когда фильтров много, это тоже нормальная практика. Ответ: 200 и массив совпадений, у каждого полный адрес, составные части, координаты и код из адресного реестра. Быстроту дают полнотекстовый индекс или поисковый движок и ограничение на число результатов, а фронтенд зовёт метод не на каждую букву, а после паузы в вводе.

Проверки стоит сгруппировать:

• функциональные: точное совпадение, часть названия, другой регистр, «ё» и «е», сокращения «ул.» и «улица», опечатки, лишние пробелы;
• граничные: пустая строка, один символ, очень длинная строка (сервер может ответить 414), параметр count на нуле, на максимуме и сверх него;
• негативные: спецсимволы, попытки SQL-инъекции, неверный токен (401), превышение лимита запросов (429);
• контракт: схема ответа, типы полей, сортировка по релевантности, одинаковый ответ на повторный запрос;
• производительность: время ответа под нагрузкой в k6 или JMeter, если в требованиях есть порог.

Где спотыкаются

Ждут 404, когда ничего не найдено. Для поиска пустой результат это нормальный 200 с пустым массивом, а 404 означает, что нет самого ресурса.

Проверяют только идеальный адрес. Реальные пользователи вводят его с опечатками, без запятых и в произвольном порядке, и основные баги именно там.

Забывают про кодирование: в Postman запрос проходит, а автотест, который склеивает URL строкой, падает на пробеле или символе #.