Comment créer un système de notification asynchrone en utilisant les services web RESTful?
j'ai une application Java que je rends disponible via les services web RESTful. Je veux créer un mécanisme pour que les clients puissent s'inscrire pour des notifications d'événements. Le hic, c'est qu'il n'y a aucune garantie que les programmes clients seront des programmes Java et donc que je ne pourrai pas utiliser JMS pour cela (c'est-à-dire que si chaque client était une application Java, nous pourrions permettre aux clients de s'abonner à un sujet JMS et d'y écouter des messages de notification).
Le cas d'utilisation est à peu près comme suit:
- un client s'enregistre avec mon application Serveur, via un appel de service Web, indiquant qu'il est intéressé à recevoir un message de notification à chaque fois qu'un objet spécifique est mis à jour.
- lorsque l'objet d'intérêt est mis à jour, alors mon application serveur doit émettre une notification à tous les clients qui sont intéressés à être informés de cet événement.
comme je l'ai mentionné ci-dessus, je sais comment je ferais si tous les clients étaient Java apps -- définissez un sujet que les clients peuvent écouter pour les messages de notification. Cependant, je ne peux pas utiliser cette approche car il est probable que de nombreux clients ne seront pas en mesure d'écouter un sujet JMS pour les messages de notification.
quelqu'un sait-il m'éclairer sur la façon dont ce problème est généralement résolu? Quel mécanisme puis-je fournir en utilisant une API RESTful?
4 réponses
je ne peux penser à de quatre approches:
une approche Twitter: vous enregistrez le Client et ensuite il rappelle périodiquement avec un GET pour récupérer les notifications.
le Client décrit comment il veut recevoir la notification quand il fait la demande d'enregistrement. De cette façon, vous pouvez autoriser JMS pour ceux qui peuvent le gérer et retomber sur le courriel ou similaire pour ceux qui ne peuvent pas.
prendre une URL pendant le demande d'inscription et postez à chaque Client individuellement lorsque vous avez une notification. A peine Pub / Sub mais l'effet serait similaire. Bien sûr, vous supposeriez que le Client était à l'écoute de ces notifications et avait mis en œuvre leur Client selon vos spécifications.
acheter IBM WebSphere MQ (MQSeries). Meilleur produit IBM jamais. Pas de repos, mais c'est génial pour une intégration multi-plateforme comme celle-ci.
nous avons ce problème et avons besoin de mises à jour asynchrones à faible latence pour relativement peu d'auditeurs. Nos deux solutions alternatives ont été:
- Sondage: Hammer la liste des ressources dont vous avez besoin avec les requêtes GET
- événement en Streaming les mises à jour: fournir une ressource de moniteur. Le serveur maintient ouverte. Au fur et à mesure que des événements se produisent, le serveur transmet un flux de descriptions d'événements à l'aide du type de contenu multipartie ou du chunked transfer-encoding.
dans la réponse à la requête RESTful, vous pouvez fournir une URL RESTful individualisée que le client peut surveiller pour les mises à jour.
C'est-à-dire que vous avez une URL (/Signup.htm, say), qui accepte les informations du client (id s'il y a lieu, id de l'objet à surveiller) et renvoie une url personnalisée (/Monitor/XYZPDQ), où XYZPDQ est un UUID créé pour ce client Particulier. Le client peut Poller cette URL personnalisée à un certain intervalle, et il recevra une notification si la mise à jour produire.
si vous ne vous souciez pas de qui est le client (et ne voulez pas créer autant d'UUIDs), vous pouvez juste avoir des URLs RESTful séparées pour chaque objet qui pourrait vouloir être surveillé, et L'URL "signup" retournerait juste la bonne URL.
comme le dit John Saunders, vous ne pouvez pas vraiment faire une publication/Abonnement plus simple via HTTP.