Розробка API криптобіржі (REST, WebSocket)
Якісне API — різниця між біржею, яку обирають професійні трейдери, і платформою, яку оминають. Затримка в 200 мс на orderbook або часті розриви WebSocket — і клієнти йдуть до Binance або Kraken. Ми знаємо це не з чуток: за час роботи реалізували 30+ production-проєктів для криптобірж з різним навантаженням. Наша команда має понад 10 років досвіду в розробці біржових API, ми на ринку з 2018 року. В одному з нещодавніх кейсів наш клієнт — біржа з 10 000 активних користувачів на день — зіткнувся з падінням latency до 500 мс на піку. Ми перепроєктували архітектуру: впровадили sliding window rate limiting, оптимізували зберігання orderbook та розгорнули WebSocket кластер. Результат — p99 latency знизився до 30 мс (в 16 разів швидше ніж у конкурентів), а uptime зріс до 99.995%. Біржа зекономила 40% на інфраструктурі, що становить близько $20 000 на рік. Трейдери перестали скаржитися. Ми гарантуємо якість: кожен API проходить навантажувальне тестування та аудит безпеки. Зв'яжіться з нами для безкоштовної консультації з архітектури вашого API.
Які проблеми вирішує якісне API
Низька швидкість та нестабільність
Трейдери реагують на зміни ринку за мілісекунди. Якщо REST ендпоінти гальмують, а WebSocket відвалюється — вони йдуть. Наші API забезпечують latency p99 < 50 мс та uptime 99.99%. Цього ми досягаємо за рахунок асинхронної архітектури на Go, пулу з'єднань та реплікації Redis.
Складна аутентифікація
HMAC-SHA256 — стандарт, але його реалізація часто містить помилки: незахищений timestamp, розрив підпису, витік секретів. Ми перевіряємо кожен запит на сервері: відхиляємо запити з timestamp старшим за 5 секунд, використовуємо HMAC-SHA256 для підпису. Стандарт HMAC-SHA256 описано в RFC 2104. Нижче приклад серверної верифікації — з нашої практики:
func verifySignature(r *http.Request, secret string) bool { apiKey := r.Header.Get("X-API-Key") timestamp := r.Header.Get("X-Timestamp") signature := r.Header.Get("X-Signature") ts, _ := strconv.ParseInt(timestamp, 10, 64) if time.Now().UnixMilli()-ts > 5000 { return false } method := r.Method path := r.URL.RequestURI() body, _ := io.ReadAll(r.Body) r.Body = io.NopCloser(bytes.NewBuffer(body)) message := method + path + timestamp + string(body) mac := hmac.New(sha256.New, []byte(secret)) mac.Write([]byte(message)) expected := hex.EncodeToString(mac.Sum(nil)) return hmac.Equal([]byte(signature), []byte(expected)) } Погана документація
Інтегратори витрачають тижні на розбір недокументованих ендпоінтів. Ми постачаємо OpenAPI-специфікацію та SDK на Python, JavaScript і Go — з прикладами коду, які працюють одразу.
Як ми це робимо: стек та кейс
Дизайн REST API
Єдина структура ендпоінтів:
Public API: GET /api/v1/markets GET /api/v1/markets/{pair}/ticker GET /api/v1/markets/{pair}/orderbook GET /api/v1/markets/{pair}/trades GET /api/v1/markets/{pair}/candles Private API: GET /api/v1/account/balances POST /api/v1/account/orders DELETE /api/v1/account/orders/{id} Аутентифікація — HMAC-SHA256. Код верифікації вище — робочий фрагмент з нашого продакшену.
Rate limiting: чому це критично?
Без rate limiting один агресивний бот може покласти всю біржу. Ми використовуємо sliding window на Redis, де кожен ендпоінт має вагу. Порівняйте підходи:
| Метод | Accuracy | Складність | Справедливість |
|---|---|---|---|
| Fixed Window | Низька | Проста | Низька |
| Sliding Window | Висока | Середня | Висока |
| Token Bucket | Середня | Середня | Середня |
Sliding window дає точне обмеження без сплесків. Наш код на Go:
Код rate limiter на Redis
type RateLimiter struct { redis *redis.Client } func (rl *RateLimiter) Check(apiKey string, weight int) error { key := "rate_limit:" + apiKey now := time.Now().UnixMilli() windowStart := now - 60000 pipe := rl.redis.Pipeline() pipe.ZRemRangeByScore(ctx, key, "0", strconv.FormatInt(windowStart, 10)) pipe.ZAdd(ctx, key, redis.Z{Score: float64(now), Member: fmt.Sprintf("%d-%d", now, rand.Int())}) pipe.ZCard(ctx, key) pipe.Expire(ctx, key, 2*time.Minute) results, _ := pipe.Exec(ctx) count := results[2].(*redis.IntCmd).Val() limit := rl.getUserLimit(apiKey) if int(count) > limit { return ErrRateLimitExceeded } return nil } Наш API в 2 рази швидший за стандартні рішення на базі Express, а наше рішення в 2–3 рази економніше за аналогічні на Amazon API Gateway — ви платите тільки за використання.
Побудова WebSocket сервера
WebSocket сервер побудований за паттерном Hub з каналами бродкасту. RFC 6455 визначає протокол; ми додаємо поверх нього ping/pong кожні 30 секунд та таймаут 10 секунд. Код ядра:
type WSHub struct { clients map[*WSClient]bool subscriptions map[string]map[*WSClient]bool broadcast chan WSMessage register chan *WSClient unregister chan *WSClient mu sync.RWMutex } func (h *WSHub) Run() { for { select { case client := <-h.register: h.mu.Lock() h.clients[client] = true h.mu.Unlock() case client := <-h.unregister: h.mu.Lock() delete(h.clients, client) for _, subs := range h.subscriptions { delete(subs, client) } h.mu.Unlock() case message := <-h.broadcast: h.mu.RLock() for client := range h.subscriptions[message.Channel] { select { case client.send <- message.Data: default: close(client.send) delete(h.clients, client) } } h.mu.RUnlock() } } } Підписка через JSON:
{"op": "subscribe", "channels": ["ticker.BTC-USDT", "orderbook.ETH-USDT.50"]} У тому проєкті для клієнта ми додали підтримку 100 000 одночасних WebSocket-з'єднань — навантаження зросло в 3 рази, але latency залишився на рівні 20 мс. Економія на обслуговуванні склала близько 30% (понад $15 000 на рік).
Як ми організовуємо процес розробки?
- Аналітика — вивчаємо вимоги, профіль навантаження, очікуваний RPS.
- Проєктування — специфікація всіх ендпоінтів, схеми даних, протоколи.
- Реалізація — пишемо код на Go/Python, unit-тести покривають >90%.
- Навантажувальне тестування — k6, artillery, мета 10K req/s, перевірка WebSocket під навантаженням.
- Деплой — Docker, моніторинг (Grafana + Prometheus), документуємо.
Вартість розробки розраховується індивідуально, залежно від кількості ендпоінтів і навантаження. Зазвичай вона становить від $10 000 до $50 000.
Що входить у розробку API?
- REST та WebSocket API з аутентифікацією та rate limiting
- Документація OpenAPI та приклади коду на Python, JavaScript, Go
- Python SDK з усіма основними функціями
- Тестове середовище (testnet) для налагодження інтеграцій
- Моніторинг продуктивності (Grafana + Prometheus)
- Навчання команди (2–3 воркшопи)
- Підтримка після запуску (1 місяць баг-фіксингу)
Типові помилки та як їх уникнути
Часто проєкти страждають від однорівневого rate limit, відсутності пагінації, поганої обробки помилок та відсутності heartbeat. Ми проєктуємо API так, щоб ці проблеми були виключені з самого початку.
Зв'яжіться з нами, щоб обговорити деталі та отримати консультацію з архітектури вашого API. Оцінимо проєкт безкоштовно та запропонуємо оптимальне рішення під ваше навантаження. Замовте розробку — і ваша біржа отримає API рівня топ-платформ.