REST API для історичних ринкових даних: інженерні рішення
Торговий бот спотикається на свічкових даних — запити йдуть у тайм-аут, бектестер завантажує сторінку по хвилині. При датасеті в 100 пар за рік база падає, а пагінація offset плодить дублі. Знайомий біль? Ми розробляємо REST API для історичних ринкових даних, які витримують 1000 паралельних запитів і віддають свічки за 50 мс. Нижче — інженерні рішення, які ми закладаємо в кожен проект: від вибору бази до стратегії кешування.
Проблеми, які вирішуємо
Типові помилки в торгових API — повільні запити при великих датасетах, негнучка фільтрація, відсутність пагінації. Ми стикалися з проектами, де вибірка OHLCV за рік по 100 парах вбивала базу. Інша часта проблема — неконсистентність даних при використанні offset-пагінації: якщо між запитами додалися нові свічки, клієнт отримує дублі або пропуски. Навантажувальне тестування наших рішень показує зростання продуктивності до 200% за рахунок шардування за часом і агресивного кешування.
Дизайн ендпоінтів
Базовий набір ендпоінтів для маркет-даних:
GET /v1/ohlcv/{exchange}/{symbol} ?from=2024-01-01T00:00:00Z &to=2024-01-31T23:59:59Z &interval=1h &limit=1000 GET /v1/trades/{exchange}/{symbol} ?from=1704067200000 &to=1704153600000 &limit=10000 GET /v1/orderbook/{exchange}/{symbol}/snapshot ?timestamp=1704067200000 &depth=20 GET /v1/tickers/{exchange}/{symbol}/history ?from=2024-01-01 &to=2024-01-02 &fields=close,volume Використання ISO 8601 для користувацького інтерфейсу та Unix timestamp (milliseconds) для програмного доступу. Підтримка обох форматів через автоматичне визначення.
Параметри та валідація
from fastapi import FastAPI, Query from datetime import datetime from typing import Optional @app.get("/v1/ohlcv/{exchange}/{symbol}") async def get_ohlcv( exchange: str, symbol: str, interval: str = Query("1h", regex="^(1m|5m|15m|1h|4h|1d|1w)$"), from_time: datetime = Query(..., alias="from"), to_time: datetime = Query(..., alias="to"), limit: int = Query(1000, ge=1, le=50000), ): if (to_time - from_time).days > 365: raise HTTPException(400, "Date range cannot exceed 365 days") data = await candle_service.get_candles( exchange, symbol, interval, from_time, to_time, limit ) return {"data": data, "count": len(data)} Пагінація для великих датасетів
Cursor-based пагінація ефективніша за offset для часових рядів:
{ "data": [...], "cursor": { "next": "eyJ0aW1lc3RhbXAiOiAxNzA0MDY3MjAwMDAwfQ==", "has_more": true } } Cursor — base64-encoded JSON з останнім timestamp у поточній сторінці. При наступному запиті клієнт передає ?cursor=... замість ?from=....
| Параметр | Cursor | Offset |
|---|---|---|
| Консистентність при вставках | Гарантована | Можливі дублі/пропуски |
| Продуктивність на великих наборах | O(log n) | O(n) при зміщенні |
| Підтримка сортування | Тільки за зростанням (timestamp) | Будь-яка |
| Простота реалізації | Середня | Проста |
Стратегії кешування
| Стратегія | Час життя | Застосовність |
|---|---|---|
| HTTP Cache-Control (public, max-age=3600) | 1 година | Дані старші за добу |
| Redis Cache | 60 секунд | Часто запитані діапазони (останні 30 днів) |
| Query Cache (TimescaleDB/ClickHouse) | 5 хвилин | Важкі агрегації |
Історичні свічки не змінюються — ідеальний кейс для кешування. Якщо запитаний діапазон повністю закритий, кешуємо на 24 години. Якщо включає поточний момент — кешуємо на 60 секунд.
Як спроектувати REST API для маркет-даних?
При проектуванні використовуємо REST з уніфікованими ендпоінтами, підтримкою кількох таймфреймів і форматів. Ключовий принцип — ресурсно-орієнтований дизайн: /v1/ohlcv/{exchange}/{symbol}. Фільтри через query-параметри, пагінація курсором. Документуємо через OpenAPI — клієнти можуть одразу тестувати в Swagger UI.
Чому важливо правильно кешувати історичні дані?
Правильне кешування знижує затримки в 3-5 разів і зменшує навантаження на базу. Наші налаштування враховують частоту запитів і статичність даних. Для популярних пар із глибокою історією використовуємо ClickHouse з матеріалізованими представленнями — це дає приріст продуктивності до 40%.
Rate Limiting та аутентифікація
from slowapi import Limiter from slowapi.util import get_remote_address limiter = Limiter(key_func=get_remote_address) @app.get("/v1/ohlcv/{exchange}/{symbol}") @limiter.limit("100/minute") async def get_ohlcv(...): ... Для комерційного API — тарифні плани через API-ключі з різними лімітами: free (10 req/min, 30 днів історії), paid (1000 req/min, повна історія).
Документація через OpenAPI
FastAPI автоматично генерує OpenAPI схему. Додатково — приклади запитів/відповідей у документації, опис форматів, коди помилок. Swagger UI та ReDoc з коробки — клієнти зможуть тестувати API прямо в браузері без додаткових інструментів.
Приклад відповіді з помилкою
{ "error": { "code": "INVALID_INTERVAL", "message": "Interval must be one of: 1m, 5m, 15m, 1h, 4h, 1d, 1w" } } Процес роботи
- Аналітика: розбираємо ваші дані, пікове навантаження, сценарії використання.
- Проектування: визначаємо схему ендпоінтів, формат відповідей, пагінацію.
- Реалізація: пишемо на FastAPI, підключаємо TimescaleDB/ClickHouse, налаштовуємо кешування.
- Тестування: навантажувальне тестування (k6 + locust), стрес-тест на 10 000 RPS.
- Деплой: розгортання у вашому хмарі або on-premise, налаштування моніторингу (Prometheus + Grafana).
Терміни — від 2 до 4 тижнів залежно від складності та обсягу даних. Вартість розраховується індивідуально.
Що входить у роботу
- REST API з описаним вище функціоналом (OHLCV, угоди, склянка, тікери).
- Документація OpenAPI (Swagger/ReDoc).
- Приклади інтеграції на Python, JavaScript, cURL.
- Розгортання (Docker, Kubernetes, CI/CD).
- Гарантія 99.9% uptime (SLA).
- Місяць безкоштовної підтримки після запуску.
Чому ми?
5+ років досвіду в розробці Web3-інфраструктури, 30+ реалізованих API для торгових систем на Ethereum, Solana та Binance Smart Chain. Рішення витримують пікові навантаження до 50 000 запитів на хвилину. Використовуємо Tenderly, Slither, Mythril для аудиту безпеки.
Зв'яжіться з нами, щоб обговорити ваш проект. Замовте розробку під ключ з гарантією продуктивності — отримайте консультацію інженера за 2 робочих дні.