🤷♂️Как вести себя на собеседовании, если не знаешь, как ответить на технический вопрос?🤷♂️
Вы старательно готовились к собеседованию.
Рассчитывали предусмотреть все каверзные вопросы, но вдруг спотыкаетесь на техническом вопросе.
Караул!
Стоп, паника.
Ничего плохого о вас не подумают.
Не сжигайте мысленно налаженные только что мосты.
Поверьте, ситуацию можно обернуть в свою пользу🙌
Как?
Читайте в картинках к посту.
#softGetAnalyst
Вы старательно готовились к собеседованию.
Рассчитывали предусмотреть все каверзные вопросы, но вдруг спотыкаетесь на техническом вопросе.
Караул!
Стоп, паника.
Ничего плохого о вас не подумают.
Не сжигайте мысленно налаженные только что мосты.
Поверьте, ситуацию можно обернуть в свою пользу🙌
Как?
Читайте в картинках к посту.
#softGetAnalyst
👍7❤3😁1
🔐 5 способов авторизации в API - наглядное демо по настройкам в Postman 🔐
При проектировании интеграций, системному аналитику важно заранее продумать сценарий авторизации запросов во внешнюю систему.
Почему?
1. Без авторизации вызовы API просто не пройдут — интеграция «упадёт» уже на первом шаге.
2. Разные механизмы требуют разной логики работы и обработки ошибок.
3. Чёткое понимание процесса авторизации упрощает тестирование и облегчает отладку сценариев интеграции.
📌 Основные способы авторизации
API Key
Basic Auth
Bearer Token
JWT Token
OAuth 2.0
Mutual TLS (по сертификатам)
📌 Как оформлять в требованиях?
При работе с задачей на интеграцию, аналитик пишет требования к интеграционным API-методам или Backend-процессам для своей системы, в логике которых встроены вызовы внешних API.
👉 Не дублируйте требования к авторизации в одном и том же внешнем API в каждом Use Case, который его использует.
Вместо того, чтобы в каждом интеграционном Use Case описывать требования к авторизации во внешней системе и обработку её ошибок, достаточно вынести общие требования к авторизации в отдельную статью (+задачу) и затем ссылаться на неё.
При описании отдельных API-методов или Backend-процессов лучше фокусироваться только на специфике их работы.
📌 Обработка ошибок
Важно предусмотреть и описать требования к обработке ошибок аутентификации и авторизации в процессе работы интеграции:
❌ 401 Unauthorized — неверные или отсутствующие учётные данные. Возможна повторная фоновая аутентификация.
❌ 403 Forbidden — недостаточно прав для выполнения операции, хотя аутентификация (учётные данные) может быть верной.
❌ 419 Token Expired — срок действия токена истёк, требуется рефреш или повторная фоновая аутентификация.
❌ 429 Too Many Requests — превышен лимит запросов (для API Key/токена OAuth, учетной записи).
📌 Логирование
Логируйте и мониторьте случаи ошибок авторизации.
Если попытки повторной фоновой авторизации не приводят к успеху, то есть высокий риск, что интеграция "упала".
#hardGetAnalyst
При проектировании интеграций, системному аналитику важно заранее продумать сценарий авторизации запросов во внешнюю систему.
Почему?
1. Без авторизации вызовы API просто не пройдут — интеграция «упадёт» уже на первом шаге.
2. Разные механизмы требуют разной логики работы и обработки ошибок.
3. Чёткое понимание процесса авторизации упрощает тестирование и облегчает отладку сценариев интеграции.
📌 Основные способы авторизации
API Key
Basic Auth
Bearer Token
JWT Token
OAuth 2.0
Mutual TLS (по сертификатам)
📌 Как оформлять в требованиях?
При работе с задачей на интеграцию, аналитик пишет требования к интеграционным API-методам или Backend-процессам для своей системы, в логике которых встроены вызовы внешних API.
👉 Не дублируйте требования к авторизации в одном и том же внешнем API в каждом Use Case, который его использует.
Вместо того, чтобы в каждом интеграционном Use Case описывать требования к авторизации во внешней системе и обработку её ошибок, достаточно вынести общие требования к авторизации в отдельную статью (+задачу) и затем ссылаться на неё.
При описании отдельных API-методов или Backend-процессов лучше фокусироваться только на специфике их работы.
📌 Обработка ошибок
Важно предусмотреть и описать требования к обработке ошибок аутентификации и авторизации в процессе работы интеграции:
❌ 401 Unauthorized — неверные или отсутствующие учётные данные. Возможна повторная фоновая аутентификация.
❌ 403 Forbidden — недостаточно прав для выполнения операции, хотя аутентификация (учётные данные) может быть верной.
❌ 419 Token Expired — срок действия токена истёк, требуется рефреш или повторная фоновая аутентификация.
❌ 429 Too Many Requests — превышен лимит запросов (для API Key/токена OAuth, учетной записи).
📌 Логирование
Логируйте и мониторьте случаи ошибок авторизации.
Если попытки повторной фоновой авторизации не приводят к успеху, то есть высокий риск, что интеграция "упала".
#hardGetAnalyst
❤5🔥3
Чаще всего нейросети обсуждают в контексте работы: написать ТЗ, помочь с кодом, разобрать данные, подготовить презентацию.
Но на самом деле они отлично помогают и становятся отличными ассистентами, которые упрощают повседневную жизнь.
Делимся вариантами➡️
#hwGetAnalyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
Во многих системах нужен API, где не просто классический запрос-ответ, а доставка данных в интерфейс в реальном времени.
Один из подходов для таких сценариев — SSE.
В этом выпуске разбираем, как устроен SSE, где он встречается в реальных проектах, чем отличается от WebSocket, как влияет на архитектуру системы, безопасность и постановку задач в разработку.
👉 Если вы системный аналитик, который хочет не просто знать названия технологий, а понимать — этот выпуск точно для вас.
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
🩵 GetAnalyst — ваш помощник в вопросах системного анализа и архитектуры 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1