Mejores Prácticas para El Diseño de Una API Rest Con Spring Boot

UNIVERSIDAD MAYOR DE SAN SIMON
FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO
“MEJORES PRÁCTICAS PARA EL DISEÑO DE

UNA API REST CON SPRING BOOT”
TRABAJO FINAL PRESENTADO PARA OBTENER EL

CERTIFICADO DE DIPLOMADO EXPERTO EN DESARROLLO DE
APLICACIONES EMPRESARIALES VERSIÓN I
.
POSTULANTE : David Mamani Colque

TUTOR : Lic. Msc. Valentin Laime Zapata
Cochabamba – Bolivia
2018
1
ii
AGRADECIMIENTOS
A Digital Harbor Bolivia por llevar el curso de

Diplomado “EXPERTO EN DESARROLLO DE
APLICACIÓN EMPRESARIALES”, con mucha
calidad, experiencia y profesionalidad.
A los amigos, compañeros y docentes que he

tenido la oportunidad de conocer y que con
sus enseñanzas y criterios aportaron en el
desarrollo y culminación del presente trabajo
de investigación.
ÍNDICE
Resumen ....................................................................................................................... 4
Introducción ................................................................................................................. 5
1. REST VS WEBSERVICES .................................................................................. 6

1.1. ¿Qué es un servicio Web? ...................................................................... 6
1.2. ¿Qué es REST?........................................................................................ 7
1.2.1. Principios de REST ..................................................................... 8
1.2.2. Principales características de REST ........................................... 9
2. MICROSERVICIOS Y SPRING BOOT ........................................................... 11
2.1. Microservicios ....................................................................................... 12
2.1.1. Beneficios ................................................................................... 14
2.2. Spring Framework y Spring Boot ..................................................................... 15
2.2.1. Spring Framework.................................................................................. 16
2.2.2. Spring Boot ............................................................................................. 17
3. MEJORES PRÁCTICAS DE SPRING BOOT ................................................. 18
3.1. Hacer uso de la configuración automática .................................................. 18
3.2. Hacer uso de Spring Initializr ...................................................................... 21
3.3. Estructurar el directorio de paquetes correctamente .................................. 22
3.4. Tener los controladores bien definidos ....................................................... 24
3.5. Construir los servicios según las capacidades del negocio........................ 27
3.6. Hacer que la Base de Datos sea un detalle ................................................. 29
3.7. Confiar en el Constructor de Inyección ...................................................... 30
3.8. Proporcionar manejo de excepciones globales ........................................... 31
3.9. Usar el Logging framework ......................................................................... 32
3.10. Aplicación práctico de una API REST ..................................................... 33
4. Conclusiones ........................................................................................................ 43
5. Bibliografía .......................................................................................................... 44
2
TABLA DE FIGURAS
Figura 1: Objeto de retorno de la URI en formato JSON.......................................... 9
Figura 2: Objeto HATEOAS en formato JSON ...................................................... 11
Figura 3: Patrón básico de arquitectura de Microservicios ..................................... 13
Figura 4: Beneficios de los microservicios .............................................................. 14
Figura 5: The Spring Framework architecture ......................................................... 16
Figura 6: Tomcat embebido en Spring Boot ............................................................ 19
Figura 7: Tag´s dependency en archivo POM ......................................................... 19
Figura 8: Librería MySql en archivo POM .............................................................. 20
Figura 9: Librería SqlServer en archivo POM ......................................................... 21
Figura 10: Formulario de la herramienta Spring Initializr ...................................... 22
Figura 11: Estructura de un proyecto Spring - I ...................................................... 23
Figura 12: Estructura de un proyecto Spring - II ..................................................... 24
Cuadro1: CRUD para el recurso de machines ......................................................... 25
Figura 13: Estructura de un Controlador .................................................................. 26
Figura 14: Servicio genérico que usa CrudRepository ............................................ 27
Figura 15: Servicio para Machine con procedimientos almacenados .................... 28
Figura 16: Lista de archivos del módulo Services ................................................... 28
Figura 17: Arquitectura Limpia ................................................................................ 29
Figura 18: Notación @Autowired y @Inject ........................................................... 30
Figura 19: Notación @Autowired ............................................................................ 31

3
Figura 20: Handling con @ResponseStatus ............................................................. 32
Figura 21: Uso de Logger.......................................................................................... 32
Figura 22: Configuraciones necesarias en Spring Initialzr ..................................... 33
Figura 23: Clase de dominio ..................................................................................... 34
Figura 24: Estructura de paquetes............................................................................. 35
Figura 25: Método genérico findByID, capturando error de solicitud HTTP ....... 35
Figura 26: Entidad Base ............................................................................................ 36
Figura 27: Entidad Machine ...................................................................................... 37
Figura 28: Command Machine ................................................................................. 38
Figura 29: Repositorio Machine ............................................................................... 39
Figura 30: Servicio Base ........................................................................................... 39
Figura 31: Servicio Machine ..................................................................................... 40
Figura 32: Controlador Machine............................................................................... 41
Figura 33: Uso de Logger.info .................................................................................. 42

4
Resumen
Esta monografía es parte del resultado que se obtuvo como producto en el desarrollo del Sistema
de Seguridad Industrial y Salud Ocupacional, por una parte se hizo un servicio web REST con
Framework Spring Boot, en la que se puede registrar y controlar la maquinaria, el equipo de
protección personal, las áreas y los equipos de trabajo.
Para el mencionado proyecto se utilizó Spring Boot, uno de los lenguajes de programación más
utilizados en el mundo por los desarrolladores. Sus principales características cómo;
portabilidad, simplicidad, arquitectura neutral y alto rendimiento, lo hacen una herramienta
potente para la construcción de software, se usó este framework ya que ocupa el primer lugar en
la lista de los más usados, sus múltiples beneficios permiten tener un software altamente
escalable y modular. Por lo tanto, las características antes mencionadas contribuyen a un
desarrollo ágil y eficiente que logran disminuir tiempos y recursos durante el proceso de
fabricación de la aplicación.
En este estudio se compartirá las mejores prácticas para el diseño de una API REST con Spring
Boot que se ha utilizado al desarrollar el Sistema de Seguridad Industrial y Salud Ocupacional,
me centro en las prácticas específicas, recomendados al implementar dicho sistema como por
ejemplo: uso de la configuración automática que ofrece, uso de Spring Initializr para comenzar
nuevos proyectos Spring Boot, estructurar el directorio de paquetes correctamente, tener los
controladores bien definidos, construir los servicios según las capacidades del negocio, hacer que
la base de datos sea un detalle (abstraerlo de la lógica central), confiar en el Constructor
Inyección, proporcionar manejo de excepciones globales, uso de logging framework y como
último punto una aplicación práctica de una API REST siguiendo las recomendaciones de los
expertos.
5
INTRODUCCIÓN
Los principales proveedores de servicios web como Facebook, Google, GitHub, Netflix, Amazon
y Twitter tienen sus propias API REST (full) a las que puedes acceder para obtener o incluso
escribir datos, resulta que REST es bastante flexible y compatible con HTTP. Ya que es un estilo
arquitectónico y no el estándar, proporciona mucha libertad para implementar diversas mejores
prácticas de diseño.
Hoy en día el uso de web services REST es indispensable en el desarrollo de aplicaciones,

