#breakfront_articles

Прочитала в интереснейшей книге “Лучшее в нас” эксперименты теории разбитых окон и в результате получилась целая статья про документацию.😂 (Да, у меня странный ассоциациативный ряд).
https://habr.com/ru/post/549588/

В конце июня посетила Летний Аналитический Фестиваль (ЛАФ) - https://lafest.ru/. Понравились атмосфера, доклады и мастер-классы, формат и организация. Сейчас расскажу подробнее.🧐

ЛАФ - это неформальная конференция, куда приезжают с семьями и детьми, большими дружными компаниями или по одиночке, но с желанием пообщаться.

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

Это очень интересный формат, где дружелюбное и расслабленное общение сочетается с серьезными темами и важными профессиональными инсайтами.

Площадка позиционирует себя как открытая и лояльная, в том числе к начинающим спикерам. Цены демократичные, организация очень заботливая, многое делается из энтузиазма и любви к сообществу.

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

Больше всего запомнились доклады про процесс разработки требований в условиях Agile и АГИЛ (это Agile курильщика по определению автора). И мастер-класс на эту же тему. Все презентации есть на страничках докладов: https://conf.uml2.ru/index.php?program2021

Самое ценное, что я получила на ЛАФ - это вдохновение и прилив интереса к профессии, неизведанныму и новому в ней.

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

​​#breakfront_tooltips

Notion для личной базы знаний

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

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

Notion инструмент не новый и широко известный. Я даже когда-то вела там проектную документацию. Было норм, но для рабочих проектов Confluence все-таки лучше, на мой взгляд (там есть встраиваемые страницы, теги, свои шаблоны, ссылки на джиру и пр.).

А вот для личной базы знаний Ноушн видится идеальным кандидатом. И у меня на это 6 причин:

1. Пространство для личного использования бесплатно и не ограничено по объему.
2. Очень много форматов представления информации: списки, таблицы, встроенные окна из других приложений, чек-боксы, таймлайны и другое.
3. Есть сквозной поиск, перекрестные ссылки, общая навигация и другие элементы нормальной вики.
4. Очень приятный и понятный интерфейс. Даже если информация не структурирована - страница выглядит красиво и опрятно.
5. Все доступно из браузера, мобильного приложения, десктопного приложения. То есть данные всегда под рукой.
6. Есть плагин в браузерах для быстрого сохранения страницы в нужный раздел. Также можно сохранять все с мобилки через функцию "Share".

Структура для моей вики сформировалась довольно естественно. Основные разделы получились такими:

- Список для чтения/изучения;
- Полезные веб-ресурсы;
- Изученные материалы (таблица с тегами и пометками);
- Доска с курсами - пройденными, в процессе, завершенными;
- Список полезных инструментов;
- Странички с рецептами, вишлистами и прочими заметками и закладками.

Однако и Notion не то оружие, что управляет всем (может, оно и к лучшему). Помимо него использую еще несколько инструментов:

- Календарь от Apple для встреч и напоминаний;
- Timestripe для планирования задач и целеполагания;
- Miro для майндмепов и прочего мыслетворчества.

А у вас есть любимые приложения для управления своими знаниями и задачами?

#breakfront_articles

Порефлексировала на тему микросервисов: https://habr.com/ru/post/583136/

Видимо реакции как-то убирают комментарии, поэтому эта запись для комментариев к статье про микросервисы.

​​#breakfront_tooltips

Подборка бесплатных курсов про базы данных и SQL

Часто в обязанности системного аналитика входит работа с базами данных(БД). В моем опыте это в основном были задачи такого типа:

1. Понимать структуру БД, доставать SELECT-запросами нужные данные: например, выгрузить отчет для анализа бизнес-показателей.
2. Писать задания на разработку, указывая конкретные таблицы и поля, формат данных и их взаимосвязи. Такой подход точно необходим при интеграциях.
3. Проверять работу системы, анализируя корректность и полноту данных в БД (все ли поля заполняются нужной информацией, например).
4. Проектировать логическую модель БД, опираясь на выявленные при анализе сущности предметной области.

Тем не менее, эти навыки получается применить не всегда: где-то NoSQL, где-то команда делает только API, где-то микросервисы и т.д. Поэтому мне не раз приходилось забывать и вспоминать заново основы SQL и реляционных БД. За это время накопился список неплохих бесплатных курсов по этой теме.

Вот эти курсы, расположенные в порядке возрастания сложности:

