Connecteur d'API

improve this page | report issue

Présentation

Les applications Mobile Foundation peuvent appeler un microservice ou un service de back-end d’entreprise à l’aide d’adaptateurs Mobile Foundation. L’écriture de l’adaptateur nécessite une bonne connaissance de l’infrastructure de l’adaptateur Mobile Foundation. Mobile Foundation permet également d’effectuer des appels sécurisés au microservice ou au service de back-end d’entreprise sans impliquer d’adaptateurs en utilisant le connecteur d’API Mobile Foundation. Le connecteur d’API, à l’instar d’un adaptateur, garantit la sécurité des appels par le biais du mécanisme OAuth 2.0 de Mobile Foundation. Avec un connecteur d’API, un administrateur Mobile Foundation peut configurer et déployer des détails de microservice ou de service de back-end d’entreprise dans Mobile Foundation. L’environnement d’exécution de Mobile Foundation utilise la configuration déployée pour initier en toute sécurité des demandes de microservice ou de service de back-end d’entreprise depuis une application mobile.

Avantages

L’utilisation du connecteur d’API Mobile Foundation présente les avantages suivants :

  • Back end à couplage lâche pour intégration avec des microservices.
  • Analyse détaillée des applications et des API.
  • Intégration simple aux patterns BFF (Backend for Frontend) pour les architectures intercanaux (Web, mobile ou autres) avec unique couche de microservice.
  • Amélioration de l’optimisation des performances entre les canaux et les back-ends.
  • Moins de dépendance aux compétences de la technologie de l’adaptateur Mobile Foundation.
  • Gestion des applications prête à l’emploi.
  • Environnement d’exécution de faible poids.
  • Environnement d’exécution fiable et évolutif sans code utilisateur.

Utilisation du connecteur d’API

Pour utiliser le connecteur d’API, vous devez effectuer les deux opérations suivantes :

  • Définir et déployer une configuration de microservice ou de service de back-end d’entreprise sur un serveur Mobile Foundation.
  • Modifier l’application client de manière à appeler les méthodes du microservice ou du service de back-end d’entreprise via la configuration déployée.

Flux

Comme indiqué dans le diagramme, la première étape consiste à configurer et à déployer les détails du microservice ou du service de back-end d’entreprise sur le serveur Mobile Foundation à l’aide de l’API de gestion d’administration. L’environnement d’exécution Mobile Foundation initie en toute sécurité des demandes de client au microservice ou au service de back-end d’entreprise approprié à l’aide de la configuration déployée.

Le mécanisme de sécurité Mobile Foundation basé sur OAuth garantit que l’appel est effectué par un client d’application légitime. Le SDK du client Mobile Foundation et le serveur d’autorisation Mobile Foundation, sous le capot, valident la demande faite par l’application. Le service de back-end d’entreprise est appelé pour des validations de sécurité satisfaisantes.

Flux du connecteur d'API

Définition et déploiement d’une configuration de microservices ou de services de back-end d’entreprise

L’API de gestion d’administration de Mobile Foundation peut être utilisée pour configurer et déployer les détails des microservices ou services de back-end d’entreprise auxquels l’application client a besoin de se connecter. L’API de gestion utilisée à cette fin est la suivante :

http://<host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config

Les méthodes suivantes sont disponibles pour l’API de configuration afin de gérer les détails du service de back-end depuis Mobile Foundation.

  1. Utilisation de POST pour déployer des configurations de service de back-end.
  2. Utilisation de GET pour extraire les configurations de service de back-end déployées.
  3. Utilisation de DELETE pour supprimer les configurations précédemment déployées.

L’API POST extrait les détails de configuration de service au format JSON. La syntaxe JSON de configuration est la suivante :

{
"backendServices" : [
    {
        "service": "resorts",
        "baseUrl":"http://mybluemix.net/resorts",
        "auth" : {
            "type" : "basic",
            "credential" : {
                "username" : "user",
                "password" : "pass"
            }
        },
        "ConnectionProperties" : {
            "maxConnetions" : "50",
            "connectionTimeoutInMilliseconds" : "20000",
            "socketTimeoutInMilliseconds" : "20000"
        }
    }
]
}

