Dans un scénario de demande-réponse HTTP standard, un client ouvre une connexion, envoie une requête HTTP au serveur (par exemple une requête HTTP GET), puis reçoit une réponse HTTP et le serveur ferme la connexion une fois la réponse entièrement envoyée / reçue.
L'initiative provient toujours d'un client lorsque le client demande toutes les données. En revanche, Server-Sent Events (SSE) est un mécanisme qui permet au serveur de transmettre de façon asynchrone les données du serveur au client une fois la connexion client-serveur établie par le client.
Une fois la connexion établie par le client, c'est le serveur qui fournit les données et décide de l'envoyer au client chaque fois qu'un nouveau «morceau» de données est disponible.
Lorsqu'un nouvel événement de données se produit sur le serveur, l'événement de données est envoyé par le serveur au client. Ainsi, le nom SSE « Server-Sent Events ».
Notez qu'à haut niveau il y a plus de technologies travaillant sur ce principe, un bref aperçu des technologies supportant la communication de serveur à client est dans cette liste.
Une question? Posez-la ici
Polling/Sondage
Lors de l'interrogation, un client envoie régulièrement de nouvelles requêtes à un serveur. Si le serveur n'a pas de nouvelles données, il envoie l'indication appropriée et ferme la connexion. Le client attend alors un peu et envoie une autre demande après un certain temps (après une seconde, par exemple).
Long sondage/Long-polling
Avec un sondage long, un client envoie une requête à un serveur. Si le serveur n'a pas de nouvelles données, il tient juste la connexion ouverte et attend que les données soient disponibles. Une fois que le serveur a des données (message) pour le client, il utilise la connexion et le renvoie au client. La connexion est alors fermée.
SSE Server-Sent events
SSE est semblable au mécanisme de long sondage/long polling, sauf qu'il n'envoie pas un seul message par connexion. Le client envoie une requête et le serveur détient une connexion jusqu'à ce qu'un nouveau message soit prêt, puis il envoie le message au client tout en maintenant la connexion ouverte afin qu'il puisse être utilisé pour un autre message une fois qu'il est disponible.
Une fois qu'un nouveau message est prêt, il est renvoyé au client sur la même connexion initiale. Client traite les messages renvoyés du serveur individuellement sans fermer la connexion après le traitement de chaque message. Ainsi, SSE réutilise généralement une connexion pour plus de messages (appelés événements). SSE définit également un type de support dédié qui décrit un format simple d'événements individuels envoyés du serveur au client. SSE propose également une API client javascript standard qui implémente les navigateurs les plus modernes. Pour plus d'informations sur SSE, consultez la spécification de l'API SSE.
Une question? Posez-la ici
WebSocket
La technologie WebSocket est différente des technologies précédentes car elle fournit une vraie connexion full duplex. L'initiateur est de nouveau un client qui envoie une requête à un serveur avec un en-tête HTTP spécial qui informe le serveur que la connexion HTTP peut être "mise à niveau" vers une connexion WebSocket TCP / IP full duplex. Si le serveur prend en charge WebSocket, il peut choisir de le faire. Une fois qu'une connexion WebSocket est établie, elle peut être utilisée pour la communication bidirectionnelle entre le client et le serveur. Le client et le serveur peuvent ensuite envoyer des données à l'autre partie à volonté quand il est nécessaire. La communication sur la nouvelle connexion WebSocket n'est plus basée sur le protocole HTTP et peut être utilisée par exemple pour les jeux en ligne ou toute autre application nécessitant un échange rapide de petits morceaux de données dans les deux sens.
Quand utiliser SSE ?
Comme expliqué ci-dessus, SSE est une technologie qui permet aux clients de s'abonner aux notifications d'événements qui proviennent d'un serveur. Le serveur génère de nouveaux événements et renvoie ces événements aux clients abonnés pour recevoir les notifications. En d'autres termes, SSE propose une solution pour un modèle unidirectionnel de publication-souscription.
Un bon exemple du cas d'utilisation où SSE peut être utilisé est un service simple RESTful échange de messages. Les clients postent de nouveaux messages au service et s’abonnent pour recevoir des messages d'autres clients. Appels des messages de ressources. Bien que le fait de faire un POST d’un nouveau message à cette ressource implique une communication typique HTTP demande-réponse entre un client et la ressource messages, l'abonnement à recevoir toutes les nouvelles notifications de message serait difficile et peu pratique à modéliser avec une séquence d'échanges standard de demande-réponse.
L'utilisation d'événements envoyés par le serveur offre une approche beaucoup plus pratique ici. On peut utiliser SSE pour permettre aux clients de s'abonner à la ressource de messages via la requête GET standard (utiliser une API client SSE, par exemple API javascript ou API SSE Client Jersey) et laisser le serveur diffuser de nouveaux messages à tous les clients connectés sous forme d'événements individuels (Dans notre cas en utilisant Jersey Server SSE API). Notez qu'avec Jersey un support SSE est implémenté comme une méthode de ressource JAX-RS habituelle. Il n'est pas nécessaire de faire quelque chose de spécial pour fournir un support SSE dans vos applications Jersey / JAX-RS, vos ressources SSE sont une partie standard de votre application Web RESTful qui définit l'API REST de votre application.
Une question? Posez-la ici
API Jersey Server-Sent Events
Jersey contient la prise en charge de SSE pour les deux - serveur et client. SSE à Jersey est implémenté comme une extension prenant en charge un nouveau type de média, ce qui signifie que SSE vraiment traité comme juste un autre type de média qui peut être retourné à partir d'une méthode de ressource et traité par le client. Il n'y a que peu de support supplémentaire pour les messages "en blocs" ajoutés à Jersey qui ne peuvent pas être mis en œuvre en tant que prolongement de type JAX-RS standard.
Dépendance JerseySSE :
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-sse</artifactId>
</dependency>
SseFeature ajoute de nouveaux types d'entité (représentation) pris en charge, à savoir OutboundEvent pour les événements du serveur sortant et InboundEvent pour les événements client entrants. Ces types sont sérialisés par OutboundEventWriter et dé-sérialisés par InboundEventReader. Il n'existe aucune restriction pour un type de média utilisé dans les messages d'événement individuels; Mais le type de média utilisé pour un flux SSE est «text / event-stream» et ce type de média doit être défini sur les messages utilisés pour servir les événements SSE (par exemple sur le côté serveur en utilisant @Produces sur la méthode renvoyée Un EventOutput - voir ci-dessous).
InboundEvent et OutboundEvent contiennent tous les champs nécessaires à la composition et au traitement des événements SSE individuels. Ces entités représentent les blocs envoyés ou reçus sur une connexion serveur-client ouverte qui est représentée par un ChunkedOutput côté serveur et ChunkedInput côté client. En d'autres termes, notre méthode de ressource qui est utilisée pour ouvrir une connexion SSE à un client ne retourne pas des OutboundEvents individuels. Au lieu de cela, une nouvelle instance de EventOutput est renvoyée. EventOutput est une extension typée de ChunkedOutput <OutboundEvent>. De même, pour recevoir InboundEvents côté client, Jersey SSE API fournit un EventInput qui représente une extension typée de ChunkedInput <InboundEvent>.
L'API SSE du serveur Jersey contient également un utilitaire SseBroadcaster qui fournit un moyen pratique de regrouper plusieurs instances EventOutput qui représentent des connexions client individuelles dans un groupe et expose des méthodes pour diffuser de nouveaux événements à toutes les connexions client regroupées dans le diffuseur. Le SseBroadcaster hérite de Broadcaster qui est l'implémentation générique de radiodiffuseur de l'installation de traitement de message en chanfrein de Jersey. Du côté client, l'API SSE Jersey contient des classes EventSource et EventListener supplémentaires qui améliorent encore la commodité du traitement des nouveaux événements SSE entrants.
Voir document original doc officielle : https://jersey.java.net/documentation/latest/sse.html
Besoin d'aide avec Jersey SSE? Remplissez ce petit formulaire: