> ## Documentation Index > Fetch the complete documentation index at: https://kawax.biz/llms.txt > Use this file to discover all available pages before exploring further. # Ciclo di vita della richiesta > Come vengono elaborate le richieste HTTP e i comandi Console in un'applicazione Laravel. ## Introduzione Quando usi uno strumento "nel mondo reale", capire come funziona ti permette di usarlo con maggiore sicurezza. Lo stesso vale per lo sviluppo applicativo. Comprendere come funzionano gli strumenti di sviluppo ti permette di costruire applicazioni con maggiore comfort e sicurezza. Questa pagina fornisce una panoramica ad alto livello di come funziona il framework Laravel. Comprendendo bene tutto il framework, nulla sembrerà più "magia" e la tua fiducia nel costruire applicazioni aumenterà. ## Ciclo di vita di una richiesta HTTP ### Panoramica generale ```mermaid theme={null} flowchart TD A[Browser/richiesta HTTP] --> B[public/index.php] B --> C[Caricamento dell'autoloader di Composer] C --> D[bootstrap/app.php] D --> E[Creazione dell'istanza dell'applicazione
service container] E --> F[HTTP kernel] F --> G[Esecuzione dei bootstrapper
error handling/logging/rilevamento dell'ambiente] G --> H[Registrazione e avvio dei service provider
register → boot] H --> I[Passaggio nello stack dei middleware] I --> J[Routing] J --> K[Esecuzione del controller/closure] K --> L[Generazione della risposta] L --> I I --> M[Invio della risposta al browser] ``` ### I primi passi Il punto di ingresso di tutte le richieste a un'applicazione Laravel è il file `public/index.php`. Tutte le richieste vengono inoltrate a questo file grazie alla configurazione del web server (Apache / Nginx). Il file `index.php` in sé contiene pochissimo codice: è il punto di partenza per caricare il resto del framework. Il file `index.php` carica le definizioni dell'autoloader generato da Composer e ottiene l'istanza dell'applicazione Laravel da `bootstrap/app.php`. La prima cosa che Laravel fa è creare l'istanza dell'applicazione/[service container](/it/service-container). ### HTTP kernel Successivamente, la richiesta ricevuta viene inviata all'HTTP kernel (`Illuminate\Foundation\Http\Kernel`). Viene elaborata tramite il metodo `handleRequest` dell'istanza dell'applicazione. L'HTTP kernel definisce un array di **bootstrapper** che vengono eseguiti prima che la richiesta venga elaborata. Questi bootstrapper eseguono le seguenti operazioni. * Configurazione della gestione degli errori * Configurazione del logging * [Rilevamento dell'ambiente dell'applicazione](/it/installation) * Altri task necessari prima dell'elaborazione della richiesta L'HTTP kernel ha inoltre la responsabilità di far passare la richiesta attraverso lo stack dei middleware dell'applicazione. Questi middleware gestiscono la lettura/scrittura della [sessione HTTP](/it/session), il controllo se l'applicazione è in modalità manutenzione, la [verifica del token CSRF](/it/middleware) e altro. La firma del metodo `handle` dell'HTTP kernel è semplice: riceve una `Request` e restituisce una `Response`. Puoi pensare al kernel come a una grande scatola nera che rappresenta l'intera applicazione. Gli passi una richiesta HTTP e ricevi una risposta HTTP. ### Service provider Una delle operazioni più importanti del bootstrapping del kernel è il caricamento dei [service provider](/it/service-providers) dell'applicazione. I service provider hanno la responsabilità di avviare i vari componenti del framework, come database, code, validazione e routing. Laravel itera sulla lista dei provider e istanzia ciascuno. Dopo l'istanziazione viene chiamato il metodo `register` di ciascun provider. Poi, una volta registrati tutti i provider, viene chiamato il metodo `boot` di ciascuno. In questo modo, al momento dell'esecuzione del metodo `boot`, i service provider hanno la garanzia che tutte le associazioni al container siano state registrate e disponibili. I service provider definiti dall'utente o di terze parti vengono registrati nel file `bootstrap/providers.php`. ### Routing Dopo che l'applicazione è stata avviata e tutti i service provider registrati, la `Request` viene passata al router per il dispatch. Il router smista la richiesta a una route o a un controller ed esegue anche i middleware specifici della route. I middleware forniscono un comodo meccanismo per filtrare o ispezionare le richieste HTTP in ingresso all'applicazione. Ad esempio, Laravel include un middleware che verifica se l'utente è autenticato. Se non lo è, il middleware effettua il redirect alla schermata di login; se lo è, la richiesta prosegue verso l'interno dell'applicazione. Una volta che la richiesta ha superato tutti i middleware assegnati alla route corrispondente, viene eseguito il metodo della route o del controller e viene restituita una risposta. ### Restituzione della risposta Quando il metodo della route o del controller restituisce una risposta, questa torna verso l'esterno attraverso i middleware della route, dando alla applicazione la possibilità di modificare o ispezionare la risposta prima dell'invio. Infine, quando la risposta attraversa i middleware, il metodo `handle` dell'HTTP kernel restituisce l'oggetto risposta a `handleRequest` dell'istanza dell'applicazione, che chiama il metodo `send` della risposta. Il metodo `send` invia il contenuto della risposta al browser dell'utente. Con questo si conclude l'intero ciclo di vita di una richiesta Laravel. ## Ciclo di vita di un comando Console ### Panoramica generale ```mermaid theme={null} flowchart TD A[Esecuzione del comando artisan] --> B[artisan] B --> C[Caricamento dell'autoloader di Composer] C --> D[bootstrap/app.php] D --> E[Creazione dell'istanza dell'applicazione
service container] E --> F[Console kernel
handleCommand] F --> G[Registrazione e avvio dei service provider
register → boot] G --> H[Caricamento dei comandi
app/Console/Commands] H --> I[Esecuzione del comando] I --> J[Restituzione del codice di uscita] ``` ### Punto di ingresso artisan Il punto di ingresso dei comandi console è il file `artisan` nella root del progetto. Come per le richieste HTTP, vengono create l'autoloader di Composer e l'istanza dell'applicazione Laravel. Poi, il controllo passa al console kernel tramite il metodo `handleCommand` dell'istanza dell'applicazione. ### Console kernel ed esecuzione del comando Il console kernel, come l'HTTP kernel, carica i service provider. Dopo che tutti i provider sono stati registrati e avviati, vengono caricati i comandi presenti nella directory `app/Console/Commands` e viene eseguito il comando specificato. ```shell theme={null} php artisan make:controller UserController ``` Questo comando viene elaborato così: 1. Il file `artisan` carica l'autoloader di Composer 2. Viene creata l'istanza dell'applicazione da `bootstrap/app.php` 3. Il console kernel carica i service provider 4. Il comando `make:controller` viene cercato ed eseguito 5. Viene restituito il codice di uscita ## Concentrati sui service provider I service provider sono la vera chiave del bootstrapping di un'applicazione Laravel. Viene creata l'istanza dell'applicazione, vengono registrati i service provider e la richiesta viene passata all'applicazione avviata. Tutto qui. Capire bene come un'applicazione Laravel viene costruita e avviata tramite i service provider è di grande valore. I service provider definiti dall'utente si trovano nella directory `app/Providers` dell'applicazione. Di default `AppServiceProvider` è quasi vuoto. Questo provider è il posto ideale per aggiungere bootstrapping specifici dell'applicazione e binding del service container. Nelle applicazioni di grandi dimensioni è consigliato creare più service provider, ciascuno dedicato al bootstrapping di un servizio specifico. ### Differenza tra register e boot I service provider hanno due metodi principali. | Metodo | Momento di esecuzione | Uso | | ---------- | ---------------------------------------------------- | ----------------------------------------------------------------------- | | `register` | Chiamato dopo l'istanziazione di tutti i provider | Solo registrazione dei binding nel service container | | `boot` | Chiamato dopo che tutti i `register` sono completati | Registrazione di view composer, event listener e altre inizializzazioni | Non registrare listener di eventi, route o altre funzionalità nel metodo `register`. Potresti accidentalmente usare servizi forniti da provider non ancora caricati. ## Prossimi passi Comprendi il meccanismo della dependency injection e del service container. Impara come avviare l'applicazione usando i service provider. ## Related topics - [Service provider](/it/service-providers.md) - [⚡Introduzione a Livewire 4 — creare UI reattive senza JavaScript](/it/blog/livewire-introduction.md) - [Eventi del ciclo di vita della sessione](/it/packages/laravel-copilot-sdk/session-lifecycle-event.md) - [Introduzione a Eloquent](/it/eloquent.md) - [Eloquent Bootable Traits](/it/advanced/eloquent-bootable-traits.md)