Introduzione

  • 3 minuti

Il software moderno è basato su API (Application Programming Interface). Riflettendo sulle applicazioni create dall'organizzazione nell'ultimo anno, è probabile che la maggior parte delle funzionalità sia basata sulle API. Su larga scala, ciò significa che molte organizzazioni possono avere centinaia, migliaia o persino decine di migliaia di API create internamente o integrate con API esterne. Con l'aumento della domanda di software e con le API come livello di base che alimenta questo software, il numero di API con cui il vostro team lavorerà è destinato ad aumentare, se non ad accelerare rapidamente.

Scenario

Contoso Corporation è una società fittizia che implementa architetture di microservizi, adottando un approccio API-first. Negli anni precedenti, l'organizzazione aveva solo pochi team che compilavano API e spesso erano gli stessi team che utilizzavano tali API. Nel corso del tempo, l'organizzazione è cresciuta e molti team stanno ora producendo e consumando API sviluppate sia internamente che esternamente. Tuttavia, i tecnici della piattaforma per API di Contoso hanno segnalato che si avvicinano a uno stato Sprawl dell'API (uno stato in cui le API dell'organizzazione aumentano in modo esponenziale e non controllabile) e prevedono altri problemi downstream, tra cui:

  • Scarsa individuabilità e riutilizzo delle API: senza una chiara comprensione delle API disponibili, gli sviluppatori potrebbero finire per creare nuove API che replicano le funzionalità esistenti, con conseguente perdita di tempo e risorse.

  • Shadow, API non governative: la maggior parte degli sviluppatori può interrompere la gestione e la manutenzione di alcune API in isolamento man mano che passano ad altri progetti.

  • Potenziali minacce alla sicurezza: il team della piattaforma per API potrebbe non essere in grado di applicare in modo efficace i criteri di sicurezza dell'organizzazione, causando potenzialmente endpoint vulnerabili e non protetti.

  • Progettazione di API incoerenti: gli sviluppatori potrebbero non produrre tutte le API conformi ai principi di progettazione unificata dell'API dell'organizzazione e sarà necessario usare altre risorse di sviluppo per riprogettare API incoerenti che potrebbero essere individuate dopo l'implementazione.

    Screenshot che mostra uno Sprawl dell'API.

A questo punto, il team della piattaforma per API ha iniziato a eseguire il brainstorming su una soluzione efficace e trasparente per impedire che l'organizzazione possa raggiungere questo stato. Se l'organizzazione deve anche adottare una strategia per centralizzare tutte le API per semplificare il monitoraggio e la governance, questo è il modulo più adatto.

Obiettivi di apprendimento

Contenuto del modulo:

  • Informazioni sul Centro API di Azure e sui vantaggi offerti.
  • Esplorare in che modo Il Centro API consente all'organizzazione di centralizzare l'inventario, la governance, la scoperta e il consumo delle API.
  • Informazioni su come iniziare a usare il Centro API di Azure per l'organizzazione.
  • Esplorare le integrazioni avanzate con strumenti di sviluppo come Visual Studio Code.