Для каких типов коммуникации архитектурный стиль REST (HTTP) плохо подходит?

REST поверх HTTP не является оптимальным выбором для систем со следующими требованиями:

• Двусторонняя связь в реальном времени. Например, чаты, онлайн-игры, коллаборативные редакторы. HTTP — это запрос-ответ, а не постоянное соединение.
• Частые и мелкие сообщения (высокий chattiness). Накладные расходы HTTP-заголовков на каждый запрос становятся значительными.
• Потоковая передача данных. Хотя возможна через chunked transfer encoding, это не является сильной стороной REST.
• Строгие требования к производительности и латенции. Бинарные протоколы обычно эффективнее текстового HTTP/JSON.

Альтернативы:

1. WebSocket или WebRTC для интерактивных приложений реального времени.
2. gRPC (на основе HTTP/2) для высокопроизводительных RPC-вызовов между микросервисами.
3. Message Brokers (Kafka, RabbitMQ) для асинхронной, событийно-ориентированной коммуникации.

Пример gRPC-сервиса для чата (proto-файл):

service ChatService {
  rpc SendMessage (MessageRequest) returns (MessageAck);
  rpc JoinChat (JoinRequest) returns (stream MessageResponse); // Server-side streaming
}

Для сложных запросов данных с клиента (например, мобильного приложения с плохим соединением) также может быть предпочтительнее GraphQL, позволяющий клиенту точно запросить нужные данные за один запрос.