RESTful HTTP i websocket w tej samej aplikacji?

17

Jeśli aplikacja ma już otwarty kanał WebSocketna żywo, czy powinienem go użyć AJAXdo innej komunikacji z serwerem?

Ponieważ połączenie jest już otwarte, czy powinniśmy go używać do żądań, które nie są realizowane w Request/Responseczasie rzeczywistym?

Wolę RESTful HTTPżądania, ponieważ łatwiej mi je debugować. Możesz użyć przeglądarki z adresami URL lub lokami, aby sprawdzić, co zwraca API. Nie musisz pisać kodu, aby otworzyć WebSocket.

Byłoby to dziwne, aby RESTful HTTP APIi WebSocketw tej samej aplikacji?

rest ajax websockets Marc
źródło
1
„nie musisz pisać żadnego kodu, aby przetestować API” Czy możesz to wyjaśnić nieco więcej? Co sprawia, że ​​myślisz, że nie musisz testować interfejsu API?
Elias Van Ootegem
Narzędzia dla programistów Chrome, jeśli się nie mylę, pozwalają otwierać
gniazdo sieciowe
@EliasVanOotegem Dobry punkt. Przepraszam, że nie było jasne. Nadal musisz przetestować API z projektem jednostkowym po stronie serwera. Chodzi mi o to, że jeśli chcesz szybko sprawdzić, co zwróci interfejs API, możesz użyć broswer z adresem URL. Nie musisz pisać kodu, aby otworzyć gniazdo sieciowe. Zaktualizowałem swoje pytanie.
Marc
@maple_shaft To dobrze, ale musisz być na stronie z WebSocket otwartym na serwerze.
Marc

Odpowiedzi:

14

Jednym z głównych celów projektowych Websockets jest umożliwienie komunikacji zarówno protokołów HTTP, jak i Websocket przez ten sam port. Osiąga to poprzez jawne wymaganie od klienta wykonania uzgadniania Websocket z żądaniem aktualizacji HTTP. W ten sposób serwer może obsłużyć standardowe połączenie żądania HTTP, jak również żądanie uaktualnienia HTTP, które jest teraz uaktualniane do trwałego dwukierunkowego połączenia dupleksowego.

Tak, jest to zdecydowanie uzasadniony przypadek użycia, jednak to, czy POWINIENEŚ to zrobić dla konkretnego zastosowania, to zupełnie inna sprawa. Websockets są przydatne i mają sens tam, gdzie istnieją scenariusze, że serwer musi mieć możliwość wysyłania niechcianych danych do klienta (kanały na żywo). Protokół HTTP i usługi REST są przydatne tam, gdzie chcesz blokować synchroniczne pozyskiwanie danych przez klientów.

Jeśli twoje wymagania są takie, że oba z nich mają sens dla twojej aplikacji, to z całą pewnością powinieneś użyć obu. Jeśli jednak Twoja jedyna interakcja z serwerem opiera się na transmisji na żywo, usługi REST nie są odpowiednie. Myślę, że łatwość debugowania powinna mieć raczej niską wagę pod względem atrybutów jakości systemu , do których należy zaprojektować swój projekt.

wałek klonowy
źródło
1
Właśnie się nad tym zastanawiałem. Rozsądne jest używanie gniazd internetowych do transmisji na żywo w czasie rzeczywistym, ale co z operacjami CRUD? Moim zdaniem bardziej sensowne jest użycie standardowego żądania HTTP.
Marc
2
@Marc, nie uważałbym za dziwne oddzielenie operacji CRUD i problemów w czasie rzeczywistym (jedna używa HTTP, a druga Websockets) ... ale ... Wierzę, że dostaniesz lepszą reakcję z serwera, a także lepszą wydajność, jeśli korzystasz z trwałego połączenia (Websocket) do wszystkich swoich operacji. To naprawdę zależy od twoich potrzeb CRUD, ale nie unikałbym interfejsu CRUD Websocket.
Myst
entuzjastycznie! początkujący tutaj, ponieważ wspomniano, że oba mają być przekazywane przez ten sam port, jeśli pobierasz powiedzmy ceny akcji ze strumienia na żywo, a ze względu na duży ruch strumień rozłącza się na kilka minut, w jaki sposób można uzyskać dane pomiędzy nimi lub co istnieją strategie rozwiązania tego problemu
PirateApp