Interfejs API Websocket zastąpi REST API?

Mam aplikację, której podstawowa funkcja działa w czasie rzeczywistym, poprzez websockets lub długie odpytywanie.

Jednak większość witryny jest napisana w sposób RESTful, co jest przyjemne dla aplikacji i innych klientów w przyszłości. Jednak myślę o przejściu na interfejs API sieci Web dla wszystkich funkcji witryny, z dala od REST. Ułatwiłoby mi to integrację funkcji czasu rzeczywistego we wszystkich częściach witryny. Czy utrudniłoby to tworzenie aplikacji lub klientów mobilnych?

Odkryłem, że niektórzy ludzie już robią takie rzeczy: SocketStream

Nie mówiąc o tym, że inne odpowiedzi tutaj nie mają wartości, mają kilka dobrych punktów. Ale mam zamiar sprzeciwić się ogólnemu konsensusowi i zgodzić się z wami, że przejście na WebSockets w celu uzyskania czegoś więcej niż tylko funkcji czasu rzeczywistego jest bardzo atrakcyjne.

Poważnie rozważam przeniesienie mojej aplikacji z architektury RESTful do stylu RPC za pośrednictwem gniazd internetowych. To nie jest „aplikacja do zabawy” i nie mówię tylko o funkcjach działających w czasie rzeczywistym, więc mam zastrzeżenia. Ale widzę wiele korzyści z pójścia tą trasą i czuję, że może to być wyjątkowe rozwiązanie.

Mój plan zakłada użycie DNode , SocketIO i Backbone . Dzięki tym narzędziom moje modele i kolekcje Backbone mogą być przekazywane z / do klienta i serwera, po prostu wywołując funkcje w stylu RPC. Koniec z zarządzaniem punktami końcowymi REST, serializacją / deserializacją obiektów i tak dalej. Nie pracowałem jeszcze z gniazdem, ale wygląda na to, że warto to sprawdzić.

Przed nami jeszcze długa droga, zanim definitywnie stwierdzę, że jest to dobre rozwiązanie i jestem pewien, że nie jest to najlepsze rozwiązanie dla każdego zastosowania, ale jestem przekonany, że to połączenie byłoby wyjątkowo potężne. Przyznaję, że są pewne wady, jak na przykład utrata możliwości buforowania zasobów. Ale mam wrażenie, że zalety przeważą nad nimi.

Byłbym zainteresowany śledzeniem twoich postępów w odkrywaniu tego typu rozwiązań. Jeśli masz jakieś eksperymenty na githubie, wskaż mi je. Jeszcze nie mam, ale mam nadzieję, że wkrótce.

Poniżej znajduje się lista linków do przeczytania później, które zebrałem. Nie mogę ręczyć, że wszystkie są warte zachodu, ponieważ tylko przejrzałem wiele z nich. Ale miejmy nadzieję, że niektórzy pomogą.

Świetny samouczek dotyczący używania Socket.IO z Express. Udostępnia sesje ekspresowe do socket.io i omawia, jak mieć różne pokoje dla każdego uwierzytelnionego użytkownika.

• http://www.danielbaulig.de/socket-ioexpress/

Samouczek dotyczący node.js / socket.io / backbone.js / express / connect / jade / redis z uwierzytelnianiem, hostingiem Joyent itp .:

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Samouczek dotyczący używania Pushera z Backbone.js (przy użyciu Railsów):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

Zbuduj aplikację za pomocą backbone.js na kliencie i node.js z express, socket.io, dnode na serwerze.

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Używanie Backbone z DNode:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP REST i WebSockets są bardzo różne. Protokół HTTP jest bezstanowy , więc serwer sieciowy nie musi nic wiedzieć, a buforowanie w przeglądarce internetowej i na serwerach proxy. Jeśli używasz WebSockets, twój serwer staje się stanowy i musisz mieć połączenie z klientem na serwerze.

Komunikacja typu żądanie-odpowiedź a funkcja Push

Używaj WebSockets tylko wtedy, gdy potrzebujesz PUSH danych z serwera do klienta, ten wzorzec komunikacji nie jest uwzględniony w HTTP (tylko przez obejścia). Funkcja PUSH jest pomocna, jeśli zdarzenia utworzone przez innych klientów muszą być dostępne dla innych podłączonych klientów, np. W grach, w których użytkownicy powinni działać na zachowanie innych klientów. Lub jeśli Twoja witryna coś monitoruje, gdzie serwer cały czas przesyła dane do klienta, np. Giełdy (na żywo).

Jeśli nie potrzebujesz PUSH danych z serwera, zwykle łatwiej jest użyć bezstanowego serwera HTTP REST. HTTP używa prostego wzorca komunikacji żądanie-odpowiedź .

Myślę o przejściu na interfejs API WebSocket dla wszystkich funkcji witryny

Nie. Nie powinieneś tego robić. Nie ma nic złego, jeśli wspierasz oba modele. Użyj REST do komunikacji jednokierunkowej / prostych żądań i WebSocket do komunikacji dwukierunkowej, zwłaszcza gdy serwer chce wysyłać powiadomienia w czasie rzeczywistym.

