Gestion des Environnements

Pourquoi ce Changement ?

La notion d'environnement est une évolution de l'écosystème d'Okapi qui permet d'avoir plusieurs environnements par API.

Historiquement il y a toujours eu deux environnements par API pour que le consommateur d'une API puisse tester ses appels sur un environnement de sandbox et bien-sûr un environnement de production pour les appels de son application au run.

A la demande de nombreux fournisseurs d'API, il est devenu essentiel de faire évoluer cette fonctionnalité pour les équipes de build ou marketing du Groupe La Poste à des fins de tests, de recette, de TNR, de montée en charges, privilégier un consommateur sur un environnement dédié, ect...

Fonctionement de OKAPI "LEGACY"

Pour ajouter une fonctionnalité à une API, on modifie le fichier de configuration au format yaml à travers le champ extra.

Ce champ peut être modifié au niveau d'une API ou bien d'une ressource pour rendre la fonctionnalité opérationnelle.

Si une fonctionnalité est ajoutée au niveau d'une API, elle s'applique à toutes les ressources.

Par contre si elle est ajoutée au niveau d'une ressource, elle va surcharger celle eventuellement declarée au niveau d'une API pour s'appliquer seulement à cette ressource.

Liste des Fonctionnalités Avancées

Liste des fonctionnalités impactées par ce changement:

Gestion des requêtes

• cache: Gestion du cache
• Header: Ajout d'entête
• excludedHeaders: Filtrage d'entête
• qs: Enrichissement de la Query String
• payload: Enrichir le Payload à destination d'une API
• plugins: Enrichissement d’une ressource
• followRedirect: Suivi de redirection
• apiCalLimiter: Limiter les appels par environnement/ressource
• Quota-Limiter: Limiter les appels vers un plan
• timeout: Configuration du Timeout
• forwardApiInternalErrors: Réponse 500

Réseau

• proxy HTTP: Supporter le Proxy HTTP d'une API
• agentClass: Gestion de Proxy SOCKS
• strictSSL: Désactivation du SSL strict
• httpCompression: Compression HTTP
• authTokenParams: Se connecter à une autre Api Manager

Authentification

• basicAuth: Implémenter Basic Auth
• jwt: Mettre en oeuvre JWT
• Authorize: Façade d'authentification
• Token: Façade d'authentification
• x-509/AgentOptions: Certificat Client
• hmac: Mise en place HMAC

Métriques

• ipCallLimiters: Limiter les appels vers une API
• kpiheaders: Activity KPI
• customEventsNs: Mise en place d'un puits de logs

Gérer les Fonctionnalités Avancées

Avec la possibilité de gérer plusieurs environnements par API, les fonctionnalités avancées sont dorénavant déterminées par environnenemt et on garde aussi la possibilité de le faire par ressource.

Il y aura donc toujours cet effet cascade où une fonctionnalité déclarée dans une ressource surcharge la fonctionnalité declarée dans un environnenemt.

Et les plugins ?

Certaines fonctionnalités avancées nécessitent d'être déclarer au niveau d'un champ plugins et dans le champ extra pour les paramétres nécessaires au bon fonctionement de la fonctionnalité.

Ce comportement est toujours présent mais il ne se declare plus au niveau d'une API mais au niveau d'un environnement.

Cela permet une meilleure maîtrise du comportement de son API par environnement.

Liste des Fonctionnalités à declarer dans un plugin

• apiCallLimiter: Limiter les appels
• ressourceCallLimiter: Limiter les appels vers une ressource
• api-cache: Gestion du cache
• authorize: Façade d'authentification
• Token: Façade d'authentification
• generate-jwt: Mettre en oeuvre JWT
• Quota-Limiter: Limiter les appels vers un plan
• before/after Enrichissement d’une ressource