Esta clase va a ser

grabada
 Clase 11. JAVA INICIAL

Spring Boot - Rest -

Postman II
Temario

10 11 12

Spring Boot - Rest Spring Boot - Rest GIT

- Postman I - Postman II

✓ Spring boot ✓ Arquitectura de 3 ✓ Versionador

✓ Rest capas de código
✓ GET- POST ✓ Configuraciones ✓ GIT
✓ POSTMAN ✓ Paso a paso
Objetivos de la clase

Aprender a armar un servicio

REST
MAPA DE CONCEPTOS

Arquitectura en capas

Patrón REST POSTMAN

CLASE N° 11

Glosario
BBDD: Base de datos

Json: JavaScript Object Notation

Arquitectura de 3 capas
¿Qué es?
La arquitectura en capas responde al patrón de
arquitectura de N niveles. En este curso nos vamos a
enfocar en el patrón de 3 capas.
Definición del
patrón

Los componentes dentro del patrón de arquitectura en

capas se organizan en capas horizontales que
desempeñan una función específica dentro de la
aplicación, por ejemplo: lógica de presentación o lógica
de negocio
Rasgos del patrón

Aunque el patrón de arquitectura en capas no

especifica el número y los tipos de capas que
deben existir en el patrón nosotros vamos a
trabajar con las 3 capas clásicas:

✓ Presentación

✓ Negocio

✓ Persistencia
Funciones y responsabilidades

Capa de presentación Capa lógica o de negocio Capa de persistencia

Es responsable de Es la responsable de Es la responsable de

manejar toda la interfaz ejecutar reglas de manejar todo lo
de usuario y la lógica de negocio específicas relacionado a la
comunicación del asociadas con la comunicación con la
navegador solicitud base de datos
 Funciones y responsabilidades

Fuente: Medium
Responsabilidades de
las capas
Tipos de
responsabilidades

Cada capa de la arquitectura se enfoca únicamente en el

trabajo que tiene hacer abstrayéndose del resto de las
capas.
Capa de presentación

✓ No necesita saber cómo obtener los

datos del cliente; solo precisa devolver
esa información en un formato
particular.

Capa de lógica o de negocio

✓ No necesita preocuparse por cómo

formatear los datos del cliente (propio
de la capa de presentación) ni tampoco
de dónde provienen los datos del
cliente (responsabilidad de la capa de
persistencia).
Capas de aislamiento

✓ Significa que los cambios realizados en una

capa de la arquitectura generalmente no
impactan ni afectan a los componentes de
otras capas: el cambio se aísla a los
componentes dentro de esa capa.

✓ Si se permite que la capa de presentación

acceda directamente a la capa de
persistencia, los cambios realizados en SQL
dentro de la capa de persistencia afectarán
tanto a la capa de negocio como a la capa de
presentación convirtiendo el diseño de la
solución en un diseño altamente acoplado que
es muy difícil de mantener.
 CoderTips

Un Web Service (o API Web) que implementa

REST es una API Rest
 Para pensar
¿Por qué no permitir que la capa de
presentación acceda directamente a la capa
de persistencia o a la capa de la base de
datos?

Contesta en el chat de Zoom

¿Qué significa el patrón
de separación en capas?
Los componentes de la capa de presentación Esta forma de agrupar los componentes de
se ocupan únicamente de la lógica de acuerdo a su funcionalidad facilita la creación
presentación, mientras que los componentes de modelos de responsabilidad en su
que residen en la capa de negocio se ocupan arquitectura y también facilita el desarrollo, la
únicamente de la lógica de negocio. prueba, el control y el mantenimiento de
aplicaciones.
Capas cerradas y
abiertas
 Tipos de capas

Capa cerrada

Significa que a medida

que una solicitud se
mueve de una capa a
otra, debe atravesar la
capa justo debajo de ella
para llegar a la siguiente
capa debajo
 Tipos de capas

Capa abierta

Si necesitamos agregar
una capa de negocio
para brindar servicios
comunes para otros
componentes que llame
directamente a la capa
de persistencia sin pasar
por la capa lógica
estamos en presencia
de una capa abierta.
Beneficios
Paso a paso
Abstracción Las capas permiten cambios que se realicen en
un nivel abstracto.

Aislamiento. El estilo de arquitectura de capas permite aislar