WebSocket jest bardziej wydajnym protokołem niż RESTful HTTP, ale nadal RESTful HTTP uzyskuje wyniki w porównaniu z WebSocket w poniższych obszarach.

1. Tworzenie / aktualizowanie / usuwanie zasobów zostało dobrze zdefiniowane dla protokołu HTTP. Musisz zaimplementować te operacje na niskim poziomie dla WebSockets.

2. Połączenia protokołu WebSocket skalują się w pionie na jednym serwerze, podczas gdy połączenia HTTP skalują się w poziomie. Istnieje kilka zastrzeżonych niestandardowych rozwiązań dla skalowania poziomego WebSocket.

3. HTTP ma wiele dobrych funkcji, takich jak buforowanie, routing, multipleksowanie, gzipping itp. Jeśli wybrałeś Websocket, muszą one być oparte na Websocket.

4. Optymalizacje wyszukiwarek działają dobrze w przypadku adresów URL HTTP.

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

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

Więcej informacji znajdziesz w tym artykule .

Jedynym problemem, jaki mogę zastosować przy używaniu protokołu TCP (WebSockets) jako głównej strategii dostarczania treści internetowych, jest to, że jest bardzo mało materiałów do czytania na temat projektowania architektury i infrastruktury witryny internetowej przy użyciu protokołu TCP.

Nie możesz więc uczyć się na błędach innych ludzi, a rozwój będzie wolniejszy. Nie jest to również strategia „wypróbowana i przetestowana”.

Oczywiście stracisz również wszystkie zalety HTTP (bycie bezstanowym i buforowanie to największe zalety).

Pamiętaj, że HTTP jest abstrakcją dla protokołu TCP zaprojektowaną do obsługi treści internetowych.

I nie zapominajmy, że SEO i wyszukiwarki nie korzystają z gniazd internetowych. Możesz więc zapomnieć o SEO.

Osobiście odradzałbym to, ponieważ istnieje zbyt duże ryzyko.

Nie używaj WS do obsługi witryn internetowych, używaj go do obsługi aplikacji internetowych

Jeśli jednak masz zabawkę lub osobiste strony internetowe, zdecydowanie idź na to. Spróbuj, bądź nowatorski. W przypadku firmy lub firmy nie można uzasadnić takiego ryzyka.

Nauczyłem się małej lekcji (trudna droga). Zrobiłem aplikację do obliczania liczb, która działa w usługach w chmurze Ubuntu AWS EC2 (używa wydajnych procesorów graficznych) i chciałem zrobić dla niej front-end, aby obserwować jej postęp w czasie rzeczywistym. Ze względu na to, że potrzebował danych w czasie rzeczywistym, było oczywiste, że potrzebuję gniazd internetowych do przesyłania aktualizacji.

Zaczęło się od weryfikacji koncepcji i działało świetnie. Ale kiedy chcieliśmy udostępnić go publicznie, musieliśmy dodać sesję użytkownika, więc potrzebowaliśmy funkcji logowania. I bez względu na to, jak na to patrzysz, websocket musi wiedzieć, z którym użytkownikiem ma do czynienia, więc wybraliśmy skrót, używając gniazd sieciowych do uwierzytelniania użytkowników . Wydawało się to oczywiste i było wygodne.

Właściwie musieliśmy spędzić trochę czasu w ciszy, aby połączenia były niezawodne. Zaczęliśmy od kilku tanich samouczków dotyczących technologii WebSocket, ale odkryliśmy, że nasza implementacja nie była w stanie automatycznie połączyć się ponownie, gdy połączenie zostało zerwane. Wszystko się poprawiło, kiedy przeszliśmy na socket-io. Socket-io jest koniecznością!

Powiedziawszy to wszystko, szczerze mówiąc, myślę, że przegapiliśmy kilka świetnych funkcji socket-io. Socket-io ma znacznie więcej do zaoferowania i jestem pewien, że jeśli weźmiesz to pod uwagę w swoim początkowym projekcie, możesz wyciągnąć z niego więcej. W przeciwieństwie do tego, po prostu zastąpiliśmy stare gniazdka sieciowe funkcjonalnością gniazda sieciowego z gniazda-io i to wszystko. (bez pomieszczeń, bez kanałów, ...) Przeprojektowanie mogło sprawić, że wszystko będzie potężniejsze. Ale nie mieliśmy na to czasu. Warto o tym pamiętać w przypadku naszego następnego projektu.

Następnie zaczęliśmy przechowywać coraz więcej danych (historia użytkowników, faktury, transakcje, ...). Przechowaliśmy to wszystko w bazie danych AWS dynamodb i PONOWNIE użyliśmy socket-io do komunikacji operacji CRUD z front-endu do backendu. Myślę, że tam źle skręciliśmy. To był błąd.

