InterSystems API Manager (IAM) vous permet de surveiller et de contrôler le trafic vers et depuis vos API basées sur le web. Si vous créez des couches d'applications orientées services, il est fort probable que le nombre d'API que vous utilisez augmente rapidement. Plus votre environnement est distribué, plus il est essentiel de gérer et de surveiller correctement votre trafic d'API. Le gestionnaire d'API vous permet d'acheminer facilement tout votre trafic via une passerelle centralisée et de transmettre les demandes d'API aux nœuds cibles appropriés.
InterSystems a le plaisir d'annoncer la sortie d'IAM 3.10. Première version significative depuis environ 18 mois, IAM 3.10 inclut de nombreuses nouvelles fonctionnalités importantes non disponibles dans IAM 3.4, notamment :
IAM - InterSystems API Manager est un excellent outil pour surveiller votre trafic. Si vous essayez de l'utiliser dans votre cluster Kubernetes, vous avez peut-être essayé de faire un déploiement similaire à celui-ci :
Les versions 2.8.4.11 et 3.4.3.11 d'InterSystems API Manager (IAM) sont désormais disponibles. Il s'agit des dernières versions des deux versions d'IAM prises en charge à long terme. Ces versions contiennent des correctifs importants et tous les clients sont encouragés à effectuer une mise à niveau.
Les clients d'IAM 3.0 ou 3.2 sont encouragés à effectuer une mise à niveau vers la version 3.4.3.11, car la prise en charge de ces versions prendra bientôt fin.
Les versions 2.8.4.10 et 3.4.3.10 d'InterSystems API Manager (IAM) sont désormais généralement disponibles. Il s'agit des dernières versions des deux versions d'IAM prises en charge à long terme. Ces versions contiennent des correctifs importants et tous les clients sont encouragés à effectuer la mise à niveau.
Les clients utilisant IAM 3.0 ou 3.2 sont encouragés à passer à la version 3.4.3.10, car la prise en charge de ces versions prendra bientôt fin.
La version 3.4.2 d'InterSystems API Manager (IAM) est désormais généralement disponible. En plus des corrections de bugs et des améliorations mineures, IAM 3.4 inclut plusieurs fonctionnalités susceptibles d'intéresser les clients IRIS.
Avec mes connaissances de base du conteneur Docker et de l'API REST, j'aimerais faire mon premier essai d'utilisation du gestionnaire d'API InterSystems pour prendre le contrôle des API et des microservices. J'ai suivi ce cours en ligne en utilisant mon instance IRIS locale comme hôte (système d'exploitation Windows) et IAM exécuté sur une machine virtuelle Linux (invité).
InterSystems API Manager (IAM) version 3.2.1 est désormais généralement disponible. En plus des corrections de bogues et des améliorations mineures, IAM 3.2 ajoute de nouveaux plug-ins susceptibles d'intéresser les clients IRIS.
Ce nouveau plugin vous permet de réduire le risque d'attaques XML en vérifiant la structure des charges utiles XML. Cela valide la complexité maximale (profondeur de l'arbre), la taille maximale des éléments et des attributs.
InterSystems API Manager (IAM) version 2.8.1 est désormais généralement disponible. En plus d'une multitude d'améliorations des performances et de corrections de bogues, cette version ajoute de nouvelles fonctionnalités importantes, notamment :
InterSystems API Management (IAM) - c'est une nouvelle fonctionnalité de la plate-forme de données InterSystems IRIS, qui vous permet de surveiller, de contrôler et de gérer le trafic vers et à partir des API basées sur le Web au sein de votre infrastructure informatique. Au cas où vous l'auriez manqué, voici le lien vers l'annonce. Et voici un article expliquant comment commencer à travailler avec IAM.
Dans cet article, nous allons utiliser InterSystems API Management pour assurer l'équilibrage de charge d'une API.
Dans notre cas, nous avons 2 instances InterSystems IRIS avec /api/atelier REST API que nous voulons publier pour nos clients.
Il y a de nombreuses raisons différentes pour lesquelles nous pourrions vouloir faire cela, par exemple :
Équilibrage de la charge pour répartir la charge de travail entre les serveurs.
Déploiement bleu-vert : nous avons deux serveurs, l'un "prod", l'autre "dev" et nous pouvons vouloir passer de l'un à l'autre.
Déploiement canary: nous pourrions publier la nouvelle version sur un seul serveur et y transférer 1% des clients.
Par mise à jour
Open Exchange app