los cambios en tecnologías a ciertas capas para reducir el
impacto en el sistema total.
Rendimiento. Distribuir las capas entre múltiples sistemas (físicos)
puede incrementar la escalabilidad, la tolerancia a fallos y el rendimiento.
Mejoras en Pruebas. Tener una interfaz bien definida para
cada capa así como de la habilidad para cambiar a
diferentes implementaciones de las interfaces.
 ☕
Break
¡10 minutos y volvemos!
 Ejemplo en vivo

Ahora, generaremos un proyecto spring boot

con las dependencias de JPA para implementar
un servicio REST de tres capas ¿empezamos?
 Servicio REST de tres capas

Ejemplo

En nuestro ejemplo en
vivo vamos a realizar una
implementación de
arquitectura de tres
Aplicación
capas cerradas que se
Postman Controller Service Repository BBDD van a invocar en el
siguiente orden:

1. Controller
2. Service
3. Repository
Configuración base de
datos
 Todo lo referido a las propiedades de configuración de los
proyectos Spring Boot
se realizan en el archivo application.properties

1 Configuración de la base de datos

En el archivo application.properties se tiene que
configurar las siguientes propiedades:

spring.datasource.url=jdbc:h2:mem:coderHouse Nombre de la base de datos

spring.datasource.driverClassName=org.h2.Driver Driver de la BBDD
spring.datasource.username=sa Usuario de conexión
spring.datasource.password= Password de conexión
spring.jpa.show-sql=false Propiedad para mostrar las queries
spring.jpa.properties.hibernate.format_sql=true
Propiedad para mostrar en formato sql
spring.h2.console.enabled=true
Propiedad para habilitar la consola
spring.h2.console.path=/h2-console
Path de la consola
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.H2Dialect
Jpa Dialect
2 Levantar la aplicación
El IDE Spring Tool Suite nos provee una vista para Spring Boot, dentro
de ella vemos el proyecto y ejecutamos el botón Start o Restart
En la consola del IDE observamos que la aplicación levantó
satisfactoriamente.
3 Probar que la base de datos quedó
configurada y corriendo en consola
Vamos a acceder a la consola de la base
de datos a través de: Consola Base de
Datos H2
1. La base de datos es coderHouse
2. Por defecto el usuario es: sa
3. Por defecto el pass es vacío
Podemos ver que la consola
de la base de datos H2 es muy
parecida a la que usamos la
clase anterior con SQL Lite.

👉 Todos los clientes de base

de datos son similares, es
bueno familiarizarse con su
uso
Configuración proyecto
con Spring Boot
Creación del proyecto
Spring Boot
1. Ir al sitio start.spring.io
2. Configurar el proyecto de tipo
Maven, lenguaje Java, Spring
Boot versión 2.6.3, completar
la metadata, el packaging va a
ser en formato jar y la versión
de Java va a ser la 8
Creación del proyecto
Spring Boot
3. Se agregan las siguientes
dependencias:
a. H2: Base de datos en memoria
b. Spring Web: La BBDD nos brinda
una consola web entonces esta
librería provee todo lo
necesario para acceder a ella
c. Spring Data JPA: librería para
implementar JPA con Hibernate
Creación del proyecto
Spring Boot
4. Se genera el proyecto y se descarga en formato zip

5. Descomprimir el zip e importar el proyecto en el IDE de

preferencia
a. Import Existing Maven Project
i. Se selecciona la carpeta descomprimida
b. Esperar que terminen de cargar todas las
dependencias.
i. Verificar que la estructura del proyecto
queda de esta manera.
Lógica de la aplicación
@RestController
@RequestMapping("/cliente")
public class ClienteController {
@Autowired
private ClienteService clienteService; Primero creamos la clase
ClienteController que va a ser la
@GetMapping(value = "/{id}", produces =
{MediaType.APPLICATION_JSON_VALUE})
encargada de manejar todos los
public ResponseEntity<?> getClienteById(@PathVariable(name = request que reciba la aplicación
"id") Long id) { para la ruta /cliente
Optional<Cliente> cliente =
clienteService.buscarClienteById(id);
Esta es la primera capa de la
if(cliente.isPresent()){ aplicación que tiene una instancia
return ResponseEntity.ok(cliente); para llamar a los métodos de la
segunda capa.
}else{
return ResponseEntity.notFound().build();
}
}
@PostMapping(consumes = {MediaType.APPLICATION_JSON_VALUE})
public ResponseEntity<?> guardarCliente(@RequestBody Cliente
cliente) {
try {
Cliente clienteGuardado =
clienteService.crearCliente(cliente);
return
ResponseEntity.created(URI.create("")).body(clienteGuardado);
} catch (Exception e) {
e.printStackTrace();
return ResponseEntity.internalServerError().body(null);
}
}}
 Luego creamos el service que es
