Exploration des bases des API REST

SAP Subscription Billing utilise un type d'API spécifique appelé Interfaces de programmation d'applications de transfert d'état représentatif, également appelées API REST.

Parlons d'abord des API.

Une API agit comme un protocole de communication entre différents programmes logiciels. Il explique comment ils doivent interagir les uns avec les autres, en fournissant un ensemble de règles et d'instructions. Considérez une API comme un « intermédiaire » qui permet aux programmes logiciels de communiquer de manière efficace. Sans API, il ne serait pas possible de profiter de la simple tâche de réservation d'une chambre d'hôtel en ligne ou de mise à jour du logiciel via le cloud.

Avant de parler des API REST, voyons comment fonctionne une API. Regardez la vidéo suivante.

Maintenant que vous comprenez le rôle des API, examinons les API REST.

REST est l'acronyme de Representative ational State Transfer (Transfert d'État représentatif). Il s'agit d'un style architectural pour la conception d'applications en réseau. Une API REST utilise HTTP - une technologie fondamentale d'Internet - pour demander et envoyer des données. Ces données peuvent fonctionner dans différents formats, y compris XML et JSON.

Le concept de REST est basé sur les ressources. Une ressource dans l'API REST est le concept fondamental pour la description de l'information ; c'est toute information qui peut être nommée. Par exemple, lorsqu'il est question de SAP Subscription Billing, un abonnement peut être une ressource et un client une autre. L'importance d'utiliser des ressources au lieu d'une grande base de données est que chaque ressource a une URL unique que vous pouvez lier ou référencer.

Une fonctionnalité robuste des API REST est leur utilisation des méthodes HTTP standard. Il s'agit notamment de POST qui ajoute une nouvelle ressource ; GET récupère une ressource ; PUT met à jour une ressource ; PATCH permet une mise à jour partielle ; et DELETE supprime une ressource.

Les méthodes PUT et PATCH sont similaires car elles mettent à jour toutes les deux une ressource. Par exemple, si vous avez un profil utilisateur avec des zones telles que le nom, l'e-mail et le mot de passe, une demande PUT vous demande d'envoyer toutes les zones même si vous voulez uniquement modifier le mot de passe. L'utilisation de PATCH over PUT permet d'éviter de réduire les performances du système avec des modifications inutiles lorsqu'il s'agit de ressources importantes ou de mises à jour fréquentes.

Un appel d'API ou une opération est idempotent s'il a le même résultat peu importe combien de fois il est appliqué. Une opération idempotente assure une protection contre les doublons accidentels d'appels provoquant des conséquences involontaires.

Par exemple, si vous envoyez plusieurs fois la même requête DELETE à une URL spécifique, les tentatives suivantes échoueront probablement car les données ont déjà été supprimées. L'état final du serveur avec les données supprimées reste le même après la première requête DELETE. Même si la deuxième requête échoue, la méthode DELETE est toujours considérée comme idempotente car l'état final souhaité a été atteint et ne changera pas avec des requêtes répétées.

Par exemple, considérez une ressource qui compte pour chaque fois qu'une requête PATCH est effectuée. La demande PATCH d'augmenter le compteur de 1 ne remplace pas l'historique du compteur. Chaque requête PATCH suivante incrémente le compteur. Si vous appliquez à nouveau la même demande PATCH, le résultat sera différent à chaque fois et augmentera le compteur.

Le choix d'une méthode API REST idempotente dépend de votre application ou service.

La beauté des API REST réside dans leur simplicité. Les API REST sont sans état, ce qui signifie que le serveur n'a pas besoin de connaître l'état du client. Une demande d'un client contient déjà les informations nécessaires pour répondre à une demande.

Notez que les méthodes REST ne sont pas considérées comme standard. Les méthodes REST sont un ensemble de principes directeurs et sont adoptées par la plupart des développeurs comme un outil puissant pour structurer les API en raison de leur simplicité, de leur évolutivité et de leur compatibilité avec le Web.

Les API (Application Programming Interfaces) et les API REST (Representative ational State Transfer APIs) jouent un rôle crucial dans le développement de logiciels modernes et les interactions numériques. Les API permettent aux différents systèmes logiciels de communiquer et d'interagir entre eux. Les API REST sont devenues un style d'architecture populaire et largement adopté pour la conception de systèmes en réseau, en particulier dans le contexte des services Web et des applications basées sur le cloud.

Obtenez une clé API, également appelée clé de service, en accédant à SAP Business Accelerator Hub, en accédant à votre API et en cliquant sur le bouton Afficher clé API en haut à droite de la page. Les clés de service permettent de sécuriser les applications avec une méthode d'authentification et d'autorisation. Ils jouent un rôle clé dans la protection des interfaces d'application et des données en veillant à ce qu'une API soit accessible uniquement par des utilisateurs ou des systèmes de confiance et autorisés.

Une clé de service est un identifiant unique qui fournit un accès d'identifiant à un service particulier et peut aider à gérer et limiter l'utilisation du service. Les clés de service peuvent être regénérées si elles sont compromises. Les clés de service sont souvent des chaînes longues et complexes qui sont difficiles à reproduire, ce qui rend plus difficile pour les utilisateurs non autorisés de contourner les mesures de sécurité.

L'authentification avec une clé de service commence par l'envoi de la clé dans le cadre d'une demande à une API. Le serveur compare la clé à la clé stockée sur le serveur. S'ils correspondent, la requête est authentifiée, comme une méthode typique de nom d'utilisateur et de mot de passe.

Dans SAP Subscription Billing, l'authentification initiale génère un identifiant temporaire ou un jeton d'accès appelé jeton du porteur. Alors que les clés de service fournissent une authentification sécurisée des systèmes de confiance, les jetons portent un accès sécurisé et temporaire aux services après authentification.

Dans SAP Subscription Billing, l'authentification initiale génère un identifiant temporaire ou un jeton d'accès appelé jeton du porteur. Alors que les clés de service fournissent une authentification sécurisée des systèmes de confiance, les jetons portent un accès sécurisé et temporaire aux services après authentification.

Les jetons du porteur ne sont pas liés à un utilisateur spécifique ; ils vérifient plutôt qu'une demande provient d'une source authentifiée auparavant.

Une fois l'authentification de clé de service réussie, le serveur génère un jeton de porteur unique signé et le renvoie au client. Ce jeton est ensuite utilisé à la place de la clé de service pour authentifier les requêtes suivantes dans cette session. Un jeton porteur permet de réduire le risque d'exposition d'une clé de service en éliminant la nécessité d'envoyer la clé de service avec chaque demande.

Les jetons du porteur sont générés pour une durée limitée et sont contrôlés par une date d'expiration. Le jeton n'est plus valide à l'expiration. L'utilisateur doit réauthentifier la clé de service pour générer un nouveau jeton du porteur. Un jeton porteur permet de réduire la possibilité d'accès à long terme par un utilisateur non autorisé.

Alors que les clés de service fournissent une authentification sécurisée des systèmes de confiance, les jetons portent un accès sécurisé et temporaire aux services après authentification. Voyons maintenant comment créer un jeton du porteur et rechercher des API.