О чем и для кого статья

Привет всем! Данная статья адресована начинающим свой путь в системном анализе и призвана помочь ответить максимально просто на один из самых частых вопросов системному аналитику на собеседовании. Мне данный вопрос задали на 3х из 5ти технических интервью, а это значит, что в теме надо разобраться. Поехали!

Вопрос: на сайте есть форма с полем поиска чего-либо по названию и кнопка, при нажатии на которую должен быть выведен результат поиска. Проблема в том, что пользователь не помнит название. Как реализовать поиск?

Первый шаг к ответу - а что, собственно, хотят услышать?

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

Возможный ход мыслей при ответе на вопрос
Возможный ход мыслей при ответе на вопрос

В моем же случае, за последний месяц в большинстве случаев этот вопрос сводился к тому, чтобы получить понимание, знает ли кандидат структуру URL, а точнее как передать в URL GET или POST запрос и что означают знаки "?", "+", "%", "=", введенные в адресной строке.

Бывает, что интервьюер уточняет, что хочет увидеть пример JSON запроса, который будет отправлен на BACK. Замечу, что примеры XML запросов лично у меня никогда не спрашивали.

JSON cформирован. Как его передать на сервер? В этот момент с Вами захотят поговорить о брокерах сообщений Каfka и RabbitMQ.

Предположим, что запрос отправлен, а как он будет обработан? Как получить нужные данные для отображения?

Ну, и конечно, вопросы безопасности. Некоторые данные нельзя передавать в открытом виде.

Хорошая идея при ответе на вопрос выше - Вы можете попробовать увести диалог в стороны, в которых Вы наиболее сильны.

Что надо понимать

При ответе на вопрос выше надо хотя бы примерно понимать "бизнес" - процесс реализации поиска по введенной подстроке. Почему я говорю о бизнес-процессе, а не о технологии? Да, потому что создание сайтов (а вместе с ними внутренних порталов и CRM c��стем) стандартизируется, а вместе с этим стандартизируется работа системных аналитиков. И когда им ставится задача выше они должны ее декомпозировать на вполне определенные блоки, чтобы поставить конкретные задачи на разных участников команды. А это уже бизнес-процесс самого системного аналитика, который спустя годы будет также автоматизирован.

Итого, чтобы получить таблицу с данными, найденными по подстроке, введенной пользователем, системного аналитику надо будет поставить задачи на вот такой набор работ как минимум:

Вопросы, на которые в общем случае должен ответить аналитик
Вопросы, на которые в общем случае должен ответить аналитик

Где искать подстроку в URL - кратко

Введенные параметры с указанием полей поиска идут сразу после вопросительного знака «?» и используется при передаче данных на сервер в случае GET запроса. В случае POST запроса данные будут отправлены "скрыто" в теле запроса, а не адресной строке. Поля и введенные в них данные разделяются символом амперсанда («&» (а по-русски "и")). Никаких кавычек добавлять к введенной подстроке при формировании URL не надо.

Ниже на картинке на сайте с доменом discript.ru по безопасному протоколу HTTPS на странице blog запросили данные по введенных в полях name и topic строкам. В первом ввели "struktura-uml", во втором - "seo".

Если бы в поле name ввели "struktura uml", то параметры запроса передали бы вместо пробела " " - знак "+".

А если бы в поле name ввели "struktura+uml", то параметры запроса передали бы вместо "+" - "%2B".

Картинка взята тут https://discript.ru/blog/chto-takoe-url/ PS (c) Параметры не включают ? и &. Первый — это разделитель адресного блока URL и блока параметров, второй — разделитель параметров. Но ни первый, ни второй в параметры не входят (пока не экранированы)
Картинка взята тут https://discript.ru/blog/chto-takoe-url/ PS (c) Параметры не включают ? и &. Первый — это разделитель адресного блока URL и блока параметров, второй — разделитель параметров. Но ни первый, ни второй в параметры не входят (пока не экранированы)

Как сформировать JSON или XML - кратко

