Теория API

Существует несколько архитектурных стилей API:
🛠 REST API
🛠GraphQL
🛠SOAP API
🛠gRPC API

Давай разберём главные теоретические принципы REST API?

1. API — это не только «техническая штука», это философия
Представь, что мир — это куча островов. Каждый остров — это система (банк, CRM, мобильное приложение). API — это мосты между ними.

Без API острова общаются так:
- «Эй, банк! Кидай мне данные своих клиентов в Excel по почте!»
- «Ок, но это займёт три дня, и файл сломается при открытии» 💥.

С API общение выглядит так:
- «Банк, дай мне баланс клиента 123» -> «Держи: {"balance": 5000}» (за 0.5 сек).

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

2. Главные принципы REST API (те самые, которые все любят)
🧩Stateless (без сохранения состояния)
Сервер не помнит, кто ты. Каждый запрос — независим.

Это как общение с роботом:
- Ты: «Дай мне заказ №1» -> Робот: «Вот заказ»
- Ты: «Теперь дай заказ №2» -> Робот: «А ты кто? Назови токен!»

👉 Фишка: Нужно каждый раз отправлять данные для аутентификации (токен, ключ).

🧩 Ресурсы и URI (как «адреса» данных)
Каждая сущность (пользователь, заказ) — это ресурс с уникальным URL.

Примеры:

- GET /users/123 -> Получить пользователя с ID 123.
- DELETE /orders/456 -> Удалить заказ 456.

Почему это удобно? Потому что это единый стандарт. Все REST API работают похоже.

🧩 HTTP-методы = действия

GET - Получение информации - Идемпотентный (т.е. вызвав несколько раз подряд - получим тот же результат) - Повторные GET запросы не изменят состояние сервера - Код успеха: 200

POST - Создание информации - Неидемпотентен (Каждый следующий запрос будет создавать новый ресурс) - Код успеха: 201

PUT - Полное обновление информации - Идемпотентен (один и тот же результат) - Код успеха: 200

PATCH - Частичное обновление информации - Неидемпотентен (Т.к. в него можно вставить инструкцию добавления элемента , а вот PUT - перезаписал бы целиком) - Код успеха: 200

DELETE - Удаление информации - Идемпотентен (многократное удаление приводит все к тому же единственному удалению) - Код успеха: 204

3. Безопасность: Как системы доверяют друг другу

Три уровня защиты API:

Аутентификация (кто ты?) 🚪
- API-ключи (простые, но небезопасные)
- OAuth 2.0 (делегирование прав)
- JWT (токены с цифровой подписью)

Авторизация (что тебе можно?) 🪞
- RBAC (ролевая модель)
- Scope в OAuth

Валидация (корректны ли данные?) 🪭
- Проверка типов
- Ограничения значений

4. Форматы обмена: JSON vs XML

JSON (Современный стандарт)

{
"transaction": {
"id": "1014",
"amount": 100.50,
"currency": "RUB"
}
}

Преимущества:

- Компактность
- Быстрый парсинг
- Поддержка всеми языками

XML (Легаси-системы)

<Transaction>
<ID>1014</ID>
<Amount>100.50</Amount>
<Currency>RUB</Currency>
</Transaction>

Где встречается:

- Банковские системы
- Государственные порталы
- Устаревшие ERP

5. Практика для аналитиков: Что проверять?

Документация API:
- Swagger/OpenAPI-спецификации
- Примеры запросов
- Коды ошибок

Ограничения:
- Rate limiting (ограничение запросов)o
- Квоты использования
- Размеры payload

Сценарии ошибок:
- Таймауты соединения
- Невалидные данные
- Отзыв токенов

Подводим итоги..

Ситуация: Заказчик говорит: «Наш сайт должен показывать курсы валют».

Плохой аналитик:
— «Нужно парсить сайт ЦБ РФ каждые 10 минут» (костыль).

Хороший аналитик:
— «Используем официальное API ЦБ: GET https://www.cbr-xml-daily.ru/daily_json.js. Данные обновляются раз в день, ключ не нужен».

Разница: Второй вариант надёжнее, быстрее и дешевле в разработке.

#СистемныйАнализ #системнаяаналитика #бизнесаналитика #БизнесАнализ  #техническоезадание   #RESTAPI   #API   #REST   #Теория