С какими сталкивался видами API?

Виды API, с которыми я работал как Business Analyst

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

REST API

Это самый распространённый тип, с которым я работал чаще всего. REST API использует стандартные HTTP-методы (GET, POST, PUT, DELETE) и основан на ресурсах. Например, при разработке системы управления заказами мы создавали endpoints типа:

• GET /api/orders — получение списка заказов
• POST /api/orders — создание нового заказа
• PUT /api/orders/{id} — обновление
• DELETE /api/orders/{id} — удаление

При работе с REST я документировал требования в Swagger/OpenAPI, согласовывал statuses коды (200, 201, 400, 404, 500), структуру request/response payload.

GraphQL

В одном из проектов переходили на GraphQL для мобильного приложения, где было критично минимизировать трафик. GraphQL позволяет клиенту запрашивать только нужные поля, что снижает размер ответа. Моя роль была в том, чтобы:

• Определить необходимые типы данных
• Спецификировать queries и mutations
• Проанализировать, какие данные реально нужны фронтенду
• Согласовать схему с бэкендом

SOAP / XML API

При интеграции с legacy-системами сталкивался с SOAP, особенно в финансовом секторе. SOAP более формальный, использует XML и требует строгого контракта (WSDL). Это было сложнее в документировании и требовало больше времени на согласование деталей.

RPC API

В проекте с блокчейном работал с JSON-RPC API — более простой формат, где есть метод и параметры. Требовал тщательного анализа возможных состояний и ошибок.

WebSocket API

Для real-time функционала (чат, уведомления, live-обновления) требовалась работа с WebSocket. Здесь нужно было документировать events, их структуры, состояния соединения.

Ключевые навыки при работе с API как BA:

• Документирование — Swagger, API Blueprint, AsyncAPI
• Анализ требований — понимание того, какие endpoints реально нужны
• Безопасность — authentication, authorization, rate limiting
• Версионирование — как управлять изменениями без breaking changes
• Мониторинг — согласование метрик, логирования, alert rules

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