Planificación de rutas REST en Laravel

Curso de Estándares y Buenas Prácticas para API REST con Laravel

Contenido del curso

Buenas prácticas a nivel general

Creación del proyecto

Planificación y mantenimiento

Funciones de seguridad

API Testing

API Breaking Changes

Conclusiones

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:08

Planificación de rutas REST en Laravel

Curso de Estándares y Buenas Prácticas para API REST con Laravel

Clase 8 de 29

Clase 8 / 29

Recursos

Antes de escribir código, conviene planificar tu API y definir su alcance. En Laravel, esto significa decidir qué rutas existirán, qué verbos HTTP usarás y cómo aprovechar las convenciones del framework para escribir menos y comunicar más. Si te interesa construir APIs limpias siguiendo estándares REST, esta guía te muestra el flujo desde la definición hasta el uso de resource routes.

¿Por qué planificar el alcance antes de programar?

La planificación es el paso que todo programador debería dar primero. Redactar específicamente qué quieres alcanzar te ahorra reescribir código y te ayuda a pensar en términos de funcionalidades, no de líneas sueltas.

En el caso de una API para recetas, ya existen dos funciones, pero faltan tres para completar las cinco operaciones posibles. Ese inventario inicial es el que define el trabajo real.

¿Cuántas rutas necesita una API REST básica? Cinco: obtener todas, crear, obtener una, actualizar y eliminar. Las vistas de creación y edición no entran porque viven en la aplicación cliente, no en el servidor [3:36].

¿Qué verbos HTTP usar para cada acción de la API?

La convención REST asigna un verbo a cada intención, y ese verbo habla por sí solo dentro del código. No necesitas comentarios extra cuando respetas el estándar.

GET para obtener recetas, ya sea el listado completo o una sola.
POST para crear una nueva receta.
PUT para actualizar una receta existente.
DELETE para eliminar una receta.

Cada ruta apunta directamente a un método del controlador, lo que mantiene la separación entre el enrutado y la lógica.

¿Cómo se escriben las rutas manualmente en api.php?

Dentro del archivo routes/api.php defines cada endpoint con su verbo y su método del controlador. La estructura queda así:

php Route::get('/recetas', [RecetaController::class, 'index']); Route::post('/recetas', [RecetaController::class, 'store']); Route::get('/recetas/{id}', [RecetaController::class, 'show']); Route::put('/recetas/{id}', [RecetaController::class, 'update']); Route::delete('/recetas/{id}', [RecetaController::class, 'destroy']);

Los nombres de los métodos (index, store, show, update, destroy) no son arbitrarios: son la convención que Laravel reconoce automáticamente.

¿Cómo simplificar las rutas con Route::apiResource?

Cuando trabajas con el estándar, Laravel premia esa decisión. En lugar de cinco líneas, puedes declarar todas las rutas en una sola usando apiResource.

php Route::apiResource('recetas', RecetaController::class);

Esta única línea genera exactamente los mismos cinco endpoints. Menos código, mismo resultado, y queda explícito que estás trabajando con un recurso REST.

¿Qué hace apiResource en Laravel? Genera automáticamente las rutas index, store, show, update y destroy para una API, omitiendo las vistas create y edit que sí incluye Route::resource [4:46].

¿Cómo verificar las rutas generadas con Artisan?

Laravel incluye un comando para listar las rutas activas y confirmar que la planificación se tradujo bien al código:

bash php artisan route:list --path=api

El resultado imprime los cinco métodos en orden: index, store, show, update y destroy. Por eso conviene declarar los métodos del controlador en ese mismo orden, así lees el código con la misma cadencia con la que el sistema lo reporta [3:01].

¿Por qué una API tiene 5 métodos y no 7?

Un módulo administrativo tradicional suele tener siete funciones porque incluye la vista para mostrar el formulario de creación y la vista para mostrar el formulario de edición, además de las acciones que persisten datos.

En una API te quedas con cinco porque las vistas viven en el cliente. El servidor solo expone los endpoints que reciben datos, los procesan y responden. Esa diferencia es la que hace que apiResource exista como variante de resource.

Trabajar con estándares no es una formalidad: es lo que te permite aprovechar herramientas profesionales como Laravel para escribir menos código y comunicar mejor tu intención. Si usas otro framework o lenguaje, cuéntame en los comentarios cómo logras un resultado equivalente.

Buenas prácticas a nivel general

Buenas prácticas para diseñar una API REST

¿Qué son los HTTP Status Codes?

Qué hace cada método HTTP

Creación del proyecto

Migrações e relações de dados em Laravel

Factories y seeders para poblar tu API en Laravel

Consultas API con Laravel: Rutas y Controladores

Consultas con relaciones en Laravel API

Planificación y mantenimiento

Planificación de rutas REST en Laravel

Recursos y colecciones en Laravel API

Recursos anidados en Laravel API

Cómo reducir 932 consultas con Telescope

CRUD de Recetas con Laravel y Symfony en Visual Studio Code

Validación de Datos en Aplicaciones Web con Laravel

Funciones de seguridad

Autenticación vs. autorización

Proteger rutas de API con Sanctum

Ruta de login y tokens con Sanctum

Corrección de bugs de seguridad en aplicaciones web

Políticas de acceso en Laravel con Artisan

Upload e validação de imagens em Laravel

Qué es autenticación en la web

API Testing

Automatiza pruebas de API en Laravel

Testing de Módulos Administrativos en Visual Studio Code

Testing de recetas con PHP Artisan

Pruebas de Creación de Datos en Aplicaciones Web

Test de actualización de recetas en Laravel

API Breaking Changes

Versionado de API en Laravel con v1 y v2

Desarrollo de API con TDD: Implementación de Versión 2

Conclusiones

Desarrollo de API RESTful con Laravel: Buenas Prácticas y Seguridad

Buenas prácticas finales para tu API en Laravel

Planificación de rutas REST en Laravel