HTTP RESTful et websocket dans la même application?

Si une application a déjà ouvert un WebSocketflux en direct, dois-je l'utiliser AJAXpour les autres communications avec le serveur?

Parce que la connexion est déjà ouverte, devons-nous l'utiliser pour des requêtes qui sont Request/Responseet non en temps réel?

Je préfère les RESTful HTTPrequê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 fichier WebSocket.

Serait-ce bizarre d'avoir RESTful HTTP APIet un WebSocketdans la même application?

rest ajax websockets

— Marc
source

"vous n'avez pas besoin d'écrire de code pour tester l'API" Pourriez-vous expliquer cela un peu plus? Qu'est-ce qui vous fait penser que vous n'avez pas à tester l'API?

— Elias Van Ootegem

Si je ne me trompe pas, les outils de développement Chrome vous permettent d'ouvrir une prise Web et d'envoyer des messages en temps réel

— maple_shaft

@EliasVanOotegem Bon point. Désolé, ce n'était pas clair. Vous devez encore tester l'API avec un projet d'unité côté serveur. Ce que je veux dire, c'est que si vous voulez un aperçu de ce que l'API retournerait, vous pouvez utiliser un navigateur avec l'URL. Vous n'avez pas besoin d'écrire du code pour ouvrir une websocket. J'ai mis à jour ma question.

— Marc

@maple_shaft C'est bien, mais vous devez être sur une page avec un WebSocket ouvert au serveur.

— Marc

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.

Alors oui, c'est certainement un cas d'utilisation valide, 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, les services REST ne sont pas appropriés. Je pense que la facilité de débogage devrait avoir une importance plutôt faible en termes d' attributs de qualité du système auxquels vous devriez concevoir votre conception.

— maple_shaft
source

Voilà ce que je me demandais. Il est logique d'utiliser les Websockets pour les flux en direct en temps réel, mais qu'en est-il des opérations CRUD? Il est plus logique dans mon esprit d'utiliser une requête HTTP standard pour ceux-ci.

— Marc

@Marc, je ne trouverais pas bizarre de séparer les opérations CRUD et les préoccupations en temps réel (l'une utilisant HTTP les autres Websockets) ... mais ... je crois que vous obtiendrez une meilleure réactivité du serveur, ainsi que de meilleures performances, si vous utilisez la connexion persistante (Websocket) pour toutes vos opérations. Cela dépend vraiment de vos besoins en CRUD, mais je ne reculerais pas devant une interface CRUD Websocket.

— Myst

voté! débutant ici, puisque vous avez mentionné que les deux doivent être communiqués sur le même port, si vous récupérez les cours des actions d'un flux en direct et en raison du trafic important, le flux se déconnecte pendant quelques minutes, comment obtiendrez-vous les données entre les deux ou quoi des stratégies existent pour s'attaquer à ce cas

— PirateApp