Websocket API zastąpi REST API?

HTTP REST i WebSockets są bardzo różne. HTTP jest stateless , więc serwer WWW nie musi nic wiedzieć, a buforowanie odbywa się w przeglądarce internetowej i w serwerach proxy. Jeśli używasz WebSockets, Twój serwer staje się stateful i musisz mieć połączenie z Klientem na serwerze.

Komunikat Request-Reply vs Push

Użyj WebSockets tylko wtedy, gdy potrzebujesz PUSH danych z serwera do klienta, ten schemat komunikacji jest nieuwzględnione w HTTP(tylko przez obejścia). PUSH jest pomocny, gdy zdarzenia tworzone przez innych klientów muszą być dostępne dla innych połączonych klientów, np. w grach, w których użytkownicy powinni reagować na zachowania innych klientów. Lub jeśli Twoja strona coś monitoruje, gdzie serwer cały czas wysyła dane do klienta np. giełdy (na żywo).

Jeśli nie musisz wysyłać danych z serwera, zwykle łatwiej jest użyć bezstanowego serwera HTTP REST. HTTP używa prostego Request-Reply schemat komunikacji.

Myślę o przejściu na WebSocket api dla wszystkich funkcji strony

WebSocket jest bardziej wydajnym protokołem niż RESTful HTTP ale mimo to RESTful HTTP sprawdza się przez WebSocket w poniżej obszarów.

1. Zasoby Create/Update/Delete zostały dobrze zdefiniowane dla HTTP. Musisz wdrożyć te operacje na niskim poziomie dla WebSockets.

2. Połączenia WebSocket skalują się pionowo na pojedynczym serwerze, gdzie jako połączenia HTTP skalują się poziomo. Istnieje kilka zastrzeżonych, niestandardowych rozwiązań do skalowania poziomego WebSocket .

3. HTTP zawiera wiele dobrych funkcji, takich jak buforowanie, routing, multipleksowanie, gzipping itd. Muszą one być zbudowane na bazie Websocket, jeśli wybrałeś Websocket.

4. Optymalizacja dla wyszukiwarek działa dobrze dla adresów URL HTTP.

5. Wszystkie Proxy, DNS, firewalle nie są jeszcze w pełni świadome ruchu WebSocket. Pozwalają na port 80, ale mogą ograniczyć ruch, szpiegując go najpierw.

6. Bezpieczeństwo dzięki WebSocket to podejście "wszystko albo nic".

Jedynym problemem, który mogę używać TCP (WebSockets) jako głównej strategii dostarczania treści internetowych, jest to, że jest bardzo mało materiałów do czytania o tym, jak zaprojektować architekturę i infrastrukturę witryny za pomocą TCP.

Więc nie można uczyć się na błędach innych ludzi i rozwój będzie wolniejszy. Nie jest to również strategia" wypróbowana".

Oczywiście również stracisz wszystkie zalety HTTP (bycie bezstanowym, a buforowanie są większe zalety).

Pamiętaj, że HTTP jest abstrakcją dla TCP przeznaczoną do serwowania treści internetowych.

I nie zapominajmy, że SEO i wyszukiwarki nie robią websocketów. Więc możesz zapomnieć o SEO.

Osobiście polecam przeciwko temu, ponieważ istnieje zbyt duże ryzyko.

Nie używaj WS do serwowania stron internetowych, używaj go do serwowania aplikacji internetowych

Jeśli jednak masz zabawkę lub osobistą stronę internetową za wszelką cenę idź na to. Spróbuj, bądź nowatorskie. w przypadku firmy lub firmy nie można uzasadnić ryzyka takiego działania.

Rozważyłbym użycie obu. Każda technologia ma swoje zalety i nie ma jednego uniwersalnego rozwiązania.

Podział pracy przebiega w ten sposób:

1) WebSockets byłby podstawową metodą aplikacji do komunikacji z serwerem, na którym wymagana jest sesja. To eliminuje wiele hacków, które są potrzebne dla starszych przeglądarek (problem polega na obsłudze starszych przeglądarek, które wyeliminują ten problem)

