API Websocket pour remplacer L'API REST?

j'ai une application dont la fonction principale fonctionne en temps réel, par le biais de websockets ou de longs sondages.

cependant, la plupart du site est écrit D'une manière reposante, ce qui est agréable pour les applications et d'autres clients à l'avenir. Cependant, je pense passer à une API websocket pour toutes les fonctions du site, loin de REST. Cela rendrait plus facile pour moi d'intégrer en temps réel des caractéristiques dans toutes les parties du site. Serait-ce le rendre plus difficile à construire des applications ou des clients mobiles?

j'ai trouvé que certaines personnes font déjà des choses comme ça: SocketStream

81
demandé sur Peter Mortensen 2011-07-24 14:30:22

8 réponses

pour ne pas dire que les autres réponses ici n'ont pas de mérite, elles font quelques bons points. Mais je vais aller à l'encontre du consensus général et d'accord avec vous que passer à websockets pour plus que des fonctionnalités en temps réel est très attrayant.

j'envisage sérieusement de déplacer mon application d'une architecture reposante à un style RPC via des websockets. Ce n'est pas une "application jouet", et je ne parle pas seulement de fonctionnalités en temps réel, donc j'ai des réservations. Mais je vois de nombreux avantages à suivre cette voie et estiment qu'elle pourrait s'avérer être une solution exceptionnelle.

mon plan est d'utiliser DNode , SocketIO , et Backbone . Avec ces outils, mes modèles et collections de base peuvent être transmis de / vers le client et le serveur en appelant simplement une fonction RPC-style. Plus de gestion des points de repos, de sérialisation / désérialisation des objets, et ainsi de suite. Je n'ai pas travaillé avec socketstream encore, mais il semble intéressant de vérifier.

j'ai encore un long chemin à parcourir avant de pouvoir affirmer que c'est une bonne solution, et je suis sûr que ce n'est pas la meilleure solution pour chaque application, mais je suis convaincu que cette combinaison serait exceptionnellement puissante. J'admets qu'il y a certains inconvénients, comme la perte de la capacité de mettre les ressources en cache. Mais j'ai le sentiment que les avantages l'emporteront.

je serais intéressé par en suivant vos progrès, explorez ce type de solution. Si vous avez des expériences de github, montrez-les-moi. Je n'ai pas encore, mais j'espère à bientôt.

vous trouverez ci-dessous une liste de liens à lire plus tard que j'ai collectionnés. Je ne peux pas garantir qu'ils en valent tous la peine, car je n'en ai parcouru qu'un grand nombre. Mais j'espère que certains vous aideront.

grand tutoriel sur l'utilisation de Socket.IO avec Express. Elle expose les sessions socket.io et discute comment avoir différentes pièces pour chaque utilisateur authentifié.

Tutoriel sur le nœud.js/socket.io/ossature.js/express/se connecter/jade/redis avec authentification, Joyent hébergement, etc:

tutoriel sur L'utilisation D'un pousseur avec colonne vertébrale.js (utilisant des Rails):

Construire des applications avec la colonne vertébrale.js sur le client et le nœud.js avec express, socket.io, dnode sur le serveur.

utilisant la colonne vertébrale avec DNode:

84
répondu Tauren 2016-12-05 09:23:35

le repos HTTP et les WebSockets sont très différents. HTTP est stateless , de sorte que le serveur web n'a pas besoin de savoir quoi que ce soit, et vous obtenez la mise en cache dans le navigateur web et dans les mandataires. Si vous utilisez WebSockets, votre serveur devient stateful et vous devez avoir une connexion au client sur le serveur.

Demande-Réponse de la communication vs Push

N'utilisez des WebSockets que si vous avez besoin de PUSH données du serveur au client, Ce modèle de communication n'est pas inclus dans HTTP (seulement par solutions de contournement). PUSH est utile si les événements créés par d'autres clients doivent être disponibles pour d'autres clients connectés, par exemple dans les jeux où les utilisateurs doivent agir sur le comportement d'autres clients. Ou si votre site Web surveille quelque chose, où le serveur pousse les données au client tout le temps, par exemple les marchés boursiers (en direct).

