⭐️ Про REST API, и разницу с RESTful - структурированное определение ⭐️

Вопросы “Что такое REST API?” или “Что такое RESTful API?” в разных вариациях и формулировках задают на технических собеседованиях системных аналитиков 👀

Чтобы уверенно отвечать на них и глубоко понимать значение REST API, необходимо знать этот набор определений:


1️⃣ API — программный интерфейс для обмена данными между приложениями (мобильное приложение - сервер, сайт - сервер и другие).


2️⃣ HTTP — это протокол, лежащий в основе любого обмена данными в Интернете, который определяет, как сообщения должны формироваться и передаваться между клиентами и серверами. Он работает как система запросов и ответов: клиент отправляет запрос на сервер, а сервер возвращает ответ.

HTTP включает в себя определенные методы (GET, POST, PUT, DELETE и другие) и коды состояния (HTTP-200, HTTP-201 и другие), которые служат для управления взаимодействием и сообщают о результатах этих взаимодействий.


3️⃣ REST (Representational State Transfer) — это архитектурный стиль проектирования программного обеспечения для создания веб-сервисов (сервер-приложений). Это набор правил и принципов, по которым разрабатываются веб-сервисы.

REST предполагает, что данные или состояние программы можно представить в виде ресурсов (например, текстовых файлов, изображений, сервисов), и эти ресурсы можно адресовать через URL (веб-адреса).

Важным принципом REST является то, что с ресурсами можно выполнять стандартные операции через HTTP-методы, такие как GET, POST, PUT, DELETE и т.д.


4️⃣ REST API — программный интерфейс приложений (API), который позволяет взаимодействовать с веб-сервисами (сервер-приложениями) с использованием принципов REST. Это означает, что API позволяет обмениваться данными через стандартные HTTP-запросы (GET, POST, PUT, DELETE и т.д.) и может возвращать данные в формате, удобном для клиента (чаще всего в JSON или XML).


5️⃣ RESTful API — это термин, который подчеркивает строгое следование принципам REST. То есть, когда мы говорим, что API является "RESTful", мы хотим сказать, что он полностью соответствует архитектурным стилям и ограничениям, определенным в идеале REST. Это подразумевает, что API не только использует HTTP-методы и работает через URL, но и строго следует всем рекомендациям и лучшим практикам REST.

По сути, RESTful API — это более точное или строгое использование термина REST API. В обоих случаях речь идет о системах, которые позволяют взаимодействовать с веб-сервисами в соответствии с архитектурой REST, но использование слова "RESTful" подразумевает более глубокое соблюдение принципов REST.

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


Желаю вам успешных технических собеседований 😉

💫 Вопросы и ответы по REST API: собеседование на системного аналитика 💫

В новом эпизоде подкаста мы обсуждаем вопросы по REST API с собеседований на позицию системного аналитика, и разбираем ответы на них с примерами.

Эпизод рекомендуется к прослушиванию как для начинающих, так и для опытных системных аналитиков, стремящихся углубить свои знания в теме проектирования REST API и успешно проходить технические собеседования. Особенно рекомендуется, если у вас завтра техническое интервью 🙂

00:59 - О структуре выпуска и причине выбора темы.
02:25 - Что такое REST API и его отличия от RESTful.
10:10 - 6 главных принципов REST API.
15:52 - Структура запросов и ответов REST API: типы методов и отличия между ними.
23:50 - URL и URI. Структура URI запроса. Примеры.
query и path-параметры, headers, тело запроса и ответа, авторизация, коды состояний HTTP.
29:10 - Ресурс в контексте REST API. Связь объектов данных (ресурсов) REST API и БД.
31:05 - Query-параметры в запросе. Элементы пагинации в query-параметрах и body. Path-параметры.
36:28 - Что спрашивают по авторизации в API на собеседовании. Про безопасность. Заголовки запросов - Headers. Форматы сообщений в Body.
39:27 - Коды ответов HTTP, их назначения и какие знать обязательно. Вопросы с подвохами про отличия между кодами ответов HTTP в разных ситуациях.
43:40 - Отличия между POST и PUT. Идемпотентность. Получение данных через POST.
47:10 - Другие важные технические вопросы про асинхронные запросы и Webhook-и.
48:48 - Виды практических задач по REST API на собеседованиях для системных аналитиков.
54:00 - Вопросы про опыт работы с REST API. Рекомендация - используйте портфолио (личные демо-проекты).
56:48 - Заключение и рекомендации по самостоятельному освоению REST API.

Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify

Подписывайтесь и делитесь с коллегами! 😉

Проектирование и разработка REST API находится в зоне ответственности:
💫 Всей Backend-команды, если в компании есть деление на команды Frontend/Mobile/Backend,
💫 В случае кросс-функциональных команд, отвечающих за части системы, это ответственность Backend-разработчиков.

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

