Oui, et c’est dommage. Des outils plus ou moins répandus utilisent les WebSockets ou sont en passe de le faire, comme Etherpad, Collabora Online ou Jitsi Meet.
Mieux vaut effectivement implémenter une solution de repli sans WebSocket. Par défaut, Trivabble essaie de se connecter en WebSocket et si ça merde, passe à du SSE + requête HTTP classique, et si ça ça foire, bascule sur XHR long polling + requête HTTP classique.
Selon le fonctionnement de votre code, je suggère de ne pas donner de réponse autre que des codes d'erreurs dans les requêtes classiques et de tout donner dans les WebSocket / requêtes longues si l'ordre des actions est important, sinon ça peut donner des bugs intéressants (ou de ne pas traiter les réponses des requêtes HTTP classiques si on sait que les données seront retrouvées dans les requêtes longues, ça permet parfois de garder son API cohérente ou de ne pas tout changer). Ça permet d'ordonner les messages plus facilement.
[^] # Re: Websocket et outils réseaux.
Posté par raphj (site web personnel) . En réponse à la dépêche Communiquer avec le serveur depuis un navigateur Web : XHR, SSE et WebSockets. Évalué à 5. Dernière modification le 18 avril 2021 à 16:48.
Oui, et c’est dommage. Des outils plus ou moins répandus utilisent les WebSockets ou sont en passe de le faire, comme Etherpad, Collabora Online ou Jitsi Meet.
Mieux vaut effectivement implémenter une solution de repli sans WebSocket. Par défaut, Trivabble essaie de se connecter en WebSocket et si ça merde, passe à du SSE + requête HTTP classique, et si ça ça foire, bascule sur XHR long polling + requête HTTP classique.
Selon le fonctionnement de votre code, je suggère de ne pas donner de réponse autre que des codes d'erreurs dans les requêtes classiques et de tout donner dans les WebSocket / requêtes longues si l'ordre des actions est important, sinon ça peut donner des bugs intéressants (ou de ne pas traiter les réponses des requêtes HTTP classiques si on sait que les données seront retrouvées dans les requêtes longues, ça permet parfois de garder son API cohérente ou de ne pas tout changer). Ça permet d'ordonner les messages plus facilement.