Les clés utilisées dans le fichier JSON sont expliquées ci-dessous.

  1. service – Nom de service logique permettant d’identifier le microservice ou le service de back-end d’entreprise. Il doit s’agir d’un nom unique pour le service concerné dans la liste des services configurés sur votre serveur Mobile Foundation à l’aide de cette API de gestion.
  2. baseurl – URL de base du microservice ou du service de back-end d’entreprise. Il s’agit de l’URL complète du microservice qui expose les méthodes pouvant être appelées par l’application client. Le nom de la méthode peut être fourni par l’application client.
  3. auth – Détails d’authentification à utiliser pour accéder au service de back-end d’entreprise.
    • type – Mobile Foundation prend en charge les trois types suivants :
      • ‘basic’ – Authentification de base avec la section ‘credentials’ pour configurer le nom d’utilisateur et le mot de passe. Par exemple,
         "credential" : {
             "username" : "hello",
             "password" : "hello"
         }
        
      • apikey – Pour une authentification basée sur les clés d’API, de multiples schémas différents sont pris en charge d’après le type policy. La syntaxe d’une clé d’API (apikey) est la suivante :
         "type" : "apikey",
         "credential" : {
             "apikey" : "abcdefg",
             "policy" : "basic",
             "name" : "apikey"
         }
        

        La règle (policy) peut être header, query ou basic en fonction de la façon dont le service de back-end escompte que la clé d’API (apikey) lui soit présentée. La valeur de règle header doit suivre apikey dans l’en-tête de demande avec l’intitulé d’en-tête indiqué dans name. La règle query envoie apikey en tant que paramètre de demande et la règle basic envoie apikey en tant qu’authentification de base.

      • mfpauth – Dans ce type, le microservice peut optimiser le mécanisme de sécurité basé sur OAuth de Mobile Foundation. La section credentials n’est pas nécessaire pour le type mfpauth et n’a pas à faire partie de la configuration JSON.

      Le service de back-end peut être protégé par la portée de sécurité, le serveur d’autorisation et le serveur d’authentification Mobile Foundation. Avant de donner accès au service de back-end, le mécanisme d’authentification Mobile Foundation s’assure que la demande transporte un jeton d’accès valide ayant la portée nécessaire. Lorsque le serveur d’authentification Mobile Foundation confirme la validité du jeton d’accès présenté lors de l’introspection, l’accès au service de back-end est accordé. Pour plus d’informations sur la configuration d’un service de back-end pour utiliser un serveur d’authentification Mobile Foundation, voir ici.

      • extauth – Ce type peut être utilisé pour prendre en charge des microservices de back-end à l’aide d’un serveur d’authentification externe ou tiers. Le client d’application doit transmettre le jeton d’accès qu’attend le service de back-end en tant qu’en-tête spécial nommé ext-token. Le connecteur d’API transmet le jeton d’accès reçu dans l’en-tête ext-token du client d’application en tant qu’en-tête Authorization au microservice de back-end. La section credential n’est pas nécessaire pour le type extauth et n’a pas à faire partie de la configuration JSON. L’introspection et le renouvellement du jeton externe après l’expiration du jeton doivent être traités par le client d’application et le microservice de back-end. Le mécanisme de sécurité Mobile Foundation pour valider le client d’application reste identique.
  4. Le paramètre ConnectionProperties permet de configurer les paramètres de connexion entre le serveur Mobile Foundation et les microservices de back-end. Ces paramètres sont facultatifs et, s’ils ne sont pas fournis, les valeurs par défaut sont utilisées. Syntaxe de ConnectionProperties :
     "ConnectionProperties" : {
         "maxConnetions" : "50",
         "connectionTimeoutInMilliseconds" : "20000",
         "socketTimeoutInMilliseconds" : "20000"
     }
    

    Les valeurs par défaut des paramètres de connexion individuels sont les suivantes :

    • maxConnetions => 20
    • connectionTimeoutInMilliseconds => 30000 (c’est-à-dire 30 secondes)
    • socketTimeoutInMilliseconds => 30000 (c’est-à-dire 30 secondes)

Syntaxe des commandes curl de l’API d’administration.

  1. POST pour déployer les configurations.
     curl -X POST -u admin:admin 'http://<host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config' --header 'Content-Type: application/json' --data-binary  @config.json
    

    config.json est le fichier JSON avec des configurations similaires à la syntaxe JSON ci-dessus.

  2. GET pour extraire les configurations existantes.
     curl -X GET -u admin:admin 'http:// <host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config'
    
  3. DELETE pour supprimer les configurations déployées existantes.
     curl -X DELETE -u admin:admin 'http:// <host>:<port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config'
    

Une fois la configuration du microservice ou du service de back-end déployée sur Mobile Foundation, vous pouvez utiliser le SDK du client de Mobile Foundation pour appeler le service de back-end d’entreprise. Pour plus d’informations sur l’API du SDK du client, voir ici.

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on July 09, 2020