1. SQL для непрограммистов - очень хороший практический курс для начинающих, на мой взгляд. С заданиями на реальной БД и понятными объяснениями.
2. sql-ex - именно объяснения были не все понятны, но тренажер для запросов там классный.
3. Введение в базы данных - тут больше про проектирование, нормальные формы и пр. Не всё подробно разъясняют, но в целом курс полезный.
4. Введение в реляционные базы данных - теоретические основы от МФТИ. Сложно, но интересно.

ER-диаграммы обычно рисую в draw.io. Но именно для обучения хорошо подходят программы, где сразу по схемам можно создать БД: MySQL Workbench, ERwin. Из бесплатных клиентов мне нравится DBeaver, из платных - TablePlus.
А какие у вас любимые инструменты для работы с БД?

Полная версия интервью для Профессионалы 4.0 о работе системного аналитика.

​​#breakfront_tooltips

По итогам недавнего поиска работы делюсь ресурсами с вакансиями и своим алгоритмом подготовки к собеседованиям.

Ресурсы для поиска работы

Для всея IT:

- LinkedIn - это социальная сеть для рабочих контактов. Иногда рекрутеры сами находят ваш профиль и присылают вакансии. Это международный сайт и там вполне реально найти работу в зарубежной компании, однако он заблокирован на территории РФ (из-за отсутствия серверов с персональными данными в России).
- ХабрКарьера - русский аналог LinkedIn, уже довольно популярный как у соискателей, так и у рекрутеров. Здесь удобно смотреть рейтинги компаний и читать отзывы сотрудников.
- g-mate - помогает подбирать вакансию/кандидата по заточенным под IT параметрам. Возможен поиск вакансий сразу по нескольким профилям. Например: менеджер/аналитик/архитектор. Также есть телеграм-бот, он высылает список вакансий, подходящих под запрос.
- HeadHunter и SuperJob - вряд ли кто-то не в курсе, но для полноты списка оставлю.
- Ханти - проект для реализации схемы "рекомендуй братуху".

Для аналитиков:

- https://news.1rj.ru/str/analyst_job
- https://news.1rj.ru/str/foranalysts
- Анализ и проектирование в ИТ-проектах - группа в FB
- Бизнес-аналитики. Вакансии и резюме. Freelance - группа в FB

Итак, где искать понятно, теперь про "как искать".

Алгоритм подготовки

Для меня поиск работы и походы по собеседованиям - довольно стрессовое занятие. Хотя понимаю, что это полезный и интересный опыт. И чтобы сосредоточиться больше на пользе и интересе, а не на переживаниях, решила подготовиться.

Алгоритм был таким:

1. Определить цель поиска, критерии успеха и ограничения (время, деньги, локация и пр.).
2. Выписать пожелания для будущей работы с приоритетами.
3. Выяснить, какие бывают вопросы и темы для обсуждения на собеседованиях.
4. Повторить то, что знаешь и умеешь.
5. Изучить незнакомые вопросы, заполнить пробелы в знаниях.
6. Определить границы своих компетенций.
7. Составить список вопросов для работодателя.
8. Составить список признаков "точно не того" работодателя.
9. Сделать таблицу с перечнем работодателей, их контактами, комментариями, статусами и датами собеседований.

В дополнение пара статей с вопросами на собеседованиях для системных аналитиков: раз, два.

​​#breakfront_analysis_fails

ОБРАТНАЯ СОВМЕСТИМОСТЬ

Начну рубрику "Ошибки анализа", где буду писать про фейлы, которые встречала или делала сама.

Первой расскажу про распространенную и довольно опасную проблему: отсутствие обратной совместимости при обновлениях.

Обратная совместимость - это способность ПО при обновлении поддерживать и новую, и старую функциональности.

Хороший пример обратной совместимости - мобильные приложения. Допустим, на главном экране банковского приложения отображался баланс на счете. А в новой версии приложения вы решили показать на главном экране весь триллион услуг банка.

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

Соответсвенно, вам необходимо в новой версии серверной части оставить данные о балансе для главного экрана, которые будут отдаваться в приложение наряду со списком услуг. И каждая версия получит то, что ожидает от сервера, и не сломается.

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

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

К сожалению, об этом нередко забывают. В результате ломаются процессы, системы, уведомления и другие потребители "старых" данных.

Однако спроектировать обратную совместимость получается не всегда. Иногда обновление конфликтует с предыдущей версией. Иногда реализация обратной совместимости требует слишком много ресурсов. Иногда поддержка старой версии невозможна. И так далее. В этих случаях аналитик отслеживает все зависимости и описывает необходимые доработки во всех задействованных системах/частях системы. Часто такая ситуация требует совместного релиза нескольких команд и даже компаний.

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

Добавлю, что для контроля обновлений, например, API, часто оперируют версионированием вроде 1.2.3. Где:

