API-Connector

improve this page | report issue

Übersicht

Mobile-Foundation-Anwendungen können mit Mobile-Foundation-Adaptern einen Mikroservice oder einen Unternehmens-Back-End-Service aufrufen. Das Schreiben des Adapters erfordert Kenntnisse über das Mobile-Foundation-Adapterframework. Als Alternative vereinfacht die Mobile Foundation sichere Aufrufe von Unternehmens-Back-End-Services ohne Adapter über den API-Connector der Mobile Foundation. Der API-Connector ermöglicht wie ein Adapter sichere Aufrufe über den OAuth-2.0-Mechanismus der Mobile Foundation. Mit dem API-Connector kann der Mobile-Foundation-Administrator Details von Mikroservices oder Unternehmens-Back-End-Services in der Mobile Foundation konfigurieren und implementieren. Die implementierte Konfiguration wird von der Mobile-Foundation-Laufzeit verwendet, um Mikroservice- oder Back-End-Serviceanforderungen von einer mobilen App aus aufzurufen.

Vorteile

Der Mobile-Foundation-API-Connector bietet die folgenden Vorteile:

  • Flexibel verbundenes Back-End für die Integration in Mikroservices
  • Ausführliche App- und API-Analyse
  • Saubere Integration von BFF-Mustern (Backend for Frontend) für kanalübergreifende Architekturen (Web, mobil oder andere) mit einer Mikroserviceschicht
  • Bessere Leistungsoptimierung über Kanäle und Back-Ends
  • Weniger Abhängigkeit von Technologie-Know-how zu Mobile-Foundation-Adaptern
  • App-Management ohne Vorbereitungs- oder Anpassungsaufwand
  • Lightweight-Laufzeit
  • Zuverlässige und skalierbare Laufzeit ohne Benutzercode

API-Connector verwenden

Für die Verwendung des API-Connectors müssen Sie die beiden folgenden Schritte ausführen.

  • Definieren und implementieren Sie die Mikroservice- oder Back-End-Servicekonfiguration in Mobile Foundation Server.
  • Modifizieren Sie die Client-App so, dass die Mikroservice- oder Back-End-Servicemethoden über die implementierte Konfiguration aufgerufen werden.

Ablauf

In der Abbildung können Sie sehen, dass der erste Schritt die Verwendung der Verwaltungs-API ist, um die Mikroservice- oder Back-End-Servicedetails in Mobile Foundation Server zu konfigurieren und zu implementieren. Die Mobile-Foundation-Laufzeit verwendet die implementierte Konfiguration für sichere Aufrufe von Clientanforderungen an den entsprechenden Mikroservice oder das entsprechende Unternehmens-Back-End.

Der OAuth-basierte Mobile-Foundation-Sicherheitsmechanismus stellt sicher, dass der Aufruf von einem berechtigten Anwendungsclient ausgeführt wird. Das Client-SDK und der Autorisierungsserver der Mobile Foundation validieren im Hintergrund die von der Anwendung abgesetzte Anforderung. Der Unternehmens-Back-End-Service wird bei einem zufriedenstellenden Ergebnis der Sicherheitsüberprüfung aufgerufen.

Ablauf für API-Connector

Konfiguration für Mikroservices oder Unternehmens-Back-Ends definieren und implementieren

Mit der Verwaltungs-API der Mobile Foundation können Sie die Details des Mikroservice oder Back-Ends, zu dem die Client-App eine Verbindung herstellen muss, konfigurieren und implementieren. Für diesen Zweck wird die folgende Verwaltungs-API verwendet:

http://<Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config

Die folgenden Methoden sind für die Konfigurations-API verfügbar, um die Back-End-Servicedetails in der Mobile Foundation zu verwalten.

  1. Mit POST können Sie Back-End-Servicekonfigurationen implementieren.
  2. Mit GET können Sie implementierte Back-End-Servicekonfigurationen abrufen.
  3. Mit DELETE können Sie zuvor implementierte Konfigurationen löschen.

Die API-Methode POST verwendet Servicekonfigurationsdetails im JSON-Format. Die Syntax für die JSON-Konfigurationsdaten sieht wie folgt aus:

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

