Contenido del curso
Configuración de Colecciones y Paginación en Laravel
¿Cómo configurar el proyecto para retornar una colección de datos?
Al abordar un proyecto de desarrollo, es crucial tener una estructura organizada que permita retornar colecciones de datos de manera eficiente. Aquí encontrarás una guía detallada sobre cómo realizar esta configuración, utilizando Laravel, un popular framework de PHP.
¿Cómo se configuran las rutas en Laravel para manejar colecciones?
El punto de partida en cualquier API de Laravel son las rutas. Para enviar múltiples datos, es necesario configurar adecuadamente las rutas de tal manera que tu aplicación esté preparada para manejar colecciones de datos. En este caso, configuraremos dos rutas, index y show, las cuales permitirán listar los recursos y acceder a un recurso específico, respectivamente.
Route::get('posts', [PostController::class, 'index']); Route::get('posts/{id}', [PostController::class, 'show']);
¿Cómo se configura el controlador para manejar colecciones?
Una vez configuradas las rutas, el siguiente paso es adaptar el controlador. En este caso, utilizarás el método index para acceder a los últimos posts con paginación. Eso lo puedes lograr mediante consultas que retornen los posts con la paginación adecuada.
public function index() { return PostResource::collection(Post::latest()->paginate(10)); }
Este bloque de código garantiza que obtendrás una colección de posts paginada, utilizando la clase PostResource para asegurarte de que solo los atributos necesarios se retornen.
¿Cómo visualizar la colección de datos con Postman?
Para probar y visualizar las configuraciones efectuadas, es recomendable utilizar Postman u otra herramienta similar. Al enviar una solicitud a la API, recibirás la colección de datos solicitados. Aquí se pueden observar algunos puntos clave:
¿Es posible retornar datos sin el formato definido por Laravel?
Sí, puedes retornar datos sin pasar por el formato de recursos de Laravel. Sin embargo, para mantener una consistencia y claridad, especialmente en este proyecto, se recomienda respetar esta estructura. Facilita la manipulación y presentación de datos, asegurando que solo se incluyen los campos necesarios: título, slug, extracto y contenido.
Si el proyecto lo requiere, se puede crear otro recurso con configuraciones diferentes adaptadas a nuevas necesidades.
¿Cómo manejar la eliminación de recursos?
Como práctica recomendada, debes configurar el método para eliminar recursos y enviar una respuesta apropiada. Cuando un recurso es eliminado exitosamente, el sistema debería retornar un estado 204, indicando que la operación fue realizada sin problemas.
public function destroy($id) { Post::destroy($id); return response()->json(null, 204); }
Asegúrate de implementar este método correctamente para manejar las solicitudes de eliminación de recursos de manera efectiva.
Con todos estos pasos, habrás establecido una base sólida para manejar colecciones y recursos en Laravel de manera eficiente. No dudes en realizar ajustes y personalizaciones según las necesidades del proyecto, siempre manteniendo las buenas prácticas que garantizan un desarrollo robusto y escalable. ¡Continúa aprendiendo y perfeccionando tus habilidades en Laravel!
Carlos Eduardo Gomez García
teacher
Felipe Rodríguez
student
Julian David Alzate Cuervo
student
Alex Maldonado
student
Ermilo Silvino Juárez Gordillo
student
Luis Eduardo Sandrea Pacheco
student
Juan David Meza Gonzalez
student
Carlos Daniel
student
IRIDIAN GUADALUPE CARRERA MONDRAGÓN
student
Cristhian Coaquira
student
Jorge Lozano Fortes
student
Camilo Venegas
studentCamilo Venegas
student
lucas cartisano
student
Carlos Roberto Villatoro Barrios
student
Mario Peña
studentMario Peña
studentMario Peña
studentMario Peña
student
Fredy Max Chavez Loyola
student
Liann Melanny Huaman Cunyas
student
Ángel David Castillo Castro
student
Frank Atencio
student
José Tuzinkievicz
student
Atahualpa Silva Falcón
student
Hector Vasquez
studentAlgo interesante es que cuando eliminas un recurso, es una buena práctica hacer un "soft delete", para eso únicamente hay que usar el trait SoftDeletes. Básicamente un SoftDelete es una forma de "eliminar los datos" sin que tengas que borrarlos realmente de la base de datos (digamos que en la base de datos hay un campo que dice si el elemento es visible o no) :D
.
En cuanto al reto, en Laravel puedes retornar un mensaje junto a un código de respuesta:
$post->delete(); return response("", 204);
Recuerden agregar la opción destroy, al array de only dentro de las rutas de api :D
Gracias compañero !
genial, me sirvió esa solución
Comparto mi código utilizado para eliminar el recurso:
public function destroy(Post $post) { $post->delete(); return response()->json(null, 204); }
Más info: https://laravel.com/docs/8.x/responses#json-responses
Para el reto, agregué el campo 'deleted_at' a la tabla de posts con una migracion, ya que no es recomendable borrar definitivamente un registro en la bd:
php artisan make:migration add_deleted_at_posts_table
. Luego agregué el trait SoftDeletes como se describe en la documentación de Laravel. . Después corrí la migración para agregar el campo:
php artisan migrate
. Por último, en el metodo 'destroy' del PostController:
$post->delete(); return response()->json([], Response::HTTP_NO_CONTENT);
. api.php
Route::apiResource("v1/posts", \App\Http\Controllers\Api\V1\PostController::class)->only(["index", "show", "destroy"]);
public function destroy(Post $post) { $post->delete(); return response()->json(null, Response::HTTP_NO_CONTENT); }
¡Perfecto! Usar Response::HTTP_NO_CONTENT, es mucho más adecuado y elocuente que solo poner 204.
Recuerden importarlo
use Symfony\Component\HttpFoundation\Response;
Versión 1: colección
le vamos a decir que queremos muestre los siguientes recursos para consuar en la api:
<?php use Illuminate\Http\Request; use Illuminate\Support\Facades\Route; Route::apiResource('v1/posts', App\Http\Controllers\Api\V1\PostController::class) ->only(['index', 'show']);
en PostController
public function index() { return PostResource::collection(Post::latest()->paginate()); }
consultamos con postman y ya debería traer todos los posts:
http://127.0.0.1:8000/api/v1/posts
Mi solucion al reto gracias a la comunidad por sus aportes
public function destroy(Post $post) { if ($post->delete()) { return response()->json([ 'data' => [ 'message' => 'Post Deleted' ] ], Response::HTTP_NO_CONTENT); } return response()->json([ 'data' => [ 'message' => 'Error deleting Post' ], Response::HTTP_INTERNAL_SERVER_ERROR ]); }
Para hacer el endpoint de delete, a tener en cuenta, habría que habilitar en api.php, el resource de destroy.
Route::apiResource('v1/posts', \App\Http\Controllers\Api\V1\PostController::class) ->only(['show', 'index', 'destroy']);
¿Que pasa si quiero eliminar cientos o miles de posts en una sola vez? El metodo destroy soporta un solo post y el metodo delete también, y la estructura de url tendría que tener un array de ids, no solo uno, ¿como se haría?
Interésate como regresamos una respuesta a parte del estado, para darle al cliente mayor visualización, mi método quedo de la siguiente manera:
public function destroy(Post $post) { $post->delete(); return response()->json(['message' => 'Post deleted successfully'], 204); } ```Y justo como dice Retax, no olviden agregar el método al only para habilitar dicha ruta: ```js Route::apiResource('v1/posts', App\Http\Controllers\Api\V1\PostController::class)->only(['index', 'show', 'destroy']);
`php
<?php
namespace App\Http\Controllers\Api\V1;
use App\Http\Controllers\Controller;
use App\Models\Post;
use Illuminate\Http\Request;
use App\Http\Resources\V1\PostResource;
class PostController extends Controller
{
/**
* Remove the specified resource from storage.
*/
public function destroy(Post $post) { # Comúnmente lo implemento asi # Eliminamos el registro $post->delete();
# Retornamos la respuesta json asi mismo # Una copia del registro eliminado para mas claridad return response()->json([ 'data' => $post, 'message' => 'Registro eliminado exitosamente' ],200);
}
}
`
`php
<?php
namespace App\Http\Controllers\Api\V1;
use App\Http\Controllers\Controller;
use App\Models\Post;
use Illuminate\Http\Request;
use App\Http\Resources\V1\PostResource;
class PostController extends Controller
{
/**
* Remove the specified resource from storage.
*/
public function destroy(Post $post)
{
# Eliminamos el registro
$post->delete();
# Retornamos la respuesta json
return response()->json([
'message' => 'Registro eliminado exitosamente'
],204);
}
}
`
Sus rutas API pueden hacerlo así para tener un poco más de orden
Route::prefix('v1')->group(function () { Route::apiResource('posts', PostController::class) ->except(['update', 'store']); });
public function destroy(Post $post) { $eliminado=$post->delete(); if ($eliminado){ $data= [ 'Elemento eliminado' => $eliminado, 'Id' => $post->id, ]; return response()->json(['message'=>$data],204); } else { return response()->json(['error' => 'No encontrado'], 404); }; }
Compartó mi respuesta
public function destroy(Post $post) { $post->delete(); return response()->json(null,204); }
$post->delete(); return (new PostResource($post)) ->additional([ “msg”=>“Post eliminado” ]) ->response() ->setStatusCode(204);
Por qué en el caso de index no se usa new antes de PostResource?
Cuando haces un "new" de alguna clase generas una instancia pero en el caso del método index no nos sirve generar una instancia de PostResource porque necesitamos un listado completo o colección. Si lo ves de otra manera necesitas que dentro de ese listado cada Post sea una instancia de PostResource y es ahí donde entra el método estático "PostResource::collection(...)" que lo que haces es justamente eso, crea un nuevo listo donde cada instancia de Post es realmente una instancia de PostResource.
el new se usa para crear una nueva instancia de una clase. Cuando usas métodos estáticos de una clase, no tienes que crear una nueva instancia de la clase. Esa es la gracia de los métodos estáticos
