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

9

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?

Victor Sergienko
fuente
1
¿Por qué tienes un servidor en la nube en la mezcla? Parece que todo lo que hace es redirigir, lo que me hace pensar que debería vivir en la misma máquina que el servidor doméstico ...
Jimmy Hoffa
3
Cuando analice las colas de mensajes, tenga en cuenta que la mayoría de ellas están optimizadas para LAN privadas: clientes con baja latencia, controlados, redes protegidas, etc. Exponer la cola a Internet puede ser un gran problema de seguridad.
Javier
@Jimmy Hoffapunto válido, gracias. Eso es correcto, pero no completamente. Es una base de datos común, almacenamiento, etc. @Javiergracias, es una buena parte de una respuesta.
Victor Sergienko
¿El servidor de inicio debe ejecutarse en el hogar de algunos usuarios y en el front-end en la nube? El hogar se conecta al front-end y el cliente envía mensajes al hogar a través del front-end. Si entiendo su diseño correctamente, puedo darle una respuesta a Dios.
Michael Brown
@Mike Brownexactamente. Por favor, hazlo.
Victor Sergienko

Respuestas:

5

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 .

gbjbaanb
fuente
Gracias. Lo que encontré después del @Javiercomentario: ØMQ parece no admitir el cifrado en sí mismo: zeromq.org/area:faq#toc8 aunque RabbitMQ sí: rabbitmq.com/ssl.html
Victor Sergienko
No sé si tengo la conectividad. Homees un dispositivo doméstico para el usuario y Clientes un teléfono inteligente a través de Wi-Fi o 3G. Una gran parte de la pregunta es mi ignorancia sobre los métodos transversales NAT.
Victor Sergienko
5

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.

Michael Brown
fuente
Muchas gracias. De hecho, podríamos superar CRUD, aunque no muy pronto, nuestro dominio es bastante simple ahora. Por cierto, el libro aún no se ha publicado, tratando de encontrar algunos materiales en el blog de Greg ... Creo que es bueno no tener que usar la tecnología de Microsoft para eso.
Victor Sergienko
Espera, su libro aún no está disponible ... ha estado hablando de eso tanto tiempo ... suena como otro autor técnico que conozco. : ">
Michael Brown
1
Para el registro, el enfoque REST sería tener un recurso de transferencia que cree. O incluso un TransferRequest que puede pasar o no. REST se vuelve complicado en algunos casos, pero este no es uno de ellos.
Jacek Gorgoń