В процессе анализа требований, связанных с интеграциями и API, системный аналитик делает:
1. Исследование бизнес-процесса
2. Анализ требований клиентов (UI / другие системы)
3. Проектирование доработок БД
4. Разработка контрактов API
5. Использование контрактов API всеми разработчиками и их сопровождение

Системный аналитик может внести следующий вклад в реализацию задачи по проектированию REST API (по факту любого API):
🟢 предоставить информацию о том, какие данные нужны для интеграции систем, и как эти данные должны быть структурированы и переданы в API;
🟢 предложить использовать соответствующие действиям в системе HTTP-методы, такие как GET, POST, PUT и DELETE;
🟢 предложить использовать определенные структуры JSON-объектов для передачи данных в API;
🟢 помочь обеспечить безопасность API, выбрав механизм аутентификации и авторизации;
🟢 документировать API для облегчения взаимодействия между системными аналитиками, тим-лидами и разработчиками;
🟢 тестировать API через Postman, для проверки правильности его работы и соответствия постановке задачи.

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

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

#RestApiGA

📌 Проект на проектирование REST API - Smart Home GA - #SHGA 📌

Проект Smart Home GA представляет собой мобильные приложения Android и iOS, с которых можно управлять умными устройствами в доме.

Умные устройства:
- Пылесос (через сервер идет включение, выключение, проверка статуса, история уборок).
- Весы (значения отправляются с весов на телефон, с телефона на сервер).
- Светильники (через сервер идет включение, выключение, проверка статуса).
- Холодильник (через сервер можно запрашивать информацию про запас воды по кол-ву бутылок в секции бутылок, блокировать-разблокировать дверь, смотреть запас яиц по датчикам в отсеке яиц).

Для взаимодействия с сервером (Backend), то есть для отправки и получения данных по умным устройствам будет использоваться REST API. Посредником в передаче данных до устройств будет сервер Backend SHGA.

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

Наши задачи на проект:
1. Выделить процессы к автоматизации. Разработать для них UI для мобильных приложений и БД сервера.
2. Для процессов и описанных UI выделить список REST API методов к проектированию.
3. Создать контракты REST API для этих методов: GET/POST/PUT/PATCH/DELETE + URL + Headers + Body (JSON) + ... .
4. Посмотрим как переносить контракты в один из инструментов Postman / Swagger.

Вводные есть, можно начинать 🙂

#RestApiGA

📰 Новости GetAnalyst 📰

🙌 Системным и бизнес-аналитикам:

1. Открыли предзапись на практическую программу REST API на специальных условиях до 18 апреля 23:59 Мск (предобучение - с 24 апреля, первая онлайн-практика 6 мая) 🚀

2. На сайте появился раздел "Карьера".
Там можно будет найти актуальные вакансии. Все вакансии будут проходить модерацию.
А первая компания, вакансии которой мы уже опубликовали, очень даже вау. Проводила у них внутреннее обучение по искусственному интеллекту. Это круто, когда компании развивают своих сотрудников!

3. Оформили YouTube-канал 📹

4. Освежили дизайн в Instagram. Туда на этой неделе опубликуют подборку книг по системному анализу - самую-самую полную, следите за актуальным в сториз 📚


🙌 Работодателям

1. Открыли предзапись на практическую программу REST API на специальных условиях до 18 апреля 23:59 Мск (предобучение - с 24 апреля, первая онлайн-практика 6 мая) 🙂

2. На сайте в разделе Карьера добавили блок "Работодателям".
Теперь у нас можно публиковать вакансии.

Стараемся сделать IT-сообщество максимально полезным.
Делитесь новостями с вашими коллегами и HR. А мы с командой GetAnalyst будем продолжать развивать наш проект для вас дальше ❤️

#RestApiGA #HrGetAnalyst

🤝 Связь CRUD-модели и методов REST API 🤝

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

C - Create - Создать - POST / PUT
R - Read - Читать / Смотреть / Получить - GET / POST в искл. случаях
U - Update - Изменить - PATCH / PUT
D - Delete - Удалить - DELETE / PATCH в случаях архивации

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

❗️Важно помнить, что эту модель нужно прогнать не только для ОДНОГО объекта, но и для МНОГИХ.
❗️Важно уточнять, кто и когда это будет делать.

Статья по созданию CRUD-модели с подробным разбором примера доступна по этой ссылке.

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

Используйте её, чтобы структурировать процесс работы с функциональными требованиями 🙌

🤝 Пример применения CRUD-модели для проекта Smart Home GA #SHGA 🤝

🔸 Сущность:
Умное устройство

🔸 Роли в системе:
Администратор - может загружать данные о произведенных заводом устройствах из файла.
Пользователь - владелец устройства.

🔸 По CRUD-модели:

Create:
+ Создать устройство - пользователь активирует и добавляет устройство в свой ЛК, чтобы управлять им (1).
+ Создать список устройств - администратор загружает список устройств из файла, получаемого от завода (2).

Read:
+ Получить информацию об одном устройстве - пользователь смотрит подробную информацию об одном своем устройстве (3), а администратор смотрит информацию о любых устройствах (4).
+ Получить список устройств - только своих для пользователя (5), и общий для администратора (6).

Update:
+ Обновить информацию об одном устройстве - пользователь изменяет имя или другие настраиваемые характеристики (7), администратор может внести изменения в любые характеристики, даже в заводской номер устройства, что недоступно пользователю (8).
- Обновить список устройств - пользователю списком обновлять ничего не надо, а вот администратору такая возможность может пригодиться, если в файле при создании были ошибки, но лучше пусть удалит ошибочные данные и перезагрузит файл заново.

Delete:
+ Удалить информацию об одном устройстве - пользователь удаляет устройство из личного списка (9), а администратор из общего (10).
+ Удалить список устройств - пользователю это избыточно, а для администратора полезно в случае ошибок при загрузке файлов с производства (11).


Получился список из 11 методов, связанных с Умным устройством.

Как модель помогает? Я по порядку прохожу по списку функций CRUD и анализирую что можно, а что нельзя будет делать с сущностью в системе. Это структурирует процесс аналитики: делает его последовательным и логичным.

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

Особенно CRUD полезна для проектов "с нуля", но и при доработках тоже.

Пусть лайфхак с CRUD-моделью помогает и вам 🙂

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

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

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

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

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

📌 Структура метода REST API - чек-лист для постановки задачи на Backend-разработчика 📌

Если вы только переходите на позицию Системного аналитика, или начинаете работать с задачами на Backend и API, то этот пост с чек-листом будет работать на вас 😎


ЗАПРОС

☑️ Назначение API и список его будущих пользователей
Метод предназначен для авторизованных пользователей Smart Home GA, чтобы отображать для них список привязанных к ЛК умных устройств в мобильном приложении.

☑️ Короткое название API-метода на родном языке
Получение списка устройств

☑️ Алгоритм работы
Здесь может быть детализированное описание Use Case взаимодействия между клиентом и сервер приложением, предоставляющим API-интерфейс.
На вход пользователь передает… . Из БД, таблица … .

☑️ Тип метода REST API
GET / POST / PUT / PATCH / DELETE / TRACE …
GET

☑️ Полный URL (endpoint)
https://smarthomega.com/api/user-apps-api/v1/devices

☑️ Query-параметры
Фильтры, сортировки, пагинация, авторизация.
status: Значения - on/off/deactivated. По умолчанию: не применяется.
name: Название устройства, поиск по вхождению подстроки в строку.
limit, offset: Элементы пагинации. По умолчанию 10, 0.
и так далее.

☑️ Headers - заголовки запроса
Content-Type: application/json.
Authorization:..
User-Agent:..

☑️ Request Body - тело запроса
Здесь может быть JSON / XML / HTML / TEXT / JavaScript пример запроса.
Нет - для примера запроса.

☑️ Маппинг данных запроса
Сопоставление данных в API, БД и в API внешних систем, если метод интеграционный. Таблица.


ОТВЕТ

☑️ HTTP-код успешного ответа
HTTP-200

☑️ Headers успешного ответа
Редко описывают отдельно, обычно они стандартные на всё API.

☑️ Response Body - тело ответа
Пример JSON:

{
"devices":
[
{
"id": 1,
"name": "my robot",
"status": "off",
...
},
{
...
}
]
}

☑️ Маппинг данных успешного ответа
Сопоставление данных в API, БД и в API внешних систем, если метод интеграционный. Таблица.

☑️ Список возможных ошибок
Код HTTP, заголовки, тело ответа, описание ситуации.

Готово!

#RestApiGA #SHGA

Для чего нужен API на проекте 🧐

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


Зачем нужен API на проекте?

⭐️ Обеспечение работы мобильных, веб- и десктоп приложений.
API обеспечивает связь с сервером и доступ к базам данных.

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

⭐️ Безопасность.
API обеспечивает безопасный доступ к функциям и данным приложений, используя стандарты аутентификации и авторизации, такие как JWT Token, OAuth и другие.

Для более глубокого понимания добавила картинку к посту.

Умение проектировать и использовать API становится важным навыком для разработчиков и системных аналитиков. В особенности REST API, который используют более 80% систем во всём мире.

А как аналитики участвуют в разработке и проектировании API - рассказала в этом посте.

#RestApiGA #SHGA

Привеееет! Пора проходить квиз на знания REST API! 😉

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

Будьте внимательны 😉 Некоторые вопросы вызывают огромное желание спорить! Обсуждаем в комментариях.

Ответы будем разбирать в начале следующей недели.

#RestApiGa #SHGA