si vous N'avez pas besoin de pousser données du serveur, il est généralement plus facile d'utiliser un serveur de repos HTTP apatride. HTTP utilise un modèle de communication simple demande-réponse .

45
répondu Jonas 2016-10-14 04:41:20

je pense passer à une api WebSocket pour toutes les fonctions du site

Pas de. Vous ne devriez pas le faire. Il n'y a pas de mal à supporter les deux modèles. Utilisez REST pour la communication unidirectionnelle / simple requests & WebSocket pour la communication bidirectionnelle en particulier lorsque le serveur veut envoyer une notification en temps réel.

WebSocket est un plus protocole efficace que RESTful HTTP mais tout de même RESTful HTTP scores sur WebSocket dans les domaines ci-dessous.

  1. créer/mettre à jour/Supprimer des ressources ont été bien définies pour HTTP. Vous devez mettre en œuvre ces opérations à faible niveau pour les WebSockets.

  2. les connexions WebSocket évoluent verticalement sur un seul serveur où les connexions HTTP évoluent horizontalement. Il existe des solutions exclusives non basées sur des normes pour la mise à l'échelle horizontale de WebSocket .

  3. HTTP est livré avec beaucoup de bonnes fonctionnalités telles que la mise en cache, le routage, le multiplexage, gzipping, etc. Ceux-ci doivent être construits sur Websocket si vous choisissez Websocket.

  4. moteur de Recherche des optimisations fonctionne bien pour les Url HTTP.

  5. tous les mandataires, DNS, pare-feu ne sont pas pourtant pleinement conscient du trafic WebSocket. Ils autorisent le port 80 mais pourraient restreindre le trafic en fouillant d'abord dessus.

  6. la sécurité avec WebSocket est une approche "tout ou rien".

regardez cet article pour plus de détails.

25
répondu Ravindra babu 2016-10-01 17:04:57

le seul problème que je peux utiliser TCP (WebSockets) comme votre principale stratégie de livraison de contenu Web est qu'il y a très peu de matériel de lecture là-bas sur la façon de concevoir l'architecture et l'infrastructure de votre site Web en utilisant TCP.

donc vous ne pouvez pas apprendre des erreurs des autres et le développement va être plus lent. Ce n'est pas non plus une stratégie "éprouvée".

bien sûr, vous allez également perdre tous les avantages de HTTP (être apatrides, et la mise en cache sont les plus grands avantages).

N'oubliez pas que HTTP est une abstraction pour TCP conçue pour servir du contenu web.

et n'oublions pas que SEO et les moteurs de recherche ne font pas de websockets. Pour que tu puisses oublier SEO.

personnellement, je recommande de ne pas le faire car il y a trop de risques.

de Ne pas utiliser WS pour servir de sites web, de l'utiliser pour servir des applications web

cependant si vous avez un jouet ou un site web personnel par tous les moyens allez-y. Essayez-la, être d'avant-garde. pour une entreprise ou une société vous ne pouvez pas justifier le risque de faire cela.

12
répondu Raynos 2011-07-24 11:06:32

j'envisagerais d'utiliser les deux. Chaque technologie a son mérite et il n'y a pas de solution unique.

la séparation du travail va de ce côté:

1) les WebSockets seraient la principale méthode d'une application pour communiquer avec le serveur lorsqu'une session est requise. Cela élimine de nombreux hacks qui sont nécessaires pour les navigateurs plus anciens (le problème est la prise en charge des navigateurs plus anciens qui éliminera cela)

2) L'API RESTful est utilisée pour les appels GET qui ne sont pas orientés session (i.e. pas d'authentification nécessaire) qui bénéficient de la mise en cache du navigateur. Un bon exemple en est celui des données de référence pour les abandons utilisés par une application web. Cependant. peut changer un peu plus souvent...