creación de API’s, etc. El problema llega cuando se comienzan a definir estos web services sin
considerar buenas prácticas. Debido a esta tendencia de migrar nuestras aplicaciones a una
arquitectura de microservicios, es cada vez más importante contar con tecnologías que ayuden a
agilizar el desarrollo, pero sobre todo, que permita crear aplicaciones muy ligeras que consuman
el menor número de recursos y es justo allí cuando entra Spring Boot.
En este estudio sobre las mejores las mejores prácticas para el diseño de una api rest con Spring
Boot, el framework Java más popular para desarrollar microservicios, primero se hará un análisis
de los conceptos básicos y definiciones, para luego mostrar algunas de las mejores prácticas de
Spring Boot.
6
1. REST vs Web Services
Actualmente existe un debate sobre esto, REST es un estilo, mientras que los servicios Web son
sistemas de software. Por tanto, no es posible la comparación de ambos. Por otra parte,
popularmente se generaliza el concepto de servicio Web con el de servicio Web basado en
REST, es decir tomando REST como estilo de diseño.
1.1. ¿Qué es un servicio Web?
El consorcio W3C define los Servicios Web como sistemas software diseñado para soportar una
interacción interoperable máquina a máquina sobre una red. Los Servicios Web suelen ser APIs
Web que pueden ser accedidas dentro de una red (principalmente Internet) y son ejecutados en el
sistema que los aloja.
La definición de Servicios Web propuesta alberga muchos tipos diferentes de sistemas, pero el
caso común de uso de refiere a clientes y servidores que se comunican mediante mensajes XML
que siguen el estándar SOAP.
En los últimos años se ha popularizado un estilo de arquitectura Software conocido como REST
(Representational State Transfer). Este nuevo estilo ha supuesto una nueva opción de estilo de
uso de los Servicios Web. A continuación se listan los tres estilos de usos más comunes:
A. Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los Servicios

Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones
distribuidas, lo cual es familiar a muchos desarrolladores. Típicamente, la unidad básica
de este tipo de servicios es la operación WSDL (WSDL es un descriptor del Servicio
Web, es decir, el homólogo del IDL para COM).
Las primeras herramientas para Servicios Web estaban centradas en esta visión. Algunos
lo llaman la primera generación de Servicios Web. Esta es la razón por la que este estilo
está muy extendido. Sin embargo, ha sido algunas veces criticado por no ser débilmente
acoplado, ya que suele ser implementado por medio del mapeo de servicios directamente
a funciones específicas del lenguaje o llamadas a métodos. Muchos especialistas creen
que este estilo debe desaparecer.
7
B. Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA): Los

Servicios Web pueden también ser implementados siguiendo los conceptos de la
arquitectura SOA, donde la unidad básica de comunicación es el mensaje, más que la
operación. Esto es típicamente referenciado como servicios orientados a mensajes.
Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores
de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es
débilmente acoplado, lo cual es preferible ya que se centra en el “contrato”
proporcionado por el documento WSDL, más que en los detalles de implementación
subyacentes.
C. REST (REpresentation State Transfer): Los Servicios Web basados en REST intentan
emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la
interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT,…). Por
tanto, este estilo se centra más en interactuar con recursos con estado, que con mensajes y
operaciones.
1.2. ¿Qué es REST?
REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas

hipermedias distribuidas tales como la web. El término fue introducido en la tesis doctoral de
Roy Fielding en 2000, quien es uno de los principales autores de la especificación de HTTP.
También cabe destacar que REST no es un estándar, ya que es tan solo un estilo de arquitectura,
pero está basado en estándares:
 HTTP
 URL
 Representación de los recursos: XML/HTML/GIF/JPEG/…
 Tipos MIME: text/xml, text/html.
REST cambió por completo la ingeniería de software, en la actualidad no existe proyecto o

aplicación que no disponga de una API REST para la creación de servicios profesionales a partir
de ese software. Twitter, YouTube, Facebook, existen cientos de empresas que generan negocio
8
gracias a REST y las APIs REST. Sin ellas, todo el crecimiento en horizontal sería prácticamente
imposible.
El éxito de REST se debe a que tiene como motivación la de capturar las características de la
Web que la han hecho tan exitosa, esto porque la web ha sido la única aplicación distribuida que
ha conseguido ser escalable al tamaño de Internet.
1.2.1. Principios de REST
El estilo de arquitectura subyacente a la Web es el modelo REST. Los objetivos de este estilo de
arquitectura se listan a continuación:
 Escalabilidad de la interacción con los componentes: La Web ha crecido

exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de
clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas
industriales, dispositivos móviles.
 Generalidad de interfaces: Gracias al protocolo HTTP, cualquier cliente puede
interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es
del todo cierto para otras alternativas, como SOAP para los Servicios Web.
 Puesta en funcionamiento independiente: Este hecho es una realidad que debe tratarse
cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas en
funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de
entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo
de características resulta muy complicado. HTTP permite la extensibilidad mediante el
uso de las cabeceras, a través de las URIs, a través de la habilidad para crear nuevos
métodos y tipos de contenido.
 Compatibilidad con componentes intermedios: Los más populares intermediaros son
varios tipos de proxys para Web. Algunos de ellos, las caches, se utilizan para mejorar el
rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. Y por último,
otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no
propiamente Web. Por tanto, la compatibilidad con intermediarios permite reducir la
latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
9
1.2.2. Principales Características de REST

