Apprenez à mobiliser vos API en configurant et en utilisant le RAPID REST Data Connector de Kinvey avec les proxies API configurés dans Apigee Edge.
Nous voyons un nombre croissant d'organisations adoptant Progress Kinvey pour mobiliser leur entreprise Apis. Cela inclut les plates-formes de gestion d'API telles que Apigee, MuleSoft, CA Technologies, Tibco Mashery et d'autres qui ne sont pas spécifiquement conçues pour la mobilité. Kinvey intègre ces API via son connecteur sans code RAPID ou FLEX
Dans ce post, nous verrons comment configurer et utiliser le connecteur de données RAPID REST de Kinvey avec des proxies API configurés dans Apigee Bord. Si vous êtes nouveau à Apigee ou Kinvey assurez-vous de vérifier les ressources suivantes:
Kinvey: https://www.progress.com/kinvey
Apigée: https: // docs Okay alors commençons.
Je vais supposer que vous avez déjà configuré vos proxies API dans Apigee pour servir votre API REST aux développeurs internes / externes. Sinon, je recommande de vous inscrire pour un compte d'essai gratuit et d'utiliser le lien ci-dessus pour en savoir plus.
Apigee Edge Proxy
Pour ma configuration, j'ai créé une spécification dans Apigee pour un endpoint appelé " messages "représentant des articles de blog. J'ai ensuite créé un proxy Api et l'ai attaché à un endpoint backend réel de l'API REST "/ posts" servi en utilisant JSONPlaceholder . Apigee peut déployer le proxy dans un environnement de test / prod dont chacun possède une URL configurable dans le connecteur Kinvey RAPID. L'URL que j'ai eu pour le proxy de mes posts était http://sameer-eval-prod.apigee.net/posts
En-têtes statiques: Possibilité de transmettre les en-têtes que vous souhaitez inclure dans chaque requête, facultatif
Query Params: Query params à inclure dans chaque requête Ceci est facultatif
Type d'authentification: Dans la plupart des cas, un API Management P latform sécurise l'accès à l'API mais pour des raisons de simplicité, je n'ai pas choisi d'ajouter une couche d'authentification à mon proxy Apigee. Cependant, si votre configuration nécessite une authentification, vous pouvez la configurer ici facilement.
Cliquez sur Enregistrer pour terminer. Il est maintenant temps de créer des objets de service dans Kinvey pour nos terminaux. Un objet de service permet à Kinvey d'interagir avec des enregistrements ou des objets de données sur un système externe. Je vais en créer un appelé "posts". Un objet de service est similaire à votre API dans Apigee. Cette fois, passons d'abord en revue les champs dans le formulaire avant de partager une capture d'écran de ma config.
Nom: Ceci est le nom de votre objet Service. Vous pouvez appeler cela n'importe quoi mais je vous recommande de garder le même nom que votre point de terminaison. Donc, si c'est "/ posts", nommez l'objet Service "posts". Veuillez noter que ce nom sera utilisé par les développeurs pour référencer le point de terminaison dans Kinvey.
Endpoint: Ceci est relatif à "host" vous mettez dans le formulaire précédent. Entrez la partie URI qui identifie la ressource spécifique. Pour moi c'est "/ posts"
Racine de contexte: Vous permet en option d'extraire des données imbriquées à partir des réponses du serveur. Cela signifie que vous pouvez renvoyer juste un sous-ensemble de la réponse réelle. Par exemple: Supposons que votre réponse API ait entre autres un objet appelé "body". Si vous souhaitez simplement renvoyer cet objet, définissez la propriété Context Root sur "body".
Type de clé primaire: Sélectionnez le type de propriété qui identifie la ressource de manière unique: nombre (int) ou chaîne.
Nom de la clé primaire: Entrez le nom de la propriété qui identifie la ressource de manière unique.
Mappage de requête: Vous permet de personnaliser la façon dont les requêtes sont passées de Kinvey à l'API REST distante.
Méthode HTTP: Ceci est le verbe par défaut à utiliser lors de demandes à l'API REST externe (Apigee Proxy ). My Proxy accepte GET qui est aussi la valeur par défaut de ce champ, donc je vais laisser vide.
Static Headers: Vous permet d'ajouter des valeurs de chaînes statiques personnalisées comme en-tête à inclure dans chaque requête à l'API Les jetons sont également pris en charge
Paramètres de requête: Vous permet d'ajouter des valeurs de chaînes statiques personnalisées en tant que paramètre de chaîne de requête à inclure dans chaque requête envoyée à l'API. Les jetons sont également supportés.
Opérations supportées: Utilisez le bouton bascule pour activer / désactiver n'importe quelle opération. Cela vous donne une autre couche de sécurité en plus de la spécification définie dans Apigee. Toute requête envoyée à Kinvey pour une opération non activée ici reçoit l'erreur "405 METHOD NOT ALLOWED"
Field Mapping: Utilisez ceci pour contrôler quels champs sont exposés. Par défaut, les champs de service sont automatiquement mappés à des champs Kinvey de même nom.
Si vous voulez plus de contrôle comme moi, cliquez sur "Découvrir les champs" pour récupérer automatiquement les champs que votre API affiche. Une fois que vous faites cela, vous devriez voir le nombre de champs récupérés par Kinvey et un bouton à côté de lui "Ajouter tout". Cliquez sur "Ajouter tout" pour revoir ou modifier les mappages par défaut. Pour définir des mappages personnalisés Cliquez sur "Ajouter un mappage de champ non par défaut". Les champs imbriqués sont pris en charge. Utilisez la notation par points pour mapper ceux-ci, par exemple: "body.title."
Important: Nous vous recommandons de mapper votre clé primaire au champ "_id" de Kinvey. J'ai souligné comment j'ai fait cela dans les écrans ci-dessous.
Astuce: "Discover Fields" peut également être utilisé comme test pour voir si votre hôte et votre point final sont accessibles par Kinvey
Et comme promis, voici ma configuration d'objet de service pour le point de terminaison "/ posts". C'est une forme longue donc je vais le faire en deux captures d'écran.
Bien, c'est Kinvey Rapid pour vous, si vous êtes intéressé à l'essayer par vous-même, rendez-vous sur la console et créez un compte gratuit. Gratuit
Source link