Chapitre 3. Gestion omnidirectionnelle de l'API
Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com
Au chapitre 2, nous avons présenté une passerelle API moderne comme une base qui, associée à l'ingénierie de la plateforme, te met sur la bonne voie pour une puissante solution de gestion des API en libre-service. Jusqu'à présent, cette approche, et à peu près toutes les autres solutions de gestion des API, considéraient le trafic d'un point de vue "entrant", c'est-à-dire le trafic entrant dans un périmètre (domaine, cluster, centre de données, etc.). Qu'en est-il du trafic entre les API à l'intérieur d'un périmètre ? Qu'en est-il du trafic entre les API et les services à l'extérieur du périmètre ?
La gestion moderne des API doit être omnidirectionnelle, et pas seulement en entrée. En fait, la plupart des utilisations d'API au sein d'une entreprise sont probablement des appels d'API "internes", c'est-à-dire des API qui appellent d'autres API. Traiter ce trafic comme du trafic entrant pourrait fonctionner, mais il y a beaucoup plus de pièces mobiles et de façons de se tromper. Par exemple, pour appeler une API, tu dois d'abord identifier l'API appelante d'une manière ou d'une autre (clé API, jeton JWT, etc.). Pour ce faire, tu dois soit échanger des informations d'identification (nom d'utilisateur, mot de passe) au moment de l'exécution, soit stocker des jetons à vie longue qui peuvent être récupérés au ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access