Uso de solicitudes de bloqueo REST para implementar publicar/suscribir

Question

Recientemente me pidieron que investigue la viabilidad de integrarse con un proveedor de sistema telefónico que quiera hacer que los eventos telefónicos (por ejemplo, timbre de línea, extensión respondida, llamada borrada) estén disponibles con RESTful servicio web.

Señalé que REST es un protocolo de solicitud/respuesta y que estaban haciendo publicar/suscribir. La solución que sugerían era hacer una solicitud de HTTP REST que bloquearía y eventualmente respondería si y cuando un evento estuviera disponible, o fuera de tiempo.

De cualquier manera, se realizaría otra solicitud para obtener el próximo evento y así sucesivamente hasta el infinito.

Esta idea me hizo encogerme, pero me aseguraron que el correo electrónico "push" de iPhone funciona de esta manera.

¿Es este un uso razonable de REST?

Answer 1

Diría que no funciona bien con el estilo arquitectónico REST (principalmente porque REST lo limita a las interacciones de servidor de cliente sin estado). Sin embargo, la web está repleta de soluciones que realizan encuestas largas, y más o menos funciona, a pesar de no estar en el espíritu de la web.

En primer lugar, una nota sobre la arquitectura: la implementación de pub/sub dentro de REST simplemente significa que el editor agrega elementos a una lista que luego está disponible para los suscriptores. Los suscriptores sondean la lista. Hay formas de crear esto para garantizar una vez y solo una vez manteniendo el orden de los mensajes y (una forma de) entrega garantizada, aunque asincrónica. Se escala muy bien, y es realmente resistente.

Mi primer consejo sería hacer que sea opcional, de modo que los clientes que no pueden realizar encuestas largas (o que no quieran) puedan hacerlo. Incluso llegaría a decir que si un cliente genérico (como Google) el predeterminado sería no para realizar un sondeo largo, y que el servidor inicia el sondeo largo mediante un entendimiento especial compartido entre su cliente y el servidor. Esa comprensión compartida podría ser un tipo de medio personalizado o una relación de enlace personalizada, o incluso un encabezado HTTP personalizado que los clientes genéricos no conocerían. Los clientes que sí admiten su encuesta larga se codificarán en para descubrir las capacidades de la encuesta larga e invocarla según sea necesario, volviendo a la encuesta normal si la encuesta larga falla (por ejemplo, un intermediario la bloquea de alguna manera).

Y en lugar de tratar de hacer esto sobre HTTP, sugeriría usar un socket que no sea HTTP para esto, para no violar las intenciones de HTTP y usar HTTP de manera efectiva como protocolo de transporte. Ver cometd.

Mi otro consejo sería hacer la pregunta de qué tan "en tiempo real" deben estar sus clientes. Si unos pocos segundos de latencia son aceptables, entonces puede hacer mucho con la votación regular, incluso para un número extremadamente grande de clientes, debido a la naturaleza escondible de resolver esto usando encuestas regulares.