Borsa API'lerinde REST ve WebSocket farkı

Kısa cevap: REST API, her veri için ayrı bir HTTP isteği gönderilip yanıt alınan istek-yanıt modelidir; WebSocket, kalıcı bir bağlantı üzerinden sunucunun değişiklikleri kendiliğinden ilettiği akış protokolüdür. Borsa API'lerinde emir ve bakiye işlemleri genellikle REST ile, fiyat ve emir defteri akışları WebSocket ile izlenir.

REST API, istemcinin her veri için sunucuya ayrı bir HTTP isteği gönderip yanıt aldığı istek-yanıt modelidir; WebSocket ise bir kez kurulan kalıcı bağlantı üzerinden sunucunun değişiklikleri kendiliğinden ilettiği çift yönlü bir akış protokolüdür. Borsa API'lerinde emir gönderme, iptal ve bakiye sorgulama gibi işlemler genellikle REST ile yapılır; fiyat, emir defteri ve hesap güncellemeleri ise WebSocket akışlarından izlenir. İkisi rakip değil, birbirini tamamlayan kanallardır.

REST API nedir?

REST, HTTP üzerinde çalışan bir API tasarım yaklaşımıdır. İstemci bir adrese GET, POST veya DELETE gibi bir HTTP isteği gönderir, sunucu çoğunlukla JSON biçiminde bir yanıt döner ve iletişim orada biter. Her istek kendi başına değerlendirilir; sunucu önceki istekleri hatırlamaz. Bu yüzden hesaba erişen her istek, API anahtarını ve imzayı yeniden taşımak zorundadır.

REST yanıtı o anın fotoğrafıdır. Bir fiyatın değişip değişmediğini öğrenmenin tek yolu tekrar sormaktır ve bu yoklama (polling) yaklaşımının iki bedeli vardır: değişiklik gecikmeyle öğrenilir ve sık sorgu, borsanın istek limitlerini hızla tüketir. Binance'in limit aşımında döndürdüğü hata mesajı bile çözümü gösterir: API'yi yoklamak yerine canlı güncellemeler için WebSocket kullanın.

WebSocket nedir?

WebSocket, IETF'in Aralık 2011'de yayımladığı RFC 6455 ile standartlaşan bir protokoldür. Bağlantı sıradan bir HTTP isteğiyle başlar: istemci Upgrade başlığıyla protokol değişikliği ister, sunucu 101 koduyla kabul eder ve aynı TCP bağlantısı tam çift yönlü (full-duplex) bir kanala dönüşür. Şifreli bağlantı için wss:// şeması ve 443 portu kullanılır.

Bağlantı açık kaldığı sürece iki taraf da istediği anda mesaj gönderebilir. Borsa tarafında her yeni işlem, emir defteri değişikliği veya emir durumu güncellemesi olur olmaz küçük bir JSON mesajı olarak istemciye iletilir. İstemci sormaz, dinler.

Borsada hangi işlem hangi kanaldan yapılır?

Kripto borsalarının çoğu bu ayrımı benzer biçimde kurar; aşağıdaki dağılım Binance spot dokümantasyonuna dayanır:

REST: emir gönderme ve iptal, bakiye ve açık emir sorgusu, işlem geçmişi, sembol kuralları (exchangeInfo), sunucu saati ve emir defterinin anlık görüntüsü (snapshot).
WebSocket piyasa akışları: gerçekleşen işlemler (trade, aggTrade), mum verisi (kline), fark bazlı emir defteri güncellemeleri (depth) ve ticker. Bu akışlar herkese açıktır, kimlik doğrulama gerektirmez.
WebSocket kullanıcı verisi akışı: emir durumu değişiklikleri (executionReport), bakiye güncellemeleri ve para giriş-çıkışları. Hesaba özeldir, kimlik doğrulama ister.

Bu ayrım her zaman bu kadar keskin değildir: Binance'in WebSocket API'si, aynı kalıcı bağlantı üzerinden emir göndermeye (order.place) de izin verir. Mantık yine istek-yanıttır; her isteğe bir kimlik (id) eklenir ve yanıt aynı kimlikle döner, ancak her emir için yeni bir HTTP bağlantısı açılmaz.

Borsa İstanbul'da durum farklıdır: piyasa verisi lisanslı veri dağıtıcı kuruluşlar üzerinden sağlanır ve algoritmik alım satım sistemleri gibi "gösterimsiz kullanım" için doğrudan Borsa İstanbul ile Veri Dağıtım Sözleşmesi imzalanması gerekir. Emir iletimi ise aracı kurumlar üzerinden yapılır; API sunan kurumların protokolleri ve koşulları kurumdan kuruma değişir.

Hız limitleri ve istek ağırlığı

