Application page unique: avantages et inconvénients
J'ai lu sur SPA et ses avantages. Je trouve la plupart d’entre eux peu convaincants. Il y a 3 avantages qui suscitent mes doutes.
Question: Pouvez-vous agir en tant qu'avocat de la SPA et prouver que je me trompe? trois premières déclarations?
=== ADVANTAGES ===
1. SPA est extrêmement bon pour les sites très réactifs:
Le rendu côté serveur est difficile à implémenter pour tous les états intermédiaires - les états de vue de petite taille ne correspondent pas bien aux URL.
Les applications à page unique se distinguent par leur capacité à redessiner n'importe quelle partie de l'interface utilisateur sans nécessiter d'allers-retours sur un serveur pour récupérer le code HTML. Ceci est réalisé en séparant les données de la présentation des données en disposant d'une couche de modèle qui traite les données et d'une couche de vue qui lit les modèles.
Quel est le problème avec la tenue d'une couche modèle pour les non-SPA? SPA est-il la seule architecture compatible avec MVC côté client?
2. Avec SPA, nous n'avons pas besoin d'utiliser de requêtes supplémentaires sur le serveur pour télécharger des pages.
Hah, et combien de pages l'utilisateur peut-il télécharger lors de la visite de votre site? Deux trois? Au lieu de cela, d'autres problèmes de sécurité apparaissent et vous devez séparer votre page de connexion, votre page d'administrateur, etc. en pages séparées. À son tour, il entre en conflit avec l'architecture de SPA.
. Peut-être que d'autres avantages? N'entendez pas parler d'autre ..
=== DISADVANTAGES ===
- Le client doit activer javascript.
- Un seul point d'entrée sur le site.
- Sécurité.
P.S. J'ai travaillé sur des projets SPA et non-SPA. Et je pose ces questions parce que je dois approfondir ma compréhension. Aucun moyen de nuire aux partisans de la SPA. Ne me demandez pas de lire un peu plus sur SPA. Je veux juste entendre vos réflexions à ce sujet.
Regardons l'un des sites SPA les plus populaires, GMail.
1. SPA est extrêmement bon pour les sites très réactifs:
Le rendu côté serveur n'est pas aussi difficile qu'avec des techniques simples comme garder un #hash dans l'URL, ou plus récemment HTML5 pushState . Avec cette approche, l’état exact de l’application Web est intégré à l’URL de la page. Comme dans GMail, chaque fois que vous ouvrez un courrier, une balise de hachage spéciale est ajoutée à l'URL. Si copié et collé dans une autre fenêtre du navigateur peut ouvrir exactement le même courrier (à condition qu'ils puissent s'authentifier). Cette approche mappe directement à une chaîne de requête plus traditionnelle, la différence réside simplement dans l'exécution. Grâce à HTML5 pushState (), vous pouvez éliminer le #hash et utiliser des URL entièrement classiques pouvant être résolus sur le serveur lors de la première requête, puis chargés via ajax lors des requêtes suivantes.
2. Avec SPA, il n’est pas nécessaire d’utiliser des requêtes supplémentaires sur le serveur pour télécharger des pages.
Le nombre de pages téléchargées par les utilisateurs lors de la visite de mon site Web? vraiment combien de mails certains lisent quand il/elle ouvre son compte mail. J'ai lu> 50 d'un coup. maintenant la structure des mails est presque la même. Si vous utilisez un schéma de rendu côté serveur, le serveur le rendra à chaque requête (cas typique). - problème de sécurité - vous ne devriez pas/ne devriez pas garder des pages séparées pour les administrateurs/identifiants qui dépendent entièrement de la structure de votre site, par exemple paytm.com, ce qui signifie également qu'un site Web utilisateurs, je veux dire, j’utilise les formulaires avec le site Web de mon spa. - dans le framework SPA probablement le plus utilisé Angular JS, le développeur peut charger l'intégralité du temple html à partir du site Web, ce qui est réalisable en fonction du niveau d'authentification de l'utilisateur. Le préchargement HTML pour tous les types d'authentification n'est pas SPA.
3. Peut-être d'autres avantages? N'entendez plus parler de rien ..
- ces jours-ci, vous pouvez supposer en toute sécurité que le client dispose de navigateurs compatibles javascript.
- un seul point d'entrée du site. Comme je l'ai mentionné précédemment, le maintien de l'état est possible. Vous pouvez avoir autant de points d'entrée que vous le souhaitez, mais vous devriez en avoir un.
- même dans un utilisateur de SPA, il ne voit que les droits appropriés. il n'est pas nécessaire d'injecter tout à la fois. le chargement de modèles html diff et de javascript async fait également partie de SPA.
Les avantages auxquels je peux penser sont:
- le rendu HTML nécessite évidemment quelques ressources maintenant que chaque utilisateur visitant votre site le fait. de plus, non seulement le rendu des logiques majeures est maintenant effectué côté client au lieu de côté serveur.
- problèmes de date et heure - je donne simplement au client l'heure UTC est un format prédéfini et je ne me soucie même pas des fuseaux horaires que je laisse javascript gérer. c’est un avantage considérable pour lequel j’ai dû deviner les fuseaux horaires en fonction de l’emplacement dérivé de l’IP des utilisateurs.
- pour moi, l'état est plus bien maintenu dans un SPA, car une fois que vous avez défini une variable, vous savez qu'elle sera là. cela donne l'impression de développer une application plutôt qu'une page Web. Cela aide généralement beaucoup à créer des sites comme foodpanda, flipkart, Amazon. parce que si vous n'utilisez pas l'état côté client, vous utilisez des sessions coûteuses.
- les sites Web sont sûrement extrêmement réactifs - je vais prendre un exemple extrême pour cet essai de création d’une calculatrice dans un site Web autre que SPA (je sais que c’est bizarre).
Mises à jour des commentaires
Il ne semble pas que quiconque ait parlé de prises de courant et de longs scrutins. Si vous vous déconnectez d'un autre client, par exemple d'une application mobile, votre navigateur doit également se déconnecter. Si vous n'utilisez pas SPA, vous devez recréer la connexion de socket à chaque fois qu'il y a une redirection. Cela devrait également fonctionner avec toutes les mises à jour de données telles que les notifications, la mise à jour de profil, etc.
Une autre perspective: en plus de votre site Web, votre projet impliquera-t-il une application mobile native? Si c'est le cas, vous allez probablement alimenter des données brutes vers cette application native à partir d'un serveur (par exemple, JSON) et effectuer un traitement côté client pour les restituer, n'est-ce pas? Donc, avec cette assertion, vous utilisez déjà un modèle de rendu côté client. Maintenant, la question devient: pourquoi ne devriez-vous pas utiliser le même modèle pour la version du site Web de votre projet? C'est une évidence. La question est alors de savoir si vous souhaitez afficher les pages côté serveur uniquement pour les avantages du référencement et la commodité des URL partageables/pouvant être marquées d'un signet.
Je suis pragmatique, je vais donc essayer d’examiner la question des coûts et des avantages.
Notez que pour tout inconvénient que je vous donne, je reconnais qu’ils sont solubles. C'est pourquoi je ne considère rien en noir et blanc, mais plutôt en coûts et avantages.
Avantages
- Suivi plus simple des états - nul besoin d'utiliser de cookies, de soumission de formulaire, de stockage local, de stockage de session, etc. pour mémoriser un état entre deux chargements de page.
- Le contenu de la plaque de la chaudière qui se trouve sur chaque page (en-tête, pied de page, logo, bannière de droits d'auteur, etc.) ne se charge qu'une fois par session de navigateur classique.
- Pas de temps d'attente supplémentaire lors du changement de "pages".
Inconvénients
- Surveillance des performances - mains liées: la plupart des solutions de surveillance des performances au niveau du navigateur que j'ai consultées se sont concentrées exclusivement sur le temps de chargement d'une page, comme le délai jusqu'au premier octet, le temps nécessaire pour la construction de DOM, l'aller-retour réseau pour le code HTML, l'événement onload, etc. le post-chargement via AJAX ne serait pas mesuré. Certaines solutions vous permettent d’instrumenter votre code pour enregistrer des mesures explicites, par exemple, lorsque vous cliquez sur un lien, démarrez une minuterie, puis finissez une minuterie après le rendu des résultats AJAX et envoyez ce commentaire. New Relic, par exemple, supporte cette fonctionnalité. En utilisant un SPA, vous ne vous êtes attaché qu'à quelques outils possibles.
- Tests de sécurité/de pénétration - mains liées: les analyses de sécurité automatisées peuvent avoir des difficultés à découvrir des liens lorsque toute votre page est construite de manière dynamique par un framework SPA. Il y a probablement des solutions à cela, mais encore une fois, vous vous êtes limité.
- Regroupement: il est facile de se retrouver dans une situation lorsque vous téléchargez tout le code nécessaire pour tout le site Web lors du chargement initial de la page, ce qui peut être très efficace pour les connexions à faible bande passante. Vous pouvez regrouper vos fichiers JavaScript et CSS pour essayer de charger des fragments plus naturels au fur et à mesure, mais vous devez maintenant conserver ce mappage et surveiller les fichiers inattendus pouvant être récupérés via des dépendances non réalisées (ce qui m'est arrivé). Encore une fois, résoluble, mais avec un coût.
- Refactoring "big bang": si vous souhaitez effectuer un changement architectural majeur, par exemple passer d'un framework à un autre, afin de minimiser les risques, il est souhaitable de procéder à des modifications incrémentielles. En d’autres termes, commencez à utiliser le nouveau, migrez sur une base donnée, comme par page, par fonctionnalité, etc., puis supprimez l’ancien après. Avec une application multi-pages traditionnelle, vous pouvez passer d'une page de Angular à Réagir, puis d'une autre page lors du prochain sprint. Avec un SPA, c'est tout ou rien. Si vous voulez changer, vous devez changer toute l'application en une fois.
- Complexité de la navigation: des outils existent pour aider à conserver le contexte de navigation dans les SPA, tels que history.js, Angular 2, dont la plupart reposent sur le cadre d'URL (#) ou la nouvelle API d'historique. Si chaque page était une page distincte, vous n'en avez pas besoin.
- Complexité de la compréhension du code: nous pensons naturellement que les sites Web sont des pages. Une application multi-pages partitionne généralement le code par page, ce qui facilite la maintenabilité.
Encore une fois, je reconnais que chacun de ces problèmes peut être résolu à un coût donné. Mais il arrive un moment où vous passez tout votre temps à résoudre des problèmes que vous auriez pu éviter en premier lieu. Cela revient aux avantages et à l’importance qu’ils revêtent pour vous.
Désavantages
1. Le client doit activer javascript. Oui, il s'agit d'un désavantage évident de SPA. Dans mon cas, je sais que je peux m'attendre à ce que mes utilisateurs activent JavaScript. Si vous ne pouvez pas, vous ne pouvez pas faire de SPA, un point c'est tout. C'est comme essayer de déployer une application .NET sur une machine sur laquelle le .NET Framework n'est pas installé.
2. Un seul point d’entrée sur le site. Je résous ce problème en utilisant SammyJS . 2-3 jours de travail pour bien configurer votre routage et permettre aux utilisateurs de créer des signets de lien profond dans votre application qui fonctionnent correctement. Votre serveur n’aura besoin que d’exposer un point de terminaison - le point de terminaison "donne-moi le code HTML + CSS + JS pour cette application" (pensez-le comme un emplacement de téléchargement/mise à jour pour une application précompilée) - et le code JavaScript côté client que vous écrivez gérer l'entrée réelle dans l'application.
3. Sécurité. Ce problème n’est pas propre aux SPA, vous devez gérer la sécurité exactement de la même manière lorsque vous utilisez une application client-serveur "ancienne école" (la Modèle HATEOAS consistant à utiliser Hypertext pour relier des pages à une autre). C'est simplement que l'utilisateur fait les demandes plutôt que votre JavaScript et que les résultats sont au format HTML plutôt que JSON ou un format de données. Dans une application autre que SPA, vous devez sécuriser les pages individuelles sur le serveur, tandis que dans une application SPA, vous devez sécuriser les points de terminaison de données. (Et si vous ne voulez pas que votre client ait accès à tout le code, vous devez également scinder le code JavaScript téléchargeable en plusieurs zones. Je le relie simplement à mon système de routage basé sur SammyJS afin que le navigateur ne demande que les éléments auxquels le client sait qu’il devrait avoir accès, en fonction de la charge initiale des rôles de l’utilisateur, et cela devient alors un problème.)
Les avantages
Un avantage architectural majeur d'un SPA (qui est rarement mentionné) est dans de nombreux cas, la réduction considérable du "bavardage" de votre application. Si vous le concevez correctement pour gérer la plupart des traitements sur le client (le point entier après tout), le nombre de requêtes adressées au serveur (lisez "Possibilités d'erreur 503 qui anéantissent votre expérience utilisateur") est considérablement réduit. En fait, un SPA permet d'effectuer un traitement entièrement hors ligne, ce qui est énorme dans certaines situations.
Les performances sont certainement meilleures avec le rendu côté client si vous le faites correctement, mais ce n’est pas la raison la plus convaincante de la création d’un SPA. (La vitesse du réseau s'améliore, après tout.) Ne défendez pas le cas de SPA uniquement sur cette base.
La flexibilité dans la conception de votre interface utilisateur est peut-être l'autre avantage majeur que j'ai trouvé. Une fois que j'ai défini mon API (avec un SDK en JavaScript), j'ai été capable de réécrire complètement mon front-end avec un impact nul sur le serveur, à l'exception de certains fichiers de ressources statiques. Essayez de faire cela avec une application MVC traditionnelle! :) (Cela devient utile lorsque vous devez vous soucier des déploiements en direct et de la cohérence des versions de votre API.)
En résumé, si vous avez besoin d’un traitement hors ligne (ou si vous voulez au moins que vos clients puissent survivre à des pannes occasionnelles de serveurs), ce qui réduira considérablement vos coûts matériels, et si vous pouvez utiliser des navigateurs JavaScript et modernes, vous avez besoin d’un SPA. Dans d'autres cas, c'est plus un compromis.
Un inconvénient majeur de SPA - SEO. Ce n'est que récemment que Google et Bing ont commencé à indexer des pages basées sur Ajax en exécutant JavaScript lors de l'analyse, mais dans de nombreux cas, les pages sont mal indexées.
Lors du développement de SPA, vous serez obligé de gérer les problèmes de référencement, probablement en post-rendant tout votre site et en créant des instantanés HTML statiques à l'usage des robots d'exploration. Cela nécessitera un investissement solide dans des infrastructures appropriées.
Mise à jour du 19.06.16:
Depuis que j'ai écrit cette réponse il y a quelque temps, j'ai acquis beaucoup plus d'expérience avec les applications Single Page (à savoir, AngularJS 1.x) - j'ai donc plus d'informations à partager.
À mon avis, le principal inconvénient des applications SPA est le référencement, ce qui les limite aux types d'applications de type "tableau de bord". En outre, vous aurez beaucoup plus de difficultés avec la mise en cache par rapport aux solutions classiques. Par exemple, dans ASP.NET, la mise en cache est extrêmement facile: il suffit d’activer OutputCaching et vous êtes satisfait: toute la page HTML sera mise en cache selon l’URL (ou tout autre paramètre). Cependant, sous SPA, vous devrez vous-même mettre en cache (en utilisant certaines solutions comme le cache de second niveau, la mise en cache des modèles, etc.).
J'aimerais faire valoir que SPA est le meilleur choix pour les applications pilotées par les données. gmail, bien sûr, est tout au sujet des données et donc un bon candidat pour un SPA.
Mais si votre page est principalement destinée à l'affichage, par exemple, une page relative aux conditions de service, un SPA est totalement excessif.
Je pense que le meilleur choix est d'avoir un site avec un mélange de pages de style SPA et de pages statiques/MVC, en fonction de la page.
Par exemple, sur un site que je construis, l'utilisateur atterrit sur une page d'index MVC standard. Mais ensuite, lorsqu'ils accèdent à l'application réelle, le SPA est appelé. Un autre avantage est que le temps de chargement du SPA ne se trouve pas sur la page d'accueil, mais sur la page de l'application. Le temps de chargement sur la page d’accueil pourrait être une source de distraction pour les nouveaux utilisateurs du site.
Ce scénario est un peu comme utiliser Flash. Après quelques années d'expérience, le nombre de sites Flash uniquement est tombé à zéro en raison du facteur de charge. Mais en tant que composant de page, il est toujours utilisé.
Pour des entreprises telles que Google, Amazon, etc., dont les serveurs fonctionnent à pleine capacité en mode 24/7, réduire le trafic signifie gagner de l'argent réel: moins de matériel, moins d'énergie, moins de maintenance. Changer l'utilisation du processeur du serveur au client est rentable, et les SPA brillent. Les avantages surpondèrent de loin les inconvénients. Ainsi, SPA ou non SPA dépend beaucoup du cas d'utilisation.
Juste pour en mentionner un autre, probablement pas si évident (pour les développeurs Web), un cas d’utilisation pour les SPA: je cherche actuellement un moyen de mettre en œuvre des interfaces graphiques dans des systèmes intégrés et une architecture basée sur un navigateur me semble intéressante. Traditionnellement, il n’y avait pas beaucoup de possibilités pour les interfaces utilisateur dans les systèmes embarqués - Java, Qt, wx, etc., ou les infrastructures commerciales propriétaires. Il y a quelques années, Adobe avait tenté d'entrer sur le marché avec Flash, mais cela ne semblait pas être un succès.
De nos jours, comme les "systèmes embarqués" sont aussi puissants que les ordinateurs centraux il y a quelques années, une interface utilisateur basée sur un navigateur et connectée à l'unité de contrôle via REST est une solution possible. L’avantage, c’est l’énorme palette d’outils d’interface utilisateur gratuite. (Par exemple, Qt nécessite 20-30 $ par unité vendue sur les redevances plus 3000-4000 $ par développeur)
Pour une telle architecture, SPA offre de nombreux avantages - par exemple, approche de développement plus familière pour les développeurs d’applications de bureau, accès au serveur réduit (souvent dans l’industrie automobile, l’interface utilisateur et les confusions système constituent un matériel distinct, où la partie système dispose d’un système d’exploitation RT).
Le navigateur intégré étant le seul client, les inconvénients mentionnés tels que la disponibilité de JS, la journalisation côté serveur et la sécurité ne comptent plus.
2. Avec SPA, nous n'avons pas besoin d'utiliser de requêtes supplémentaires sur le serveur pour télécharger des pages.
Je dois encore beaucoup apprendre mais depuis que j'ai commencé à apprendre SPA, je les aime.
Ce point particulier peut faire une énorme différence.
Dans de nombreuses applications Web qui ne sont pas des SPA, vous verrez qu'elles récupèreront et ajouteront du contenu aux pages faisant des requêtes ajax. Donc, je pense que SPA va au-delà en considérant: que se passe-t-il si le contenu qui va être récupéré et affiché en utilisant ajax est la page entière? et pas seulement une petite partie d'une page?
Permettez-moi de présenter un scénario. Considérez que vous avez 2 pages:
- une page avec la liste des produits
- une page pour afficher les détails d'un produit spécifique
Considérez que vous êtes à la page de liste. Ensuite, vous cliquez sur un produit pour afficher les détails. L'application côté client va déclencher 2 requêtes ajax:
- une demande d'obtention d'un objet json avec les détails du produit
- une demande pour obtenir un modèle HTML où les détails du produit seront insérés
Ensuite, l'application côté client insérera les données dans le modèle html et les affichera.
Ensuite, vous retournez à la liste (aucune demande n’est faite pour cela!) Et vous ouvrez un autre produit. Cette fois, il n'y aura qu'une demande ajax pour obtenir les détails du produit. Le modèle html sera identique, vous n'avez donc pas besoin de télécharger à nouveau.
Vous pouvez dire que dans un non-SPA, lorsque vous ouvrez les détails du produit, vous ne faites qu'une demande et dans ce scénario, nous en avons fait 2. Oui. Mais vous obtenez un gain dans une perspective globale, lorsque vous naviguez sur plusieurs pages, le nombre de demandes diminue. Et les données transférées entre le côté client et le serveur seront également réduites car les modèles html vont être réutilisés. En outre, vous n'avez pas besoin de télécharger dans toutes les demandes tous les fichiers css, images, fichiers javascript présents dans toutes les pages.
En outre, considérons que votre langage côté serveur est Java. Si vous analysez les 2 demandes que j'ai mentionnées, 1 télécharge des données (vous n'avez pas besoin de charger de fichier de vue ni d'appeler le moteur de rendu de vue), ainsi que les autres téléchargements et le modèle HTML statique afin que vous puissiez disposer d'un serveur Web HTTP capable de récupérer directement sans avoir à appeler le serveur d’applications Java, aucun calcul n’est fait!
Enfin, les grandes entreprises utilisent SPA: Facebook, GMail, Amazon. Ils ne jouent pas, ils ont les plus grands ingénieurs qui étudient tout cela. Donc, si vous ne voyez pas les avantages, vous pouvez initialement leur faire confiance et espérer les découvrir plus tard.
Mais il est important d’utiliser de bons modèles de conception de SPA. Vous pouvez utiliser un framework comme AngularJS. N'essayez pas de mettre en œuvre un SPA sans utiliser de bons modèles de conception, car vous pourriez vous retrouver en désordre.
Dans mon développement, j'ai trouvé deux avantages distincts à utiliser un SPA. Cela ne veut pas dire que les éléments suivants ne peuvent pas être atteints dans une application Web traditionnelle, mais que je vois un avantage supplémentaire sans introduire d’inconvénients supplémentaires.
Le potentiel pour moins de demandes de serveur en tant que rendu de nouveau contenu n'est pas toujours, ni même jamais, une demande de serveur http pour une nouvelle page HTML. Mais je parle de potentiel, car un nouveau contenu pourrait facilement nécessiter un appel Ajax pour extraire des données, mais ces données pourraient être progressivement plus légères que la balise elle-même et générer un avantage net.
La capacité de maintenir "Etat". En termes simples, définissez une variable à l'entrée de l'application et elle sera disponible pour d'autres composants tout au long de l'expérience de l'utilisateur sans la transmettre ni la définir comme modèle de stockage local. La gestion intelligente de cette capacité est toutefois essentielle pour garder la portée de premier niveau non encombrée.
À part exiger JS (ce qui n’est pas une folie d’exiger des applications Web), d’autres inconvénients signalés sont, à mon avis, non spécifiques à SPA ou peuvent être atténués par de bonnes habitudes et des schémas de développement.
Inconvénients : Techniquement, la conception et le développement initial de SPA sont complexes et peuvent être évités. Les autres raisons de ne pas utiliser ce spa peuvent être:
- a) Sécurité: les applications à une seule page sont moins sécurisées que les pages traditionnelles en raison du script intersite (XSS).
- b) Fuite de mémoire: une fuite de mémoire en JavaScript peut même ralentir un ordinateur puissant. Comme les sites Web traditionnels incitent à naviguer entre les pages, toute fuite de mémoire causée par la page précédente est presque nettoyée, ce qui laisse moins de résidus.
- c) Le client doit activer JavaScript pour exécuter SPA, mais dans les applications multi-pages, JavaScript peut être complètement évité.
- d) La taille du SPA atteint sa taille optimale, entraînant une longue attente. Exemple: travailler sur Gmail avec une connexion plus lente.
Outre ce qui précède, d'autres limitations architecturales sont la perte de données de navigation, l'absence de journal de l'historique de navigation dans le navigateur et la difficulté des tests fonctionnels automatisés avec Selenium.
This link explique les avantages et les inconvénients de Single Page Application.
Essayez de ne pas envisager d'utiliser un SPA sans d'abord définir comment vous allez aborder la sécurité et la stabilité des API du côté serveur. Ensuite, vous verrez certains des vrais avantages de l’utilisation d’un spa. En particulier, si vous utilisez un serveur RESTful qui implémente OAUTH 2.0 pour la sécurité, vous obtiendrez une séparation fondamentale des préoccupations pouvant réduire vos coûts de développement et de maintenance.
- Cela déplacera la session (et sa sécurité) sur le SPA et soulagera votre serveur de toute cette surcharge.
- Vos API deviennent à la fois stables et facilement extensibles.
Fait allusion à plus tôt, mais pas explicite; Si votre objectif est de déployer des applications Android & Apple, écrire un SPA JavaScript encapsulé par un appel natif pour héberger l'écran dans un navigateur (Android ou Apple) élimine la nécessité de conservez une base de code Apple et une base de code Android.
Je comprends que c’est une question plus ancienne, mais je voudrais ajouter un autre inconvénient des applications à page unique:
Si vous construisez une API qui renvoie des résultats dans un langage de données (tel que XML ou JSON) plutôt que dans un langage de mise en forme (tel que HTML), vous augmentez l'interopérabilité des applications, par exemple dans les applications interentreprises (B2B). Une telle interopérabilité présente de grands avantages, mais permet aux utilisateurs d'écrire un logiciel pour "exploiter" (ou voler) vos données. Cet inconvénient particulier est commun à toutes les API qui utilisent un langage de données, et non aux SPA en général (un SPA qui demande au serveur du HTML pré-rendu évite cela, mais aux dépens d'une séparation médiocre modèle/vue). Ce risque exposé par cet inconvénient peut être atténué par divers moyens, tels que la limitation de la demande et le blocage de la connexion, etc.