la segunda capa o capa lógica
que es la que se comunica con la
tercer capa o capa de datos, para
procesar la información recibida y
@Service devolver al Controller
public class ClienteService {

@Autowired
private ClienteRepository clienteRepository;

public Cliente crearCliente(Cliente cliente) {

return clienteRepository.save(cliente);
}

public Optional<Cliente> buscarClienteById(Long idCliente) {

return clienteRepository.findById(idCliente);
}

}
 Generamos la capa de datos o
tercera capa que tiene la
responsabilidad de conectarse a
una base de datos
@Repository
public interface ClienteRepository extends
JpaRepository<Cliente,Long>
{
}
 Por último, generamos la clase
@Entity Cliente que va a ser la entidad de
@Table(name = "CLIENTE") dominio que vamos a guardar
public class Cliente {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

@Column(name = "NOMBRE")
private String nombre;

@Column(name = "APELLIDO")
private String apellido;

@Column(name = "DNI")
private long dni;

// Resto de los métodos

Test con Postman
Test con Postman

1.

Vamos a verificar que la la

BBDD H2 en memoria
está levantada y que la
tabla Cliente no tiene
registros.

a. En un browser de
nuestra preferencia
acceder a
localhost:8080
Test con Postman

1.

b. Ejecutar una
consulta a la tabla
CLIENTE para
confirmar que no
tiene registros.
Test con Postman

2.

En la aplicación Postman
vamos a ejecutar un
POST contra la url
pasando en el body (en
formato Json) los datos
del cliente a guardar.
{
"nombre": "Jorge Luis",
"apellido": "Borges",
"dni": 23456789
}
Test con Postman

3.

En la aplicación Postman
vemos el resultado de la
ejecución.
Test con Postman

3.

En la BBDD observamos
el registro creado.
Test con Postman

4.

Desde postman
buscamos el Cliente con
id = 1 haciendo un GET.
http://localhost:8080/cli
ente/1
Pudimos dar de alta un cliente en nuestra base
de datos y luego recuperarlo usando REST con
una arquitectura de tres capas.
 Calculadora
Generar un proyecto Spring boot rest que publique un
endpoint para cada operación algebraica básica

Duración: 30 minutos
 ACTIVIDAD EN CLASE

Calculadora
Generar un proyecto Spring boot rest que publique un
endpoint para cada operación algebraica básica: Suma,
Resta,Multiplicación y División. Cada endpoint recibe dos
parámetros y devolverá el resultado de la operación. Realizar
las validaciones correspondientes y devolver un mensaje de
error cuando los parámetros no cumplan las validaciones
Cliente API Rest
 DESAFÍO ENTREGABLE

Cliente API Rest

Consigna Formato
✓ Crear la tabla cliente con los siguientes atributos: ✓ Se debe entregar un archivo en
nombre, apellido, fecha de nacimiento. Además, formato .jar.
crear un restcontroller que retorne un json con la El formato del nombre debe ser
siguiente estructura: “ClienteApiRest+Apellido.java”
{
nombre: XXXXXX,
apellido: YYYYYY, ✓
años: #####
}

En la capa servicio se deberá calcular la edad de

la persona consultada y retornar el JSON
 DESAFÍO ENTREGABLE

Cliente API Rest

Sugerencias
✓ Se recomienda comentar el código para explicar
qué hace cada parte del mismo.
Aspectos a incluir
✓ Entregar el proyecto en formato jar que ejecute
sin errores y dejar el resultado en consola
¿Preguntas?
Opina y valora
esta clase
Muchas gracias.
 Resumen
de la clase hoy
✓ Arquitectura en capas.
✓ Beneficios de la arquitectura en capas.
Encuesta
sobre esta clase
Por encuestas de Zoom

¡Terminamos la clase!

Cuéntanos qué temas te resultaron más complejos de

entender. Puedes elegir más de uno. Vamos a retomar
aquellos temas que resultaron de mayor dificultad en el
próximo AfterClass.