Condividi tramite


Gestione API federata con aree di lavoro

SI APPLICA A: Premium

Questo articolo offre una panoramica delle aree di lavoro di Gestione API e del modo in cui consentono ai team di sviluppo decentralizzato di API di gestire e prodotto le API in un'infrastruttura di servizi comune.

Perché le organizzazioni devono eseguire la federazione della gestione API?

Oggi, le organizzazioni affrontano sempre più sfide nella gestione di una proliferazione di API. Man mano che aumenta il numero di API e team di sviluppo di API, la complessità della gestione. Questa complessità può comportare un aumento del sovraccarico operativo, dei rischi per la sicurezza e una riduzione dell'agilità. Da un lato, le organizzazioni vogliono stabilire un'infrastruttura API centralizzata per garantire la governance, la sicurezza e la conformità delle API. D'altra parte, vogliono che i team API possano innovare e rispondere rapidamente alle esigenze aziendali, senza il sovraccarico della gestione di una piattaforma API.

Un modello federato di Gestione API soddisfa queste esigenze. La gestione API federata consente la gestione decentralizzata delle API da parte dei team di sviluppo con l'isolamento appropriato dei piani di controllo e dati, mantenendo al contempo governance centralizzata, monitoraggio e individuazione API gestita da un team della piattaforma API. Questo modello supera le limitazioni degli approcci alternativi, ad esempio la gestione API completamente centralizzata dal team della piattaforma o dalla gestione API siloed da ogni team di sviluppo.

Gestione API federata offre:

  • Governance centralizzata delle API e osservabilità
  • Portale per sviluppatori unificato per l'individuazione e l'onboarding efficaci delle API
  • Autorizzazioni amministrative separate tra i team API, migliorando la produttività e la sicurezza
  • Runtime api separato tra team API, miglioramento dell'affidabilità, resilienza e sicurezza

Come le aree di lavoro abilitano la gestione API federata

In Azure Gestione API usare le aree di lavoro per implementare la gestione API federata. Le aree di lavoro funzionano come "cartelle" all'interno di un servizio Gestione API:

  • Ogni area di lavoro contiene API, prodotti, sottoscrizioni, valori denominati e risorse correlate. Per un elenco completo delle risorse e delle operazioni supportate nelle aree di lavoro, vedere le informazioni di riferimento sull'API REST di Gestione API.
  • L'accesso alle risorse all'interno di un'area di lavoro viene gestito tramite il controllo degli accessi in base al ruolo di Azure con ruoli predefiniti o personalizzati assegnabili agli account Microsoft Entra e con ambito a un'area di lavoro.
  • Ogni area di lavoro è associata a uno o più gateway dell'area di lavoro per il routing del traffico API ai servizi back-end delle API nell'area di lavoro.
  • Il team della piattaforma può applicare criteri API che si estendono sulle API nelle aree di lavoro, monitorare la piattaforma visualizzando i log per tutte le aree di lavoro e implementare un'esperienza centralizzata di individuazione API con un portale per sviluppatori.

Diagramma concettuale del servizio Gestione API con aree di lavoro.

Nota

  • Le funzionalità più recenti dell'area di lavoro sono supportate nell'API REST di Gestione API versione 2023-09-01-preview o successiva.
  • Per considerazioni sui prezzi, vedere Prezzi di API Management.

Anche se le aree di lavoro vengono gestite in modo indipendente dal servizio Gestione API e da altre aree di lavoro, è possibile fare riferimento alle risorse a livello di servizio selezionate. Vedere Aree di lavoro e altre funzionalità di Gestione API più avanti in questo articolo.

Panoramica degli scenari di esempio

Un'organizzazione che gestisce le API che usano API Management di Azure può avere più team di sviluppo che sviluppano, definiscono, gestiscono e producono diversi set di API. Le aree di lavoro consentono a questi team di usare Gestione API per gestire, accedere e proteggere le API separatamente e indipendentemente dalla gestione dell'infrastruttura del servizio.