2) RESTful API jest używany do wywołań GET, które nie są zorientowane na sesję (tzn. nie wymaga uwierzytelniania), które korzystają z buforowania przeglądarki. Dobrym tego przykładem mogą być dane referencyjne dla rozwijanych aplikacji internetowych. Jednak. może się zmieniać nieco częściej niż...

3) HTML i Javascript. Obejmują one interfejs aplikacji webapp. Na ogół korzystniej byłoby umieścić je na CDN.

4) Usługi internetowe wykorzystujące WSDL są nadal najlepszym sposobem komunikacji na poziomie przedsiębiorstwa i między przedsiębiorstwami, ponieważ zapewnia dobrze zdefiniowaną standard przekazywania wiadomości i danych. Przede wszystkim można przenieść to do urządzenia Datapower do proxy do obsługi usługi internetowej.

Wszystko to dzieje się na protokole HTTP, który daje już bezpieczne gniazda poprzez SSL.

W przypadku aplikacji mobilnej, websockets nie może ponownie połączyć się z odłączoną sesją (Jak ponownie połączyć się z websocket po bliskim połączeniu) i zarządzanie tym nie jest trywialne. Więc dla aplikacji mobilnych nadal polecam REST API i ankiety.

Kolejną rzeczą, na którą należy zwrócić uwagę podczas korzystania z WebSockets vs REST, jest skalowalność. Sesje WebSocket są nadal zarządzane przez serwer. RESTful API, gdy są prawidłowo wykonane, są bezstanowe (co oznacza, że nie ma stanu serwera, którym trzeba zarządzać), a więc skalowalność może rosnąć poziomo (co jest tańsze) niż pionowo.

Czy chcę aktualizacje z serwera?

• Tak: Socket.io
• No: REST

Wady do Socket.io są:

• skalowalność: WebSockets wymagają otwartych połączeń i znacznie innej konfiguracji Ops do skali internetowej.
• nauka: nie mam nieograniczonego czasu na naukę. Rzeczy muszą być zrobione!

I ' ll still use Socket.io w moim projekcie, ale nie dla podstawowych formularzy internetowych, które reszta będzie dobrze.

Transporty oparte na Websocketach (lub long polling) służą głównie do (bliskiej) komunikacji w czasie rzeczywistym między serwerem a klientem. Chociaż istnieje wiele scenariuszy, w których tego rodzaju transporty są wymagane, takich jak czat lub jakiś rodzaj kanałów w czasie rzeczywistym lub inne rzeczy, nie wszystkie części niektórych aplikacji internetowych muszą być koniecznie połączone dwukierunkowo z serwerem.

REST jest architekturą opartą na zasobach, która jest dobrze rozumiana i oferuje własne korzyści w porównaniu z innymi architektury. WebSockets skłaniają się bardziej do strumieni / kanałów danych w czasie rzeczywistym, co wymagałoby utworzenia pewnego rodzaju logiki opartej na serwerze w celu ustalenia priorytetów lub rozróżnienia między zasobami i kanałami (w przypadku, gdy nie chcesz używać REST).

Zakładam, że w przyszłości będzie więcej WebSockets centric frameworków, takich jak socketstream , gdy ten transport będzie bardziej rozpowszechniony i lepiej zrozumiany/udokumentowany w postaci typu danych/formy agnostycznej dostawa. Myślę jednak, że nie oznacza to, że zastąpi/zastąpi resztę tylko dlatego, że oferuje funkcjonalność, która nie jest koniecznie wymagana w wielu przypadkach użycia i scenariuszach.

To nie jest dobry pomysł. Standard nie jest jeszcze sfinalizowany, obsługa różni się w różnych przeglądarkach itp. Jeśli chcesz to zrobić teraz, będziesz musiał wycofać się do Flasha lub długiego sondażu itp. W przyszłości prawdopodobnie nadal nie będzie to miało większego sensu, ponieważ serwer musi obsługiwać pozostawianie połączeń otwartych dla każdego użytkownika. Większość serwerów internetowych jest zaprojektowana tak, aby szybko reagować na żądania i zamykać je tak szybko, jak to możliwe. Heck nawet Twój system operacyjny by muszą być dostrojone, aby poradzić sobie z dużą liczbą jednoczesnych połączeń (każde połączenie zużywa więcej efemerycznych portów i pamięci). Trzymaj się korzystania z odpoczynku dla jak największej części witryny.