Nachfolgend sind die in den JSON-Daten verwendeten Schlüssel erläutert.

  1. service – Name eines logischen Service zur Identifizierung des Mikroservice oder Unternehmens-Back-End-Service. Dieser Name muss ein eindeutiger Name für einen bestimmten Service in der Liste der Services sein, die mit dieser Verwaltungs-API in Mobile Foundation Server konfiguriert wurden.
  2. baseurl – Basis-URL des Mikroservice oder Unternehmens-Back-End-Service. Dies ist die vollständige URL des Mikroservice, über die die Methoden zugänglich gemacht werden, die von der Client-App aufgerufen werden können. Der Methodenname könnte von der Clientanwendung bereitgestellt werden.
  3. auth - Authentifizierungsdetails für den Zugriff auf den Unternehmens-Back-End-Service
    • type – Die Mobile Foundation unterstützt die drei folgenden Typen:
      • ‘basic’ – Basisauthentifizierung mit einem Abschnitt für Berechtigungsnachweise (‘credential’), um den Benutzernamen und das Kennwort zu konfigurieren. Beispiel:
         "credential" : {
             "username" : "hello",
             "password" : "hello"
         }
        
      • apikey – Für die Authentifizierung auf der Basis von API-Schlüsseln werden je nach Richtlinientyp (policy) diverse Schemata unterstützt. Es folgt die Syntax für API-Schlüssel (apikey):
         "type" : "apikey",
         "credential" : {
             "apikey" : "abcdefg",
             "policy" : "basic",
             "name" : "apikey"
         }
        

        Die Richtlinie kann header, query oder basic sein, je nachdem, welche Präsentation des API-Schlüssels (apikey) der Back-End-Service erwartet. Bei Verwendung des Richtlinienwertes header wird der API-Schlüssel (apikey) im Anforderungsheader mit dem Headernamen (name) weitergeleitet. Mit der Richtlinie query wird der API-Schlüssel (apikey) als Abfrageparameter gesendet und bei Verwendung der Richtlinie basic wird apikey als Basisauthentifizierung gesendet.

      • mfpauth – Bei diesem Typ (type) kann der Mikroservice den OAuth-basierten Sicherheitsmechanismus der Mobile Foundation verwenden. Der Abschnitt credential ist für den Typ mfpauth nicht erforderlich und muss daher nicht in den JSON-Konfigurationsdaten enthalten sein.

      Der Back-End-Service kann durch einen Sicherheitsbereich, den Autorisierungsserver und den Mobile-Foundation-Authentifizierungsserver geschützt werden. Bevor der Zugriff auf den Back-End-Service gewährt wird, stellt der Authentifizierungsmechanismus der Mobile Foundation sicher, dass die Anforderung ein gültiges Zugriffstoken mit dem erforderlichen Bereich enthält. Wenn der Mobile-Foundation-Authentifizierungsserver die Gültigkeit des während der Introspektion präsentierten Zugriffstokens bestätigt, wird der Zugriff auf den Back-End-Service gewährt. Wie Sie einen Back-End-Service für die Verwendung des Mobile-Foundation-Authentifizierungsservers konfigurieren, erfahren Sie hier.

      • extauth - Dieser Typ kann verwendet werden, um Back-End-Mikroservices zu unterstützen, die einen Authentifizierungsserver eines anderen Anbieters nutzen. Der Anwendungsclient muss das vom Back-End-Service erwartete Zugriffstoken als speziellen Header mit dem Namen ext-token übergeben. Der API-Connector leitet das mit dem Header ext-token vom App-Client empfangene Zugriffstoken als Autorisierungsheader (Authorization) an den Back-End-Mikroservice weiter. Der Abschnitt mit Berechtigungsnachweisen (credential) ist für den Typ extauth nicht erforderlich und muss daher nicht in den JSON-Konfigurationsdaten enthalten sein. Die Introspektion des externen Tokens und dessen Verlängerung nach Ablauf des Tokens müssen vom App-Client und vom Back-End-Mikroservice durchgeführt werden. Der Mobile-Foundation-Sicherheitsmechanismus für die Validierung des App-Clients bleibt derselbe.
  4. Mit den Verbindungseigenschaften (ConnectionProperties) können Parameter für die Verbindung zwischen Mobile Foundation Server und Back-End-Mikroservices konfiguriert werden. Diese Parameter sind optional. Sind sie nicht angegeben, werden Standardwerte verwendet. Die Syntax für ConnectionProperties sieht wie folgt aus:
     "ConnectionProperties" : {
         "maxConnetions" : "50",
         "connectionTimeoutInMilliseconds" : "20000",
         "socketTimeoutInMilliseconds" : "20000"
     }
    

    Es folgen die die Standardwerte für die einzelnen Verbindungsparameter:

    • maxConnetions => 20
    • connectionTimeoutInMilliseconds => 30000 (d. h. 30 Sekunden)
    • socketTimeoutInMilliseconds => 30000 (d. h. 30 Sekunden)

Nachfolgend sehen Sie die Syntax für die curl-Befehle der Verwaltungs-API.

  1. POST für die Implementierung der Konfigurationen:
     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
    

    Hier steht config.json für die JSON-Datei mit Konfigurationen, deren JSON-Syntax mit der oben angegebenen vergleichbar ist.

  2. GET für das Abrufen vorhandener Konfigurationen:
     curl -X GET -u admin:admin 'http:// <Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config'
    
  3. DELETE für das Entfernen vorhandener implementierter Konfigurationen:
     curl -X DELETE -u admin:admin 'http:// <Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/mfp/backend-services-config'
    

Wenn die Konfiguration des Mikroservice oder Back-End-Service in der Mobile Foundation implementiert ist, können Sie das Client-SDK der Mobile Foundation verwenden, um den Unternehmens-Back-End-Service aufzurufen. Weitere Informationen zur Client-SDK-API finden Sie hier.

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 02, 2020