Avance rapide jusqu'en décembre 2017, les Websockets sont pris en charge par (pratiquement) tous les navigateurs et leur utilisation est très courante.
Cependant, cela ne signifie pas que Websockets a réussi à remplacer AJAX, du moins pas complètement, d'autant que l'adaptation HTTP / 2 est en augmentation.
La réponse courte est que AJAX est toujours idéal pour la plupart des applications REST, même lors de l'utilisation de Websockets. Mais Dieu est dans les détails, alors ...:
AJAX pour le sondage?
L'utilisation d'AJAX pour l'interrogation (ou l'interrogation longue) est en train de disparaître (et elle devrait l'être), mais elle reste utilisée pour deux bonnes raisons (principalement pour les petites applications Web):
Pour de nombreux développeurs, AJAX est plus facile à coder, en particulier lorsqu'il s'agit de coder et de concevoir le backend.
Avec HTTP / 2, le coût le plus élevé lié à AJAX (l'établissement d'une nouvelle connexion) a été éliminé, permettant aux appels AJAX d'être assez performants, en particulier pour la publication et le téléchargement de données.
Cependant, Websocket push est de loin supérieur à AJAX (pas besoin de ré-authentifier ou de renvoyer les en-têtes, pas besoin d'aller-retour «pas de données», etc.). Cela a été discuté à plusieurs reprises.
AJAX pour REST?
Une meilleure utilisation d'AJAX est les appels d'API REST. Cette utilisation simplifie la base de code et empêche la connexion Websocket de se bloquer (en particulier lors de téléchargements de données de taille moyenne).
Il existe un certain nombre de raisons impérieuses de préférer AJAX pour les appels d'API REST et les téléchargements de données:
L'API AJAX a été pratiquement conçue pour les appels d'API REST et c'est un excellent ajustement.
Les appels et les téléchargements REST utilisant AJAX sont beaucoup plus faciles à coder, à la fois sur le client et sur le backend.
À mesure que la charge utile des données augmente, les connexions Websocket peuvent être bloquées à moins que la logique de fragmentation / multiplexage des messages ne soit codée.
Si un téléchargement est effectué dans un seul send
appel Websocket , il peut bloquer un flux Websocket jusqu'à la fin du téléchargement. Cela réduira les performances, en particulier sur les clients plus lents.
Une conception courante utilise de petits messages bidirectionnels transférés sur les Websockets tandis que le REST et les téléchargements de données (client vers serveur) tirent parti de la facilité d'utilisation d'AJAX pour empêcher le Websocket de se bloquer.
Cependant, sur des projets plus importants, la flexibilité offerte par les Websockets et l'équilibre entre la complexité du code et la gestion des ressources feront pencher la balance en faveur des Websockets.
Par exemple, les téléchargements basés sur Websocket pourraient offrir la possibilité de reprendre des téléchargements volumineux après qu'une connexion soit interrompue et rétablie (rappelez-vous que le film de 5 Go que vous vouliez télécharger?).
En codant la logique de fragmentation du téléchargement, il est facile de reprendre un téléchargement interrompu (la partie difficile était de coder la chose).
Qu'en est-il du HTTP / 2 push?
Je devrais probablement ajouter que la fonction push HTTP / 2 ne remplace pas (et ne peut probablement pas) remplacer les Websockets.
Cela avait déjà été discuté ici auparavant, mais il suffit de mentionner qu'une seule connexion HTTP / 2 dessert l'ensemble du navigateur (tous les onglets / fenêtres), donc les données poussées par HTTP / 2 ne savent pas à quel onglet / fenêtre il appartient, éliminant sa capacité à remplacer la capacité de Websocket à envoyer des données directement vers un onglet / une fenêtre de navigateur spécifique.
Alors que les Websockets sont parfaits pour les petites communications de données bidirectionnelles, AJAX comportait toujours un certain nombre d'avantages - en particulier lorsque l'on considère des charges utiles plus importantes (téléchargements, etc.).
Et la sécurité?
Eh bien, en général, plus un programmeur bénéficie de la confiance et du contrôle, plus l'outil est puissant ... et plus les problèmes de sécurité augmentent.
AJAX, par nature, aurait le dessus, car sa sécurité est intégrée au code du navigateur (ce qui est parfois discutable, mais il est toujours là).
D'un autre côté, les appels AJAX sont plus sensibles aux attaques de type "homme au milieu", tandis que les problèmes de sécurité Websockets sont généralement des bogues dans le code d'application qui ont introduit une faille de sécurité (généralement la logique d'authentification principale est l'endroit où vous les trouverez).
Personnellement, je ne trouve pas que ce soit une si grande différence, si je pense que les Websockets sont un peu mieux, surtout quand vous savez ce que vous faites.
Mon humble avis
À mon humble avis, j'utiliserais des Websockets pour tout sauf les appels d'API REST. Importations de données volumineuses Je fragmenterais et enverrais par Websockets lorsque cela est possible.
L'interrogation, à mon humble avis, devrait être interdite, le coût du trafic réseau est horrible et Websocket push est assez facile à gérer même pour les nouveaux développeurs.