- 1 - мажорный номер версии, подразумевающей несовместимые изменения.
- 2 - минорные изменения с обратной совместимостью.
- 3 - номер релиза с исправлением ошибок с сохранением обратной совместимости.

ВЕБИНАР «ОСНОВЫ ИНТЕГРАЦИИ СИСТЕМ»

Провела тут для группы Systems.Education вебинар про основы интеграции. Мне лично было интересно😄.
https://www.youtube.com/watch?v=MfpFK17huBE

#breakfront_analysis_fails
Продолжаю рубрику с ошибками анализа.

ПАГИНАЦИЯ

Пагинация - это выдача данных по частям, разбитыми на страницы или блоки. Например, товары интернет-магазина можно выдавать, сортируя по дате создания, разными способами:
-с 1го по 50й,
- 15 товаров, следующих за товаром с артикулом 1111-111,
- товары страницы 4 при размещении 100 записей на странице,
- и т. д.

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

При обычном положении вещей мы отдаем только отфильтрованные данные. То есть отправляется запрос на показ товаров с указанием данных для фильтрации. Внутри одной категории товаров не так много, как во всем интернет-магазине (хотя тоже может быть довольно большое количество). То есть в ответе на запрос будет не миллион товаров, а, например, несколько тысяч.

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

Поэтому нельзя давать возможность посмотреть сразу ВСЕ. Даже если сейчас в вашем интернет-магазине 500 товаров - через 3 года их может стать 500 тысяч.

И даже если сейчас вы не хотите или не можете делать пагинацию, надо хотя бы сделать ограничение. Например, чтобы можно было получить только первые 1000 записей. Также необходимо делать ограничение, если хотите дать возможность потребителю выбирать количество товаров на одной странице. Например, сделать максимум 100 - тогда пользователь может посмотреть по 10, 15, 50, 100 записей на странице, но не по 1000.

Пагинация делается при разработке и ее необходимо описывать в требованиях. https://twirl.github.io/The-API-Book/index.ru.html (глава 11 п. 16), тут и тут есть про виды пагинации и какие с ней могут возникнуть трудности.

#breakfront_tooltips

Выложу и тут свою памятку для погружения в новый проект.

#breakfront_tooltips

Что почитать/посмотреть про интеграции c REST-like API

В порядке возрастания сложности:

- Наталья Косинова. Мастер-класс: Интеграция информационных систем (вебинар)
- Мой вебинар про введение в интеграции
- Андрей Бураков. REST, что же ты такое? (вебинар или статья)
- Brian Cooksey, An Introduction to APIs (короткий бесплатный курс на английском)
- А. Лоре, Проектирование веб-API (книга)
- Бесплатный курс по документированию API
- Спецификация OpenAPI
- Сергей Константинов, API (короткая бесплатная книга)
- Крис Ричардсон: Микросервисы. Паттерны разработки и рефакторинга (книга)
- Хоп, Вульф: Шаблоны интеграции корпоративных приложений (книга)

#breakfront_tooltips

Идентификаторы

В информационных системах, и особенно в их базах данных, необходимо использовать уникальные идентификаторы для объектов. Как правило, это числовые или текстовые поля.

Например, заказ в интернет-магазине мы все привыкли идентифицировать по номеру. Обычно это человекочитаемый код, вроде 34538.

Можно предположить, что всего у интернет-магазина на момент нашего заказа было 34537 заказов в базе. То есть в качестве идентификатора заказа система интернет-магазина генерирует десятичные целые числа путем автоинкремента. То есть при создании заказа БД прибавляет к Id последнего объекта 1.

Это довольно распространенная практика, простая в реализации и понятная всем людям. То есть директор интернет-магазина посмотрит на номер последнего заказа сразу поймет, сколько у него всего было заказов.

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

Еще, если я на странице своего заказа вижу ссылку http://store.ru/order/3 - ничего не мешает мне заменить 3 на 2 и потенциально увидеть заказ другого пользователя. Если доступ к нему не закрыли, конечно. Однако часто этот доступ не закрыт:)

В общем, порядковый номер заказа в БД - чувствительная информация, часто закрытая договорами о неразглашении.

Что же делать? Можно путать следы: начинать отсчет с 10000, например. Но в целом от перечисленных опасностей это не спасает.

Часто используют какой-то составной код, сформированный по внутренней логике приложения. Например, “номер заказа в регионе”-”номер заказа у пользователя”. Кажется, примерно такой способ сейчас используют все крупные e-commerce игроки, когда показывают номер заказа покупателям. Потому что им важно, чтобы человек увидел свой заказ и не впал в ступор. Чтобы он мог где-то внести номер этого заказа или сказать его сотруднику магазина.

