Пост🤖 📡 Базовые протоколы клиент-серверного взаимодействия (без обратной связи)

🤖 📡 Базовые протоколы клиент-серверного взаимодействия (без обратной связи) Хочется сделать серию постов по основам CS и system-design. Если будет отклик, масштабируем в mind-map. И начать хочется с сетевого взаимодействия. Когда мы говорим про клиент-серверные запросы в большинстве приложений, мы почти всегда имеем в виду модель request → response. Важно сразу зафиксировать: это не всегда про HTTP, хотя на практике часто выглядит именно так. В первом посте разберём основные стили взаимодействия, которые используются для однонаправленных запросов с ответом. 📌 Немного про транспорт: - SOAP — почти всегда поверх HTTP/HTTPS - REST — по определению строится поверх HTTP - GraphQL — чаще всего поверх HTTP, подписки через WebSocket (но об этом можно глубже, в другом посте) - RPC — не обязан использовать HTTP 👉 Поэтому корректнее говорить не «HTTP-протоколы», а API-стили / протоколы поверх разных транспортов. Небольшая затравка из практики: В бородатых годах я использовал Apache Thrift на Objective-C — тогда для меня это был "магический" опыт с RPC: отличный кодген, строгие контракты, минимум ручной работы. Это был классический пример RPC-подхода, задолго до хайпа gRPC, и он отлично показывал разницу между: - «я работаю с ресурсами» (REST) - и «я вызываю удалённые методы» (RPC) Детальнее про протоколы: 🔹 SOAP (Simple Object Access Protocol) Что это: Строгий протокол обмена сообщениями, основанный на XML и формальных контрактах (WSDL). Транспорт: почти всегда HTTP Когда применять: - корпоративные и интеграционные системы - среды с жёсткими требованиями к контрактам, безопасности и совместимости Почему: SOAP — это максимум формализма: строгая схема, строгие правила, минимум свободы. Цена — высокая сложность и избыточность. 📍 SOAP — это «корпоративный стандарт», а не инструмент скорости. 🔹 REST (Representational State Transfer) Что это: Архитектурный стиль, завязанный на HTTP, где всё крутится вокруг ресурсов и их состояний. Транспорт: HTTP. Когда применять: - CRUD-сценарии - публичные API - системы, где важны кэширование, простота и масштабируемость Почему: REST максимально использует возможности HTTP: методы, статусы, cache-control. Он прост, прозрачен и отлично поддерживается инструментами. 📍 REST — дефолтный выбор, если нет веской причины делать иначе. 🔹 GraphQL Что это: Язык запросов и runtime, где клиент сам описывает, какие данные ему нужны. Транспорт: - чаще всего HTTP - иногда WebSocket (но это уже про real-time) Когда применять: - сложные графы данных - разные клиенты с разными требованиями к payload - желание сократить количество запросов Почему: GraphQL снимает проблему overfetching/underfetching, но усложняет сервер и наблюдаемость. 📍 GraphQL — про гибкость клиента, а не про простоту системы. 🔹 RPC (gRPC, Thrift, JSON-RPC) Что это: Удалённый вызов процедур: клиент вызывает метод, сервер его исполняет. Транспорт: не привязан к HTTP - gRPC — HTTP - Thrift — TCP / HTTP / custom transport Когда применять: - межсервисное взаимодействие - высокая производительность - чёткие контракты и кодогенерация Почему: RPC ближе к обычному программированию: вызвал метод — получил результат. Это эффективно, но хуже ложится на публичные API и браузный мир. 📍 RPC — лучший выбор для внутренних систем и платформенных API. #L #Network #HTTP #TCP #REST #SOAP #GraphQL #RPC 👏