A. Los objetos REST son manipulados a través de una URI (Uniform Resource
Identifier): Esta URI (endpoint) hace de identificador único de cada recurso del sistema
REST, por lo que no puede ser compartida por más de un recurso. La estructura básica de
una URI es la siguiente: {protocolo}://{hostname}:{puerto}/{ruta del
recurso}?{parámetros de filtrado (opcional)}.
El nombre de la URI no debe contener palabras que impliquen acciones, por lo que deben
evitarse los verbos en su construcción. Además, las URI siguen una jerarquía lógica de
capas que permite ordenar los recursos y englobar las distintas funcionalidades entre sí.
Por ejemplo: http://localhost:8080/machines o bien agregando un cuerpo a la llamada
REST en cualquier tipo de formato, siendo los más usados JSON y XML.
Figura 1: Objeto de retorno de la URI en formato JSON

Fuente: Elaboración propia.
B. Uso de la especificación HTTP: para el desarrollo de una API REST es necesario un

conocimiento profundo de la especificación HTTP, sobre todo en lo referente a métodos
permitidos, códigos de estado y aceptación de tipos de contenido.
10
Los métodos son usados para manipular los diferentes recursos que conforman la API.
Los principales métodos soportados por HTTP y por ello usados por una API REST son:
 POST: crear un recurso nuevo.

 PUT: modificar un recurso existente.
 GET: consultar información de un recurso.
 DELETE: eliminar un recurso determinado.
 PATCH: modificar solamente un atributo de un recurso.
Estos métodos junto con la URI, proporcionan una interfaz uniforme que permite la
transferencia de datos en el sistema REST aplicando operaciones concretas sobre un
recurso determinado. Aunque la mayoría de las operaciones que componen una API
REST podrían llevarse a cabo mediante métodos GET y POST, el abuso de ellos para
operaciones que nada tienen que ver con el propósito con el que se concibieron, puede
provocar un mal uso del protocolo alejado del estándar o la construcción de URIs con
nomenclatura errónea mediante el uso de verbos.
C. Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la información
necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar
ningún estado previo para satisfacerla. Aunque esto es así, algunas aplicaciones HTTP
incorporan memoria caché. Se configura lo que se conoce como protocolo cliente-caché-
servidor sin estado: existe la posibilidad de definir algunas respuestas a peticiones HTTP
concretas como cacheables, con el objetivo de que el cliente pueda ejecutar en un futuro
la misma respuesta para peticiones idénticas. De todas formas, que exista la posibilidad
no significa que sea lo más recomendable.
D. Uso de recursos Hypermedia: haciendo uso de hipermedios se le permite al cliente
consumidor de una API REST acceder de manera fácil a la navegación entre recursos, así
como conectar unos recursos con otros que guardan algún tipo de relación entre sí. Este
intercambio de vínculos mediante el uso de hipermedios tiene sus cimientos en el
principio de HATEOAS (Hypermedia As The Engine Of Application State – Hipermedia
Como Motor del Estado de la Aplicación). Este principio permite que cada vez que se
11
hace una petición al servidor, parte de la respuesta que éste devuelve, debe contener
información sobre vínculos relacionados con el recurso que se está consultando. Esto
permite la navegación entre recursos.
Figura 2: Objeto HATEOAS en formato JSON

Fuente: Elaboración propia.
La principal ventaja del uso de una API REST reside en la independencia que proporciona frente
a cualquier consumidor, sin importar el lenguaje o plataforma con el que se acceda a ella. Esto
permite que una misma API REST sea consumida por infinidad de clientes sea cual sea la
naturaleza de estos y que el cambio a cualquier otro tipo de consumidor no provoque impacto
alguno en ella. Esta característica proporciona fiabilidad, escalabilidad y una fácil portabilidad a
cualquier otra plataforma, ya que aísla por completo al cliente del servidor. Sólo se requiere que
el intercambio de información de las respuestas se haga en un formato soportado, por lo general
JSON o XML. Dicha separación entre el cliente y el servidor hace que se pueda migrar a otros
servidores o bases de datos de manera transparente, siempre y cuando los datos se sigan enviado
de manera correcta. Esto convierte a las APIs REST en una de las arquitecturas web más
utilizadas actualmente por la flexibilidad que aportan a cualquier entorno de trabajo sea cual sea
su naturaleza.
2. MICROSERVICIOS Y SPRING BOOT
James Lewin y Marting Fowler, ambos expertos en el campo, definen una arquitectura de
microservicios de la siguiente manera: “El estilo de arquitectura de microservicios es un enfoque
para desarrollar una aplicación individual como un conjunto de pequeños servicios, cada uno
12
corriendo su propio proceso y comunicándose con mecanismos livianos”. Lo que hace Spring
Boot es que facilita la creación de aplicaciones basadas en Spring Framework eliminando toda la
configuración XML. No se trata de generación de código sino que proporciona configuraciones
por defecto a la vez que permite de manera muy sencilla sobrescribir estas configuraciones según
nuestras necesidades.
2.1. Microservicios
Es un enfoque para el desarrollo de una aplicación única como un conjunto de pequeños

servicios, cada uno ejecutándose en su propio proceso y mecanismos ligeros de comunicación, a
menudo un recurso de una interfaz de programación de aplicaciones (API) sobre protocolo de
transferencia de hipertexto (HTTP). Estos servicios están construidos alrededor de las
capacidades del negocio y con independencia de despliegue e implementación totalmente
automatizada. Existe un mínimo de gestión centralizada de estos servicios, los que pueden estar
escritos en lenguajes de programación diferentes y utilizar diferentes tecnologías de
almacenamiento de datos (Fowler y Lewis, 2014).
El término microservicios no es relativamente nuevo, este estilo arquitectural fue acuñado por
Martin Fowler en un taller de arquitectos de software como una descripción del nuevo campo
que los participantes estaban explorando. No existe una definición en concreto para
microservicio, sin embargo una aproximación que la realiza (Newman, 2015) lo define como:
“Pequeños servicios autónomos que trabajan juntos”.
Una arquitectura de microservicios promueve el desarrollo y despliegue de aplicaciones

compuestas por unidades independientes, autónomas, modulares y auto-contenidas, lo cual
difiere de la forma tradicional o monolítico (Wolff, 2016).
También el uso de los microservicios fomentan buenas prácticas de ingeniería, interfaces

limpias, bajo acoplamiento, alta cohesión, escalabilidad independiente. Y algo muy importante
es el que permiten independencia en equipos de trabajo y facilitan el Continous delivering de
forma muy puntual mientras el resto del sistema se mantiene estable y disponible.
13
Figura 3: Patrón básico de arquitectura de Microservicios

