Эту неделю планировали плавно вернуться в рабочий режим – без новых сложных тем, но всё же с пользой 🤓
И кажется, у нас получилось! 💃

И всё так под конец недели немного поговорим о работе. А точнее об образовании для работы.
У большинства из нас существует устойчивое мнение, что без диплома о высшем образовании никуда работать не возьмут. Но так ли это? 🤔🤔

Предлагаем прослушать #GApodcast от нашей Екатерины, где поразмышляем на тему необходимости высшего образования в сфере IT для специалистов, которые только ступили на путь системного анализа.

Слушаем подкаст по ссылке:
🔗 ССЫЛКА НА ПОДКАСТ

И отличного настроения вам в эту пятницу! Вы большие молодцы 😉 🤪

🤔 ЧТО ТАКОЕ API? 🤔

API (Application Programming Interface) - это набор правил и протоколов, которые позволяют различным программам взаимодействовать друг с другом.

🥷: Читается как «ЭйПиАй» или в обиходе «Апи», «Апиха» и аналоги.

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

Приведём три простых примера про разработку и использование API:

1️⃣ Сервисы социальных сетей
Facebook, Instagram и Twitter предоставляют API, которые позволяют различным приложениям и сайтам получать доступ к данным пользователя, таким как профиль, фотографии и т.д. Это позволяет разработчикам создавать приложения, которые могут использовать данные из социальных сетей, например, для авторизации или для отображения фотографий.

2️⃣ Карты и местоположение
Google Maps и другие сервисы карт и местоположения также предоставляют API, которые позволяют другим приложениям использовать их функциональность. Например, мобильное приложение для заказа такси может использовать API Google Maps, чтобы определить местоположение пользователя и проложить маршрут.

3️⃣ Банковские сервисы
Банки также предоставляют API, которые позволяют другим приложениям получать доступ к данным о балансе, транзакциях и т.д. Это может использоваться, например, для создания приложений для управления личными финансами, которые позволяют пользователю просматривать свой баланс и транзакции из разных банков в одном месте.

КОРОЧЕ ГОВОРЯ:

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

Знание темы API и умение его читать и проектировать – это важнейший хард-скилл системного аналитика.
На собеседованиях на позицию СА (🥷: И даже иногда и для БА уровня мидла и выше) часто задают вопросы про API (и интеграционное взаимодействие в целом), поэтому эту неделю посвятим обсуждению этой темы 🦾

#hardGetAnalyst

⚡️ПРО ВИДЫ API ⚡️

Есть несколько распространённых видов API, каждый из которых предназначен для определённых задач и целей:

⭐️ REST API (Representational State Transfer)
Это подход, акцентирующийся на использовании стандартных HTTP-протоколов и форматов данных, например, JSON или XML. REST API позволяет клиентам выполнять операции по CRUD-модели (создание, чтение, обновление, удаление) над ресурсами, представленными URL-адресами.

⭐️ SOAP API (Simple Object Access Protocol)
Это протокол, который позволяет приложениям обмениваться структурированными данными через XML, используя также WSDL (Web Services Description Language) для описания интерфейсов веб-сервиса.

⭐️ GraphQL API
Это язык запросов, который позволяет клиентам запрашивать именно те данные, которые им нужны, получая их в оптимизированном формате, и часто возвращающий данные в формате JSON.
Пример: Запрос списка друзей пользователя в социальной сети, с получением в ответ только имён и изображений профилей.

⭐️ gRPC
Это протокол, облегчающий выполнение удалённых вызовов процедур (RPC), используя для этого бинарный протокол сериализации, что позволяет обмениваться данными быстро и эффективно.
Пример: Использование gRPC для обмена данными между микросервисами в распределенной системе.

⭐️ WebSocket API
Это протокол, который позволяет установить постоянное соединение между клиентом и сервером, обеспечивая обмен данными в реальном времени без необходимости отправки повторных запросов.
Пример: Чат-приложение, где сервер и клиент обмениваются сообщениями в реальном времени через WebSocket соединение.

Существует также множество других типов API, таких как XML-RPC, JSON-RPC, HAL, OData и другие. Каждый тип API имеет свои особенности и выбор между ними зависит от конкретной задачи и требований к проекту.

Один из наиболее распространенных и широко применяемых видов API на сегодняшний день – это REST API. Освоив его, вам гораздо проще будет понять остальные протоколы, а значит ваша экспертиза будет расти.
Как и ваша ценность на рынке труда 🤩😎

#hardGetAnalyst

ЗАЧЕМ ПРОЕКТИРОВАТЬ REST API? 🧐

Системные аналитики (СА) и разработчики проектируют REST API, чтобы обеспечить общее понимание между командами бэкенда и фронтенда по взаимодействию систем.

Особенно это важно, пока бэк-часть еще не готова, а разработчики фронтенда уже хотят начать работу. Описанный REST API помогает создать понятную и эффективную архитектуру обмена данными, которая будет поддерживаться на всех этапах разработки.

Результатом проектирования REST API является его дизайн.
Дизайн REST API - это контракт между backend- и frontend-разработчиками.

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

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

Благодаря этому подходу, ускоряется процесс разработки, а также повышается эффективность и качество проектируемого решения. Этот вклад в работу команды через создание дизайна REST API обычно вносят СА 😎

По данным hh.ru, средняя з/п СА с навыками проектирования REST API в Москве варьируется от 250 000 до 350 000 рублей в месяц, а максимальная может достигать 440 000 рублей в месяц и выше 💸