3) HTML et Javascript. Ceux-ci comprennent L'UI de la webapp. Il serait généralement avantageux de les placer sur un CDN.

4) Les Services Web utilisant WSDL sont toujours les meilleurs de communication au niveau de l'entreprise et à l'échelle de l'entreprise, car il fournit une norme bien définie pour la transmission de messages et de données. Principalement, Vous déchargeriez cela sur un périphérique de Datapower pour proxy à votre gestionnaire de services web.

tout cela se passe sur le protocole HTTP qui permet d'utiliser des sockets sécurisés via SSL.

pour l'application mobile cependant, les websockets ne peuvent pas se reconnecter à une session déconnectée ( comment se reconnecter à websocket après la connexion étroite ) et la gestion qui n'est pas anodine. Donc pour les applications mobiles, je recommande toujours REST API et polling.

une autre chose à surveiller lors de L'utilisation de WebSockets vs repos est l'évolutivité. Les sessions WebSocket sont toujours gérées par le serveur. Les API RESTful lorsqu'elles sont correctement effectuées sont apatrides (ce qui signifie qu'il n'y a pas d'état serveur qui doit être géré), donc l'évolutivité peut croître horizontalement (ce qui est moins cher) que verticalement.

2
répondu Archimedes Trajano 2017-05-23 12:18:23

est-ce que je veux des mises à jour du serveur?

  • Oui: Prise.io
  • : REPOS

Les inconvénients de la Prise.io:

  • évolutivité: les WebSockets nécessitent des connexions ouvertes et une configuration Ops très différente à l'échelle du web.
  • Learnin: Je n'ai pas de temps illimité pour mon learnin. Les choses doivent être faites!

je vais encore l'utilisation de Socket.io dans mon projet, mais pas pour la base de formulaires web qui RESTE fera très bien l'affaire.

2
répondu Michael Cole 2015-04-18 07:38:38

les transports WebSockets (ou longs sondages) servent principalement à la communication (quasi) en temps réel entre le serveur et le client. Bien qu'il existe de nombreux scénarios où ces types de transports sont nécessaires, tels que le chat ou une sorte de flux en temps réel ou d'autres choses, toutes les parties d'une application web ne doivent pas nécessairement être connectés bidirectionnellement avec le serveur.

REST est une architecture basée sur les ressources qui est bien compris et offre ses propres avantages par rapport aux autres architectures. Les WebSockets s'inclinent davantage vers les flux/flux de données en temps réel, ce qui vous obligerait à créer une sorte de logique basée sur le serveur afin de prioriser ou de différencier les ressources et les flux (dans le cas où vous ne voulez pas utiliser REST).

je suppose que finalement il y aurait plus de WebSockets cadres centriques comme socketstream dans le futur quand ce transport serait plus répandu et mieux compris/documenté sous forme de type de données/de livraison agnostique. Cependant, je pense que cela ne veut pas dire qu'il remplacerait ou devrait remplacer le reste simplement parce qu'il offre des fonctionnalités qui ne sont pas nécessairement nécessaires dans de nombreux cas et scénarios d'utilisation.

1
répondu yojimbo87 2011-07-24 11:19:36

ce n'est pas une bonne idée. La norme n'est même pas encore finalisée, la prise en charge varie selon les navigateurs, etc. Si vous voulez faire cela, vous allez maintenant devoir de secours de flash ou d'interrogation, etc. À l'avenir, cela n'aura probablement pas beaucoup de sens, puisque le serveur doit supporter de laisser les connexions ouvertes à chaque utilisateur. La plupart des serveurs web sont plutôt conçus pour exceller à répondre rapidement aux demandes et à les fermer aussi rapidement que possible. Heck, même votre système d'exploitation devrait être réglé pour faire face à un nombre élevé de connexions simultanées (chaque connexion utilisant plus de ports éphémères et de mémoire). Tenir à l'utilisation de RESTE pour autant de site que vous le pouvez.

-1
répondu zeekay 2011-07-24 10:40:42