Fuente: (Mark Richards, 2015).
Una de las ventajas de utilizar microservicios es la capacidad de publicar una aplicación grande
como un conjunto de pequeñas aplicaciones (microservicios) que se pueden desarrollar,
desplegar, escalar, manejar y visualizar de forma independiente. Los microservicios permiten a
las empresas gestionar las aplicaciones de código base grande usando una metodología más
práctica donde las mejoras incrementales son ejecutadas por pequeños equipos en bases de
código y despliegues independientes. La agilidad, reducción de costes y la escalabilidad
granular, traen algunos retos de los sistemas distribuidos y las prácticas de gestión de los equipos
de desarrollo que deben ser considerados.
14
2.1.1. Beneficios
Un enfoque de microservicios provee de una serie de beneficios tales como:
Figura 4: Beneficios de los microservicios

Fuente: (Wolff, 2016)
A. Intensa modularización: Básicamente, la arquitectura de microservicios consiste en

dividir una aplicación o sistema en partes más pequeñas. La modularización facilita la
automatización y proporciona un medio concreto de abstracción. Los servicios
modularizados son desplegables de forma independiente y ayudan en la velocidad de la
que se entrega del software (Nadareishvili, Mitra, McLarty, y Amundsen, 2016).
B. Intercambiabilidad: Los microservicios se pueden reemplazar más fácilmente que los
módulos en un sistema monolítico. Si un nuevo servicio ofrece la misma interfaz, puede
reemplazar el microservicio existente, el cual puede utilizar una base de código diferente
e incluso diferentes tecnologías, siempre y cuando presente la misma interfaz, lo que en
un sistema monolítico puede ser difícil o imposible de lograr. La fácil sustitución de los
microservicios reduce los costes de decisiones incorrectas, si un microservicio fue
construido bajo la decisión de una tecnología o enfoque, este puede ser completamente
reescrito si surge la necesidad. Esta necesidad de reemplazar el código en el futuro,
frecuentemente se descuida durante el desarrollo de los sistemas de software (Wolff,
2016).
C. Desarrollo sostenible: El desarrollo de software sostenible se debe gracias a la intensa
modularización y la fácil sustitución o intercambiabilidad ya que los microservicios no
están vinculados a una tecnología específica, lo que permite la utilización de nuevas
15
tecnologías apropiadas para cada problema, evitando su caducidad o deterioro por la

acción de su mantenimiento correctivo, evolutivo o adaptativo (dependiendo de qué se
quiere perfeccionar).
D. Entrega continua. Lo que hace especial la modularización, es que cada microservicio
puede ser desplegado de manera independiente. Concretamente, los microservicios
pueden ser, por ejemplo: contenedores (Docker) en los que está instalado el software que
constituye el microservicio que forma parte de un sistema de software general, siendo
alternativamente, partes de una página HTML con llamadas JavaScript o pueden ofrecer
servicios a través de REST, que pueden ser utilizados por otros microservicios u otros
sistemas externos o clientes móviles. Estos microservicios pueden ofrecer una interfaz de
usuario, o llamar a otros que implementan la lógica de negocio (Wolff, 2017).
E. Libre elección de tecnologías. A diferencia de una aplicación monolítica en donde todos
necesitan estar de acuerdo en un lenguaje de programación, frameworks o librerías,
incluso de una versión específica de dichos frameworks, con un enfoque de
microservicios la aplicación puede estar compuesta de servicios independientes que
aprovechan diferentes frameworks, versiones de bibliotecas e incluso plataformas de
sistema operativo completamente diferentes (Scholl, Swanson, y Fernandez, 2016).
F. Time-to-market. Los microservicios reducen el tiempo de lanzamiento al mercado
(time-to-market) pudiendo permitir realizar cambios sólo en aquellos que requieren de un
cambio, cada equipo a cargo del desarrollo de uno o varios microservicios puede
desarrollar e implementar características sin la coordinación de tiempo con el resto de
equipos, lo que permite trabajar en paralelo y poner en producción las nuevas
funcionalidades en corto tiempo. (Wolff, 2017)
2.2. Spring Framework y Spring Boot
En la actualidad existe un debate sobre la diferencia de Spring Framework y Spring Boot, el

primero se centra en proporcionar mayor flexibilidad de configuraciones esto le hace que sea
bastante extenso en las configuraciones, en cambio, Spring Boot es básicamente un conjunto de
frameworks y tecnologías preconfigurados, lo cual proporciona una forma corta de tener una
aplicación web Spring lista para funcionar.
16
2.2.1. Spring Framework
Spring es uno de los frameworks Java EE más utilizados para construir aplicaciones. Spring
Framework proporciona un elaborado modelo de programación y configuración. Su objetivo es
simplificar el desarrollo de Java EE y ayudar a los desarrolladores a ser más productivos en el
trabajo. Puede ser utilizado en cualquier tipo de plataforma de despliegue. Tiene en cuenta las
crecientes necesidades de las empresas de hoy se esfuerza por satisfacerlas.
Figura 5: The Spring Framework arhitecture

Fuente: docs.spring.io (2018)
A diferencia de otros frameworks, Spring se centra en varias áreas de una aplicación y

proporciona una amplia gama de características.
Una de las características principales de Spring Framework es la inyección de dependencias, es

una de las formas que toma la idea de Inversion of Control (IoC). En una aplicación tradicional,
los elementos que realizan tareas hacen llamadas a librerías reusables para hacer ciertos procesos
genéricos, con IoC se consigue que este código sea el que influya en el código que va a realizar
el proceso.
17
2.2.2. Spring Boot
Spring tiene una amplia cantidad de módulos que implican multitud de configuraciones. Estas
configuraciones pueden tomar mucho tiempo, pueden ser desconocidas para principiantes y
suelen ser repetitivas. La solución de Spring es Spring Boot que aplica el concepto de
Convention over Configuration (CoC).
CoC es un paradigma de programación que minimiza las decisiones que tienen que tomar los
desarrolladores, simplificando tareas. No obstante, la flexibilidad no se pierde, ya que a pesar de
otorgar valores por defecto, siempre se puede configurar de forma extendida. De esta forma se
evita la repetición de tareas básicas a la hora de construir un proyecto.
Mientras que Spring Framework se enfoca en brindar flexibilidad, Spring Boot apunta a acortar
código y brindar la manera más fácil de desarrollar una aplicación web. Con la configuración de
anotación y los códigos predeterminados, Spring Boot acorta el tiempo necesario para desarrollar
una aplicación. Ayuda a crear una aplicación independiente con menos configuraciones.
La autoconfiguración es una característica especial en Spring Boot, por lo cual es una de las
tecnologías dentro del mundo de Spring de las que más se está hablando últimamente.
Para los que no están familiarizados con esta tecnología, se podria decir que Spring Boot es una
herramienta que nace con la finalidad de simplificar el desarrollo de aplicaciones basadas en
Spring Core. Spring Boot busca que el desarrollador solo se centre en el desarrollo de la
solución, olvidándose por completo de la compleja configuración que actualmente tiene Spring
Core para poder funcionar.
Spring Boot centra su éxito en las siguientes características que lo hacen extremadamente fácil
de utilizar:
 Configuración: Spring Boot cuenta con un complejo módulo que autoconfigura todos
