Dans le contexte de l’architecture ou de la conception de système, la gestion des API fait généralement référence à un proxy inverse configurable et hautement performant qui permet de gérer l’accès des clients (externes, internes ou autres) à une API, un point de terminaison ou une méthode. Couramment utilisée avec les API RESTful, mais pas exclusivement, la gestion des API fournit une couche de gestion et de protection des requêtes afin qu’une requête entrante puisse être vérifiée, inspectée, modifiée et traitée, et que la réponse qui revient du système back-end puisse être modifiée ou prise en compte. Certaines organisations peuvent utiliser un bus de services d’entreprise pour atteindre des objectifs similaires. Un bus de services d’entreprise est un terme défini de manière flexible désignant une classe de technologies qui incluent des implications supplémentaires liées à ce composant, mais qui peuvent bénéficier du même ensemble de recommandations pour les services de gestion des API.
Voici quelques exemples de systèmes de gestion d’API :
Le comportement de la gestion des API est différent de celui d’un proxy inverse traditionnel, qui transmet généralement un modèle entier de trafic HTTP à un serveur back-end. Par exemple :
<external-host>:443/server/rest/services/* » <internal-host>>:6443/arcgis/rest/services/*
La gestion des API implique souvent la sélection de chemins d’accès individuels aux URI d’API et de méthodes HTTP (c’est-à-dire un POST vers /routes/extract et un PATCH vers /routes/<routeid>). Cela signifie que chaque méthode ou modèle individuel doit être défini, mais aussi que chaque modèle peut avoir des règles, des comportements et des processus d’écoute ou des services back-end différents. Cette approche est souvent utilisée pour la création de nouvelles API ou de nouveaux systèmes, lorsqu’un ensemble existant de services Web n’existe pas, ou pour l’activation d’une architecture de type microservices où différents composants ou systèmes back-end sont responsables de la prise en charge de requêtes d’API distinctes. Dans certains cas, la gestion des API peut utiliser une définition d’API back-end telle qu’une spécification OpenAPI pour créer de nombreux points de terminaison ou méthodes front-end.
La gestion des API comprend également généralement un éventail d’autres options de traitement, qui manipulent le contenu de la requête (ajustement ou réécriture d’un chemin, ajout ou modification d’un en-tête, modification de la destination en fonction du contenu du corps POST), appliquent un filtrage à la requête (limitation du débit, blocage de certaines plages d’adresses IP, exigence de clés d’API) ou opèrent sur la réponse (offuscation des noms de serveur, suppression des en-têtes de réponse, ajout d’une empreinte digitale ou d’un identifiant). Ces opérations sont définies dans la couche de gestion des API et s’appliquent à chaque requête lorsqu’elle est soumise et qu’une réponse est créée.
Tous ces modèles s’appliquent généralement aux technologies de bus de services d’entreprise, à quelques différences près. Les bus de services d’entreprise ont tendance à être plus axés sur la distribution synchrone de messages, c’est-à-dire qu’une modification dans une partie du système (ajout d’un nouvel enregistrement, application d’une mise à jour) déclenche la transmission de cette modification au bus, qui transforme ensuite et transmet le message à d’autres systèmes pour les maintenir synchronisés. Dans un sens, la gestion des API s’apparente davantage à une méthodologie de requête et d’interrogation, où les bus de services d’entreprise introduisent souvent des engagements forts en matière de distribution de messages, des modèles de publication/abonnement ou d’autres approches similaires.
La gestion des API est utilisable dans de nombreux modèles différents avec ArcGIS. En règle générale, la gestion des API est surtout applicable aux cas d’utilisation dans lesquels elle est déployée « devant » des services basés sur ArcGIS Server, tels que des services de carte, d’entités ou de géotraitement, dans des scénarios où ces services doivent être exposés soit à un autre système d’entreprise, soit à un développeur ou à un client final à l’aide d’une application personnalisée. Voici quelques éléments clés à prendre en compte pour l’utilisation de la gestion des API :
Par exemple :
/arcgis/rest/services/ServiceName/MapServer/arcgis/rest/services/ServiceName/MapServer/exportImage/arcgis/rest/services/ServiceName/MapServer/0/query/arcgis/rest/services/ServiceName/MapServer/1/queryLa gestion des API est un moyen de plus en plus populaire de fournir des options d’intégration entre les systèmes d’entreprise. De nombreuses organisations investissent dans des stratégies ou les développent pour s’assurer que toutes les transactions internes utilisent comme broker un système de gestion des API, ou peuvent nécessiter l’utilisation de la gestion des API pour créer des services accessibles en externe. Dans le contexte de l’intégration de systèmes, les meilleures pratiques sont les suivantes :
Par définition, la gestion des API n’inclut pas de couche d’authentification, mais de nombreuses organisations souhaitent appliquer l’authentification à leurs points de terminaison de gestion des API, à des fins de validation des utilisateurs et de gestion des autorisations. Les méthodes d’authentification courantes de gestion des API incluent l’utilisation d’une clé ou d’un abonnement d’API, ainsi que l’intégration des méthodes d’authentification basées sur OAuth à un fournisseur d’identités existant. Chacun de ces modèles peut créer des défis pour les processus d’intégration ArcGIS.
N’oubliez pas que les méthodes d’authentification client basées sur la gestion des API peuvent ne pas être compatibles avec les clients ArcGIS standards. Si, par exemple, le système de gestion des API exige l’authentification basée sur l’en-tête, que ce soit à l’aide d’un en-tête spécifique au service ou d’un en-tête d’autorisation du porteur, les clients ArcGIS standards ne pourront pas ajouter cet en-tête de manière dynamique aux requêtes de prise en charge de l’accès à ce service. De même, les clés d’API peuvent être une couche d’authentification commune ajoutée via une interface de gestion des API, mais les développeurs d’applications doivent être conscients de cette exigence et avoir la possibilité de l’ajouter aux requêtes afin d’intégrer ces services dans une application. Divers SDK ArcGIS et modèles d’inscription de service peuvent prendre en charge ce type de modèle d’authentification de clé d’abonnement ou de clé d’API. Il est cependant nécessaire de les tester minutieusement avant de supposer qu’un modèle d’authentification convient.
L’authentification basée sur OAuth pour la gestion des API présente d’autres défis. Lors du développement d’une application personnalisée à l’aide d’un SDK pris en charge, il peut être relativement simple de fournir une redirection initiale vers le service OAuth, de renvoyer un jeton ou un code, et d’utiliser celui-ci pour l’ajouter à d’autres requêtes dans cette session. Toutefois, lors de l’utilisation d’une application ArcGIS prête à l’emploi, cette configuration est beaucoup plus difficile à utiliser, car ces clients s’attendent à accéder directement aux services géographiques d’ArcGIS, sans étapes d’authentification supplémentaires qui ne sont pas gérées par ArcGIS.
Généralement, l’utilisation de clés d’API ou d’abonnement constitue le chemin d’intégration le plus efficace dans ce contexte, avec les recommandations suivantes :