Где не применяется REST API?

Где не применяется REST API

REST API — это мощный стиль архитектуры, но он не универсален и имеет ограничения. Есть сценарии, где REST не подходит или не оптимален.

1. Real-time коммуникация и streaming

REST основан на модели request-response, где клиент инициирует запрос. Для real-time приложений это неэффективно.

Примеры, где REST не подходит:

• Чаты и мессенджеры (Telegram, Slack) — нужны WebSocket для instant delivery
• Live notifications — push-уведомления требуют long polling или WebSocket
• Collaborative editing (Google Docs, Figma) — нужна двусторонняя связь
• Live sports scores, stock tickers — требуется streaming data

Что использовать: WebSocket (Socket.io, Django Channels), gRPC streaming, Server-Sent Events (SSE)

# Правильно для real-time: WebSocket
from channels.generic.websocket import AsyncWebsocketConsumer

class ChatConsumer(AsyncWebsocketConsumer):
    async def receive(self, text_data):
        # Двусторонняя связь, не request-response
        await self.send(text_data=response)

2. Тяжёлые вычисления и background работа

REST API синхронный и может "зависнуть", если вычисление длится долго.

Примеры:

• Обработка видео — могут занять часы
• Большие ML модели — инференс может быть дорогим
• Генерация отчётов из миллионов строк
• Массовая обработка данных

Что использовать: Task queues (Celery, RQ), Kafka, async workers

# Плохо: REST API ждёт результата
@app.post('/process-video')
def process_video(file):
    result = heavy_processing(file)  # Может зависнуть на 30+ минут
    return result

# Хорошо: Task queue
@app.post('/process-video')
def process_video(file):
    task = process_video_task.delay(file)  # Асинхронно
    return {"task_id": task.id}

@app.get('/task/{task_id}')
def get_task_status(task_id):
    task = process_video_task.AsyncResult(task_id)
    return {"status": task.status, "result": task.result}

3. Файловые системы и binary data

REST хорошо работает с JSON/XML, но для binary data и файлов требуется специальная обработка.

Примеры, где REST не оптимален:

• Streaming больших файлов (видео, архивы) — требуется range requests, resumable uploads
• WebDAV (облачные хранилища) — специальный протокол, основан на HTTP
• FTP альтернативы — REST не заменяет FTP для файловых операций

Что использовать:

• S3/облачные хранилища с presigned URLs
• WebDAV для полноценного файлового сервера
• gRPC для бинарных данных

# Хорошо: S3 presigned URL для больших файлов
import boto3

s3 = boto3.client('s3')
url = s3.generate_presigned_url(
    'put_object',
    Params={'Bucket': 'my-bucket', 'Key': 'video.mp4'},
    ExpiresIn=3600
)
# Клиент напрямую загружает в S3, не через наш API

4. Complex queries и специализированный поиск

REST плохо справляется со сложными, многоуровневыми запросами.

Примеры:

• GraphQL-подобные запросы — где клиент указывает точно, какие данные ему нужны
• Полнотекстовый поиск — Elasticsearch, Sphinx требуют собственный протокол
• Geo-поиск — требуется специальный синтаксис для геоквери

Что использовать: GraphQL, ElasticSearch Query DSL, специализированные API

# REST ограничение: множество параметров
GET /products?category=electronics&min_price=100&max_price=500&sort=price&geo=lat,lng&radius=10km

# GraphQL решение: точный запрос
query {
  products(filter: {category: "electronics", priceRange: {min: 100, max: 500}}) {
    id
    name
    price
  }
}

5. Микросервисная коммуникация внутри системы

Для внутренней коммуникации микросервисов REST может быть медленным и неэффективным.

Примеры:

• High-frequency RPC между сервисами — требуется низкая latency
• Strongly-typed contracts — REST JSON не имеет сильной типизации
• Multiplexing — HTTP/1.1 открывает новое соединение на запрос

Что использовать: gRPC, MessageQueue (RabbitMQ, Kafka), HTTP/2

# REST между микросервисами: медленно и неправильно
response = requests.get('http://user-service/users/123')

# gRPC между микросервисами: быстро и типизировано
user = stub.GetUser(GetUserRequest(id=123))

6. Очень низкая latency и высокая throughput

REST поверх HTTP имеет overhead. Если нужна максимальная производительность:

• High-frequency trading — нужна минимальная задержка
• Gaming servers — real-time synchronization
• IoT с миллионами устройств — нужна эффективность протокола

Что использовать: UDP, собственные бинарные протоколы, MQTT для IoT

Итоговая таблица

Вывод

REST API — отличное решение для CRUD операций, публичных API, простых интеграций. Но для real-time, streaming, high-performance и специализированных сценариев нужно выбирать более подходящие технологии. Хороший архитектор выбирает инструмент по задаче, а не пытается подогнать задачу под инструмент.