los aspectos de nuestra aplicación para poder simplemente ejecutar la aplicación, sin
tener que definir absolutamente nada.
18
 Resolución de dependencias: Con Spring Boot solo hay que determinar qué tipo de
proyecto se está utilizando y él se encarga de resolver todas las librerías/dependencias
para que la aplicación funcione.
 Despliegue: Spring Boot se puede ejecutar como una aplicación Stand-alone, pero
también es posible ejecutar aplicaciones web, ya que es posible desplegar las aplicaciones
mediante un servidor web integrado, como es el caso de Tomcat, Jetty o Undertow.
 Métricas: Por defecto, Spring Boot cuenta con servicios que permite consultar el estado
de salud de la aplicación, permitiendo saber si la aplicación está prendida o apagada,
memoria utilizada y disponible, número y detalle de los Bean’s creado por la aplicación,
controles para el prendido y apagado, etc.
 Extensible: Spring Boot permite la creación de complementos, los cuales ayudan a que la
comunidad de Software Libre cree nuevos módulos que faciliten aún más el desarrollo.
“Spring Boot hace que la vida de los desarrolladores sea fácil cuando se crea un código listo
para la producción. Adoptar estas mejores prácticas ayudará a escribir menos y a producir
códigos manejables con poco mantenimiento y menos errores.”
3. Mejores prácticas de Spring Boot
En este apartado, hare referencia a las prácticas que se realizaron en el módulo II del Diplomado
“Experto en desarrollo de aplicaciones empresariales” 1ra versión, recomendaciones que la
mayoría de las veces es aplicable a proyectos con Spring. Estas se enlistan sin ningún orden en
particular.
3.1. Hacer uso de la configuración automática
Una de las características principales de Spring Boot es que hace uso de configuraciones
automáticas. De esta manera Spring Boot hace que tu aplicación se ponga en funcionamiento con
muy pocas configuraciones. La poca configuración que necesita esta en forma de anotaciones.
19
Una de las cosas interesantes que pude experimentar es el que Spring Boot maneja en cada
módulo criterios es decir que tiene valores predeterminados, por ejemplo el uso de Tomcat como
contenedor web.
Figura 6: Tomcat embebido en Spring Boot

Fuente: Elaboración Propia
Esta estructura que proporciona Spring Boot es personalizable, tanto en la configuración inicial,
como en el ciclo de desarrollo, por ejemplo si se prefiere usar Maven se cambiara los valores de
<dependency> en el archivo POM.
Figura 7: Tag´s dependency en archivo POM

20
Los iniciadores son parte de la magia de Spring Boot, se utilizan para limitar la cantidad de
configuración manual de las dependencias que tiene que hacerse, todos los iniciadores utilizan la
siguiente nomenclatura: spring-boot-starter-XYZ, donde XYZ es el tipo de aplicación que se
quiere desarrollar, como se mostró en la figura anterior, a continuación se mostrara algunos de
los iniciadores más populares de Spring Boot:
 spring-boot-starter-web se utiliza para desarrollar servicios web de RESTful con Spring

MVC y Tomcat como el contenedor de aplicaciones incorporado.
 spring-boot-starter-jersey es una alternativa a spring-boot-starter-web que utiliza Apache
Jersey en vez de Spring MVC.
 spring-boot-starter-jdbc se utiliza para el agrupamiento de conexiones JDBC. Se basa en
la implementación del grupo de conexiones JDBC de Tomcat.
Ahora si se necesitaria usar MySql como base de datos simplemente se añade esa dependencia:
Figura 8: Librería MySql en archivo POM

Y si se quisiera trabajar con SqlServer so habría que comentar el tag de la dependencia de MySql
y añadir el de SqlServer, por ejemplo:
21
Figura 9: Librería SqlServer en archivo POM

Al confiar en los iniciadores de Spring Boot, se tendría la certeza de que se está usando una
configuración probada y comprobada que funcionará bien. Todo esto también ayuda a evitar el
temido “Jar Hell” o Infierno de Dependencias.
3.2. Hacer uso de Spring Initializr
En la página oficial de Spring se encuentra disponible la herramienta Spring Initializr

