Resumen

Convertir un proyecto web en un API es uno de los escenarios más frecuentes en el desarrollo con Laravel. Todo comienza con un sitio que cumple una necesidad puntual y, con el tiempo, requiere exponer información a otros sistemas. Aquí se explica paso a paso cómo sentar las bases de ese proyecto, desde la instalación hasta la configuración de rutas, modelos y datos de prueba.

¿Cómo instalar un proyecto Laravel preparado para evolucionar hacia un API?

El punto de partida es abrir el terminal dentro de Visual Studio Code y ejecutar el comando laravel new api [01:12]. Este comando descarga una copia limpia del framework sin incluir el componente Jetstream, que se instala con el parámetro --jet. Aunque Jetstream facilita la construcción de APIs, el enfoque aquí es instalar cada componente de forma individual para comprender qué herramientas se necesitan realmente.

Una vez concluida la instalación, se genera la estructura de archivos del modelo principal con un solo comando:

bash php artisan make:model Post -c -m -f

  • -c: crea el controlador (PostController).
  • -m: genera la migración de la tabla.
  • -f: produce el factory para datos falsos.

Este comando [02:10] crea tres archivos esenciales que permiten trabajar con el modelo Post, su tabla en base de datos y datos de prueba de forma organizada.

¿Cómo configurar la migración y las relaciones entre tablas?

Dentro del archivo de migración correspondiente a los posts, se definen los campos necesarios [02:55]:

php $table->foreignId('user_id'); $table->string('title'); $table->string('slug')->unique(); $table->text('content');

El campo slug se marca como unique() porque es el identificador que se utiliza para buscar cada post de forma individual. Además, se establece la relación con la tabla de usuarios mediante el método references('id')->on('users') [03:50], lo que garantiza la integridad referencial entre ambas tablas.

¿Cómo generar datos falsos con el factory y el seeder?

El factory de Post se configura con Faker, la librería que Laravel incluye para producir información aleatoria [04:15]:

php 'user_id' => $this->faker->numberBetween(1, 10), 'title' => $this->faker->sentence(), 'slug' => $this->faker->slug(), 'content' => $this->faker->text(1600),

En el seeder se indica que se generen 120 posts asociados a 10 usuarios [05:10]. Luego se conecta la base de datos editando el archivo .env con el nombre api y se crea la base de datos desde el cliente de MySQL.

Para ejecutar todo de una vez se utiliza:

bash php artisan migrate --seed

Este comando crea las tablas y pobla la base de datos con los registros falsos en un solo paso [05:45].

¿Cómo configurar la ruta web y el controlador para mostrar los posts?

Es fundamental distinguir entre el archivo web.php y api.php. Las rutas web corresponden al sitio tradicional, mientras que las rutas API se configurarán después en un archivo separado [06:20].

En web.php se define la ruta principal apuntando directamente al controlador:

php Route::get('/', [\App\Http\Controllers\PostController::class, 'index']);

Dentro de PostController, el método index retorna una vista con los posts paginados y ordenados del más reciente al más antiguo [07:05]:

php public function index() { return view('index', [ 'posts' => Post::latest()->paginate() ]); }

Se importa el modelo Post con use App\Models\Post; para que la consulta funcione correctamente. El método latest() ordena los registros por fecha de creación descendente, y paginate() divide los resultados en páginas automáticamente.

¿Por qué separar la lógica web de la lógica API desde el inicio?

Laravel organiza las rutas en archivos distintos precisamente para este propósito. El archivo web.php maneja las peticiones del navegador con vistas y sesiones, mientras que api.php está diseñado para respuestas en formato JSON sin estado. Separar ambos contextos desde el principio permite que el proyecto crezca sin conflictos cuando llegue el momento de exponer los datos como un API.

Con esta base —modelo, migración, factory, seeder, controlador y ruta— el proyecto queda listo para mostrar información en el navegador y preparado para dar el siguiente paso: construir las rutas y respuestas propias de un API. ¿Ya has trabajado con esta separación en tus proyectos? Comparte tu experiencia en los comentarios.