Pruebas de CRUD REST con Postman

Clase 29 de 31Curso de Java: Backend con Spring Boot

Contenido del curso

JPA con Spring y Spring Data

Resumen

Validar que cada operación de un CRUD funciona correctamente es tan importante como escribirla. A continuación se explica paso a paso cómo probar los servicios REST de creación, lectura, actualización y eliminación usando Postman, además de corregir un error común con Optional en Spring Boot.

¿Cómo corregir el error de retorno con Optional en el servicio de update?

Antes de abrir Postman, es necesario resolver un problema que quedó pendiente en el código. Dentro de la clase UsersService, el método findById devuelve un Optional de la entidad User. Al hacer el map para actualizar los campos y luego llamar a userRepository.save, el tipo de retorno no coincide porque sigue envuelto en un Optional [0:30].

La solución es agregar el método .get() al final de la cadena. De esta forma se extrae la entidad del Optional y el método update retorna directamente el objeto User actualizado. Es un detalle sencillo pero que impide la compilación si no se corrige.

¿Cómo probar cada operación del CRUD en Postman?

Con el error resuelto, se procede a verificar cada endpoint desde Postman.

Crear un registro con POST y status 201

Para registrar un nuevo usuario se selecciona el método POST sobre la misma ruta base del servicio. En la pestaña Body se elige Raw y el formato JSON. El cuerpo de la petición luce así [1:22]:

{ "name": "Michael", "email": "michael23", "birthday": "20210425" }

Al presionar Send, el servidor responde con el usuario recién creado y un código de respuesta 201 (Created). Este código indica que el recurso se generó exitosamente, a diferencia del 200 genérico.

Actualizar un registro con PUT

Para actualizar se cambia el método a PUT y se agrega el ID del usuario como parámetro en la URL. En el cuerpo JSON se modifican los campos deseados [2:22]:

{ "name": "test update", "email": "update", "birthday": "20210428" }

Después de enviar la petición, se puede confirmar el cambio volviendo al método GET y consultando el listado completo. El usuario aparece con los datos actualizados.

Eliminar un registro con DELETE y status 204

Se selecciona el método DELETE y se pasa el ID del usuario que se desea eliminar en la URL. Al presionar Send, el servidor responde con un código 204 (No Content) [3:02]. Esto significa que la operación fue exitosa pero no hay cuerpo en la respuesta. Al consultar nuevamente con GET, el registro ya no aparece en el listado.

¿Qué significan los códigos de respuesta HTTP en un CRUD?

Los códigos de estado HTTP comunican al cliente qué ocurrió con su petición. En el contexto de este CRUD se utilizan tres principales:

  • 200 OK: la petición se procesó correctamente y se devuelve contenido.
  • 201 Created: el recurso se creó con éxito, se usa en el método POST.
  • 204 No Content: la operación fue exitosa pero no hay cuerpo de respuesta, ideal para el método DELETE.

Responder con el código adecuado no es solo buena práctica, es parte del estándar REST y facilita que cualquier cliente interprete correctamente el resultado.

Errores frecuentes al probar servicios

Durante las pruebas surgieron dos situaciones comunes [4:12]:

  • Falta del slash en la URL: produce un error de enrutamiento que impide llegar al endpoint.
  • Email duplicado: al intentar registrar un usuario con un correo que ya existe, el servidor rechaza la petición por restricción de unicidad en base de datos.

Ambos casos se resuelven revisando la URL y asegurándose de enviar datos únicos donde el esquema lo requiera.

Si te ha resultado útil esta guía de pruebas con Postman, comparte en los comentarios qué otros escenarios te gustaría validar en tus servicios REST.