GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

⚡ 6 способов пагинации в REST API ⚡

Когда мы получаем списки через API, то получать весь миллион записей сразу - плохая идея. Лучше получать по частям — порциями.

Пагинация — отвечает за порционное получение данных в REST API.

Помогает:
✔️ не перегружать как сервер, так и клиента API;
✔️ ускорить отклик на запрос;
✔️ пользователю не надо ждать данных вечность.


👇 6 способов пагинации на примере получения списка пользователей:

🔹 Offset
Используются параметры смещения (offset) и ограничения (limit) для определения начальной точки и количества возвращаемых записей.

GET /users?offset=0&limit=3

✅ Простая в реализации
✅ Подходит, когда данных немного
➖ Неэффективна при больших offset: система перебирает все записи, чтобы дойти до нужных


🔹 Page
Используются номер и размер каждой страницы для переключения между ними.

GET /users?page=2&size=10

✅ Привычно для пользователей (страницы)
✅ Подходит, когда пользователь реально листает страницы
➖ Проблемы те же, что у offset


🔹 Cursor
Используется курсор (id записей в БД) для обозначения позиции в наборе данных.

GET /users?cursor=123

✅ Быстрая и надёжная при больших объёмах данных.
✅ Часто используют в соцсетях, чатах и платежных системах из-за постоянного потока новых данных.


🔹 Keyset
Используется ключ для фильтрации набора данных. Часто это первичный ключ или другой индексированный столбец.

GET /users?afterId=123&limit=3

✅ Быстрая при больших данных
✅ Подходит для бесконечной прокрутки (infinite scroll)
➖ Требует уникального и индексированного поля (обычно ID)


🔹 Time
Используются временные метки или дата для разбиения записей на страницы.

GET /users?startTime=...&endTime=...

✅ Идеальна для систем, где данные привязаны ко времени: логи, события, аналитика


🔹 Гибридная пагинация
Этот метод объединяет несколько методов пагинации, чтобы максимально использовать их сильные стороны.

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

➖ Чуть сложнее реализовать
➖ Может путать клиентов API


#RestApiGA

🤔 В чем отличие REST от RESTful API? 🤔

Вопросы “Что такое 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.

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


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

#RestApiGA

📒 3 вида параметров в REST API, где чаще всего путаются аналитики 📒

Мини-гайд про виды параметров HTTP (REST API) запросов, в которых чаще всего косячат новички:


👉 query-parameters — после ? в URL
фильтры, сортировки, пагинация, поисковые строки, api-key (если так принято).

Формат:

GET /products?name=milk&limit=10&offset=20&order=price,asc

Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query вместо тела json.
• Дробят сортировку в несколько параметров, вместо одного аккуратного.
• Добавляют query в POST/PUT без причины.



👉 path-parameters — часть пути (эндпоинта)
Идентификатор конкретного ресурса или вложенного ресурса.

Формат:

GET /products/{productId} → GET /products/3a46b…

Можно внутри пути:

PATCH /products/{productId}/archive

Типичные проблемы:
• Отправляют ?productId=… в query, хотя это сущность, а не фильтр.



👉 body-parameters — тело запроса json
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.

Формат:

{
"name": "Яблоки Гала",
"shortName": "Гала",
"description": "Сладкие и хрустящие"
}

Типичные проблемы:
• Отправляют огромное количество параметров в GET, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.


В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры


Изучайте, запоминайте и не путайтесь 🤝

#RestApiGA #FarmFreshGA

🙈 Не про «успешный успех» 🙈

Привет! С вами как всегда я, автор канала и основатель сообщества GetAnalyst - Екатерина Ананьева.

По логике блогинга, я должна ежедневно продавать, постить «идеальную жизнь» и бесконечные сториз и рилс. Но за год в инстаграм (запрещен в РФ) - 2.5 фото.
И это осознанно.



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




Я много работаю (до 50ч/нед) и учусь (до 12ч/нед).
Я отдаю невероятно много энергии проектам, вашему обучению и своему тоже.

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

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

Баланс между работой и отдыхом — мой самый сложный и важный проект.

Я могу показать дом, машину, жизнь в пальмах и бренды. Станцевать или пошутить шутку.
👉 Но что это поменяет в вашей карьере?

Гораздо честнее говорить: путь аналитика — это труд, дисциплина, любопытство и постоянное развитие.
И давать вам тут 90%+ времени полезные материалы.

❗️ Ваше время на каждый текст должно быть проведено с пользой.


А я хочу быть счастливой, без необходимости ежедневно доказывать это в сторис 🙂


Если вы здесь ради профессии и роста — вы в правильном месте. А иллюзии, что можно за 2 месяца с нуля стать системым аналитиком, или сменить работу на зарплату x2 натренировавшись проходить собеседования без реальных знаний?
Так можно, но тут этого нет, и это часто имеет негативный исход.

Я зануда, и я про реальные знания 🤓
Ценю ваше время на каждый пост.

Немного фото из жизни добавила к посту. Дополним инстаграм))

И спасибо, что вы со мной! ❤️


P.S. Буду рада, если в комментариях поделитесь, какие ещё хобби есть у системных аналитиков, кроме работы 😃

🤖 Как аналитики работают в Generative AI проектах: старт карьеры, ключевые навыки и задачи 🤖

Повсюду «AI, AI, AI»: Generative AI, LLM, Fine-Tuning, RAG — но что это значит для системных и бизнес-аналитиков? Куда бежать, что изучать и с чего начать, если уже сейчас хочется новый виток в карьере в направлении AI?

