Implementar las operaciones REST para crear y actualizar información

Clase 28 de 38 • Curso de Hibernate y Java Spring 2018

Edson Lemus

student•

Una explicación buena y breve de por qué usar DTOs (VO en el video): https://www.oscarblancarteblog.com/2018/11/30/data-transfer-object-dto-patron-diseno/

Rubén Zamora González

student•

Está genial el artículo, me aclaró muchas cosas.

Gracias !

Diego Edgardo Vega Herrera

student•

Muchas gracias

Luis Garcia

student•

Para los que estén siguiendo la lección paso por paso, al profesor se le olvido hacer set la identificación del clienteVo al cliente: cliente.setIdentificacionCli(clienteVo.getIdentificacionCli());

Esto es importante por que sin una identificación en la base de datos no podremos actualizar, borrar, o buscar por identificación.

Luis Fernando Pedroza Taborda

student•

Muchas gracias Luis, Exactamente eso mismo pense por eso lo agregue.

DANIEL VILLALOBOS

student•

Para los que esten usando IntelliJ no pude instalar desde el jar el lombok por que decia que solo tenia soporte para eclipse, spring tool: Realice los siguientes pasos: 1.- instalar el plugin para el soporte de lombok Settings-> plugins-> lomboK install.

2.- Setting->Annotation Processors-> habilitar check "Enable annotation Processing".

Y Listo con esto me funciono los getter y setters.

Cristhian Franco

student•

Buena información, no es solo escribir la dependencia en el pom, estoy aprendiendo a usar ambos, algunso trabajos en mi ciudad piden especificamente Eclipse aunque IntelliJ es muy superior.

Alex Soto Mendez

student•

Encuentro que esa clase (vo) es muy redundante, he visto maneras más eficiente, quizás estoy equivocado, tengo el siguiente código, en el cual en vez de setear cada parametro, recibo y guardo el objeto completo:

< @RestController @RequestMapping("/usuario") publicclassUsuarioController { privatefinalstatic Logger logger = Logger.getLogger(UsuarioController.class);

	@Autowired
	privatefinal UsuarioRepository usuarioRepository;

	public UsuarioController(UsuarioRepository usuarioServices) {
		this.usuarioRepository	=	usuarioServices;
	}

	@RequestMapping(value = "/crear", method = RequestMethod.POST)
	public ResponseEntity<Usuario> createUsuario(@RequestBody Usuario usuario){
		returnnew ResponseEntity<>(usuarioRepository.save(usuario), HttpStatus.CREATED);
}

William Rodriguez

student•

Si usuario esta relacionado con clientes y tiene 520000 te los va a traer todos los clientes por que al convertir una a json durante la conversion dispara todas las consultas de las relaciones. Tu codigo es mas limpio y no necesita otra clase hasta el momento pero te dara ese problema a futuro.

William Rodriguez

student•

tecnica de conversion automatica de ENTITY a VO o DTO

Cesar David Ramírez Dimaté

student•

Excelente aporte. Así uno se evita estar haciendo SET a los valores.

Nadir Antonio Soza Solis

student•

Existe algún mecanismo para evitar la asignación de cada una de la propiedades del objeto?, me imagino lo doloroso que podría ser una tabla de unas 20 o mas columnas.

Victoria Tejeda

student•

Puedes crear una clase Builder la cual te convierta:

de VO a Entity
de Entity a VO

Así solo lo programas una sola vez y lo reutilizas donde lo necesites, como en este video si te das cuenta hay dos métodos createCliente y updateCliente los cuales repiten código al setear los valores, con la clase Builder podrías ahorrarte esas lineas y tener un mejor mantenimiento a futuro.

Diego Marquina

student•

Creo que lo que estas buscando es JMapper

Mario Alberto Ramón Uceda

student•

VO = DTO, algo de información para entederlo: https://www.arquitecturajava.com/rest-dto-y-json-arquitecturas-web/

Francisco Ruiz Lezcano

student•

Dejo mi repositorio del proyecto por si lo necesitan! Saludos y paz

https://github.com/franciscoruizlezcano/Reservation

Yossijaki Jorge Astilleros Chávez

student•

Muy buena clase! ahora veo de donde salieron las clases de vista 😃

Francisco Javier Velasco Conde

student•

POST -> Crear un recurso. PUT--> Editar un recurso. GET-> Obtener uno o mas recursos. DELETE-> Eliminar un recurso

Estos son los metodos REST mas comunes y se asemejan al CRUD (Crear, Leer, Actualizar y Eliminar)

Luis Fernando Pedroza Taborda

student•

Muchas gracias Francisco por este aporte.

Luis Fernando Pedroza Taborda

student•

Muy bien, ya estan implementados los métodos de crear y actualizar para nuestro servicio web.

Mateo Villanueva

student•

Hola a todos, saben porque usa ResponseEntity?

Pamela Freyre

student•

Cuando yo lo he usado es para representar la respuesta de mi endpoint , ahi puedes darle un status code, message etc que es lo que el usuario vera cuando consuma tu api.

Víctor Daniel Cardozo Fernández

student•

Alguien sabe por qué no se usa el @RequestBody en el put?

Julian Zapata Parra

student•

De hecho lo debes utilizar. Al profesor diría que se le olvidó, ya que si ejecutas el put sin el @RequestBody no funcionará.

Alex Soto Mendez

student•

<	@RestController
	@RequestMapping("/usuario")
	public class UsuarioController {
		private final static Logger logger = Logger.getLogger(UsuarioController.class);
	
		@Autowired
		private final UsuarioRepository usuarioRepository;
	
		public UsuarioController(UsuarioRepository usuarioServices) {
			this.usuarioRepository	=	usuarioServices;
		}
	
		@RequestMapping(value = "/crear", method = RequestMethod.POST)
		public ResponseEntity<Usuario> createUsuario(@RequestBody Usuario usuario){
			return new ResponseEntity<>(usuarioRepository.save(usuario), HttpStatus.CREATED);
	}>

Marco Antonio Toscano Freire

teacher•

También es válida, se utiliza un VO para tener independencia en el transpaso del objeto en el servicio tomando en cuenta que mañana podrias integrarte con otra plataforma no necesariamente java, dejando al objeto simple

Vespaciano Forero Sanchez

student•

@Data no me reconoce los métodos getter y setter

Vespaciano Forero Sanchez

student•

Diego A de la Cruz Rojas

student•

En la parte de tu @RequestBody necesitas instanciar un objeto ClienteVo es por eso que el IDE no te lo reconoce, quedaría de esta manera.

public ResponseEntity<Cliente> createCliente(@RequestBody ClienteVO clienteVo) {

JESUS ALMIRCAR CASTELLANOS

student•

🚑️Ir a repositorio
🚑️Ir a repositorio

Angel Gonçalves

student•

¿Alguien entendió realmente esta clase?

Francisco Romero Jovel

student•

yo si la he entendido...

Lázaro Bucio Marín

student•

Buena Clase.!!

Voy Muy Bien 😃

Noe de Jesus Muñoz Martinez

student•

Buena explicación.

JOSE ADRIAN TEZOYOTL MORALES

student•

Y el manejo de errore como se haria, para no responder siempre 200 OK sino cuando falle algun mensaje de cual fue el error

Alexandra Medina

student•

Si te refieres al http status cualquiera diferente a 200 es un error, puedes ver la definición de cada uno en este link.

Otra manera práctica sería manejar un objeto genérico de respuesta que tenga un String returnCode y String returnMsg, para que todos los objetos VO lo implementen, de esta manera cuando ocurra una excepción o manejes alguna validación puedas llenar estos campos e interpretarlos en el frontEnd.