Вопрос проверяет знание распространённых подходов к построению структуры и взаимодействия API.
Существуют разные паттерны, которые помогают делать API понятным, расширяемым и удобным для поддержки.
Наиболее известные паттерны — REST, RPC, GraphQL, gRPC и Webhooks.
Они различаются способом передачи данных, форматом взаимодействия и степенью гибкости.
Новичку важно понимать, в чём сильные и слабые стороны каждого подхода.
Чаще всего выбирают REST или gRPC, в зависимости от задачи.
Существуют несколько распространённых подходов к построению API, каждый из которых решает конкретные задачи и подходит для разных сценариев.
Определение: стиль архитектуры API, основанный на использовании HTTP-методов и ресурсов.
Прост в реализации
Подходит для большинства CRUD-систем
Хорошо работает с кэшированием
Данные обычно передаются в JSON
Пример запроса:
GET /users/1
Когда применять: когда нужен простой, понятный, стандартизированный HTTP-интерфейс.
Определение: модель API, где клиент вызывает удалённые функции как локальные.
Минимум абстракций
Хорош для внутренних микросервисов
Может использовать HTTP или бинарные протоколы
Пример:
{"method": "get_user", "params": {"id": 1}}
Когда применять: когда важна скорость и простота вызовов.
Определение: язык запросов, позволяющий клиенту выбирать, какие данные ему нужны.
Избегает «overfetching» и «underfetching»
Хорош для сложных UI
Требует схемы
Пример:
query {
user(id: 1) { id name }
}
Когда применять: когда клиентам требуется гибкость в запросах.
Определение: высокопроизводительный бинарный протокол поверх HTTP/2.
Очень быстрый
Строгая типизация
Требует .proto-описаний
Пример:
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
Когда применять: при взаимодействии микросервисов, где нужна скорость.
Определение: механизм, позволяющий серверу отправлять события клиенту.
Работает по push-модели
Полезен для асинхронных уведомлений
Когда применять: когда нужно реагировать на события в реальном времени.
