HTTP RESTful et websocket dans la même application?
Si une application a déjà ouvert un WebSocket pour les flux en direct, dois-je l'utiliser sur AJAX pour les autres communications avec le serveur?
Étant donné que la connexion est déjà ouverte, devons-nous l'utiliser pour les demandes qui sont Request/Response et pas en temps réel?
Je préfère RESTful HTTP requêtes car je les trouve plus faciles à déboguer. Vous pouvez utiliser un navigateur avec des URL ou des boucles pour tester ce que l'API renvoie. Vous n'avez pas besoin d'écrire du code pour ouvrir un WebSocket.
Serait-ce bizarre d'avoir RESTful HTTP API et un WebSocket dans la même application?
L'un des principaux objectifs de conception de Websockets est qu'il permet aux protocoles HTTP et Websocket d'être communiqués sur le même port. Il y parvient en demandant explicitement à un client d'effectuer une négociation Websocket avec une demande de mise à niveau HTTP. De cette façon, le serveur peut gérer une connexion de demande HTTP standard ainsi qu'une demande de mise à niveau HTTP qui est maintenant mise à niveau vers une connexion duplex bidirectionnelle persistante.
Donc oui, c'est certainement un cas d'utilisation valable, mais si vous DEVRIEZ le faire pour votre application spécifique, c'est une tout autre affaire. Les Websockets sont utiles et ont du sens lorsque vous avez des scénarios selon lesquels le serveur doit avoir la possibilité d'envoyer des données non sollicitées au client (flux en direct). Le protocole HTTP et les services REST sont utiles lorsque vous souhaitez bloquer la sollicitation de données par le client synchrone.
Si vos exigences sont telles que ces deux éléments ont un sens pour votre application, vous devez certainement utiliser les deux. Si toutefois votre seule interaction avec le serveur est basée sur un flux en direct, alors REST ne sont pas appropriés. Je pense que la facilité de débogage devrait avoir une importance plutôt faible en termes de Attributs de qualité du système que vous devez architecturer votre conception.