> ## 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 de vida de la solicitud > Explicamos cómo se procesan en una aplicación Laravel las solicitudes HTTP y los comandos de consola. ## Introducción Cuando usas una herramienta en el "mundo real", entender cómo funciona te permite utilizarla con más confianza. En el desarrollo de aplicaciones ocurre lo mismo. Entender cómo funcionan tus herramientas de desarrollo te permite construir aplicaciones con más comodidad y seguridad. Esta página ofrece una visión general de alto nivel de cómo funciona el framework Laravel. Al comprender bien el framework, todo dejará de parecerte "magia" y aumentará tu confianza al construir aplicaciones. ## Ciclo de vida de una solicitud HTTP ### Flujo general ```mermaid theme={null} flowchart TD A[Navegador/Solicitud HTTP] --> B[public/index.php] B --> C[Carga del autoloader de Composer] C --> D[bootstrap/app.php] D --> E[Creación de la instancia de la aplicación
Contenedor de servicios] E --> F[Kernel HTTP] F --> G[Ejecución de bootstrappers
Manejo de errores/Logging/Detección de entorno] G --> H[Registro y arranque de service providers
register → boot] H --> I[Paso por la pila de middlewares] I --> J[Enrutamiento] J --> K[Ejecución del controlador/closure] K --> L[Generación de la respuesta] L --> I I --> M[Envío de la respuesta al navegador] ``` ### Los primeros pasos El punto de entrada de todas las solicitudes a una aplicación Laravel es el archivo `public/index.php`. Cualquier solicitud es reenviada a este archivo mediante la configuración del servidor web (Apache / Nginx). El propio `index.php` apenas contiene código: es el punto de partida para cargar el resto del framework. El archivo `index.php` carga la definición del autoloader generada por Composer y obtiene la instancia de la aplicación Laravel desde `bootstrap/app.php`. Lo primero que hace Laravel es crear la instancia de la aplicación / [contenedor de servicios](/es/service-container). ### Kernel HTTP A continuación, la solicitud recibida se envía al Kernel HTTP (`Illuminate\Foundation\Http\Kernel`). El procesamiento se realiza a través del método `handleRequest` de la instancia de la aplicación. El Kernel HTTP define un array de **bootstrappers** que se ejecutan antes de que la solicitud sea atendida. Estos bootstrappers realizan lo siguiente: * Configurar el manejo de errores * Configurar el logging * [Detectar el entorno de la aplicación](/es/installation) * Otras tareas necesarias antes del procesamiento de la solicitud El Kernel HTTP también se encarga de hacer pasar la solicitud por la pila de middlewares de la aplicación. Estos middlewares gestionan la lectura/escritura de la [sesión HTTP](/es/session), verifican si la aplicación está en modo mantenimiento, [validan tokens CSRF](/es/middleware), etc. La firma del método `handle` del Kernel HTTP es sencilla: recibe una `Request` y devuelve una `Response`. Piensa en el kernel como una gran caja negra que representa toda la aplicación. Le pasas una solicitud HTTP y te devuelve una respuesta HTTP. ### Service providers Uno de los procesos más importantes del bootstrapping del kernel es cargar los [service providers](/es/service-providers) de la aplicación. Los service providers son responsables de inicializar los distintos componentes del framework, como la base de datos, las colas, la validación o el enrutamiento. Laravel itera sobre la lista de providers e instancia cada uno. Tras la instanciación, se invoca el método `register` de todos ellos. A continuación, una vez registrados todos, se llama al método `boot` de cada uno. De este modo, cuando se ejecuta el método `boot`, todos los bindings del contenedor ya están registrados y disponibles. Los service providers definidos por el usuario o de terceros se registran en el archivo `bootstrap/providers.php`. ### Enrutamiento Una vez que la aplicación se ha inicializado y todos los service providers están registrados, la `Request` se entrega al enrutador para su despacho. El enrutador despacha la solicitud a una ruta o a un controlador, y ejecuta también los middlewares específicos de la ruta. Los middlewares proporcionan un mecanismo cómodo para filtrar o inspeccionar las solicitudes HTTP que entran en la aplicación. Por ejemplo, Laravel incluye un middleware que comprueba si el usuario está autenticado. Si no lo está, el middleware lo redirige a la pantalla de inicio de sesión. Si lo está, permite que la solicitud continúe hacia el interior de la aplicación. Cuando la solicitud pasa todos los middlewares asociados a la ruta coincidente, se ejecuta la ruta o el método del controlador y se devuelve una respuesta. ### Devolución de la respuesta Cuando la ruta o el método del controlador devuelve una respuesta, esta vuelve a través de los middlewares de la ruta hacia el exterior, dándoles la oportunidad de modificar o inspeccionar la respuesta que enviará la aplicación. Finalmente, cuando la respuesta ha atravesado los middlewares, el método `handle` del Kernel HTTP devuelve el objeto respuesta al método `handleRequest` de la instancia de la aplicación, que llama al método `send` sobre la respuesta devuelta. `send` envía el contenido de la respuesta al navegador web del usuario. Con esto termina el recorrido completo del ciclo de vida de la solicitud en Laravel. ## Ciclo de vida de un comando de consola ### Flujo general ```mermaid theme={null} flowchart TD A[Ejecución del comando artisan] --> B[artisan] B --> C[Carga del autoloader de Composer] C --> D[bootstrap/app.php] D --> E[Creación de la instancia de la aplicación
Contenedor de servicios] E --> F[Kernel de consola
handleCommand] F --> G[Registro y arranque de service providers
register → boot] G --> H[Carga de comandos
app/Console/Commands] H --> I[Ejecución del comando] I --> J[Devolución del código de salida] ``` ### Punto de entrada artisan El punto de entrada de los comandos de consola es el archivo `artisan` en la raíz del proyecto. Al igual que con las solicitudes HTTP, se cargan el autoloader de Composer y la instancia de la aplicación Laravel. Después, el control se pasa al kernel de consola a través del método `handleCommand` de la instancia de la aplicación. ### Kernel de consola y ejecución de comandos El kernel de consola, al igual que el HTTP, carga los service providers. Una vez que todos los providers están registrados e iniciados, se cargan los comandos del directorio `app/Console/Commands` y se ejecuta el comando indicado. ```shell theme={null} php artisan make:controller UserController ``` Este comando se procesa así: 1. El archivo `artisan` carga el autoloader de Composer 2. Se genera la instancia de la aplicación desde `bootstrap/app.php` 3. El kernel de consola carga los service providers 4. Se busca y ejecuta el comando `make:controller` 5. Se devuelve el código de salida ## Céntrate en los service providers Los service providers son la verdadera clave para inicializar una aplicación Laravel. Se crea la instancia de la aplicación, se registran los service providers y la solicitud se entrega a la aplicación ya inicializada. Eso es todo. Comprender bien cómo se construye e inicializa una aplicación Laravel a través de los service providers es muy valioso. Los service providers definidos por el usuario se almacenan en el directorio `app/Providers`. El `AppServiceProvider` por defecto está casi vacío. Este provider es el lugar ideal para añadir el bootstrapping propio de tu aplicación o los bindings del contenedor de servicios. En aplicaciones grandes se recomienda crear varios service providers, cada uno responsable de una porción específica de la inicialización de los servicios que utiliza la aplicación. ### Diferencia entre register y boot Los service providers tienen dos métodos principales. | Método | Momento | Uso | | ---------- | -------------------------------------------------------------- | ------------------------------------------------------------- | | `register` | Se llama en todos los providers tras su instanciación | Solo para registrar bindings en el contenedor de servicios | | `boot` | Se llama tras completarse el `register` de todos los providers | View composers, listeners de eventos y otras inicializaciones | No registres listeners de eventos, rutas ni otras funcionalidades dentro del método `register`. Podrías acabar utilizando por error servicios de providers que aún no se han cargado. ## Próximos pasos Comprende la inyección de dependencias y el funcionamiento del contenedor de servicios. Aprende a usar los service providers para inicializar tu aplicación. ## Related topics - [Service providers](/es/service-providers.md) - [Eventos del ciclo de vida de sesión](/es/packages/laravel-copilot-sdk/session-lifecycle-event.md) - [⚡Introducción a Livewire 4 — Crear UIs reactivas sin JavaScript](/es/blog/livewire-introduction.md) - [Guía de desarrollo de apps con integración de la Engine API - VOICEVOX for Laravel](/es/packages/laravel-voicevox/app-guide.md) - [Introducción a Eloquent](/es/eloquent.md)