Этот способ не очень удобен тем, что нужно поддерживать внутреннюю логику генерации этих кодов. Особенно проблематично, если заказы создаются в разных экземплярах сервиса. Так что, возможно, внутри БД магазина скрыты другие кода - GUID или UUID.

GUID - Globally Unique Identifier, статистически уникальный 128-битный идентификатор. GUID выглядит так: b118c6e2-e0a5-4e83-81d3-8320a24eb8bf.

UUID - это аналогичный код, только формирующийся по другим правилам.

Самостоятельно guid’ы можно генерировать, например, здесь. Большинство программ для разработки включают в себя функции для генерации GUID/UUID.

GUID/UUID делают несколько сложнее взаимодействие человека с системой, а также имеют бОльший объем и могут несколько замедлить работу с БД.

Тем не менее, сейчас такие кода очень часто используют в качестве идентификаторов. И вот почему:

1) Уникальность - вероятность, что вы сгенерируете guid, который уже является где-то идентификатором настолько мала, что ей пренебрегают.
2) Сложно подобрать - простым перебором явно не получится.
3) Используется стандартный алгоритм генерации, не требующий закладывания специальной логики в приложение.
4) Не надо следить за уникальностью идентификаторов и актуальностью логики в разных частях системы.

В итоге, можно сделать вывод, что клиентам лучше показывать код, который никак нельзя “расшифровать”, чтобы получить информацию о заказе. А для внутренних процессов и разработки удобно использовать GUID или UUID.

Про техническую сторону сравнения GUID и автоинкремента можно почитать здесь.

Ооо, возвращение легенды! Если где и учиться сбору требований, то здесь: https://news.1rj.ru/str/systems_education/245

Подготовила совместно с systems.education воркшоп по проектированию интеграций c REST-like API.

Очень рада, что получилось реализовать эту задумку. Лично мне не хватало материалов, где бы рассказывали про процесс интеграции целиком, а не только про методы, способы и прочие «кусочки пазла». Училась этому на своих и чужих ошибках, по частям выхватывала информацию из разных источников. Поэтому особенно приятно сформулировать свой подход в цельный процесс.

В итоге на воркшопе проектируем интеграцию по шагам - от общего к частному. От бизнес-задачи до контракта API.

Мы уже провели несколько пилотов, так что 12-13 ноября будет обкатанная и “зрелая” программа.
Особенно подойдет тем, кто еще не работал с интеграциями или работал, но чуть-чуть. Но также поможет структурировать знания и, возможно, познакомиться с новым подходом более опытным коллегам.

Записаться можно тут: https://systems.education/rest-workshop

#breakfront_tooltips #breakfront_analysis_fails

ДОСТУП К ДАННЫМ В API

Чтобы подобраться к данным из API клиент, как правило, проходит два этапа: аутентификация и авторизация.

Аутентификация - это проверка подлинности пользователя (правильный логин и пароль, например). Очень часто клиент проходит аутентификацию и получает JWT-токен, с которым делает запросы к API разных сервисов. Сервисы проверяют подлинность и актуальность этого токена при каждом запросе. У токена задается время жизни, по прошествии которого токен надо обновить. Если токен неверный или “протух”, API ответит на вызов ошибкой.

Примечательно, что даже сервис, который сам не генерировал JWT-токен, имея соответсвующий ключ, может проверить подлинность и актуальность токена. Что делает эту технологию очень удобной в случае сервисно-ориентированной и микросервисной архитектуры: достаточно сделать один сервис аутентификации, который будет хранить данные клиентов, выдавать токены и заботиться о безопасности, а остальные сервисы будут иметь дело только с токенами.

Также в JWT-токене может быть какой-то payload, то есть “полезная нагрузка”: данные, которые можно передавать прямо в токене, сообщая что-то сервису. Например, там может быть id пользователя, его роль и доступы и пр. В интересах безопасности payload можно зашифровать. Но, например, в системах, работающих в контуре компании под VPN какие-то данные можно передавать открыто и тогда их легко получить сразу из токена.

Тема аутентификации очень обширна и технически нетривиальна. Но часто в компаниях принят единый стандарт аутентификации, разработкой этого сервиса занимается отдельная команда с активным участием отдела безопасности. Остальным остается только получать и проверять токены:)

Вот с авторизацией проектировщики API работают гораздо чаще.

Авторизация - это проверка, есть ли у пользователя права на выполнение действия.