JSON или XML запроса состоит из 3х блоков:

  1. Метод + путь URL

    1. Метод. Ниже приведены наиболее часто используемые.

      1. GET Запрашивает получение данных с сервера.

      2. POST Создает новый ресурс или обновляет существующий на сервере.

      3. PUT Полностью заменяет указанный ресурс новыми данными.

      4. DELETE Удаляет указанный ресурс.

      5. PATCH Частично обновляет указанный ресурс.

    2. URL: /api/data?[��араметр=значение] с указанием параметров запроса в случае открытой передачи данных или /api/data без параметров запроса, если данные передаются в теле запроса это путь к ресурсу на сервере.

  2. Заголовки:
    Host: Указывает доменное имя сервера.
    Content-Type: тип содержимого, например, application/json, при необходимости.
    Content-Length: Указывает длину тела запроса в байтах, при необходимости.

  3. Тело запроса с описанием объекта или массива в формате "ключ-значение"

Разница между JSON и ХML будет только в формате тела запроса. Ниже примеры.

GET запрос

POST запрос

JSON

Для GET запроса тело отсутствует, так как данные передаются открыто в адресной строке после URL

GET /api/data?key=value HTTP/1.1
Host: example.com

Запрос в формате XML идентичен запросу в формате JSON

В случае POST запроса введенные данные передаются скрыто в теле запроса.

POST /api/data HTTP/1.1
Host: example.com
Content-Type: application/json
{
 "key": "value"
}

XML

POST /api/data HTTP/1.1
Host: example.com
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<data>
<item>
<key>value</key>
</item>
</data>

Методы обмена данными между серверами - кратко

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

  • FTP/SFTP: Протокол передачи файлов, используемый для загрузки и скачивания файлов с удаленного сервера.

  • HTTP/HTTPS: Стандартный протокол для веб-коммуникаций, часто используется для передачи данных через API и RESTful сервисы.

  • WebSocket: Двухсторонняя связь в режиме реального времени, подходит для приложений, требующих мгновенной реакции (чат, игры).

  • AMQP/MQTT/Kafka/RabbitMQ: Брокеры сообщений, обеспечивающие асинхронную передачу данных между приложениями. Используются для организации очередей сообщений и событийно ориентированной архитектуры.

  • SOAP/XML-RPC: Старые стандарты обмена структурированными сообщениями, основанные на XML, используются реже, уступив место современным REST API.

  • gRPC: Современный протокол RPC (Remote Procedure Call), использующий бинарный формат Protobuf для быстрого обмена большими объемами данных.

Варианты обработки запроса - кратко

После того как будет получено сообщение с данными, введенными пользователем, сервером - необходимо обработать это сообщение и извлечь данные из БД по подстроке. Ниже перечень возможных решений.

  • Вариант 1: Простое SQL-подобное решение с использованием оператора LIKE
    Один из простейших способов реализовать поиск по подстроке – использование операторов сравнения строковых значений в базах данных, например LIKE.
    SELECT * FROM products WHERE name LIKE '%${userInput}%';

  • Вариант 2: Использование полнотекстового поиска (Full-text search), встроенныго в большинство современных СУБД. Это позволит учитывать морфологию, стемминги и синонимы, обеспечивая более точный поиск.
    --Пример использования full-text index в MySQL:
    CREATE FULLTEXT INDEX idx_name ON products(name); SELECT * FROM products WHERE MATCH(name) AGAINST('${userInput}' IN NATURAL LANGUAGE MODE);

  • Вариант 3: Решение на стороне приложения с использованием регулярных выражений
    путем обработки запроса на уровне бизнес-логики. Например, на Python можно создать функцию для фильтрации объектов на основе регулярного выражения:
    def find_by_substring(data, substring): pattern = re.compile(substring, re.IGNORECASE) return list(filter(lambda x: bool(pattern.search(x['name'])), data))

  • Вариант 4: Реализация автоподсказок (autocomplete) путем создания отдельного API-интерфейса, возвращающего список предложений по мере набора текста пользователем.

Послесловие

Казалось бы вопрос простой, а сколько за ним всего стоит. И еще пару лет назад было достаточно рассказать интервьюеру о том, что будет поставлено несколько задач: на создание полей и кнопок на UI и на обработку запроса BACK'ом. В большинстве своем программисты сами бы определили типы запросов, коды новых поле, способы извлечения данных из БД и т.д. Вопрос способа реализации передачи данных вообще бы не стоял при доработке для существующего функционала.

Почему интервью стали столь глубоки - мне не известно, но факт остается фактом. Собеседования аналитиков теперь проходят очень жестко по заранее подготовленным задачам без "бла-бла-бла "и "кем вы видите себя через 5 лет".