¿REST o una cola de mensajes en un sistema heterogéneo de varios niveles?

Estoy diseñando una API REST para un sistema de tres niveles como: Client application-> Front-end API cloud server-> user's home API server (Home).

Homees un dispositivo doméstico, y se supone que mantiene la conexión a Front-endtravés de Websocket o una encuesta larga (este es el primer lugar donde estamos violando REST. Más adelante empeora) . Front-endla mayoría de las veces hace un túnel Clientpara las solicitudes de Homeconexión y maneja algunas de las llamadas en sí. A veces Homeenvía notificaciones a Client.

Front-endy Hometiene básicamente la misma API; Clientpodría estar conectando Homedirectamente, a través de LAN. En este caso, Homenecesita registrar algunas Clientacciones en Front-endsí mismo.

Los pros para REST en este sistema son:

• REST es legible por humanos;
• REST tiene un mapeo bien definido de verbos (como CRUD), sustantivos y códigos de respuesta a objetos de protocolo;
• Funciona a través de HTTP y pasa todos los proxies posibles;

Los contras de REST son:

• No solo necesitamos un estilo de comunicación de solicitud-respuesta, sino también una publicación-suscripción;
• Los códigos de error HTTP pueden ser insuficientes para manejar errores de comunicación de tres niveles; Front-endpodría volver 202 Accepteda alguna llamada asincrónica solo para descubrir que la Homeconexión necesaria está interrumpida y debería haberla 503;
• Homenecesita enviar mensajes a Client. Clienttendrá que sondear Front-endo mantener una conexión.

Estamos considerando WAMP / Autobahn sobre Websocket para obtener la funcionalidad de publicación / suscripción, cuando me di cuenta de que ya parecía una cola de mensajes.

¿Vale la pena evaluar una especie de cola de mensajes como transporte?

Parece que los contras de la cola de mensajes son:

• Necesitaré definir verbos CRUD y códigos de error yo mismo a nivel de mensaje.
• Leí algo sobre "mayor costo de mantenimiento", pero ¿qué significa?

¿Qué tan serias son estas consideraciones?

Si tiene conectividad, vaya con una cola de mensajes, aunque debe definir sus propios protocolos (¡difícilmente una tarea difícil!) Para enviar mensajes de una estructura y formato particular.

El problema con el mantenimiento es que, por lo general, el cliente y el servidor se crean por separado, por lo que debe tener cuidado de mantener ambos extremos utilizando las mismas definiciones de mensaje, pero si no está lo suficientemente organizado, simplemente use el mismo XML que usaría en su REST Servicio.

Si tiene problemas de conectividad a través de Internet, con el puerto 80 y solo http y comunicaciones 'unidireccionales', entonces un sistema de estilo REST es probablemente el mejor. Envíe y realice encuestas, u obtenga un WebSocket para los datos de devolución de llamada, pero en general cree que su sistema sea cliente / servidor Si tiene la capacidad de obtener la conectividad, los sistemas de mensajería son excelentes.

Me gustaría ir con ZeroMQ para un sistema de mensajería, es lo suficientemente configurable para torcer en todo tipo de escenarios, incluyendo los de alta disponibilidad. Sin embargo, no estoy seguro de que funcione sobre http .

Parece que Autobahn encaja muy bien con lo que estás tratando de hacer. También hay otras herramientas disponibles. Consulte el Windows Azure Service Bus (que tiene marcos de cliente para Java, .NET, PHP, Python, NodeJS y Ruby).

Mientras que los mensajes de descanso incorporados son útiles. Encontrará que su aplicación superará las operaciones CRUD básicas. Por ejemplo, si su aplicación fuera un sistema bancario. En vez de

Actualizar cuenta 54321 Saldo = Saldo - 20.00 Actualizar cuenta 98765 Saldo = Saldo + 20.00

Probablemente quieras un solo mensaje como

Transfiera 20.00 de la cuenta 54321 a la cuenta 98765

Es mejor que descubras este impedimento con REST ahora y no más tarde. Echa un vistazo a Event Centric de Greg Young, que analiza cómo crear un modelo más rico para la mensajería dentro de tu aplicación.