На поверхности авторизации лежит ролевая модель и доступ к ресурсам по ролям. Пользователи с ролью “сотрудник” не имеют доступа к ресурсу с зарплатами, в отличие от пользователей с ролью “руководитель”. Может быть более сложная логика: пользователи с ролью “продавец” видят только товары со статусом “готово к продаже”.

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

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

Вы предоставляете один интерфейс для всех. Причем магазины и сети магазинов делают на своей стороне интерфейс для продавцов. То есть на каждого вашего партнера-организации приходится какое-то количество пользователей.

Скорее всего, у вас будет метод получения заказа по UUID/GUID. И критически важно не давать пользователю из одного магазина получать заказы другого магазина. Просто представьте, что будет, если через ваш API ВкусВилл сможет получать заказы для X5.

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

Кто-то вам может сказать: зачем заморачиваться, у нас же заказы не инкрементом пронумерованы, а UUID/GUID - их очень сложно подобрать. Но их же можно и не перебором вычислять, а, например, перехватить какие-то вызовы и разжиться нужным списком идентификаторов. Конечно, случайно это сделать не получится, но компании могут на многое пойти, чтобы узнать о продажах своих конкурентов.

В итоге, очень важно внимательно и скрупулезно обдумывать политику доступов к API. Причем не только на уровне доступов к методам и ролевой модели, но и на уровне логики приложения.

У systems.education тут стартовал новый воркшоп по очередям и кафкам: https://systems.education/kafka-workshop.

Будет интересно тем, кто хочет все потрогать руками, я вот записалась)

Что можно почитать и послушать, чтобы познакомиться с обменом сообщениями/брокерами сообщений/Kafka/Event Driven Architecture (EDA):

1. Базовая книга “Шаблоны интеграций корпоративных приложений” Г. Хоп и Б. Вульф - в плане практических примеров может быть где-то устарела, но основные паттерны и понятия интеграции через обмен сообщениями там есть и довольно хорошо описаны.
2. “Микросервисы. Паттерны разработки и рефакторинга” К. Ричардсон - хорошая книга, чтобы познакомиться со всеми современными способами интеграций. В главах 5 и 6 дается базовое разъяснение EDA, Event Streaming и Event Sourcing и зачем они вообще нужны.
3. Выпуск подскаста Podlodka про менеджеры очередей
4. Выпуск подскаста Podlodka про EDA (на самом деле больше про Kafka)
5. Отдельная статья про Event Streaming and Event Sourcing
6. И про outbox pattern - хороший способ реализации отправки сообщений из БД

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

В одной из рассылок от ByteByteGo пришла прекрасная инфографика с 12 способами сделать API безопаснее. Буду по мере сил публиковать более подробное описание каждого из пунктов.

Итак, первый способ - это HTTPS

HTTPS  -  это HTTP с обеспечением безопасности (HTTP over TLS/SSL).

В рамках взаимодействия по HTTPS происходит шифрование данных и проверка сертификатов. 

При установке соединения сервер отправляет клиенту свой сертификат и открытый ключ (public key). На основе открытого ключа генерируются сессионные ключи (session key), которые живут только одну сессию.

Далее с помощью session key клиент сверяет данные из сертификата с данными сервера, от которого приходят запросы. Если данные (например, имя) сервера не совпадают с указанными в сертификате - клиент может прервать соединение, либо сообщить о проблеме пользователю.

Аналогичным образом сервер может проверять сертификат клиента. Так HTTPS-соединение помогает избежать перехвата данных. 

Но даже если данные будут перехвачены - их нельзя будет просто так прочитать. Так как HTTPS обеспечивает шифрование данных. Расшифровать сообщения можно только с помощью закрытого ключа (private key).

Часто, при взаимодействиях внутри контура компании, HTTPS-ресурс используют именно при аутентификации/получении токена. А дальнейшее взаимодействие идет по обычному HTTP.
То есть создается отдельный API для авторизации - туда по HTTPS передается логин и пароль. В ответ сервис авторизации присылает токены.
Далее клиент с этими токенами идет в API сервисов, содержащих нужные ему данные. Особенно это удобно при микросервисной архитектуре - клиенту не нужно проходить аутентификацию в каждом из сотни микросервисов.

Если взаимодействие между сервисами происходит под VPN, то часто в HTTPS нет необходимости.
Но все же так шанс перехватить токен становится выше, поэтому важно, чтобы время жизни токена было небольшое.

Источники:
- https://www.cloudflare.com/learning/ssl/what-is-a-session-key/
- https://ru.wikipedia.org/wiki/HTTPS
- https://en.wikipedia.org/wiki/HTTPS
- Вот тут можно почитать, зачем сайтам использовать HTTPS и как это влияет на SEO