Pourquoi utiliser des services (REST / SOAP) au lieu d'une bibliothèque?

Imaginons que vous envisagiez de diviser vos applications en services. Existe-t-il de bonnes raisons d'adopter une approche SOA par rapport à la simple création d'une API de bibliothèque pouvant être chargée par les applications qui en ont besoin?

La différence peut être subtile entre les deux. Par exemple, dans le monde .NET, vous pouvez avoir une application qui semblerait monolithique pour un utilisateur final et qui fonctionnera sur une même machine, mais à l'intérieur, serait séparée en un tas de services WCF. Vous pouvez également avoir des architectures où les bibliothèques ne sont pas fortement liées (compléments / plugins) et suivent simplement un protocole lorsque vous vous parlez.

Si nous évitons de parler de ces cas intermédiaires et ne traitons que la bibliothèque d'API fortement liée par rapport à un service REST distinct, vous pouvez considérer les points suivants:

1. Une API de bibliothèque est appelée sur la même machine. Les services peuvent être hébergés n'importe où et être appelés de n'importe où. Si vous comptez héberger l'application sur plusieurs machines pour des raisons de performances / évolutivité / sécurité, vous aurez probablement besoin d'utiliser des services.

2. La situation est similaire lorsqu'il s'agit d'utiliser un service par une application déployée sur plusieurs machines. Par exemple, si vous faites une application pour une banque qui effectue des calculs financiers, une façon consiste à déployer la grande application dans son ensemble sur chaque bureau et à être obligé de faire des mises à jour de grande taille pour chaque client à chaque fois; une autre approche consisterait à héberger une partie de calcul sur des serveurs et à déployer sur les postes de travail uniquement une application légère avec seulement une interface utilisateur et un tas d'appels vers ces serveurs.

3. Si vous hébergez un service REST, n'importe qui peut l'utiliser: un utilisateur Mac, une personne qui utilise Linux, etc. Si vous avez créé une bibliothèque C # avec Visual Studio et que vous la distribuez sous forme de DLL, oubliez les utilisateurs (clients ?) qui n'ont pas Windows.

Un autre avantage des services est que lorsque vous mettez à jour le service, il est immédiatement déployé auprès de tous les consommateurs du service. Donc, si vous corrigez un bogue ou un problème de performances, tout le monde en profite dès que le service mis à jour est mis en ligne, au lieu d'avoir à distribuer une mise à jour que les gens peuvent choisir d'ignorer.

Avantages de la bibliothèque:

• Réduisez les frais généraux par appel (uniquement sauter ou même inline ) = peut augmenter les performances
• Chose la plus simple qui pourrait fonctionner
• Aucun risque de panne de service centralisé et d'impact sur tous les consommateurs

Avantages du service:

• Tout le monde obtient des mises à niveau immédiatement et de manière transparente (sauf si l'API versionnée est proposée)
• Les consommateurs ne peuvent pas décompiler le code
• Peut adapter le matériel de service séparément
• Agnostique technologique. Avec une bibliothèque partagée, les consommateurs doivent utiliser une technologie compatible.
• Plus sûr. Le niveau d'interface utilisateur peut appeler le service qui se trouve derrière un pare-feu au lieu d'accéder directement à la base de données.

Une approche SOA permet aux différents services d'être hébergés et maintenus séparément. En plus du code, le déploiement d'un service particulier peut nécessiter beaucoup de configuration spéciale (mots de passe, ports, certificats, etc.). La consommation d'un service REST présente une complexité limitée qui peut être clairement documentée et facilement comprise. Il est également plus sécurisé car cela signifie que vous n'avez pas besoin d'accorder l'accès aux bases de données ou à d'autres ressources aux clients.

S'il y a un changement à un service SOA, alors ce service SOA devra être redéveloppé, retesté et redéployé. Toutes les applications qui utilisent ce service peuvent continuer à le faire. Un changement à une bibliothèque dans une DLL signifie que tous les consommateurs de cette bibliothèque devront être redéveloppés pour référencer cette DLL, ils devront tous être retestés et ils devront tous être redéployés. Il existe également le risque que cela ne se produise pas correctement et différentes applications auront différentes versions de la DLL. Parfois, cela peut ne pas être un problème - peut-être que chaque système devrait avoir la version de la bibliothèque qui était présente au moment du déploiement (vous avez peut-être mis à jour votre système de journalisation pour avoir de nouvelles fonctionnalités utiles - avez-vous vraimentbesoin de mettre à jour chaque système avec lui?) dans ce cas, une bibliothèque est très bien. Mais supposons que vous ayez un service pour calculer le taux d'imposition et que les lois fiscales changent. Vous ne voulez pas avoir à mettre à jour chaque système pour intégrer ce changement, il serait préférable de le faire en un seul endroit. Dans ce cas, un service est une meilleure option.

Il y a plusieurs bonnes réponses mais je voudrais ajouter plus de choses aux réponses données:

La méthode de bibliothèque d'API est très utile lorsque vous souhaitez interagir avec des choses avec le moins de frais généraux possible. La conséquence est qu'il existe un couplage plus élevé entre l'API et les applications l'utilisant. Parfois, c'est correct pour l'application et même nécessaire, mais si vous avez un système très distribué ou si vous pensez que l'interopérabilité est un problème énorme, vous devrez peut-être aller un peu plus loin dans l'abstraction et utiliser d'autres moyens de communication. Surtout, si vous voulez avoir un système distribué, SOAP est une sorte de prochaine étape dans SOA, mais vous resterez avec la dépendance entre les unités, car elles doivent connaître les procédures des autres. REST l'amène à un nouveau niveau, en permettant à une machine d'apprendre quelque chose sur le contenu des autres services de manière unifiée.

Dans votre cas, si votre application n'est pas distribuée, je ne vois aucune raison de transformer votre application en SOA.