REST tarafında her uç noktanın bir ağırlığı vardır; çok sayıda sembol sorgulayan istekler daha ağırdır. Ekim 2026 itibarıyla Binance spot API'sinin exchangeInfo yanıtında ilan ettiği limitler şöyledir: dakikada 6.000 istek ağırlığı, 10 saniyede 100 ve günde 200.000 emir, 5 dakikada 300.000 ham istek. Emir sayacı yalnızca gerçekleşmemiş emirleri sayar; kısmen veya tamamen gerçekleşen emirler bu sayaca dahil edilmez. İstek ağırlığı IP başına sayılır ve o IP'den açılan bütün bağlantılar aynı havuzu paylaşır; emir sayacı ise hesap başına tutulur ve hesabın bütün API anahtarları için ortaktır. Bu değerler değişebilir; güncel limitleri uygulama içinden exchangeInfo ile okumak gerekir.

Her yanıt, X-MBX-USED-WEIGHT-1M biçimindeki başlıkla o IP'nin tüketilen ağırlığını bildirir. Limit aşılınca sunucu 429 kodu ve Retry-After başlığıyla bekleme süresini döner; 429'a rağmen istek göndermeye devam eden IP'ler 418 koduyla yasaklanır ve yasak süresi tekrarlayan ihlallerde 2 dakikadan 3 güne kadar uzar.

WebSocket tarafında limit, veri hacmine değil bağlantı yönetimine odaklanır: spot akışlarında bağlantı başına saniyede istemciden gelen en fazla 5 mesaj (ping, pong ve abone olma mesajları dahil), bağlantı başına en fazla 1.024 akış ve IP başına 5 dakikada 300 bağlantı denemesi. Sunucunun gönderdiği veriler bu sayaca girmez; saniyede yüzlerce fiyat güncellemesi almak WebSocket'te sorun değilken aynı veriyi REST ile sorgulamak limiti dakikalar içinde doldurur.

İmzalı istekler ve zaman senkronizasyonu

Hesaba erişen her REST isteği imzalanır. API anahtarı X-MBX-APIKEY başlığında gönderilir; istek parametreleri gizli anahtarla HMAC-SHA256, RSA veya Ed25519 yöntemiyle imzalanır ve imza signature parametresi olarak eklenir. Binance, performans ve güvenlik gerekçesiyle Ed25519 anahtarlarını önerir; anahtar oluşturma ve yetki kısıtlama adımları Binance API anahtarı yazısında anlatılır.

İmzalı isteklerde milisaniye cinsinden bir timestamp ve isteğe bağlı recvWindow parametresi bulunur. Sunucu, zaman damgası kendi saatinden en fazla 1 saniye ileride olan ve recvWindow (varsayılan 5.000 ms, en fazla 60.000 ms) içinde kalan istekleri işler; diğerlerini -1021 hata koduyla reddeder. Bilgisayar saati birkaç saniye kaymışsa bütün imzalı istekler bu hatayla reddedilir. Çözüm, uygulama başlarken /api/v3/time ile sunucu saatini alıp farkı yerel saate uygulamak ve sistem saatini NTP ile senkron tutmaktır; recvWindow değerini büyütmek sorunu çözmez, yalnızca gizler; Binance 5.000 ms veya daha düşük bir değer önerir.

WebSocket tarafında piyasa akışları kimlik doğrulama gerektirmez. Kullanıcı verisi akışına ise Binance spot tarafında artık WebSocket API üzerinden abone olunur: ya Ed25519 anahtarıyla oturum açılıp (session.logon) userDataStream.subscribe çağrılır ya da imzalı userDataStream.subscribe.signature kullanılır. Eski listenKey yöntemi, Binance'in değişiklik günlüğüne göre Nisan 2025'te kullanımdan kaldırılacağı duyurulduktan sonra 20 Şubat 2026 07.00 UTC itibarıyla kapatıldı; başka borsalarda benzer anahtarlar hâlâ kullanılıyor olabilir.

Emir defteri senkronizasyonu: anlık görüntü ve fark güncellemeleri

WebSocket'ten gelen emir defteri verisi tam defter değil, değişen fiyat seviyelerinin listesidir. Yerel kopya, REST'ten alınan anlık görüntünün akıştan gelen farklarla sıra numarası denetimi altında birleştirilmesiyle kurulur. Binance spot dokümantasyonundaki yöntem:

Önce depth akışına bağlanılır ve gelen olaylar tamponlanır; ilk olayın U (ilk güncelleme numarası) değeri not edilir.
REST'ten limit=5000 ile anlık görüntü alınır; yanıttaki lastUpdateId defterin hangi ana ait olduğunu söyler ve ilk olayın U değerinden küçükse görüntü tekrar alınır.
Tampondaki, u (son güncelleme numarası) değeri lastUpdateId'ye eşit veya küçük olan olaylar elenir. Kalan ilk olayın [U;u] aralığı lastUpdateId'yi kapsamalıdır.
Olaylar sırayla uygulanır. Normalde her yeni olayın U değeri bir önceki olayın u değerinin bir fazlasıdır; U bu değerden büyükse arada olay kaçırılmış demektir ve defter anlık görüntüden yeniden kurulur.
Her seviyedeki miktar fark değil, mutlak değerdir; miktar 0 ise o fiyat seviyesi defterden silinir.

