Którego API powinienem użyć? REST kontra WebSocket

Na rynku spot, choć zarówno REST, jak i WebSocket dostarczają dokładnie te same dane rynkowe (księgi zleceń, historia transakcji itp.) oraz dokładnie te same dane konta (salda konta, status zlecenia/transakcji itp.), robią to w znacząco różny sposób.

REST oferuje interfejs typu „wywołanie/odpowiedź” (pytanie/odpowiedź) i dostarcza migawkę bieżących danych, podczas gdy WebSocket oferuje interfejs typu „strumieniowanie na żywo” i dostarcza aktualizacje w czasie rzeczywistym.

Analogią byłaby różnica między zdjęciem a filmem, gdzie na żądanie zdjęcie dostarcza migawkę obiektu, ale bez dalszych aktualizacji, podczas gdy film zapewnia podgląd obiektu w czasie rzeczywistym z aktualizacjami na żywo.

Chociaż ani REST, ani WebSocket nie są trudne do zaimplementowania, ogólnie przyjmuje się, że REST jest mniej złożony, co pozwala skrócić czas rozwoju i szybciej rozwiązywać wszelkie późniejsze problemy.

REST opiera się na standardowych żądaniach HTTPS, które są zawarte w standardowych bibliotekach wszystkich nowoczesnych języków programowania (i mogłyby być łatwo zakodowane od podstaw, gdyby nie były), podczas gdy WebSocket opiera się na uaktualnieniu WSS z HTTPS, co zazwyczaj wymaga dodatkowych bibliotek stron trzecich (takich jak nasza zalecana biblioteka WebSocket dla Pythona).

Nasze strony wsparcia API zawierają gotowy do użycia przykładowy kod zarówno dla REST, jak i WebSocket, dlatego wybór interfejsu może być dokonany na podstawie bardziej krytycznych kryteriów, a nie łatwości implementacji.

W zależności od zadania, optymalnym wyborem byłoby użycie tylko REST, tylko WebSocket lub, co bardziej prawdopodobne, kombinacji obu.

W przypadku zadań wymagających jedynie sporadycznych aktualizacji danych rynkowych, REST byłby preferowanym wyborem. Na przykład, bot do uśredniania kosztów dziennych, który potrzebuje danych rynkowych tylko raz na 24 godziny, nie potrzebowałby strumieniowych danych rynkowych w czasie rzeczywistym, dlatego punkty końcowe danych rynkowych REST byłyby więcej niż odpowiednie.

W przypadku zadań wymagających najbardziej aktualnych dostępnych danych rynkowych, WebSocket byłby preferowanym wyborem. Na przykład, bot arbitrażowy potrzebowałby danych rynkowych w czasie rzeczywistym z wielu rynków, aby wykorzystać chwilowe różnice cen, dlatego kanały danych rynkowych WebSocket byłyby idealnym wyborem.

W większości przypadków (takich jak większość botów handlowych) kombinacja REST i WebSocket pozwoliłaby na najskuteczniejszą implementację. Na przykład, aplikacja mobilna może wymagać danych rynkowych w czasie rzeczywistym dla swoich wykresów, podczas gdy dane konta potrzebne są tylko sporadycznie (np. podczas dokonywania transakcji handlowej lub transakcji finansowania), dlatego użycie kanałów danych rynkowych WebSocket wraz z punktami końcowymi statusu zlecenia/transakcji/finansowania REST byłoby najbardziej efektywną kombinacją.

Nasz zespół wsparcia API z przyjemnością omówi z Tobą implementację API i zasugeruje optymalny sposób korzystania z naszego API w oparciu o zamierzony scenariusz użytkowania.