Связанные навыки:
⚡️Взаимодействие с разработчиками и техническими архитекторами.
⚡️Опыт работы с интеграциями SOAP, REST, очереди.
⚡️Понимание REST/SOAP.
⚡️Умение проверить api посредством Postman.
⚡️Практический опыт работы и проектирования REST API.
⚡️Практический опыт работы с мобильными приложениями.
⚡️Практической опыт декомпозиции и проектирования сервисов.

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

Специалисты с навыками проектирования REST API на рынке востребованы, а их квалификация влияет на размер зарплаты.

Что еще важно: навыком хорошо владеют не все разработчики.
Поэтому часто руководители проектов ищут куда направить коллег, чтобы они глубоко разбирались в REST API и знали best-practice в его проектировании 😉

✨ ПРО МЕТОДЫ REST API ✨

Продолжаем с важной для системных аналитиков темой интеграционного взаимодействия систем. И сегодня поговорим про методы REST API #hardGetAnalyst

Как вы уже знаете, REST API - это архитектурный стиль проектирования взаимодействия нескольких систем. Этот стиль использует протокол HTTP для общения между системой-клиентом и системой-сервером. Поэтому интеграционное взаимодействие иногда ещё называют клиенто-серверным.

REST API позволяет клиентам выполнять операции с данными внутри ПО по CRUD-модели.
CRUD-модель представляет собой четыре основных функции, которые напрямую связаны с REST API:

1️⃣ CREATE (Создать) = POST в REST API
Это процесс для создания новой записи в системе. Например, при регистрации пользователя в каком-либо приложении.

2️⃣ READ (Прочитать) = GET в REST API
Это операция для получения или чтения данных из системы. Например, при запросе информации о пользователе, который зарегестрировался в приложении.

3️⃣ UPDATE (Обновить) = PUT или PATCH в REST API
Это операция для обновления существующих данных в системе. Например, при редактировании данных зарегестрированного пользователя в приложении: его адреса, номера телефона и так далее.

4️⃣ DELETE (Удалить) = DELETE в REST API
Это операция для удаления данных из системы. Тут отлично впишется пример, когда пользователь решил удалить свой профиль в каком-либо приложении.

Важно помнить: конкретное использование этих методов REST API может отличаться в зависимости от специфики API и/или проектируемой системы. Знание же этих методов и их различий между собой поможет определить, как необходимо споектировать интеграционное взаимодействие, чтобы получить необходимый результат.

Когда HR говорит загадками 😮
#GAhahaha

✨ РАЗНИЦА МЕЖДУ PUT И PATCH ✨

Начнём с того, что PUT и PATCH предназначены не только для изменения данных, но и для их создания.
Разберём на примере работы с комментарием к товару на маркетплейсе.

Предположим, комментарий (comment) состоит из:
- заголовка с именем пользователя (name),
- тела комментария (text).

Для создания комментария можно использовать аж три метода: очевидный POST и менее очевидные PUT и PATCH.

Например, пользователю Ивану понравился товар, который ему доставили, и он решил этим срочно поделиться. В этом случае есть три вариации создания комментария:

1️⃣ POST /comment/1
{
name: 'Иван',
text: 'Я очень рекомендую этот товар!'
}

2️⃣ PUT /comment/1
{
name: 'Иван',
text: 'Я очень рекомендую этот товар!'
}

3️⃣ PATCH /comment/1
{
name: 'Иван',
text: 'Я очень рекомендую этот товар!'
}

Предположим, используя товар, Иван понял, что результат его не удовлетворил. Теперь Иван хочет отредактировать свой положительный отзыв на негативный. Метод POST создаст только новый комментарий, но не изменит ранее созданную запись. Остаётся два варинта: PUT и PATCH.

Продолжим совсем скоро...

#hardGetAnalyst

Итак, наш рандомный Иван разочаровался в товаре и решил отредактировать свой ранее оставленный отзыв на маркетплейсе.
Мы хотим изменить только текст комментария, а значит отправлять в методе будем только text.


1️⃣ При использовании метода PUT, весь комментарий перепишется заново.
Учитывая, что в методе мы передали только текст комментария, но не передали имя пользователя, прошлая запись обновится до состояния, где имя будет отсутствовать, а текст изменится.

PUT /comment/1
{
text: 'Я вообще не рекомендую этот товар!'
}

Запись изменена, но теперь сам комментарий неполноценный - у него напрочь отсутствует информация об имени пользователя.


2️⃣ Что же произойдёт в PATCH-методе?🤔
В случае "пластыря" ("patch" с англ. "пластырь") будет изменена только та часть, которая была отправлена в запросе.

PATCH /comment/1
{
text: 'Я вообще не рекомендую этот товар!'
}

При передаче в PATCH-методе только текста комментария, имя пользователя останется неизменным, а текст комментария обновится. То, что нужно, когда нужно переписать только часть данных, а не весь объект комментария.


КОРОЧЕ ГОВОРЯ:

⚡️PATCH используется для того, чтобы изменить часть данных в записи. Говоря на языке метафор, этим методом можно прилепить "пластырь" в неактуальной части всего полотна информации.

⚡️PUT же в свою очередь обновляет полотно полностью, то есть создает новый ресурс данных. Что актуально для изменения всего объекта целиком.


Ну что ж, вам может показаться, что тема REST API довольно сложная и тернистая 😫
Отчасти так и есть. Но если вы хотите оставаться конкурентоспособным на рынке труда в сфере IT, REST API понять придётся. А для понимания необходимо изучать теорию и отрабатывать её на практике, формируя навык.