¿AJAX empuja una aberración del protocolo HTTP?

Question

Desarrollar una elegante arquitectura Pub-Sub en aplicaciones orientadas a la web es un verdadero desafío. Aunque hay algunas soluciones muy interesantes que utilizan conexiones largas de sondeo (por ejemplo, COMET) y tiempos de espera repetitivos (por ejemplo, js setTimeout). En mi humilde opinión, AJAX todavía se ve como una capa de ajustes y hacks forzando el inocente protocolo HTTP.

¿Qué crees que ¿AJAX empuja una aberración del protocolo HTTP?

¿Qué otras alternativas podría considerar en una arquitectura web?

Answer 1

Otra opción que he visto antes es utilizar un pequeño escondido de Java o Flash para conectarse a través de sockets simples al servidor remoto. El servidor puede enviar datos/eventos a través de estos sockets en cualquier momento, sin ninguna votación del cliente.

Flash es un poco mejor IMO ya que no requiere un applet firmado (que muestra advertencias de seguridad para el usuario). Ha tenido Sockets de una forma u otra durante algo así como 9 años, aunque no fue hasta Flash 9/AS3 que obtuviste enchufes "puros" que podrías usar para conectarte a cualquier tipo de servicio (anteriormente requería que los mensajes fueran terminado con un paquete 'nulo', lo que significa que debe diseñar su protocolo específicamente para flash, en lugar de poder usar XMPP o SMTP o cualquier protocolo existente)

Answer 2

¿Qué otras alternativas puede considerar en una arquitectura web?

El HTML 5 Web Sockets API y Server-sent Events parecen prometedores para el futuro. Todavía no hay soporte de IE para Web Sockets, y los eventos enviados por el servidor aún son experimentales. La propuesta de JSONRequest de Douglas Crockford también sería una alternativa interesante al empuje de AJAX, pero todavía no se implementa en los navegadores modernos.

Por el momento, me quedo con Comet.

Answer 3

El sondeo es la forma de arquitectura web de hacer pub-sub. Funciona bien cuando los clientes sondean con poca frecuencia y las respuestas pueden almacenarse en caché y compartirse (por ejemplo, el feed rss de un blog). Mantener un socket tcp abierto por cliente, como con cometa, no es la forma ideal de usar http. Sin embargo, si su aplicación se ejecuta en un navegador web y necesita actualizaciones frecuentes, únicas y por cliente, esa no es una mala manera de hacerlo.

Los cometas y las encuestas para los recursos por cliente no son completamente abusivos para http o la web, es solo que http y la web fueron diseñados especialmente para compartir los mismos recursos (es decir, páginas web) entre muchos clientes, así que esa es la forma en que funciona mejor.

Answer 4

Solo piense en las implementaciones de Comet más comunes, solo el hecho de que tiene que engañar al navegador haciéndole creer que está recibiendo una respuesta multiparte o un html infinitamente largo dentro de un iframe es suficiente para mostrar si este es el tecnología apropiada o no para el trabajo.