В этом выпуске разбираем реальные проекты, задачи и роли в компании red_mad_robot: где место аналитика в Generative AI, какие навыки нужны на старте и как меняется работа команд по сравнению с «обычными» IT-проектами.

🔗 Сайт эпизода
🔗 Компания red_mad_robot
🔗 AI акселератор для СА и БА

Анастасия и Игорь «раскрывают кухню» Generative AI-проектов: RAG vs Fine-Tuning, Small LLMs, метрики качества, безопасность и свой реальный опыт работы. К концу эпизода вы поймёте, с чего начать переход, какие артефакты добавить в портфолио и чего ожидать на собеседованиях.

✍️ Слушайте, делайте заметки и задавайте вопросы в комментариях, чтобы мы могли дать вам максимум пользы от этого выпуска!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


GetAnalyst - сообщество, где аналитики каждый день получают новый опыт и самые актуальные знания! 🚀

✨ Открыта запись на практическую программу REST API для СА и БА 🚀

В вакансиях на Системных Аналитиков постоянно встречаются эти формулировки:

+ Знание REST API / JSON
+ Опыт проектирования и документирования API
+ Понимание принципов работы мобильных приложений
+ Знание OpenAPI / Swagger
+ Навык тестирования API Backend (Postman)

Все эти навыки ожидают от Middle и Senior СА, которым предстоит работать с Backend-, мобильными командами или в проектах с интеграциями.


❗️ И это не про интеграции и чтение готовой API-документации, а про умение проектировать REST API методы с нуля, самостоятельно, и выстраивать стандарты API на любом проекте.


Мы приглашаем вас освоить REST API на практике в рамках одного большого проекта на программе:

💻 Дизайн REST API
🗓 Старт 5 ноября 2025

👉 Узнать подробности и записаться


В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.

Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты СА 🛠



🎯 В результате обучения вы создаете свой проект API-документации в Postman, OpenAPI (Swagger) и умеете делать работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩
Это самая весомая и “программистская” часть вашего профессионального портфолио.



Есть вопросы?
Пишите @getanalyst или заполняйте анкету предзаписи. Мы свяжемся с вами, поможем оценить текущие навыки и ответим на вопросы! 🤝

✅ Квиз по REST API - результаты детальный разбор ✅

Анализируем статистику квиза и разбираем варианты ответов:

--------

👉 1. Какой метод + URL выбрать для просмотра каталога продуктов (для роли покупателя)?

✅ B. GET ../api/v1/products (47%)
❌ H. GET ../api/v1/public/products (32%)

Итого:
Меньше 50% участников выбрали верный вариант.
Вариант G со структурой URL под микросервисную архитектуру, был проигнорирован - всего 7% голосов.

--------

👉 2. Какой метод + URL выбрать для создания заказа покупателем?

❌ D. POST ../api/v1/order/create (47%)
✅ B. POST ../api/order-management/v1/orders (23%)

Итого:
Шок! 😱
Только 23% участников смогли выявить правильный ответ! Остальные выбрали решение, которое применяют для HTTP API без архитектурного стиля REST.

--------

👉 3. Какой метод + URL выбрать для редактирования информации о продукте фермером?

✅ F. PATCH ../api/v1/products/productld} (62%)
▫️ G. PUT ../api/catalog/v1/products/{productld} (20%)

Итого:
Большинство участников отлично справились с заданием!

--------

Разбор всех ответов - на картинках к посту.

Запоминать ошибки легче, чем правила.
Сохраните пост как шпаргалку и сверяйтесь при проектировании 🤝


#RestApiGA #FarmFreshGA

🔥 9 элементов URL в REST API: чек-лист с примерами 🔥

Пример:

PATCH https://farmfresh.com/api/catalog/v1/products/{productId}

1️⃣ Метод HTTP
GET, POST, PUT, PATCH, DELETE
Не относится к URL, но связан с ним.
Подробнее тут

2️⃣ Протокол
Для REST API всегда HTTP / HTTPs

3️⃣ Доменное имя
Основной адрес, по которому можно обращаться к серверу с API-приложением (backend)

Путь (Path)
Включает в себя один или несколько сегментов, разделённых слешами (/):
4️⃣ api - указатель на каталог API сервера, может быть в доменном имени
5️⃣ имя API - указывает на конкретный интерфейс API, предназначенный для разных пользователей системы, либо для разных микросервисов
6️⃣ v1 - версия API, важна для поддержки совместимости с предыдущими версиями

Эндпонит:
7️⃣ products - это ресурс, к которому осуществляется доступ. В данном случае “продукт”. Может быть в единственном числе (event)
8️⃣ {productId} - это параметр в пути URL (path-параметр), указывающий на конкретный продукт по его id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено (например, идентификатор 2324)

9️⃣ иерархия с вложенными сущностями/действия над объектами.
Примеры:
GET ../orsers/(id}/payments - получить платеж(и) по заказу
PATCH ../users/(id}/block - заблокировать пользователя


9️⃣ Query-параметры
Дополнительные параметры после ?, необязательны.
Если их несколько, то перечисление через символ &.
Обычно используются для фильтров, сортировок и пагинации при получении списков методом GET, но могут быть и в других.

Пример:
GET …/products?offset=0&limit=10&name=брокколи
👉 offset=0&limit=10 - запрос результатов с 0-го, 10 элементов на страницу. Это два отдельных query-параметра - элементы пагинации (постраничного получения данных)
👉 name - фильтр по названию продукта


➕ Есть исключения из правил, особенности и ошибки. Часть разобрала на картинках к посту - ответы квиза.


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

#RestApiGA #FarmFreshGA