Di seguito è riportato un flusso di lavoro di esempio per la creazione e l'uso di un'area di lavoro.

  1. Un team centrale della piattaforma API che gestisce l'istanza di API Management crea un'area di lavoro e assegna le autorizzazioni ai collaboratori dell'area di lavoro usando i ruoli controllo degli accessi in base al ruolo, ad esempio le autorizzazioni per creare o leggere risorse nell'area di lavoro. Viene creato anche un gateway API con ambito area di lavoro per l'area di lavoro.

  2. Un team centrale della piattaforma API usa gli strumenti DevOps per creare una pipeline DevOps per le API in tale area di lavoro.

  3. I membri dell'area di lavoro sviluppano, pubblicano, generano e mantengono le API nell'area di lavoro.

  4. Il team centrale della piattaforma API gestisce l'infrastruttura del servizio, ad esempio il monitoraggio, la resilienza e l'applicazione dei criteri di tutte le API.

Gateway dell'area di lavoro

Ogni area di lavoro è associata a uno o più gateway dell'area di lavoro per abilitare il runtime di API gestite all'interno dell'area di lavoro. Il gateway dell'area di lavoro è una risorsa di Azure autonoma con le stesse funzionalità di base del gateway integrato nel servizio Gestione API.

I gateway dell'area di lavoro vengono gestiti in modo indipendente dal servizio Gestione API e l'uno dall'altro. Consentono l'isolamento del runtime tra aree di lavoro o casi d'uso, aumentando l'affidabilità dell'API, la resilienza e la sicurezza e abilitando l'attribuzione dei problemi di runtime alle aree di lavoro.

Nota

Si sta introducendo la possibilità di associare più aree di lavoro a un gateway dell'area di lavoro, aiutando le organizzazioni a gestire le API con le aree di lavoro a un costo inferiore. Questa funzionalità è in fase di implementazione a partire da dicembre 2024 e potrebbe non essere disponibile per tutti i servizi idonei prima di gennaio. Ulteriori informazioni

Nome host del gateway

Ogni associazione di un'area di lavoro a un gateway dell'area di lavoro crea un nome host univoco per le API gestite nell'area di lavoro. I nomi host predefiniti seguono il modello <workspace-name>-<hash>.gateway.<region>.azure-api.net. Attualmente, i nomi host personalizzati non sono supportati per i gateway dell'area di lavoro.

Isolamento della rete

Un gateway dell'area di lavoro può essere configurato facoltativamente in una rete virtuale privata per isolare il traffico in ingresso e/o in uscita. Se configurato, il gateway dell'area di lavoro deve usare una subnet dedicata nella rete virtuale.

Per i requisiti dettagliati, vedere Requisiti delle risorse di rete per i gateway dell'area di lavoro.

Nota

  • La configurazione di rete di un gateway dell'area di lavoro è indipendente dalla configurazione di rete dell'istanza di Gestione API.
  • Attualmente, un gateway dell'area di lavoro può essere configurato solo in una rete virtuale quando viene creato. Non è possibile modificare la configurazione di rete o le impostazioni del gateway in un secondo momento.

Ridimensionare la capacità

Gestire la capacità del gateway aggiungendo o rimuovendo manualmente unità di scala, in modo analogo alle unità che possono essere aggiunte all'istanza di Gestione API in determinati livelli di servizio. I costi di un gateway dell'area di lavoro si basano sul numero di unità selezionate.

Disponibilità a livello di area

Per un elenco corrente delle aree in cui sono disponibili i gateway dell'area di lavoro, vedere Disponibilità di livelli v2 e gateway dell'area di lavoro.

Vincoli del gateway

I vincoli seguenti si applicano attualmente ai gateway dell'area di lavoro:

  • Un gateway del workspace deve essere nella stessa regione della regione primaria di Azure dell'istanza Gestione API e nella stessa sottoscrizione.
  • Un'area di lavoro non può essere associata a un gateway self-hosted
  • I gateway dell'area di lavoro non supportano endpoint privati in ingresso
  • Le API nei gateway dell'area di lavoro non possono essere assegnate a nomi host personalizzati
  • Le API nelle aree di lavoro non sono coperte da Defender per le API
  • I gateway dell'area di lavoro non supportano la gestione credenziali del servizio Gestione API
  • I gateway dell'area di lavoro supportano solo la cache interna; la cache esterna non è supportata
  • I gateway dell'area di lavoro non supportano API GraphQL sintetiche e API WebSocket
  • I gateway dell'area di lavoro non supportano la creazione di API direttamente dalle risorse di Azure, ad esempio il servizio OpenAI di Azure, le servizio app, le app per le funzioni e così via
  • Le metriche delle richieste non possono essere suddivise per area di lavoro in Monitoraggio di Azure; tutte le metriche dell'area di lavoro vengono aggregate a livello di servizio
  • I log di Monitoraggio di Azure vengono aggregati a livello di servizio; I log a livello di area di lavoro non sono disponibili
  • I gateway dell'area di lavoro non supportano i certificati CA
  • I gateway dell'area di lavoro non supportano la scalabilità automatica
  • I gateway dell'area di lavoro non supportano le identità gestite, incluse le funzionalità correlate, ad esempio l'archiviazione di segreti in Azure Key Vault e l'uso dei criteri di authentication-managed-identity

