Czy AJAX wypycha aberrację protokołu HTTP?

Question

Opracowanie eleganckiej architektury Pub-Sub w aplikacjach zorientowanych na sieć to prawdziwe wyzwanie. Chociaż istnieje kilka bardzo interesujących rozwiązań wykorzystujących długie połączenia głosowania (np. COMET) i powtarzające się limity czasu (np. Js setTimeout). Pchnięcie IMHO AJAX wciąż wygląda jak warstwa ulepszeń i hacków wymuszających niewinny protokół HTTP.

Więc jak myślisz Czy AJAX wypycha aberrację protokołu HTTP?

Jakie inne alternatywy można rozważyć w architekturze internetowej?

Answer 1

Inną opcją, którą widziałem wcześniej, jest użycie małej ukrytej Java lub Flasha do połączenia przez zwykłe gniazda z serwerem zdalnym. Serwer może następnie przesyłać dane/zdarzenia przez te gniazda w dowolnym momencie, bez pobierania z klienta.

Flash jest nieco lepszy IMO, ponieważ nie wymaga podpisanego apletu (który wyskakuje ostrzeżenia bezpieczeństwa dla użytkownika). Posiadał gniazda w takiej czy innej formie przez około 9 lat, ale dopiero w wersji Flash 9/AS3 otrzymałeś "czyste" gniazda, które można wykorzystać do połączenia z dowolnym rodzajem usługi (wcześniej wymagało to, aby wiadomości były zakończone pakietem "zerowym", co oznacza, że ​​musisz zaprojektować swój protokół specjalnie dla flash, zamiast być w stanie używać XMPP lub SMTP lub dowolnego istniejącego protokołu)

Answer 2

Jakie inne alternatywy można zastosować w architekturze internetowej?

HTML 5 Web Sockets API i Server-sent Events wyglądają obiecująco na przyszłość. Brak wsparcia dla IE dla Web Sockets, a zdarzenia Server-sent są wciąż eksperymentalne. Propozycja Douglasa Crockforda JSONRequest byłaby również interesującą alternatywą dla push AJAX, ale nie została jeszcze zaimplementowana w nowoczesnych przeglądarkach.

Do tej pory będę trzymać się z Comet.

Answer 3

Ankietowanie jest sposobem architektury internetowej na tworzenie pub-sub. Działa dobrze, gdy klienci rzadko przeprowadzają ankietę, a odpowiedzi mogą być buforowane i udostępniane (na przykład kanał RSS rss). Pozostawienie otwartego gniazda tcp na klienta, podobnie jak w przypadku komety, nie jest idealnym sposobem korzystania z protokołu http. Jeśli jednak Twoja aplikacja działa w przeglądarce i wymaga częstych, unikalnych aktualizacji na klienta, nie jest to zła metoda.

Kometa i pobieranie za zasoby klienta nie są całkowicie obraźliwe dla http lub internetu - po prostu http i sieć zostały zaprojektowane specjalnie w celu udostępniania tych samych zasobów (np. Stron internetowych) wielu klientom, więc to sposób, w jaki działa najlepiej.

Answer 4

Wystarczy pomyśleć o najczęstszych implementacjach Comet, tylko fakt, że trzeba oszukać przeglądarkę w myśleniu, że otrzymuje ona odpowiedź wieloczęściową lub nieskończenie długi kod HTML w elemencie iframe, wystarczy, aby podnieść flagę, czy jest to odpowiednią technologię lub nie do tej pracy.