(https://start.spring.io/ ), el cual ofrece una forma totalmente sencilla de comenzar un nuevo
proyecto, donde se puede elegir la herramienta de construcción, Maven o Gradle, la versión de
Spring Boot, los metadatos de la aplicación para el paquete de las clases y artefacto, las
dependencias de otros módulos de Spring y otras librerías populares.
22
Figura 10: Formulario de la herramienta Spring Initializr

Fuente: Pagina web spring.io
Una vez seleccionadas las opciones se genera el proyecto y descarga un archivo compreso zip. Y
dependiendo de la IDE que se esté utilizando el proceso de instalación de las dependencias será
automático o en defecto será necesario escribir el comando maven install, para maven o
gradlew bootRun, para gradle.
Al usar la herramienta Spring Initializr le asegura que está usando dependencias probadas y
aprobadas que funcionarán bien con la configuración automática de Spring. Incluso puede
descubrir algunas integraciones nuevas que no sabía que existían y en pocos minutos disponer de
un proyecto básico funcional y listo para implementar la funcionalidad de la aplicación.
3.3. Estructurar el directorio de paquetes correctamente
Si bien Spring Boot, da la libertad de estructurar nuestra paquetería como se desea, es importante
seguir las siguientes recomendaciones:
23
 No usar solamente todo en el paquete predeterminado, distribuir los archivos creados en

su paquetería bien definida, asegurándose que se encuentren en nivel de jerarquía del
main class del proyecto. De esta forma se evitara sorpresas, (mensajes de error que no se
entienda) relacionadas con la estructura y el componente scan.
Figura 11: Estructura de un proyecto Spring - I

Fuente: Elaboración propia
 Mantener el archivo Application.java (la clase de entrada) en el directorio de origen de

nivel superior. Como se puede apreciar en el anterior figura el archivo
SsibAplication.java se encuentra en el directorio de origen, este archivo tiene el
main, y además tiene la notación @SpringBootApplication, que es un conjunto de
anotaciones, predeterminada y las más importante tiene la notación @ComponentScan,
24
el cual buscara a todos los componentes (beans), que se encuentren en el directorio del
archivo SsibAplication.java.
 Es también recomendable mantener los Controllers y Services juntos en módulos
orientados a la funcionalidad que presenta el proyecto, pero esto es opcional.
Figura 12: Estructura de un proyecto Spring - II

En la figura se observa que todos los Controllers se encuentran en un solo modulo,

de la misma manera los Services, esto es por recomendación de algunos expertos.
3.4. Tener los controladores bien definidos
Una característica principal de REST es que está orientado a recursos, un recurso es cualquier
cosa tiene una URI (Uniform Resource Indentifier), estos recursos se usan a través de peticiones
HTTP donde cada una de los métodos del protocolo (GET, POST, PUT, PATCH, DELETE)
tienen un significado muy específico, para tener unos controladores bien definidos se enlistan las
siguientes recomendaciones:
25
 Los controladores deben ser stateless (sin estado). Los controladores son por defecto
singletons y darles cualquier estado puede causar problemas masivos, según los expertos.
Lo que significa que no es una buena práctica el instanciarlos ya que solo son recursos
que deben ser consumidos a través de peticiones HTTP.
 Los controladores no deben ejecutar la lógica de negocios sino confiar en la delegación
del recurso asignado.
 Los controladores deben tratar con la capa HTTP de la aplicación. Esto no debe pasar a
Servicios.
 Los controladores deben estar orientados en torno a un caso de uso / capacidad
empresarial.
Además de todo lo anterior es importante usar nombres y no verbos para los end-points ejemplo:
POST GET PUT

Recurso DELETE
create read update
Actualización en
Crea una nueva Devuelve la lista Borrar todos las
/machines bloque de
machine de machines machines
machines
Devuelve una Borra una
Método no Actualiza una
/machines/34 machine machine
permitido (405) machine específico
específico específico
Cuadro 1: CRUD para el recurso de machines

No usar verbos como:
- /getAllMachines
- /createNewMachine
- /deleteAllRedMachines
Usar nombres en plural, no es recomendable mesclar nombres de los end-points con nombres en
singular:
- /machine
26
- /UnitOrganizational
- /employee
Usa en plural:
- /machines
- /unitsOrganizational
- /employees
A continuación se muestra el end-point de /machines:
Figura 13: Estructura de un Controlador

Como se puede observar en la figura, el controlador de machines está delegando responsabilidad

a su servicio la lógica del negocio, o sea el cómo debe manejar la información solicitada y
enviada por la capa web, MachineService determinara como esta información podrá ser creada,
mostrada y cambiada, en el siguiente punto se hablara de la responsabilidad de los servicios.
27
3.5. Construir los servicios según las capacidades de negocio
Los servicios son otro concepto central en Spring Boot. Los servicios se usan para escribir la
lógica de negocios, pienso que es mejor crear servicios en torno a capacidades, dominios, casos
de uso de la aplicación.
En el siguiente ejemplo se creara un servicio genérico, no solo para machine, la cual hereda las
propiedades CRUD de CrudRepository.
Figura 14: Servicio genérico que usa CrudRepository

Como se puede observar Spring Boot facilita en todo, ahora solo faltaría implementar el servicio
para machine, en el diplomado se vio distintas maneras de aprovechar las bondades de JPA y el
ejemplo siguiente se manejó procedimientos almacenados.
28
Figura 15: Servicio para Machine con procedimientos almacenados

Al tener un servicio genérico del cual solo se hereda características CRUD, solo faltaría
implementar los diferentes servicios del negocio.
Figura 16: Lista de archivos del módulo Services

29
3.6. Hacer que la base de datos sea un detalle (abstraerlo de la lógica central)
Aunque sea posible escribir código limpio, siguiendo los principios de SOLID, se puede
encontrar que al crecer nuestro sistema, la arquitectura del mismo sea un impedimento, la
filosofía de C. Martin, “Arquitectura Limpia” resume que:
Figura 17: Arquitectura Limpia

Fuente: Robert C. Martin
 Las entidades: son las que incluyen las reglas de negocio críticas para el sistema. Estas
entidades pueden ser utilizadas por distintos componentes de la arquitectura, por lo que
son independientes, y no deben cambiar a consecuencia de otros elementos externos.
 Los casos de uso: son reglas de negocio aplicables a una aplicación concreta. Estos casos
de uso siguen un flujo para conseguir que las reglas definidas por las entidades se
cumplan. Los casos de uso, solo definen como se comporta nuestro sistema, definiendo
los datos de entrada necesarios, y cual será su salida. Los cambios en esta capa no
deberían afectar a las entidades, al igual que los cambios en otras capas externas no
deberían afectar a los casos de uso.
 Adaptadores de interfaz: Los datos generados por los casos de uso y las entidades,
tienen que transformarse en algo entendible por la siguiente capa que los va a utilizar y de
30
eso se encarga esta capa. Pensando en MVC por ejemplo, los controladores y las vistas,
pertenecerían a esta capa, y el modelo, serían los datos que se pasan entre los casos de
uso y los controladores para luego poder presentar las vistas.
 Frameworks y drivers: En la capa más externa es, como dice Bob Martin, donde van los
detalles. Y la base de datos es un detalle, nuestro framework web, es un detalle etc.
Lo que entendí de todo lo que habla C. Martin es que se debe pensar en nuestro sistema, como un
sistema de plugins de forma que los componentes estén aislados y se pueda sustituir unos por
otros sin demasiados problemas. Por ejemplo la base de datos debería poder cambiarse de
Oracle, a SQL Server, a MongoDB, a Casandra o a cualquier otra base de datos sin que afectara
demasiado a nuestro sistema.
3.7. Confiar en el constructor de Inyección
Figura 18: Notación @Autowired y @Inject

Fuente: Alejandro Pérez García, @alejandropgarci 2017
Aunque @Autowired es una anotación especifica de Spring y no pertenece al estándar JSR 330
(Java Specification Request), es una forma de mantener la lógica de negocio, @Autowired es
opcional pero tiene la ventaja de instanciar fácilmente un bean, permite resolver la inyección de
dependencias de los siguientes modos:
 En el constructor de la clase.
 En un atributo
31
 En un método setter.
 En un método JavaConfig.
En la siguiente figura se observa como @Autowired se usa para construir un bean de ese mismo
objeto en su constructor.
Figura 19: Notación @Autowired

3.8. Proporcionar manejo de excepciones globales
Spring ofrece un framework de excepciones a nivel web, por lo cual es posible mapear todos
nuestros errores de CONFLICT, NOT FOUND y BAD REQUEST.
Para ello se mostrara un ejemplo del uso de técnica HandlerExceptionResolver, para definir la
estrategia global de manejo de excepciones como se puede ver en la siguiente figura.
32
Figura 20: Handling con @ResponseStatus

3.9. Usar de Logging framework
Usar esta librería de java me parecía no necesario, lo que yo hacía y la mayoría de mis
compañeros, para depurar su programa era imprimir mensajes así System.out.println(“Estoy
aqui”), porque no usar el Logging Framework, mostrar registros en depuración de nuestro
programa estandarizado, un Logger para el registro en lugar de hacerlo manualmente con
System.out.println(“”). Esto se hace fácilmente en Spring Boot prácticamente sin configuración.
Solo obtén tu instancia de logger para la clase:
Figura 21: Uso de Logger

Esto es importante, ya que le permitirá establecer diferentes niveles de registro según sea
necesario.
33
3.10. Aplicación práctica de una API REST
Para este ejemplo práctico, de una aplicación REST con Spring Boot, se creara un servicio web
para una empresa constructora que registra empleados, equipos, maquinarias, proyectos para lo
cual se hará uso de las siguientes herramientas:
 Maven: Herramienta que automatiza el proceso de construcción de nuestro proyecto

java.
 Spring Initializr: Herramienta web que permitirá crear la estructura de nuestro proyecto
Spring Boot.
 Intellij IDEA: IDE (Entorno de Desarrollo Integrado), un entorno de desarrollo muy
completo, que puede extenderse mediante numerosos complementos (plugins).
 Postman: Herramienta que permite crear peticiones (GET, POST, PUT, etc.) a nuestra
API.
Como primera buena práctica se usara Spring Initialzr, para ello diríjase a la siguiente dirección:
https://start.spring.io/, se debe seleccionar las configuraciones y dependencias necesarias que
tendrá nuestro proyecto Spring, tal como muestra la siguiente imagen:
Figura 22: Configuraciones necesarias en Spring Initialzr

34
Una vez se haya generado y descargado el proyecto se descomprime y luego abrir, con IntelliJ
IDEA, el cual empezara a descargar las dependencias automáticamente
El siguiente paso es crear nuestra clase de dominio, siempre teniendo en cuenta la buena práctica
de C. Martin, en este caso Spring ayuda a que la base datos sea solamente un detalle.
equipment
equipment_id
assign_equipment
name
assign_equipment_id
code
personnel_id
brand
equipment_id
quantity
loan_date
photo
return_date
price
quantity
type
state
active
observation contract
description
assign_supervisor_unit created_by
contract_id
assign_supervisor_unit_id created_by position_id
organizational_unit_id code
personnel_id place
observation salary
created_by start_date
updated_by end_date
created_date organizational_unit [document]
organizational_unit_id
modified_date description
type_organizational_unit_id
version created_by
name personnel updated_by
[level] personnel_id
created_date
description type_personnel_id
modified_date
created_by organizational_unit_id
type_organizational_unit version
type_organizational_unit_id updated_by contract_id
name created_date company_id
[level] modified_date personnel_ci
description version name

assign_material
created_date first_name
assign_material_id
modified_date last_name
personnel_id
version gender
material_id
assign_project birth_date
loan_date
assign_project_id photo
return_date
project_id phone
quantity
personnel_id email
state
project address
name
project_id observation
assignment_date description
name created_by
finish_date active
code updated_by
state
description created_date
observation
created_date modified_date
created_by
modified_date version
updated_by
version
created_date
modified_date
version
material
material_id
name
code
assign_machine brand
assign_machine_id
quantity
personnel_id
photo
machine_id
price
loan_date
type
machine
return_date
machine_id active
quantity
name description
state
code created_by
observation
brand updated_by
quantity created_date
photo modified_date
price version
type
active
description
Figura 23: Clase de dominio

35
La siguiente buena práctica es agrupar las clases en paquetes según las responsabilidades que
tengan.
Figura 24: Estructura de paquetes

En el paquete command se creara los POJO’s, en controller se colocara todos los controladores,
en la carpeta domain se creara toda la clase de dominio y el repositorio que se haya elegido
JPA o CRUD. A continuación se mostrara como quedaría para el recurso de Machine, teniendo
en cuenta las buenas practicas que se mencionó.
Una de las mejores prácticas es el uso de excepciones de manera central, un uso que lo daremos
es al momento de buscar algún elemento de nuestro repositorio como se muestra en la siguiente
figura:
Figura 25: Método genérico findByID, capturando error de solicitud HTTP

36
Para las entidades se creara una base entidad, por las características que son comunes.
Entidad Base
Figura 26: Entidad Base

37
Entidad Machine
Figura 27: Entidad Machine

38
Command Machine
Figura 28: Command Machine

39
Repositorio Machine
Figura 29: Repositorio Machine

Al igual como se hizo una base para las entidades, se hará uno para los servicios
Servicio Base
Figura 30: Servicio Base

40
Servicio Machine
Figura 31: Servicio Machine

41
Controlador Machine
Figura 32: Controlador Machine

42
Para usar el logger, ya se tiene instanciado en MachineController, solo se mandara un logger.info

a la consola del IntelliJ IDEA.
Figura 33: Uso de Logger.info

Para ver el proyecto completo y ver como quedo puede ingresar a la siguiente dirección:
https://gitlab.com/edaeg2/ssib.git.
43
4. Conclusiones
Durante la elaboración de esta investigación se revisó varios conceptos y se reforzó los que
previamente tenía y con la elaboración del proyecto se espera que los lectores adquieran
habilidades necesarias para desarrollar una aplicación REST más óptima, siguiendo las
recomendaciones de los expertos.
Una de las ventajas que brinda Spring es que proporciona la posibilidad de integrar al framework
con otras herramientas o incluso con otros frameworks con el fin de obtener los beneficios que el
desarrollador desea de cada una de ellas. Para esto brinda diferentes módulos, según el tipo de la
herramienta o framework a integrar. Por lo que se puede decir que Spring intenta integrarse con
otras tecnologías y no competir contra ellas, aquí es donde recae la frase de que no trata de
“reinventar la rueda”. Otro de los aspectos más interesantes de Spring es que la complejidad de
la aplicación es proporcional a la complejidad del problema que se está resolviendo.
Se podría decir que Spring Boot recoge todas estas mejores prácticas y las incorpora en sus
versiones, por ejemplo en su página oficial, proporciona la herramienta Spring Initializr, el cual
cumple con la tarea de estructurar la aplicación de una buena manera. Otras de las cosas
interesantes que se puede ver, es que está diseñado con interfaces para que el desarrollador ya
pueda utilizarlas, por ejemplo un caso práctico es hacer que el código sea menos repetitivo al
momento de hacer una lectura y/o escritura de datos en una base de datos, además de hacerlo de
una manera segura y no queden abiertas conexiones a la base de datos y que las excepciones que
se den sean capturadas y traducidas a excepciones del mismo Spring. Los microservicios
fomentan buenas prácticas de ingeniería, uso de APIs e interfaces limpias, bajo acoplamiento,
alta cohesión, escalabilidad independiente, entre otras. Los microservicios permiten
independencia en equipos de trabajo y facilitan el Continous delivering de forma muy puntual
mientras el resto del sistema se mantiene estable y disponible.
Otro enfoque que tiene Spring es que los controladores están diseñados para tengan una única
función, cumpliendo así con una de buena práctica haciendo que los controladores sean Stateless,
todo esto con el propósito de que se enfoque a resolver su tarea de manera más centrada.
44
5. Bibliografía
- Spring Guides. [en línea]. https://spring.io/guides [Consulta: octubre de 2018].
- Spring Initializr. [en línea]. https://start.spring.io/ [Consulta: octubre de 2018].
- Bruno Krebs. [en línea]. https://auth0.com/blog/automatically-mapping-dto-to-entity-on-
spring-boot-apis/ [Consulta: octubre de 2018].
- Bartosz Jedrzejewski. [en línea]. https://www.e4developer.com/2018/08/06/spring-boot-
best-practices/ [Consulta: octubre de 2018].
- Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software
Architectures – Chapter 5: Representational State Transfer (REST). DISSERTATION
UNIVERSITY OF CALIFORNIA, IRVINE 2000.
- Vladimir Pecanac. [en línea]. https://dzone.com/articles/top-rest-api-best-practices
[Consulta: octubre de 2018].
- Nicolai Parlog. [en línea]. https://dzone.com/articles/what-is-jar-hell [Consulta: octubre
de 2018].
- POSTA, Cristian. Microservices for Java Developers - A Hands-On Introduction to
Framework & Containers. California, USA : O'Reilly Media Inc., 2016.
- Patorjk, Text to ASCII Art Generator. [en línea]. <http:// patorjk.com/software/taag/
[Consulta: octubre de 2018].
- Robert C. Martin. Clean Architecture - a craftsman’s guide to software structure and
design. Chapter 7 - SRP: The Single Responsibility Principle. Pearson Education, Inc.,
2018.