Ruoli controllo degli accessi in base al ruolo per le aree di lavoro

Il controllo degli accessi in base al ruolo di Azure viene usato per configurare le autorizzazioni dei collaboratori dell'area di lavoro per leggere e modificare le entità nell'area di lavoro. Per un elenco dei ruoli, vedere Come usare il controllo degli accessi in base al ruolo in API Management.

Per gestire le API e altre risorse nell'area di lavoro, ai membri dell'area di lavoro devono essere assegnati ruoli (o autorizzazioni equivalenti usando ruoli personalizzati) con ambito per il servizio Gestione API, l'area di lavoro e il gateway dell'area di lavoro. Il ruolo con ambito servizio consente di fare riferimento a determinate risorse a livello di servizio dalle risorse a livello di area di lavoro. Ad esempio, organizzare un utente in un gruppo a livello di area di lavoro per controllare la visibilità dell'API e del prodotto.

Nota

Per semplificare la gestione, configurare i gruppi di Microsoft Entra per assegnare le autorizzazioni dell'area di lavoro a più utenti.

Aree di lavoro e altre funzionalità di API Management

Le aree di lavoro sono progettate per essere autonome per ottimizzare la separazione dell'accesso amministrativo e del runtime API. Esistono diverse eccezioni per garantire una maggiore produttività e abilitare la governance a livello di piattaforma, l'osservabilità, la riutilizzabilità e l'individuazione delle API.

  • Riferimenti alle risorse: le risorse in un'area di lavoro possono fare riferimento ad altre risorse nell'area e alle risorse selezionate dal livello di servizio, ad esempio utenti, server di autorizzazione o gruppi di utenti predefiniti. Non possono fare riferimento a risorse da un'altra area di lavoro.

    Per motivi di sicurezza, non è possibile fare riferimento a risorse a livello di servizio da criteri a livello di area di lavoro (ad esempio, valori denominati) o da nomi di risorse, ad esempio backend-id nei criteri set-back-end-service.

    Importante

    Tutte le risorse in un servizio di Gestione API (ad esempio, API, prodotti, tag o sottoscrizioni) devono avere nomi univoci, anche se si trovano in aree di lavoro diverse. Non possono esistere risorse dello stesso tipo e con lo stesso nome di risorsa di Azure nella stessa area di lavoro, in altre aree di lavoro o a livello di servizio.

  • Portale per sviluppatori: le aree di lavoro sono un concetto amministrativo e non vengono visualizzate come tali per i consumer del portale per sviluppatori, tra cui tramite l'interfaccia utente del portale per sviluppatori e l'API sottostante. Le API e i prodotti all'interno di un'area di lavoro possono essere pubblicati nel portale per sviluppatori, proprio come le API e i prodotti a livello di servizio.

    Nota

    Gestione API supporta l'assegnazione di server di autorizzazione definiti a livello di servizio alle API all'interno delle aree di lavoro.

Eseguire la migrazione dalle aree di lavoro di anteprima

Se sono state create aree di lavoro in anteprima in Gestione API di Azure e si vuole continuare a usarle, eseguire la migrazione delle aree alla versione disponibile a livello generale associando un gateway del workspace a ogni area di lavoro.

Per informazioni dettagliate su altre modifiche che potrebbero influire sulle aree di lavoro di anteprima, vedere Modifiche di rilievo delle aree di lavoro (marzo 2025).

Eliminazione di un'area di lavoro

L'eliminazione di un'area di lavoro elimina tutte le relative risorse figlio (API, prodotti e così via) e il gateway associato, se si elimina l'area di lavoro usando l'interfaccia del portale di Azure. Non elimina l'istanza di Gestione API o altre aree di lavoro.