Actualizar registros en Laravel requiere conectar tres piezas: las rutas, el controlador y la vista. Aprenderás a implementar la operación update usando el método PUT, validar datos antes de tocar la base de datos y completar el ciclo CRUD para gestionar enlaces de forma segura.

¿Cómo se define la ruta de actualización en Laravel?

Todo empieza en el archivo de rutas web. Justo debajo de la ruta de edición, registras una nueva entrada que escuche el método PUT, apunte al controlador correspondiente y ejecute el método update.

php Route::put('/links/{id}', [LinkController::class, 'update']);

Si al probar el navegador te lanza un error tipo "método no soportado", es completamente normal. Hasta ahora tu sistema reconocía GET, POST y DELETE. Con esta línea cierras el ciclo y tu sistema de rutas queda completo: leer, crear, eliminar y actualizar [01:15].

¿Por qué Laravel usa PUT en lugar de POST para actualizar? Porque PUT es el método HTTP semánticamente correcto para modificar recursos existentes. Aunque el navegador solo envía GET y POST, Laravel simula PUT mediante un campo oculto en el formulario.

¿Cómo configurar el formulario para enviar el método PUT?

Aquí está el detalle que muchos pasan por alto. El formulario HTML solo entiende GET y POST de forma nativa, así que necesitas un campo oculto que le diga a Laravel que la intención real es actualizar.

En Blade, basta con agregar la directiva @method('PUT') dentro del formulario. Si inspeccionas el HTML generado, verás que aparece un input oculto con el valor PUT. Sin ese campo, el sistema arroja un error indicando que no puede trabajar con POST en esa ruta [02:30].

¿Qué pasa si olvidas el campo method?

El error que verás no apunta directamente a PUT, sino a POST. Eso despista. La pista es que el sistema de rutas funciona, pero el formulario envía un verbo HTTP que no coincide con la ruta declarada. Agregar @method('PUT') resuelve el conflicto al instante.

¿Cómo se programa el método update en el controlador?

Dentro de App\Http\Controllers\LinkController, justo debajo del método edit, defines el método update siguiendo un orden claro. Primero validas, después consultas y por último actualizas.

• Valida los datos entrantes: el título debe tener mínimo 10 caracteres.
• Crea el objeto que contendrá los errores y datos para reutilizarlo si la validación falla.
• Ejecuta la consulta a base de datos buscando el enlace por su ID.
• Aplica la actualización solo si la validación pasó.
• Si algo falla, regresa a la vista de edición con los errores [03:45].

La lógica se ve así en pseudocódigo:

php public function update(Request $request, $id) { $request->validate([ 'title' => 'required|min:10' ]);

$link = Link::findOrFail($id);
$link->update($request->all());

return redirect('/links');

}

El autocompletado del editor a veces sugiere un mínimo de 3 caracteres por defecto. Cámbialo a 10 para forzar títulos descriptivos [04:10].

¿Por qué la búsqueda del registro debe ir por GET y no por POST?

Un detalle técnico que confunde: la vista envía el ID del enlace a través de la URL, no del cuerpo de la petición. Si el controlador intenta leer ese ID con $request->post('id'), recibirá null y la consulta fallará silenciosamente.

¿Cómo recupero el ID del registro a actualizar? Usa el parámetro de la ruta, no el método POST. En Laravel, el ID llega como argumento del método del controlador o vía $request->route('id').

Esa diferencia entre GET y POST explica por qué a veces el sistema responde "no consigo ese registro" aunque el dato exista en la base.

¿Cómo se completa el ciclo CRUD en Laravel?

Con esta práctica cierras las cuatro operaciones administrativas sobre la base de datos:

1. Leer registros con GET.
2. Crear nuevos registros con POST.
3. Eliminar registros con DELETE.
4. Actualizar registros con PUT.

El flujo siempre arranca en las rutas, viaja al controlador correspondiente, valida la información, consulta la base de datos y, si todo sale bien, ejecuta la acción. Si la validación falla, los errores regresan a la vista para mostrarse al usuario [06:20].

Después de probar editando un registro real, escribiendo "ABCDEF" como título y guardando los cambios, verás cómo la base de datos refleja la modificación de inmediato. Ese es el momento en que tu aplicación pasa de ser estática a permitir acciones reales.

El reto ahora es tuyo: replica estas cuatro funciones administrativas dentro del módulo de blog. ¿Qué dificultades encontraste al implementar PUT en tu propio proyecto? Cuéntame en los comentarios.