Mejores Prácticas para El Diseño de Una API Rest Con Spring Boot

Cargado por

Copyright:

Formatos disponibles

Mejores Prácticas para El Diseño de Una API Rest Con Spring Boot

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Mejores Prácticas para El Diseño de Una API Rest Con Spring Boot

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

“MEJORES PRÁCTICAS PARA EL DISEÑO DE

TRABAJO FINAL PRESENTADO PARA OBTENER EL

POSTULANTE : David Mamani Colque

A Digital Harbor Bolivia por llevar el curso de

A los amigos, compañeros y docentes que he

1. REST VS WEBSERVICES .................................................................................. 6

Figura 1: Objeto de retorno de la URI en formato JSON.......................................... 9

Figura 2: Objeto HATEOAS en formato JSON ...................................................... 11

Figura 3: Patrón básico de arquitectura de Microservicios ..................................... 13

Figura 4: Beneficios de los microservicios .............................................................. 14

Figura 5: The Spring Framework architecture ......................................................... 16

Figura 6: Tomcat embebido en Spring Boot ............................................................ 19

Figura 7: Tag´s dependency en archivo POM ......................................................... 19

Figura 8: Librería MySql en archivo POM .............................................................. 20

Figura 9: Librería SqlServer en archivo POM ......................................................... 21

