Che cosa sono le aree di lavoro in Gestione API di Azure?

SI APPLICA A: Premium

In Gestione API, le aree di lavoro offrono un nuovo livello di autonomia ai team API di un'organizzazione, consentendo loro di creare, gestire e pubblicare le API più velocemente, in modo più affidabile, sicuro e produttivo all'interno di un servizio Gestione API. Grazie a un accesso amministrativo isolato e runtime alle API, le aree di lavoro consentono ai team API di mantenere la supervisione del team della piattaforma API. Sono inclusi il monitoraggio centrale, l'applicazione dei criteri e la conformità API e la pubblicazione di API per l'individuazione tramite un portale per sviluppatori unificato.

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.
• 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 di Microsoft Entra.
• Ogni area di lavoro è associata a un gateway dell'area di lavoro per il routing del traffico API ai servizi back-end delle API nell'area di lavoro.

Gestione API federata con aree di lavoro

Le aree di lavoro aggiungono il supporto di prima classe per un modello federato di gestione delle API in Gestione API, oltre ai modelli centralizzati e silo già supportati. Per un confronto di questi modelli, vedere la tabella seguente.

Modello	Descrizione
Centralizzato	Vantaggi • Governance centralizzata delle API e osservabilità • Portale per sviluppatori unificato per l'individuazione e l'onboarding efficaci delle API • Efficienza dei costi dell'infrastruttura Svantaggi • Nessuna separazione delle autorizzazioni amministrative tra i team • Il gateway API è un singolo punto di errore • Impossibilità di attribuire problemi di runtime a team specifici • Il carico di lavoro sul team della piattaforma per facilitare la collaborazione può ridurre la crescita delle API
In silos	Vantaggi • La separazione delle autorizzazioni amministrative tra i team aumenta la produttività e la sicurezza • La separazione del runtime API tra i team aumenta l'affidabilità, la resilienza e la sicurezza delle API • I problemi di runtime sono contenuti e attribuibili a team specifici Svantaggi • Mancanza di governance centralizzata delle API e osservabilità • Mancanza di un portale per sviluppatori unificato • Aumento dei costi e gestione delle piattaforme più difficile
Federato	Vantaggi • Governance centralizzata delle API e osservabilità • Portale per sviluppatori unificato per l'individuazione e l'onboarding efficaci delle API • La separazione delle autorizzazioni amministrative tra i team aumenta la produttività e la sicurezza • La separazione del runtime API tra i team aumenta l'affidabilità, la resilienza e la sicurezza delle API • I problemi di runtime sono contenuti e attribuibili a team specifici Svantaggi • Difficoltà di gestione e costi della piattaforma maggiori rispetto al modello centralizzato, ma inferiori rispetto al modello in silos

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 dedicato 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.

Gestione API in un'area di lavoro

Teams gestisce le proprie API, prodotti, sottoscrizioni, back-end, criteri, logger e altre risorse all'interno delle aree di lavoro. 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.

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.

Gateway dell'area di lavoro

Ogni area di lavoro può essere associata ai gateway dell'area di lavoro per abilitare il runtime delle 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. Garantiscono l'isolamento del runtime tra aree di lavoro, aumentando l'affidabilità dell'API, la resilienza e la sicurezza e abilitando l'attribuzione dei problemi di runtime alle aree di lavoro.

• Per informazioni sul costo dei gateway dell'area di lavoro, vedere Prezzi di Gestione API.
• Per un confronto dettagliato dei gateway di Gestione API, vedere Panoramica dei gateway di Gestione API.

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.

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

I gateway dell'area di lavoro devono trovarsi nella stessa area di Azure e nella stessa sottoscrizione del servizio Gestione API.

• Stati Uniti occidentali
• Stati Uniti centro-settentrionali
• Stati Uniti orientali 2
• Regno Unito meridionale
• Francia centrale
• Europa settentrionale
• Asia orientale
• Asia sud-orientale
• Australia orientale
• Giappone orientale

Vincoli del gateway

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

• Un gateway può essere associato solo a un'area di lavoro
• 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 le API create da risorse di Azure, ad esempio il Servizio OpenAI di Azure, il 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.

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 Gestione API (ad esempio API, prodotti, tag o sottoscrizioni) devono avere nomi univoci, anche se si trovano in aree di lavoro differenti. 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.

Contenuto correlato

• Creare un'area di lavoro
• Modifiche che causano un'interruzione delle aree di lavoro (giugno 2024)
• Modifiche che causano un'interruzione delle aree di lavoro (marzo 2025)
• Limiti - Aree di lavoro di Gestione API