• Ponieważ wkrótce po tym, jak dowiedzieliśmy się, że usługi chmurowe Amazon (AWS) oferują świetne narzędzia do równoważenia / skalowania obciążenia dla aplikacji RESTful .
• Mamy wrażenie, że musimy napisać dużo kodu, aby wykonać uzgadnianie operacji CRUD.
• Niedawno wdrożyliśmy integrację Paypal. Udało nam się to uruchomić. Ale znowu, wszystkie samouczki robią to za pomocą RESTful API . Musieliśmy przepisać / przemyśleć ich przykłady, aby zaimplementować je za pomocą gniazd sieciowych. Jednak udało nam się to dość szybko. Ale wydaje się, że idziemy pod prąd.

Powiedziawszy to wszystko, będziemy żyć w przyszłym tygodniu. Dotarliśmy na czas, wszystko działa. Jest szybki, ale czy będzie skalowany?

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

Rozdzielenie pracy przebiega następująco:

1. WebSockets byłyby podstawową metodą komunikacji aplikacji z serwerem, na którym wymagana jest sesja. Eliminuje to wiele hacków, które są potrzebne w starszych przeglądarkach (problemem jest obsługa starszych przeglądarek, która to wyeliminuje)

2. RESTful API jest używany do wywołań GET, które nie są zorientowane na sesję (tj. Nie są wymagane uwierzytelnianie), które korzystają z buforowania przeglądarki. Dobrym przykładem mogą być dane referencyjne dla list rozwijanych używanych przez aplikację internetową. Jednak. może zmieniać się nieco częściej niż ...

3. HTML i Javascript. Obejmują one interfejs użytkownika aplikacji internetowej. Te generalnie przyniosłyby korzyści, gdyby znalazły się w CDN.

4. Usługi sieci Web używające języka WSDL są nadal najlepszym sposobem komunikacji na poziomie przedsiębiorstwa i między przedsiębiorstwami, ponieważ zapewniają dobrze zdefiniowany standard przekazywania komunikatów i danych. Przede wszystkim przeładowałbyś to na urządzenie Datapower w celu proxy do modułu obsługi usług internetowych.

Wszystko to dzieje się na protokole HTTP, który już teraz zapewnia bezpieczne gniazda przez SSL.

Jednak w przypadku aplikacji mobilnej gniazda sieciowe nie mogą ponownie połączyć się z rozłączoną sesją ( jak ponownie połączyć się z usługą WebSocket po zamknięciu połączenia ), a zarządzanie tym nie jest trywialne. Tak więc w przypadku aplikacji mobilnych nadal polecałbym REST API i odpytywanie.

Inną 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 jest wykonane prawidłowo, jest bezstanowe (co oznacza, że ​​nie ma stanu serwera, którym trzeba zarządzać), dlatego skalowalność może rosnąć poziomo (co jest tańsze) niż pionowo .

Czy chcę aktualizacje z serwera?

• Tak: Socket.io
• Bez odpoczynku

Wady Socket.io to:

• Skalowalność: WebSockets wymagają otwartych połączeń i znacznie różniącej się konfiguracji operacji w celu skalowania sieci.
• Learnin: Nie mam nieograniczonego czasu na naukę. Trzeba coś zrobić!

Nadal będę używać Socket.io w moim projekcie, ale nie w przypadku podstawowych formularzy internetowych, które REST będzie dobrze działać.

Transporty oparte na protokołach WebSockets (lub długich odpytywaniach) służą głównie do (prawie) komunikacji w czasie rzeczywistym między serwerem a klientem. Chociaż istnieje wiele scenariuszy, w których wymagane są tego rodzaju transporty, takie jak czat lub jakieś źródła danych 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 architekturami. WebSockets skłaniają się bardziej do strumieni / źródeł danych w czasie rzeczywistym, co wymagałoby stworzenia pewnego rodzaju logiki opartej na serwerze w celu ustalenia priorytetów lub rozróżnienia między zasobami i kanałami (na wypadek, gdybyś nie chciał używać REST).

Zakładam, że w przyszłości będzie więcej struktur zorientowanych na WebSockets, takich jak socketstream, kiedy ten transport będzie bardziej rozpowszechniony i lepiej zrozumiany / udokumentowany w postaci dostarczania agnostycznego typu / formy danych. Myślę jednak, że nie oznacza to, że zastąpiłby / powinien zastąpić REST tylko dlatego, że oferuje funkcjonalność, która niekoniecznie jest wymagana w wielu przypadkach użycia i scenariuszach.

Chciałbym zwrócić uwagę na ten wpis na blogu, który należy do mnie, najlepszą odpowiedź na to pytanie.

Krótko mówiąc, TAK

Post zawiera wszystkie najlepsze praktyki dla tego rodzaju API.

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ł wrócić do flashowania lub długiego odpytywania itp. W przyszłości prawdopodobnie nadal nie będzie Ma to sens, ponieważ serwer musi obsługiwać pozostawianie otwartych połączeń dla każdego użytkownika. Zamiast tego większość serwerów internetowych jest zaprojektowana tak, aby szybko odpowiadać na żądania i zamykać je tak szybko, jak to możliwe. Do licha, nawet system operacyjny musiałby być dostrojony do obsługi dużej liczby jednoczesnych połączeń (każde połączenie zużywa więcej efemerycznych portów i pamięci). Trzymaj się REST dla jak największej części witryny.