Varsayımsal bir fark olayı şöyle görünür (100 fiyatındaki alış miktarı 2'ye güncellenir, 101 fiyatındaki satış seviyesi silinir):

{"e":"depthUpdate","U":1001,"u":1003,
 "b":[["100","2"]],
 "a":[["101","0"]]}

Vadeli işlem akışlarında süreklilik, bir önceki olayın u değerini taşıyan pu alanıyla denetlenir. Alan adları borsadan borsaya değişir, ilke aynıdır: anlık görüntü ve sıra numarası denetiminden geçen fark güncellemeleri.

Ping-pong, yeniden bağlanma ve sessiz kopmalar

Kalıcı bir bağlantı ağ kesintisinde sessizce kopabilir ve iki taraf da bunu fark etmeden dakikalar geçebilir. RFC 6455 bunun için ping ve pong kontrol çerçevelerini tanımlar: ping alan taraf, aynı veriyi taşıyan bir pong ile yanıt vermek zorundadır. Binance spot akışlarında sunucu her 20 saniyede bir ping gönderir, bir dakika içinde pong gelmezse bağlantıyı keser; her bağlantı en fazla 24 saat açık kalır ve sunucu kapanmadan önce serverShutdown olayı gönderir.

Bu yüzden yeniden bağlanma istisna değil, tasarımın parçasıdır. Sağlam bir istemci kopuşta artan bekleme süreleriyle (1, 2, 4, 8 saniye gibi) tekrar bağlanır, aboneliklerini yeniler, emir defterini anlık görüntüden baştan kurar ve kullanıcı verisi aboneliğini yeniden açar. Kopukluk sırasında olan emir değişiklikleri akıştan sonradan alınamaz; açık emirler ve bakiyeler REST ile tekrar sorgulanır. 24 saat sınırı dolmadan planlı biçimde yeniden bağlanmak, kesintiyi piyasanın hareketli bir anına bırakmaktan iyidir.

Hata yönetimi

REST'te 4XX kodları isteğin hatalı olduğunu, 429 ve 418 limit aşımını, 5XX ise borsa tarafında bir sorunu gösterir. 5XX yanıtlarında Binance dokümantasyonu işlemin sonucunun bilinmediğini ve başarılı olmuş olabileceğini açıkça belirtir. Zaman aşımı (-1007) alınan bir emri gönderilmemiş sayıp yeniden göndermek çift emirle sonuçlanabilir; doğru yaklaşım, emir durumunu önce kullanıcı verisi akışından izlemek, orada görünmezse REST ile sorgulamaktır. İmza hatası (-1022) ve zaman damgası hatası (-1021) ise yapılandırma sorunudur, tekrar denemekle çözülmez.

WebSocket tarafında hata çoğunlukla bir mesaj değil, bağlantı kopmasıdır. Dinleyici sıra numaralarını denetlemeli, beklenmeyen biçimde gelen bir mesajda çökmek yerine olayı kaydedip devam etmeli ve bağlantı sağlığını ayrı bir denetimle izlemelidir; sessizleşen bir fiyat akışının sakin piyasadan mı, kopuk bağlantıdan mı kaynaklandığını ancak ping-pong zamanlaması gösterir.

Pratikte iki kanal nasıl birleştirilir?

Üretim ortamındaki bir alım satım sistemi iki kanalı birlikte çalıştırır: piyasa verisi ve emir durumu WebSocket'ten izlenir, emirler ve düzeltici sorgular REST ile gönderilir, limitler ve saat farkı sürekli ölçülür. Algoritmik işlem ve TradingView webhook kurulumlarındaki kesintilerin önemli bir bölümü bu katmandan kaynaklanır. Fincode, borsa API entegrasyonu ve algoritmik işlem sistemleri projelerinde bu yazılım altyapısını müşteriye özel kurar.

Sık sorulan sorular

WebSocket her zaman REST'ten daha mı hızlı?

Değişen veriyi izlemek için evet; sunucu değişikliği olur olmaz iletir ve her mesaj için yeni bağlantı kurulmaz. Tek bir sorgu veya emir için fark küçüktür; belirleyici olan ağ gecikmesi ve eşleştirme motorudur.

Emir WebSocket ile gönderilebilir mi?

Borsaya bağlıdır. Binance spot, WebSocket API üzerinden emir göndermeye izin verir; bazı borsalar emirleri yalnızca REST'ten kabul eder.

Bağlantı koptuğunda açık emirler iptal olur mu?

Genellikle hayır. Emirler borsanın eşleştirme motorunda durur; kopan yalnızca bilgi kanalıdır. Bu nedenle yeniden bağlandıktan sonra açık emirleri ve bakiyeyi REST ile sorgulamak gerekir.

Kaynaklar

Bu yazı genel bilgilendirme amaçlıdır ve yatırım tavsiyesi niteliği taşımaz. Örneklerdeki rakamlar varsayımsaldır; belirli bir fon veya hisse için öneri değildir.