Architecture API interne et externe

La société pour laquelle je travaille maintient un produit SaaS performant qui s'est développé "organiquement" au fil des ans. Nous prévoyons d'étendre la gamme avec une suite de nouveaux produits qui partageront les données avec le produit existant. Pour cela, nous cherchons à consolider la logique métier en un seul endroit: une couche de service Web. La couche WS sera utilisée par:

• Les applications web
• Un outil pour importer des données
• Un outil à intégrer avec d'autres logiciels clients (pas une API en soi)

Nous voulons également créer une API qui peut être utilisée par nos clients qui sont capables de l'utiliser pour créer leurs propres intégrations. Nous nous débattons avec la question suivante:

L'API interne (alias la couche WS) et l'API externe doivent-elles être identiques, avec des paramètres de sécurité et d'autorisation pour contrôler ce qui peut être fait par qui, ou doivent-elles être deux applications distinctes où l'API externe appelle simplement l'API interne comme toute autre application? Jusqu'à présent, dans notre débat, il semble que les séparer soit plus sûr, mais cela ajoutera des frais généraux.

Qu'ont fait d'autres dans une situation similaire?

Il est toujours bon de manger votre propre nourriture pour chien. Une API devrait également être plus simple à gérer que deux, même si vous tenez compte de certains frais généraux pour l'authentification et l'autorisation.

Bien que je sois d'accord avec Aneurysm9, parfois, vous ne voulez pas exposer toutes les capacités de votre système. Dans ce cas, avoir deux API serait préférable ... MAIS si vous le faites de cette façon ... assurez-vous que toutes les fonctionnalités communes partagent la même API, IE que l'une soit une version étendue de l'autre par opposition à deux distinctes ensembles de code.

De cette façon, vous pouvez utiliser le vôtre pour vous-même tout en ayant une place pour que le travail expérimental privé et sensible progresse tout en vous permettant de publier et d'utiliser les nouvelles choses sans trop changer l'API publique.

Je l'ai déjà rencontré (plusieurs fois) et ce que j'ai fini par préférer c'est:

Retirez le BL du site Web. Faites du site Web un consommateur de l'API. Traitez le site Web comme un simple client de votre API. Votre API EST le service.

Si vous pensez que vous avez besoin de méthodes API spéciales uniquement pour le site Web, détrompez-vous! Si c'est bon pour l'oie, c'est bon pour le jars. Si vous avez vraiment vraiment vraiment besoin de fonctionnalités spéciales pour le site Web, je dirais que ce que vous avez vraiment trouvé est une différence dans le "profil utilisateur" et donc c'est une situation où l'API devrait toujours prendre en charge les fonctions "spéciales", mais alors vous les contrôler via une autorisation.

Pas convaincu?

Prenez le paradigme un peu plus loin ...

L'application téléphonique s'exécute sur une plate-forme où le bytecode est exécuté, l'application vit dans le téléphone et consomme des services API via HTTP / JSON

Le site Web est une application fonctionnant sur une plate-forme où HTML + Javascript est exécuté, l'application vit dans un navigateur et consomme des services API via HTTP / JSON

Pareil pareil!

Étendez cela aux tablettes, téléviseurs, autres plates-formes téléphoniques, plugins, applications tierces, mashups, ...

De nombreuses expériences utilisateur différentes sont toutes connectées à une API commune.

Votre application EST l'API. Le site Web n'est qu'un client (parmi tant d'autres)

Utilisez une API

Si vous implémentez l'API de service en tant que couche REST, ajoutez simplement l'authentification aux routes qui sont protégées.

Vous voudrez probablement utiliser un cadre de développement qui ne fait pas trop de «magie». Quelque chose où vous pouvez définir des itinéraires directement sans beaucoup d'ingénierie inverse.

Pensez à quelque chose comme Node.js / Express, python / pylons, moteur d'application python / google, etc.

J'ai récemment implémenté cela sur Google App Engine pour une API REST / Datastore et je ne pense pas que cela aurait pu être plus facile. Les contrôleurs sont implémentés en tant que classes et leurs requêtes HTTP suivantes (c'est-à-dire GET / POST / PUT / DELETE) sont implémentées en tant que méthodes de ces classes. J'ai réussi à implémenter basic-auth en tant que décorateur. Cela a rendu l'ajout d'une exigence d'authentification à une demande aussi simple que d'attacher le décorateur @basicAuth.

De cette façon, je pourrais rendre les demandes GET entrantes publiques ajouter une exigence d'authentification aux demandes POST / PUT / DELETE sur le même contrôleur pour ce modèle.

Si vous savez parler en REST, la vie devient beaucoup plus facile car la prise en charge de REST est déjà intrinsèquement intégrée dans un serveur Web (c.-à-d. Que HTTP n'est qu'un type d'API REST). Vous pouvez même opter pour la compression gzip transparente si vous envoyez beaucoup de données sur le fil.

Ma première impression est qu'il devrait s'agir de la même API et que votre sécurité devrait être totalement différente. Peut-être géré par un front Web?