Figura 10: Formulario de la herramienta Spring Initializr ...................................... 22

Figura 11: Estructura de un proyecto Spring - I ...................................................... 23

Figura 12: Estructura de un proyecto Spring - II ..................................................... 24

Cuadro1: CRUD para el recurso de machines ......................................................... 25

Figura 13: Estructura de un Controlador .................................................................. 26

Figura 14: Servicio genérico que usa CrudRepository ............................................ 27

Figura 15: Servicio para Machine con procedimientos almacenados .................... 28

Figura 16: Lista de archivos del módulo Services ................................................... 28

Figura 17: Arquitectura Limpia ................................................................................ 29

Figura 18: Notación @Autowired y @Inject ........................................................... 30

Figura 19: Notación @Autowired ............................................................................ 31

Figura 20: Handling con @ResponseStatus ............................................................. 32

Figura 21: Uso de Logger.......................................................................................... 32

Figura 22: Configuraciones necesarias en Spring Initialzr ..................................... 33

Figura 23: Clase de dominio ..................................................................................... 34

Figura 24: Estructura de paquetes............................................................................. 35

Figura 26: Entidad Base ............................................................................................ 36

Figura 27: Entidad Machine ...................................................................................... 37

Figura 28: Command Machine ................................................................................. 38

Figura 29: Repositorio Machine ............................................................................... 39

Figura 30: Servicio Base ........................................................................................... 39

Figura 31: Servicio Machine ..................................................................................... 40

Figura 32: Controlador Machine............................................................................... 41

Figura 33: Uso de Logger.info .................................................................................. 42

Hoy en día el uso de web services REST es indispensable en el desarrollo de aplicaciones,

1. REST vs Web Services

1.1. ¿Qué es un servicio Web?

A. Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los Servicios

B. Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA): Los

1.2. ¿Qué es REST?

REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas

REST cambió por completo la ingeniería de software, en la actualidad no existe proyecto o

1.2.1. Principios de REST

 Escalabilidad de la interacción con los componentes: La Web ha crecido

1.2.2. Principales Características de REST

Figura 1: Objeto de retorno de la URI en formato JSON

B. Uso de la especificación HTTP: para el desarrollo de una API REST es necesario un

 POST: crear un recurso nuevo.

Figura 2: Objeto HATEOAS en formato JSON

2. MICROSERVICIOS Y SPRING BOOT

Es un enfoque para el desarrollo de una aplicación única como un conjunto de pequeños