Laravel proporciona varios helpers para asistirte en la generación de URLs para tu aplicación. Éstos son útiles principalmente al momento de construir enlaces en tus plantillas y respuestas de API, o al momento de generar respuestas redireccionadas a otra parte de tu aplicación.
Fundamentos
Generando URLs básicas
El helper url puede ser usado para generar URLs arbitrarias en tu aplicación. La URL generada utilizará automáticamente el esquema (HTTP o HTTPS) y el host de la solicitud actual:
Para buscar más información sobre ¿Cómo escribir plantillas de Blade? Revisa la documentación de Blade completa para comenzar.
Las vistas contienen el HTML servido por tu aplicación y separan la lógica de tu controlador/aplicación de la lógica de presentación. Las vistas son almacenadas en el directorio resources/views. Una vista sencilla podría lucir de esta forma:
Ya que esta vista es almacenada en resources/views/greeting.blade.php, podemos devolverla usando el helper global view, de la siguiente forma:
Route::get('/', function () {
return view('greeting', ['name' => 'James']);
});
Como puedes ver, el primer argumento pasado al helper view corresponde al nombre del archivo de la vista en el directorio resources/views. El segundo argumento es un arreglo de datos que debería estar disponible para la vista. En este caso, estamos pasando la variable name, la cual es mostrada en la vista usando la sintaxis de Blade.
Las vistas también pueden estar anidadas dentro de sub-directorios del directorio resources/views. La notación de «punto» puede ser usada para referenciar vistas anidadas. Por ejemplo, si tu vista está almacenada en resources/views/admin/profile.blade.php, puedes hacer referencia a ella de la siguiente forma:
return view('admin.profile', $data);
Los nombres de directorio de vista no deberían contener el carácter ..
Determinando si una vista existe
Si necesitas determinar si una vista existe, puedes usar la clase facade View. El método exists devolverá true si la vista existe:
use Illuminate\Support\Facades\View;
if (View::exists('emails.customer')) {
//
}
Creando la primera vista disponible
Usando el método first, puedes crear la primera vista que existe en un arreglo de vistas dado. Esto es útil si tu aplicación o paquete permite que las vistas sean personalizadas o sobrescritas:
También puedes ejecutar este método por medio de la clase facadeView:
use Illuminate\Support\Facades\View;
return View::first(['custom.admin', 'admin'], $data);
Pasando datos a las vistas
Como viste en los ejemplos previos, puedes pasar un arreglo de datos a las vistas:
return view('greetings', ['name' => 'Victoria']);
Al momento de pasar información de esta manera, los datos deberían ser un arreglo con pares clave / valor. Dentro de tu vista, entonces puedes acceder a cada valor usando su clave correspondiente, tal como <?php echo $key; ?>. Como una alternativa a pasar un arreglo completo de datos a la función helper view, puedes usar el método with para agregar partes individuales de datos a la vista:
Ocasionalmente, puedes necesitar compartir una parte de los datos con todas las vistas que son renderizadas por tu aplicación. Puedes hacer eso usando el método share de la clase facade View. Típicamente, deberías colocar las ejecuciones a share dentro del método boot de un proveedor de servicio. Eres libre de agregarlos al AppServiceProvider o generar un proveedor de servicio diferente para alojarlos:
<?php
namespace App\Providers;
use Illuminate\Support\Facades\View;
class AppServiceProvider extends ServiceProvider
{
/**
* Register any application services.
*
* @return void
*/
public function register()
{
//
}
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
View::share('key', 'value');
}
}
View Composers
Los view composers son funciones de retorno (callbacks) o métodos de clase que son ejecutados cuando una vista es renderizada. Si tienes datos que quieres que estén enlazados a una vista cada vez que la vista es renderizada, un view composer puede ayudarte a organizar esa lógica dentro de una sola ubicación.
Para este ejemplo, vamos a registrar los View Composers dentro de un proveedor de servicio. Usaremos la clase facade View para acceder a la implementación de la interfaz Illuminate\Contracts\View\Factory subyacente. Recuerda, Laravel no incluye un directorio predeterminado para los View Composers. Eres libre de organizarlos del modo que desees. Por ejemplo, podrías crear un directorio app/Http/View/Composers:
<?php
namespace App\Providers;
use Illuminate\Support\Facades\View;
use Illuminate\Support\ServiceProvider;
class ViewServiceProvider extends ServiceProvider
{
/**
* Register any application services.
*
* @return void
*/
public function register()
{
//
}
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
// Using class based composers...
View::composer(
'profile', 'App\Http\View\Composers\ProfileComposer'
);
// Using Closure based composers...
View::composer('dashboard', function ($view) {
//
});
}
}
Recuerda, si creas un nuevo proveedor de servicio para contener tus registros de View Composers, necesitarás agregar el proveedor de servicio al arreglo providers en el archivo de configuración config/app.php.
Ahora que hemos registrado el composer, el método ProfileComposer@compose será ejecutado cada vez que la vista profile esté siendo renderizada. Así que, vamos a definir la clase composer:
<?php
namespace App\Http\View\Composers;
use App\Repositories\UserRepository;
use Illuminate\View\View;
class ProfileComposer
{
/**
* The user repository implementation.
*
* @var UserRepository
*/
protected $users;
/**
* Create a new profile composer.
*
* @param UserRepository $users
* @return void
*/
public function __construct(UserRepository $users)
{
// Dependencies automatically resolved by service container...
$this->users = $users;
}
/**
* Bind data to the view.
*
* @param View $view
* @return void
*/
public function compose(View $view)
{
$view->with('count', $this->users->count());
}
}
Justo antes de que la vista sea renderizada, el método compose del composer es ejecutado con la instancia Illuminate\View\View. Puedes usar el método with para enlazar datos a la vista.
Todos los View Composers son resueltos por medio del contenedor de servicio, de modo que puedas colocar la referencia a cualquier dependencia que necesites dentro del constructor de un composer.
Adjuntando un composer a múltiples vistas
Puedes adjuntar un View Composer a múltiples vistas de una vez al pasar un arreglo de vistas como primer argumento del método composer:
El método composer también acepta el carácter * como un comodín, permitiendo que adjuntes un composer a todas las vistas:
View::composer('*', function ($view) {
//
});
View Creators
Los View Creators (creadores de vistas) son muy similares a los View Composers; sin embargo, son ejecutados inmediatamente después de que la vista sea instanciada en lugar de esperar hasta que la vista sea renderizada. Para registrar un View Creator, usa el método creator:
Todas las rutas y controladores deberían devolver una respuesta para ser enviada de regreso al navegador del usuario. Laravel proporciona diferentes formas de devolver respuestas. La respuesta más básica es devolver una cadena desde una ruta o controlador. El framework convertirá la cadena en una respuesta HTTP completa:
Route::get('/', function () {
return 'Hello World';
});
Además de devolver cadenas desde tus rutas y controladores, también puedes devolver arreglos. El framework convertirá automáticamente el arreglo en una respuesta JSON:
Route::get('/', function () {
return [1, 2, 3];
});
¿Sabías que también puedes devolver colecciones de Eloquent desde tus rutas o controladores? Estas serán convertidas automáticamente a JSON. ¡Inténtalo!
Objetos de respuesta
Típicamente, no sólo estarás devolviendo cadenas básicas o arreglos desde tus acciones de ruta. Además, estarás devolviendo instancias Illuminate\Http\Response completas o vistas.
Devolver una instancia Response completa te permite personalizar el código de estado y los encabezados HTTP de la respuesta. Una instancia Response hereda desde la clase Symfony\Component\HttpFoundation\Response, la cual proporciona una variedad de métodos para construir respuestas HTTP:
Ten en cuenta que la mayoría de los métodos de respuestas son encadenables, permitiendo la construcción fluida de instancias de respuesta. Por ejemplo, puedes usar el método header para agregar una serie de encabezados para la respuesta antes de enviarla de regreso al usuario:
Laravel incluye un middleware cache.headers, el cual puede ser usado para rápidamente establecer el encabezado Cache-Control para un grupo de rutas. Si etag está especificado en la lista de directivas, un hash MD5 del contenido de la respuesta será automáticamente establecido como identificador del ETag:
Route::middleware('cache.headers:public;max_age=2628000;etag')->group(function () {
Route::get('privacy', function () {
// ...
});
Route::get('terms', function () {
// ...
});
});
Adjuntando cookies a las respuestas
El método cookie en las instancias de respuesta permite que adjuntes fácilmente cookies a la respuesta. Por ejemplo, puedes usar el método cookie para generar una cookie y adjuntarla fluidamente a la instancia de respuesta, de la siguiente manera:
El método cookie también acepta unos cuantos argumentos los cuales son usados con menos frecuencia. Generalmente, estos argumentos tienen el mismo propósito y significado que los argumentos que serán dados al método nativo de PHP setcookie:
Alternativamente, puedes usar la clase facade Cookie para agregar cookies a la cola y adjuntarlas a la respuesta saliente de tu aplicación. El método queue acepta una instancia Cookie o los argumentos que se necesitan para crear una instancia Cookie. Estas cookies serán adjuntadas a la respuesta saliente antes de que sea enviada al navegador:
De forma predeterminada, todos los cookies generados por Laravel son encriptados y firmados de modo que no puedan ser modificados o leídos por el cliente. Si prefieres deshabilitar la encriptación para un subconjunto de cookies generados por tu aplicación, puedes usar la propiedad $except del middleware App\Http\Middleware\EncryptCookies, el cual es localizado en el directorio app/Http/Middleware:
/**
* The names of the cookies that should not be encrypted.
*
* @var array
*/
protected $except = [
'cookie_name',
];
Redirecciones
Las respuestas redireccionadas son instancias de la clase Illuminate\Http\RedirectResponse y contienen los encabezados apropiados que se necesitan para redireccionar al usuario a otra URL. Hay varias formas de generar una instancia RedirectResponse. El método más simple es usar el helper global redirect:
Route::get('dashboard', function () {
return redirect('home/dashboard');
});
Algunas veces podrás querer redireccionar al usuario a su página previa, tal como cuando un formulario enviado no es válido. Puedes hacer eso usando la función helper global back. Ya que esta característica utiliza la sesión, asegúrate de que la ruta llamando a la función back está usando el grupo de middleware web o tiene todos los middleware de sesión aplicados:
Route::post('user/profile', function () {
// Validate the request...
return back()->withInput();
});
Para obtener una instancia de la solicitud HTTP actual por medio de una inyección de dependencia, deberías poner la referencia de la clase Illuminate\Http\Request en tu método de controlador. La instancia de la solicitud entrante automáticamente será inyectada por el contenedor de servicio:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class UserController extends Controller
{
/**
* Store a new user.
*
* @param Request $request
* @return Response
*/
public function store(Request $request)
{
$name = $request->input('name');
//
}
}
Inyección de dependencias y parámetros de rutas
Si tu método de controlador también está esperando la entrada de un parámetro de ruta deberías listar tus parámetros de ruta después de tus otras dependencias. Por ejemplo, si tu ruta es definida como sigue:
Route::put('user/{id}', 'UserController@update');
Todavía puedes poner la referencia de la clase Illuminate\Http\Request y acceder a tu parámetro de ruta id al definir tu método de controlador como sigue:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class UserController extends Controller
{
/**
* Update the specified user.
*
* @param Request $request
* @param string $id
* @return Response
*/
public function update(Request $request, $id)
{
//
}
}
Accediendo la solicitud a través de closures de rutas
También puedes poner la referencia de la clase Illuminate\Http\Request en una Closure de ruta. El contenedor de servicio automáticamente inyectará la solicitud entrante dentro de la Closure que es ejecutada:
use Illuminate\Http\Request;
Route::get('/', function (Request $request) {
//
});
En lugar de definir toda la lógica de manejo de solicitud como Closure en archivos de ruta, puedes desear organizar este comportamiento usando clases Controller. Los controladores pueden agrupar la lógica de manejo de solicitud relacionada dentro de una sola clase. Los controladores son almacenados en el directorio app/Http/Controllers.
Laravel hace que sea fácil proteger tu aplicación de ataques de tipo cross-site request forgery (CSRF). Los ataques de tipo CSRF son un tipo de explotación de vulnerabilidad malicioso por el cual comandos no autorizados son ejecutados en nombre de un usuario autenticado.
Laravel genera automáticamente un «token» CSRF para cada sesión de usuario activa manejada por la aplicación. Este token es usado para verificar que el usuario autenticado es quien en realidad está haciendo la petición a la aplicación.
En cualquier momento que definas un formulario HTML en tu aplicación, debes incluir un campo de token CSRF oculto en el formulario para que el middleware de protección CSRF pueda validar la solicitud. Puedes usar la directiva de Blade @csrf para generar el campo de token:
El middlewareVerifyCsrfToken, el cual es incluido en el grupo de middleware web, verificará automáticamente que el token en el campo de la solicitud coincida con el almacenado en la sesión.
Tokens CSRF & JavaScript
Cuando se crean aplicaciones controladas por JavaScript, es conveniente hacer que tu librería HTTP de JavaScript agregue automáticamente el token CSRF a cada petición saliente. Por defecto, la librería HTTP Axios proporcionada en el archivo resources/js/bootstrap.js automáticamente envía un header X-XSRF-TOKEN usando el valor de la cookie encriptada XSRF-TOKEN. Si no estás usando esta librería, necesitarás configurar de forma manual este comportamiento en tus aplicaciones.
Excluyendo las URIs de la protección CSRF
Algunas veces puedes desear excluir un conjunto de URIs de la protección CSRF. Por ejemplo, si estás usando Stripe para procesar pagos y estás utilizando su sistema webhook, necesitarás excluir tu ruta de manejador webhook de Stripe de la protección CSRF ya que Stripe no sabrá que token CSRF enviar a sus rutas.
Típicamente, deberías colocar este tipo de rutas fuera del grupo de middleware web que el RouteServiceProvider aplica a todas las rutas en el archivo routes/web.php. Sin embargo, también puedes excluir las rutas al añadir sus URIs a la propiedad except del middleware VerifyCsrfToken:
<?php
namespace App\Http\Middleware;
use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;
class VerifyCsrfToken extends Middleware
{
/**
* The URIs that should be excluded from CSRF verification.
*
* @var array
*/
protected $except = [
'stripe/*',
'http://example.com/foo/bar',
'http://example.com/foo/*',
];
}
El middleware CSRF está deshabilitado automáticamente al ejecutar pruebas.
X-CSRF-TOKEN
Además de comprobar el token CSRF como parámetro POST, el middleware VerifyCsrfToken también comprobará el encabezado de solicitud X-CSRF-TOKEN. Podrías, por ejemplo, almacenar el token en una etiqueta meta de HTML:
Entonces, una vez que has creado la etiqueta meta, puedes instruir una biblioteca como jQuery para añadir automáticamente el token a todos los encabezados de las peticiones. Esto proporciona protección CSRF fácil y conveniente para tus aplicaciones basadas en AJAX.
Laravel almacena el token CSRF actual en una cookie XSRF-TOKEN encriptada que es incluida con cada respuesta generada por el framework. Puedes usar el valor del cookie para establecer el encabezado de la solicitud X-XSRF-TOKEN.
Esta cookie primeramente es enviada por conveniencia ya que algunos frameworks JavaScript y librerías, como Angular y Axios, colocan automáticamente su valor en el encabezado X-XSRF-TOKEN en las solicitudes de mismo origen.
Por defecto, el archivo resources/js/bootstrap.js incluye la librería HTTP Axios que enviará automáticamente esto por ti.
Los middleware proporcionan un mecanismo conveniente para filtrar solicitudes HTTP entrantes a tu aplicación. Por ejemplo, Laravel incluye un middleware que verifica si el usuario de tu aplicación está autenticado. Si el usuario no está autenticado, el middleware redireccionará al usuario a la pantalla de inicio de sesión. Sin embargo, si el usuario es autenticado, el middleware permitirá que la solicitud proceda dentro de la aplicación.
Los middleware adicionales pueden ser escritos para realizar una variedad de tareas además de autenticar. Un middleware de CORS podría ser responsable de agregar los encabezados apropiados para todas las respuestas que va dejando tu aplicación. Un middleware de registro podría registrar todas las solicitudes entrantes en tu aplicación.
Hay varios middleware incluidos en el framework Laravel, incluyendo middleware para autenticación y protección CSRF. Todos esos middleware están localizados en el directorio app/Http/Middleware.
Definiendo un middleware
Para crear un nuevo middleware, usa el comando de Artisan: make:middleware:
php artisan make:middleware CheckAge
Este comando ubicará una nueva clase CheckAge dentro de tu directorio app/Http/Middleware. En este middleware, nosotros solo permitiremos el acceso a la ruta si la age (edad) suministrada es mayor que 200. De otra forma, redireccionaremos a los usuarios de vuelta a la URL home:
<?php
namespace App\Http\Middleware;
use Closure;
class CheckAge
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
if ($request->age <= 200) {
return redirect('home');
}
return $next($request);
}
}
Como puedes ver, si la age (edad) dada es menor o igual a 200, el middleware retornará una redirección HTTP al cliente; de otra forma, la solicitud pasará más adentro de la aplicación. Para pasar la solicitud más profundo dentro de la aplicación (permitiendo al middleware «pasar») llama al callback $next con el $request.
Es mejor visualizar el middleware como una serie de «capas» que deben pasar las solicitudes HTTP antes de que lleguen a tu aplicación. Cada capa puede examinar la solicitud e incluso rechazarla por completo.
Todos los middleware son resueltos a través del contenedor de servicio, de esta forma, puedes declarar el tipo de cualquier dependencia que necesites dentro del constructor del middleware.
Las rutas de Laravel más básicas aceptan una URI y una Closure, proporcionando un método muy fácil y expresivo de definición de rutas:
Route::get('foo', function () {
return 'Hello World';
});
Los archivos de ruta predeterminados
Todas las rutas de Laravel están definidas en tus archivos de ruta, los cuales están localizados en el directorio routes. Estos archivos son cargados automáticamente por el framework. El archivo routes/web.php define rutas que son para tu interfaz web. Estas rutas son asignadas al grupo de middleware web, el cual proporciona características como estado de sesión y protección CSRF. Las rutas en routes/api.php son independientes de estado y son asignadas al grupo de middleware api.
Para las principales aplicaciones, empezarás definiendo rutas en tu archivo routes/web.php. Las rutas definidas en routes/web.php pueden ser accedidas colocando la URL de la ruta definida en tu navegador. Por ejemplo, puede acceder a la siguiente ruta al navegar a http://your-app.test/user en tu navegador:
Route::get('/user', 'UserController@index');
Las rutas definidas en el archivo routes/api.php son agrupadas dentro de un grupo de ruta por el RouteServiceProvider. Dentro de este grupo, el prefijo de URI /api es aplicado automáticamente de modo que no es necesario aplicarlo manualmente en todas las rutas en el archivo. Puedes modificar el prefijo y otras opciones de grupos de ruta al modificar tu clase RouteServiceProvider.
Métodos disponibles del enrutador
El enrutador permite que registres rutas que responden a cualquier verbo HTTP:
Algunas veces puede que necesites registrar una ruta que responda a verbos HTTP múltiples. Puedes hacerlo usando el método match. También, puedes incluso registrar una ruta que responda a todos los verbos HTTP usando el método any:
Route::match(['get', 'post'], '/', function () {
//
});
Route::any('/', function () {
//
});
Protección CSRF
Cualquiera de los formularios HTML que apunten a rutas POST, PUT, o DELETE que sean definidas en el archivo de rutas web deberían incluir un campo de token CSRF. De otra manera, la solicitud será rechazada. Puedes leer más sobre protección CSRF en la documentación de CSRF:
Los Contratos de Laravel son un conjunto de interfaces que definen los servicios principales proporcionados por el framework. Por ejemplo, un contrato Illuminate\Contracts\Queue\Queue define los métodos necesarios para las colas de trabajo, mientras que el contrato Illuminate\Contracts\Mail\Mailer define los métodos necesarios para el envío de correos electrónicos.
Cada contrato tiene una implementación correspondiente provista por el framework. Por ejemplo, Laravel proporciona una implementación de cola con una variedad de conductores (drivers), y una implementación de envío de correo electrónico que funciona con SwiftMailer.
Todos los contratos de Laravel residen en su repositorio de GitHub propio. Esto proporciona un punto de referencia rápido para todos los contratos disponibles, así como un paquete único y desacoplado que puede ser utilizado por los desarrolladores de paquetes.
Las Facades proveen una interfaz «estática» a las clases disponibles en el contenedor de servicios de la aplicación. Laravel viene con numerosas facades, las cuales brindan acceso a casi todas las características de Laravel. Las facades de Laravel sirven como «proxies estáticas» a las clases subyacentes en el contenedor de servicios, brindando el beneficio de una sintaxis tersa y expresiva, manteniendo mayor verificabilidad y flexibilidad que los métodos estáticos tradicionales.
Todas las facades de Laravel se definen en el namespace Illuminate\Support\Facades. Entonces, podemos fácilmente acceder a una facade de esta forma:
use Illuminate\Support\Facades\Cache;
Route::get('/cache', function () {
return Cache::get('key');
});
A través de la documentación de Laravel, muchos de los ejemplos usarán facades para demostrar varias características del framework.
Cuándo usar facades
Las Facades tienen múltiples beneficios. Brindan una sintaxis tersa y memorizable que permite utilizar las características de Laravel sin tener que recordar nombres de clase largos que deben ser inyectados o configurados manualmente. Además, debido a su uso único de los métodos dinámicos PHP, son fáciles de probar.
Sin embargo, deben guardarse ciertas precauciones al hacer uso de facades. El peligro principal de las facades es la corrupción de alcance de clases. Como las facades son tan fáciles de usar y no requieren inyección, puede resultar fácil dejar que tus clases sigan creciendo y usar muchas facades en una sola clase. Usando inyección de dependencias, este potencial es mitigado por la retroalimentación visual que un constructor grande te da cuando tu clase está creciendo demasiado. Entonces, al usar facades, pon especial atención al tamaño de tu clase para que su alcance de responsabilidades permanezca limitado.
Cuando se construye un paquete de terceros que interactúa con Laravel, es mejor inyectar contratos de Laravel en vez de usar facades. Como los paquetes son construidos fuera de Laravel, no tendrás acceso a las funciones (helpers) de testing para facades de Laravel.
Styde usa cookies para guardar tus preferencias y para seguimiento anónimo AceptarLeer más
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.