На каждом собеседовании для системных аналитиков звучат вопросы про REST API. От джуна до сеньора 🙌
Но ответить на него невозможно, если не понимать, как работает протокол HTTP.
REST API — это архитектурный стиль, использующий HTTP в качестве протокола передачи данных (или: основанный на протоколе HTTP).
HTTP
— это протокол прикладного уровня, используемый для передачи данных между клиентом и сервером в Интернете.
И чтобы вы действительно поняли значение слов “архитектурный стиль”, когда мы в следующих постах будем подробнее разбирать определение REST API, я хочу рассказать про протокол HTTP.
Всё самое важное на картинках к посту ☝️
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27❤8👍6❤🔥4👎1🤣1
💻 Когда Системный Аналитик работает с REST API 💻
Глядя на ключевые слова "REST API" в вакансиях Системных Аналитиков, полезно понимать, что может за этим скрываться.
Предлагаю чек-лист, который вы всегда можете применить, чтобы оценить свой текущий круг обязанностей и то, что может ожидать вас в будущих проектах📈
👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.
Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:
+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).
+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).
👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.
👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.
Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.
👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.
👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.
Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.
#RestApiGA
Глядя на ключевые слова "REST API" в вакансиях Системных Аналитиков, полезно понимать, что может за этим скрываться.
Предлагаю чек-лист, который вы всегда можете применить, чтобы оценить свой текущий круг обязанностей и то, что может ожидать вас в будущих проектах
👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.
Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:
+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).
+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).
👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.
👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.
Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.
👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.
👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.
Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤29👍11❤🔥2🔥2
🎯 [13.10 в 19Мск] Практика SQL-запросов в реальной БД через DBeaver 🎯
В следующий понедельник проводим продвинутый онлайн-практикум по БД и SQL:
🎯 Инструмент DBeaver. Практика SQL-запросов
🗓 13 Октября 2025 (пн)
🕖 19:00 Мск
👉 Подробности и регистрация
🤝 Доступ к записи
на следующий день, для всех подключенных участников.
🎁 Актуальный бонус
доступ к записи занятия "Оптимизация БД. Работа с индексами в БД".
План:
1*. Знакомство с инструментом DBeaver. Подключение тестовой БД
2*. О применении SQL аналитиками. Ключевые операторы SQL-запросов.
3. Практика SQL-запросов на получение данных в DBeaver.
4. Использование AI (искусственного интеллекта) в качестве помощника в работе с SQL
* - самостоятельная подготовка по видео-уроку в платформе, на занятии максимально практикуемся с SQL
Практикум подойдёт, если вы:
✔️ умеете читать ER-диаграммы,
✔️ хотите освоить SQL с нуля, на практике,
✔️ и хотите упрощать свою жизнь с использованием AI при работе с SQL.
👉 Материалы по БД для знакомства и подготовки к онлайн-практикуму по DBeaver + SQL:
🔗 Обучающее видео "Проектирование БД - логический уровень"
🔗 Статья "зачем БД аналитику"
🔗 Статья о возможностях DBeaver
До встречи! 😉
Вопросы по практикуму можно написать @getanalyst (или на почту info@getanalyst.ru)
В следующий понедельник проводим продвинутый онлайн-практикум по БД и SQL:
🎯 Инструмент DBeaver. Практика SQL-запросов
🕖 19:00 Мск
👉 Подробности и регистрация
🤝 Доступ к записи
на следующий день, для всех подключенных участников.
🎁 Актуальный бонус
доступ к записи занятия "Оптимизация БД. Работа с индексами в БД".
План:
1*. Знакомство с инструментом DBeaver. Подключение тестовой БД
2*. О применении SQL аналитиками. Ключевые операторы SQL-запросов.
3. Практика SQL-запросов на получение данных в DBeaver.
4. Использование AI (искусственного интеллекта) в качестве помощника в работе с SQL
* - самостоятельная подготовка по видео-уроку в платформе, на занятии максимально практикуемся с SQL
Практикум подойдёт, если вы:
✔️ умеете читать ER-диаграммы,
✔️ хотите освоить SQL с нуля, на практике,
✔️ и хотите упрощать свою жизнь с использованием AI при работе с SQL.
👉 Материалы по БД для знакомства и подготовки к онлайн-практикуму по DBeaver + SQL:
До встречи! 😉
Вопросы по практикуму можно написать @getanalyst (или на почту info@getanalyst.ru)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13❤🔥1
🔐 Разница между HTTP и HTTPS 🔐
Это один из наиболее частых вопросов, которые я встречаю на занятиях про API от наших студентов. Его же спрашивают на собеседованиях. Поэтому давайте разберёмся, в чём же отличия.
HTTP - это протокол прикладного уровня.
Он включает в себя варианты использования:
👉 HTTP — данные идут «в открытом виде»
Любой, кто перехватил трафик, увидит весь запрос и ответ как текст.
Если трафик в HTTP (незащищённый), то перехватчик сможет видеть:
🔺 Полный URL (включая query-параметры)
🔺 Все HTTP-заголовки (включая Authorization, Cookie, User-Agent)
🔺 Тело запроса/ответа — JSON, формы, файлы.
❗️ То есть любые передаваемые пароли, токены, номера карт, персональные данные будут перехвачены.
👉 HTTPS — тот же HTTP поверх шифрованного канала TLS
Перехватчик трафика не увидит содержимого запросов и ответов - оно зашифровано, он увидит только:
🔺 линию связи: IP-адрес сервера, порт (обычно 443), объём и тайминги пакетов.
🔺 может увидеть SNI (Server Name Indication) - имя хоста, переданное открыто в TLS ClientHello (в большинстве реализаций)
🔺 НЕ видит содержимое заголовков и тела запросов - они зашифрованы. Токены/пароли/JSON недоступны.
❗️ При перехвате трафика все персональные данные будут защищены.
👉 Как перехватывают трафик?
⚪ Открытая Wi-Fi сеть (public hotspot)
Пользователь подключается к общему Wi-Fi, злоумышленник в той же сети запускает сниффер.
Без HTTPS — все данные видно.
С HTTPS — трафик зашифрован.
⚪ Компрометация роутера / провайдера
Подменённый DNS или перенаправление на прокси. Может потребоваться поддельный сертификат.
⚪ Браузерные расширения / вредоносное ПО
Может читать/перехватывать запросы на клиенте до шифрования (например, JS-обработчики, extensions).
⚪ Атакующий выдает себя за шлюз в локальной сети (ARP poisoning) и проксирует (перенаправляет) трафик через себя.
⚪ И другие способы атак.
Без них HTTPS просто не сможет работать и будет просто HTTP.
#RestApiGA #АрхитектураGA
Это один из наиболее частых вопросов, которые я встречаю на занятиях про API от наших студентов. Его же спрашивают на собеседованиях. Поэтому давайте разберёмся, в чём же отличия.
HTTP - это протокол прикладного уровня.
Он включает в себя варианты использования:
👉 HTTP — данные идут «в открытом виде»
Любой, кто перехватил трафик, увидит весь запрос и ответ как текст.
Если трафик в HTTP (незащищённый), то перехватчик сможет видеть:
🔺 Полный URL (включая query-параметры)
🔺 Все HTTP-заголовки (включая Authorization, Cookie, User-Agent)
🔺 Тело запроса/ответа — JSON, формы, файлы.
❗️ То есть любые передаваемые пароли, токены, номера карт, персональные данные будут перехвачены.
👉 HTTPS — тот же HTTP поверх шифрованного канала TLS
Перехватчик трафика не увидит содержимого запросов и ответов - оно зашифровано, он увидит только:
🔺 линию связи: IP-адрес сервера, порт (обычно 443), объём и тайминги пакетов.
🔺 может увидеть SNI (Server Name Indication) - имя хоста, переданное открыто в TLS ClientHello (в большинстве реализаций)
🔺 НЕ видит содержимое заголовков и тела запросов - они зашифрованы. Токены/пароли/JSON недоступны.
❗️ При перехвате трафика все персональные данные будут защищены.
👉 Как перехватывают трафик?
⚪ Открытая Wi-Fi сеть (public hotspot)
Пользователь подключается к общему Wi-Fi, злоумышленник в той же сети запускает сниффер.
Без HTTPS — все данные видно.
С HTTPS — трафик зашифрован.
⚪ Компрометация роутера / провайдера
Подменённый DNS или перенаправление на прокси. Может потребоваться поддельный сертификат.
⚪ Браузерные расширения / вредоносное ПО
Может читать/перехватывать запросы на клиенте до шифрования (например, JS-обработчики, extensions).
⚪ Атакующий выдает себя за шлюз в локальной сети (ARP poisoning) и проксирует (перенаправляет) трафик через себя.
⚪ И другие способы атак.
Чтобы обеспечить работу HTTPS, на сервер должны установить сертификаты SSL/TLS
Без них HTTPS просто не сможет работать и будет просто HTTP.
#RestApiGA #АрхитектураGA
👍34❤20🔥10❤🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
🔐 SSL/TLS-сертификаты для обеспечения HTTPS 🔐
Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.
👉 SSL/TLS-сертификат - это цифровой документ, который:
▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),
▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.
Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)
👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).
Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).
Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.
📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.
👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата
👉 Что происходит, когда ты заходишь на HTTP://getanalysts.com?
Браузер сообщает, что соединение небезопасно
📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций
#RestApiGA #АрхитектураGA
Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.
👉 SSL/TLS-сертификат - это цифровой документ, который:
▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),
▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.
Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)
👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).
Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).
Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.
📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.
👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата
👉 Что происходит, когда ты заходишь на HTTP://getanalysts.com?
Браузер сообщает, что соединение небезопасно
📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций
#RestApiGA #АрхитектураGA
🔥21❤🔥5❤4👍4🤩1
GET, POST, PUT, PATCH и DELETE - виды методов, часть протокола HTTP. Используются в архитектурном стиле REST API.
Нужны, чтобы стандартизировать взаимодействие между клиентом и сервером.
Каждый метод выполняет определённое действие и соответствует логике CRUD-модели (Create, Read, Update, Delete).
🩷 GET - Чтение данных
Не поддерживает тело - Body (JSON).
Идемпотентен.
💚 POST - Создание ресурсов (объектов в БД)
Поддерживает тело - Body (JSON).
Не идемпотентен.
* Исключения, когда POST используют для чтения: сложные запросы с большим кол-вом фильтров, асинхронные операции.
** Почему в некоторых REST API все POST? Потому что они не REST API, а HTTP API.
💙 PUT - Полная замена и/или создание ресурса
В теле JSON требует полный объект.
Идемпотентен.
* Часто используют только для изменения.
💜 PATCH - Частичное обновление ресурса
В теле JSON передаются только те поля объекта, которые нужно изменить.
Не идемпотентен.
❤️ DELETE - Удаление ресурса.
Не поддерживает тело - Body (JSON).
Идемпотентен.
💛 А что по поводу TRACE, HEAD, OPTIONS, CONNECT?
Могут быть заменены GET-ом.
Очень маленький шанс встретить или применить на практике.
Правильное использование HTTP-методов в REST API упрощает взаимодействие с вашей системой, так как делает API предсказуемым и удобным для разработчиков.
P.S. Ссылка на подкаст про идемпотентность и коммутативность в API
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤4🔥4❤🔥2💯2👌1
📗 REST API - 6 главных принципов, про которые спрашивают на собеседованиях 📗
REST API — это архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.
То, что REST API основан на протоколе HTTP, означает, что все принципы работы, структура запросов и ответов, будут также применимы и для REST API.
Архитектурный стиль REST приносит для HTTP дополнительные правила и принципы, по которым должен происходить обмен данными в Интернете 👇
Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу
В картинках к посту просто и с примерами разобрала эти принципы.
Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 👌
#RestApiGA
REST API — это архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.
То, что REST API основан на протоколе HTTP, означает, что все принципы работы, структура запросов и ответов, будут также применимы и для REST API.
Архитектурный стиль REST приносит для HTTP дополнительные правила и принципы, по которым должен происходить обмен данными в Интернете 👇
Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу
В картинках к посту просто и с примерами разобрала эти принципы.
Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 👌
#RestApiGA
❤20🔥7👍3❤🔥2