REST API vs appels DB directs dans Desktop Application
Je prépare actuellement une application qui sera utilisée dans une entreprise. Il est nécessaire de créer une application de bureau. Pour le moment, ils ne savent pas si l'application devrait être disponible sur mobile ou navigateur dans un avenir proche.
J'ai deux possibilités:
Accédez à la base de données directement depuis l'application de bureau
Créez une API REST et connectez-vous à cette
Puis-je utiliser une API REST si l'application reste uniquement une application de bureau au sein de l'entreprise? Je sais que c'est possible, mais est-ce "la bonne" façon? ( Les meilleures pratiques)
Il existe certains (possibles) avantages et inconvénients pour créer directement une API REST:
Inconvénients:
- Prend plus de temps à se développer
- Plus complexe
- Le serveur fait plus de travail
- problèmes de sécurité
- Ralentissez? (Le serveur et l'application de bureau sont sur le même réseau)
Avantages:
- La migration vers d'autres plateformes est plus facile
- La logique métier est également nécessaire lors de l'appel direct à la base de données. Le développement ne prendra pas beaucoup de temps
- Il en va de même pour la complexité
- Sécurité (comme mentionné par tkausl dans les commentaires)
- Maintenabilité (comme mentionné par WindRaven dans les commentaires)
Lorsqu'il s'agit de grandes applications avec une énorme base de données contenant des millions d'enregistrements, vous vous rendez vite compte que les sélections, les mises à jour, les insertions et les suppressions ne sont tout simplement pas suffisantes.
Vous commencez donc à penser différemment. Vous créez des procédures et des déclencheurs pour vous occuper de choses plus compliquées directement dans la base de données et ce n'est pas très bon. Les bases de données offrent d'excellentes performances lors de l'exécution des opérations CRUD. Des procédures longues? Pas tellement.
Le problème avec les procédures
Imaginez maintenant que vous passiez à une base de données qui ne prend pas en charge le concept de procédures? Qu'est ce que tu vas faire? Vous êtes obligé de déplacer les procédures vers votre base de code à la place, où vous pouvez être sûr qu'une fois que vous le programmez en disons Java, il y restera toujours, quel que soit le moteur de base de données que vous choisissez.
Sans oublier, vos procédures font généralement partie de votre logique métier et ce n'est pas une bonne idée d'avoir votre logique métier répartie sur votre base de code et votre base de données.
Idéalement, vous devriez toujours avoir un médiateur entre la base de données et le client mettant en œuvre ses propres règles métier. Fournir un accès direct à la base de données n'est pas une bonne idée, car lorsque vous le faites, celui qui a accès a un accès direct aux tables et peut faire à peu près n'importe quoi avec les données existantes.
Désavantages
- prend plus de temps à développer: Bien sûr, vous créez un nouveau système, qui va prendre plus de temps que de simplement donner au client une chaîne de connexion à la base de données et le laisser écrire les requêtes.
- Plus complexe: Complexité d'un système> complexité d'une requête de base de données.
- Le serveur fait plus de travail: Pas nécessairement. Avec une bonne conception, une mise en cache, ... vous pouvez déplacer la charge du serveur de base de données vers celle du médiateur.
- Plus lent: En termes de développement? Oui. En termes de vitesse lors de la récupération des données? Non. Vous pouvez optimiser votre médiateur à l'aide de caches (tels que - populaire à partir de janvier 2016 - Redis, Elasticsearch) et lui faire réellement livrer des données plus rapidement qu'un requête de base de données simple.
Les avantages
- Migration vers d'autres plates-formes est plus facile: Migration vers un nouveau moteur de base de données? Absolument. Migrer l'ensemble du médiateur vers une nouvelle langue? Pas vraiment.
- La Business Logic est également nécessaire lors de l'appel direct à la base de données. Le développement ne prendra pas beaucoup de temps: Comme expliqué précédemment, le problème des procédures.
- Sécurité: Avec une autorisation appropriée, avoir un médiateur est certainement beaucoup plus sûr que de donner à un utilisateur un accès direct à la base de données, car vous le limitez aux points de terminaison qui exécutent uniquement les requêtes que vous souhaitez.
- Maintenabilité: L'un des meilleurs avantages d'avoir un médiateur. S'il y a un bogue dans une API que vos clients appellent, vous le corrigez, envoyez le correctif à votre référentiel VCS, créez votre médiateur à partir de la version actuelle de VCS contenant le correctif et tous vos clients utilisent soudainement le correctif, sans qu'ils aient besoin de télécharger une mise à jour. Cela est tout simplement impossible à faire si les requêtes sont stockées directement dans les applications clientes. Dans ce cas, les clients sont obligés de mettre à jour leur application.
Voici mon opinion à ce sujet: vous avez la bonne idée de vouloir utiliser un service Web, mais vous envisagez peut-être d'utiliser la mauvaise technologie.
Lorsque vous dites REST, je suppose que vous parlez d'Asp.Net WebApi. Ce n'est pas la bonne technologie pour les applications intranet. REST & WebApi sont géniaux, ne vous méprenez pas, mais pour tout type d'application interne, les services Web WCF sont la voie à suivre à mon humble avis. Ils permettent au client de référencer le point de terminaison de service comme une bibliothèque de classes, ce qui signifie que vous ne traitez pas en XML ou JSON dans votre client de bureau. Vous travaillez avec des classes et des objets.
Quoi qu'il en soit, oui. Vous avez la bonne idée. S'ils ne sont pas sûrs d'avoir besoin d'un client Web, vous devez concevoir votre système pour l'ajouter facilement s'ils décident de le vouloir plus tard. Il est beaucoup plus facile d'ajouter différents types de clients lorsque vous avez une architecture orientée services.
Regardez-le de cette façon, il est certain un modèle courant et peut raisonnablement être décrit comme la meilleure pratique.
Selon votre plate-forme, vous pouvez trouver des outils qui font presque disparaître le problème - Microsoft prend en charge ODATA pour les applications connectées, ce qui devrait simplifier les formulaires sur les données une fois que vous avez gravi la courbe d'apprentissage.
Plus pragmatique - définissez l'API dont vous avez besoin pour votre couche de données dans l'application de bureau et codez pour cette API. Mettez tous les accès à la base de données derrière cette API - ce qui améliore les choses du point de vue du développement de l'application - puis l'emplacement du code d'accès à la base de données réel devient moins important (la même API pourrait être implémentée par un code qui parle directement à la base de données ou par un code qui communique indirectement avec la base de données via un point de terminaison de repos). Si vous commencez avec une implémentation directe, la version REST va essentiellement être un wrapper autour de la même API, vous ne serez donc pas trop pénalisé ...
Ce n'est probablement pas aussi simple que j'aimerais le faire croire - mais c'est un bon modèle, il vous donne la flexibilité dont vous pourriez avoir besoin sans aller trop loin YAGNI route.