Creare un'API con Funzioni di Azure
A questo punto, è necessario creare un'API per l'app per la lista della spesa.
Funzioni di Azure
Uno dei principali vantaggi di App Web statiche di Azure è quello di ospitare l'app Web insieme a un'API creata con Funzioni di Azure. App Web statiche di Azure distribuisce a livello globale gli asset statici dell'app Web e ospita l'API in Funzioni di Azure. Con questa configurazione, si ottengono la disponibilità e la velocità garantite dalla distribuzione globale degli asset dell'app Web.
È anche importante cosa non si ottiene.
Non sono necessarie la configurazione e la manutenzione di un server completo per il front-end o il back-end. Questo è un altro vantaggio di App Web statiche di Azure: la semplicità di pubblicare l'app e l'API con attività minime di configurazione e manutenzione.
Funzioni di Azure rende disponibili gli endpoint delle route, non richiede la configurazione o la manutenzione di un server back-end completo e fornisce scalabilità orizzontale e ridimensionamento automatici su richiesta. Tutto questo fa di Funzioni di Azure un ottimo partner di API per l'app Web per la lista della spesa, che rende disponibili gli asset statici.
App Web statiche di Azure genera un URL univoco per il sito, che è disponibile nella scheda Panoramica nel portale. L'API è disponibile tramite questo stesso URL aggiungendovi /api.
API per la lista della spesa
L'app per la lista della spesa permette agli utenti di ottenere, aggiungere, aggiornare ed eliminare articoli nella propria lista. È quindi logico che l'API includa endpoint che soddisfano queste esigenze.
Ecco i quattro endpoint che verranno creati:
| Metodi | Endpoint delle route | Endpoint API completo |
|---|---|---|
| GET | products |
api/products |
| POST | products |
api/products |
| PUT | products/:id |
api/products/:id |
| DELETE | products/:id |
api/products/:id |
Si noti che la route delle richieste HTTP GET riporta a api/products. Il prefisso api è riservato per gli endpoint API nell'app. È possibile definire qualsiasi altra route in base alle esigenze del sito, ma api punta sempre all'app Funzioni di Azure.
Creare un'API per l'app Web
Fino a ora è stato usato un framework front-end. A breve si potrà aggiungere un'API e la si connetterà all'app front-end. Il repository include una cartella api-starter che contiene un progetto di Funzioni di Azure incompleto ed endpoint HTTP per richieste PUT, POST e DELETE per i prodotti.
L'API è priva della funzione HTTP GET. Si completerà l'API del progetto di Funzioni di Azure e si aggiungerà la funzione mancante. Si connetterà quindi l'API all'app Web front-end.
Visualizzazione in anteprima delle modifiche apportate all'app Web
Prima di apportare modifiche a un'app, è consigliabile creare un nuovo ramo per le modifiche. Poiché si stanno apportano diverse modifiche per completare l'API per l'app, è necessario creare un ramo per queste modifiche.
Dopo aver apportato le modifiche, è preferibile osservarle in esecuzione prima di decidere di unirle. Dopo aver creato una richiesta pull dal nuovo ramo al ramo main, GitHub Actions compila l'app e l'API e le distribuisce entrambe in un URL di anteprima. Questa funzionalità permette di lasciare l'app Web in esecuzione con App Web statiche di Azure, ma anche visualizzare una seconda istanza di anteprima con i risultati della richiesta pull.
Comunicazione tra l'app Web e l'API
Quando si esegue l'API in locale con Funzioni di Azure, per impostazione predefinita viene usata la porta 7071. L'app Web usa una porta locale diversa. Quando l'app Web prova a effettuare una richiesta HTTP dalla propria porta alla porta 7071 dell'API, questa operazione è nota come condivisione di risorse tra le origini (CORS). Il browser impedisce il completamento della richiesta HTTP, a meno che il server API non consenta alla richiesta di procedere.
La condivisione di risorse tra le origini (CORS) non è un aspetto di cui preoccuparsi quando si esegue la pubblicazione in App Web statiche di Azure. App Web statiche di Azure configura automaticamente l'app in modo che possa comunicare con l'API su Azure usando un proxy inverso. Un proxy inverso permette all'app Web e all'API di apparire come appartenenti allo stesso dominio Web. Di conseguenza, è necessario configurare la condivisione di risorse tra le origini solo in caso di esecuzione in locale.
Passaggi successivi
È ora possibile creare l'API e configurare gli endpoint HTTP per l'app per la lista della spesa.