Estilo de interacción basada en eventos en REST

Question

Actualmente estoy luchando con un problema de diseño relacionado con REST. La aplicación que estoy diseñando tiene el requisito de enviar eventos y también admite el estilo de interacción pub/sub. No puedo crear un diseño para proporcionar este estilo de interacción sin romper la restricción de "interacción sin estado" del REST. No estoy en contra de las encuestas como algunas personas parecen (las encuestas son una mierda), pero mi aplicación exige un estilo de interacción basado en eventos y pub/sub (la votación no es una opción para mí). Entonces, mi pregunta es:

1. ¿Puedo diseñar una aplicación RESTful que admita interacciones basadas en eventos y pub/sub sin romper el CONTRAST de REST?
2. ¿El estilo REST es adecuado para este tipo de estilo de interacción?

Answer 1

Recomendaría el Distributed Observer Pattern de Duncan Cragg como una buena lectura (un poco difícil de asimilar, pero vale la pena el esfuerzo).

Como otros han indicado, es probable que necesite usar encuestas pero, como correctamente dice, los suscriptores podrían registrar sus propios intereses (POST para crear una suscripción).Si ve la suscripción como su propio recurso, un contrato entre el editor y el suscriptor, entonces no lo vería como una restricción REST (consulte Estado y apatridia en la página 217 de RESTful Web Services para ver la diferencia entre la aplicación y estado del recurso)

Answer 2

No veo una razón por la cual las interfaces RESTful no deberían admitir eventos.

Tendrá que hacerse a través de las encuestas; y eso sería cierto incluso si fuera a usar SOAP en su lugar.

Si bien sus servidores web definitivamente deberían permanecer sin estado, es probable que tenga una base de datos en algún lugar en la parte de atrás. Puede usar este DB para manejar suscripciones a eventos agregando una tabla de suscripción.

Answer 3

Supongo que quiere decir que el servidor debe notificar a los clientes sobre los eventos. No veo cómo la tecnología específica importa aquí: usted enfrentará los mismos problemas y tendrá que elegir una solución del mismo grupo de servidores, independientemente de usar REST, servicios web basados ​​en SOAP o cualquier otra alternativa.

La pregunta básica es, ¿su servidor puede iniciar las conexiones? Complementando esto, ¿pueden los clientes escuchar un puerto? Si es así, el cliente se registra (sub) y el servidor notifica eventos (pub). Tanto la operación de registro como los eventos de notificación pueden ser RESTful.

Necesita conexiones iniciadas por el servidor y clientes que escuchan. Si ninguno de los dos es una opción (por ejemplo, porque el cliente es un navegador web), tendrá que arreglárselas con las encuestas (también puede buscar algo así como websockets, si está tratando con un navegador). Diseñe su encuesta cuidadosamente: la respuesta del servidor al evento de votación debe indicar un retraso mínimo antes de que el cliente pueda volver a sondear. La implementación inicial del servidor puede devolver una constante para este valor de retardo, pero más tarde (suponiendo que los clientes se porten bien) esto le permitirá controlar la carga en el servidor, diferenciar entre clientes críticos y menos críticos, y así en.

Y, por supuesto, la votación puede ser RESTful.

Answer 4

Here es una discusión sobre el tema por Roy.

Answer 5

Sólo un registro rápido en las limitaciones REST:

• arquitectura cliente-servidor
• sin estado
• caché
• interfaz uniforme
  • identificación de recursos
  • manipulación de recursos a través de representaciones
  • mensajes de auto-desriptive
  • hipermedia del motor del estado de la aplicación del sistema
• capas Código
• bajo demanda (opcional)

De la disertación Fielding:

El estilo cliente-servidor es el más frecuentemente encontrado de los estilos arquitectónicos para las aplicaciones basadas en la red. Un componente de servidor , que ofrece un conjunto de servicios, escucha solicitudes sobre esos servicios . Un componente del cliente, que desea que se realice un servicio, envía una solicitud al servidor a través de un conector. El servidor rechaza o realiza la solicitud y envía una respuesta al cliente .

Btw. un sistema basado en eventos probablemente violaría la mayoría de las restricciones. Es difícil de definir cosas como hypermedia the engine of application state sin clientes (ya que el otro nombre de application state es client state) e hiperenlaces (ya que no tienen sentido por el pub/sub), y así sucesivamente ...

De todas formas es una cuestión interesante cómo diseñar un sistema basado en eventos algo similar a REST. Creo que deberías publicar mensajes autodescriptivos que contengan RDF, pero eso es solo un consejo. El sondeo puede ser viable solution, pero si yo fuera usted, no intentaría forzar REST en un sistema basado en eventos ...

actualización 2016.05.15.

Por lo que yo entiendo, el cliente - arquitectura del servidor - Fielding describe here y here en su disertación - utiliza siempre la comunicación REQ/REP. El cliente envía la solicitud y el servicio REST responde. Si desea tener algo como PUB/SUB sin la violación de la restricción cliente-servidor, la única forma de hacerlo es mediante el uso de sondeo. Si no quiere usar encuestas, entonces ofc. puede utilizar un servicio REST y un servicio websocket juntos, no está prohibido ...

Answer 6

Los webhooks son la respuesta a este problema. Permiten eventos sin violar los principios de REST.