En este manual vamos a desmigajar, paso por paso, la creación de una API con servicios REST,

a través el framework Spring, en lenguaje JAVA.

Los pasos a seguir serán:

-Instalación de Spring

Vamos a IntelliJ IDE, buscamos el pluging Spring Boot Helper (es de pago, solo tendremos una
de prueba) y los instalamos. Reiniciamos, abrimos un nuevo proyecto y tendremos esta opción
añadida:

Una vez tenemos esto, ya podemos empezar con la creación de la API REST con Spring.

En la parte superior pondremos el nombre, luego en lenguaje seleccionamos Java, el Type

Maven, en Group vamos a poner com.openbootcamp , seleccionamos JDK 17 y Packagin Jar:
Luego nos lleva a la siguiente página, donde en el apartado web vamos a seleccionar el
framework JERSEY. Damos luego a crear en una nueva Ventana:

Cuando acabe, veremos una serie de carpetas y documentos. El documento pom.xml tiene
todas las dependencias necesarias ya cargadas automáticamente, que son:

También nos ha generado una estructura de directorios, las carpetas Java y resources dentro
de src->main:

Dentro de la carpeta java tenemos una clase ya creada, con sus anotaciones pertinentes, sus
importaciones, su inicialización:

Probamos a correr el programa a ver que ocurre. En el caso de que nos de error algún puerto,
abrimos el siguiente archivo, y escribimos “server.port= 9000”:
Una vez la tengamos corriendo, vamos al navegador, ponemos localhost:puerto-que-
tengamos-asignado y nos aparece esto. Es que estamos dentro de la aplicación:

Ahora empezaremos a implementarlo. Lo primero que haremos, será crear un fichero

configuración para Jersey y decirle donde van a estar nuestros controladores. Un controlador
es lo que va a recibir las peticiones por HTTP y va a procesarlas, es el punto de entrada a
nuestras llamadas. Cuando pongamos por ejemplo

Tengo que implementar algo que procese esto, y se hace mediante un controlador, y estos,
tiene que estar en algún sitio, y ese sitio hay que decírselo a la aplicación. Para ello, la
paramos, vamos a la carpeta java y crearemos un nuevo paquete, que llamaremos config, con
una nueva clase dentro que llamaremos JerseyConfig:
Dentro de JerseyConfig pondremos algunas anotaciones, las cuales le dicen tanto a Springboot
como a Jersey lo que vamos a hacer. Escribimos @AplicationPack (lo autocompleta), el import
se pone solo. Esto quiere decir que nuestra aplicación se ejecuta después del: puerto-que-
tengas-asignado:

También le diremos a Spring que esto, es un componente, para ello, ponemos @Component e
importamos clase si nos lo pide:

Vamos a la clase JerseyConfig, ponemos que hereda de ResourceConfig, si nos lo pide,

importamos la clase. Dentro de la clase JerseyConfig crearemos un constructor, y dentro de
ese constructor, viene lo difícil, que es decirle donde van a estar nuestros controladores. Esto
ya depende de uno mismo, pero hay dos sitios típicos que veremos ahora. Lo primero,
usaremos la función this.packages que hemos heredado de ResourceConfig. Vamos a meterlos
en otro paquete, que crearemos en la carpeta de com.openbootcamp.demospringrest y que
llamaremos controllers. A estas alturas, nuestro entorno de trabajo debería verse así:

Ahora, creamos nuestro controlador. Tenemos que decirle la ruta a this.packages:

Un controlador no es mas que una clase de Java, que crearemos en la carpeta controllers. Para
ellos, vamos a dicha carpeta, creamos una clase de Java que llamaremos
BootcampersController, y dentro pondremos una serie de configuraciones. Lo primero, será
decirle a Spring, que esta clase es un componente con @Component, también que va a
procesar usando @Path(“/”)-> Esta barra, es la que va después del número de puerto, y
significa que cuando me meta en la página raíz, me tiene que decir algo. A estas alturas,
debemos tener lo siguiente:

Procedemos a implementar lo que nos tiene que decir una vez entremos en la página raíz. En
HTTP, el verbo típico para obtener información en GET. Para implementar una función, usando
Spring Jersey, que me devuelvan algo, vamos a implementar los métodos, y en este caso,
implementamos el método GET, luego creamos la función:

En este trocito de código de aquí arriba, le estamos diciendo al controlador que, cuando se
meta en Path (página raíz, la barra) mediante el verbo GET, me pongo un Hola. Esto es lo que
vemos en el navegador al acceder ya que entramos en la raíz:
Cuando estamos programando una aplicación de back end, no vamos a hacerlo así, no
usaremos el navegador, si no que usaremos peticiones de HTTP directamente. Para ello,
usaremos la aplicación curl que viene en el propio Windows, y la ejecutamos a través de la
terminal. La abrimos y escribimos esto (petición), le damos a enter y nos sale en crudo el
resultado. No sale nada bonito, todo esto es back:

Este servicio no esta haciendo nada. Ahora nos complicaremos la vida. Vamos a crear un
“algo”, donde esté la info de los usuarios. El término correcto para esto, es modelo. Un modelo
es lo que da forma, o lo que contiene la información de los datos. Procedemos a crearlo.

Para ello, volvemos al código en IntelliJ, y creamos otra carpeta más dentro de la de
com.openbootcamp.demospringrest a la que llamaremos models:

Y dentro una clase que llamaremos Bootcamper. NOTA: En controllers, tenemos puesto
Bootcampers, en plural, asique a esta la llamaremos la versión en singular. Es una especie de
convención:

A esta parte, a implementar el modelo, se le conoce como POJO -> Plain Old Java Object. Como
aquí en Bootcamper somos personas, vamos a decir que tenemos un nombre, ponemos esto
dentro de la clase:

NOTA: Leer los comentarios de la imagen de abajo

La parte que comunica un controlador con un modelo, se llama servicio. Este servicio estará en
otro paquete, también dentro del com.openbootcamps.demospringrest.

El controlador acepta la petición, el modelo tiene la información y el servicio hace de unión. El

servicio es lo que manipula el modelo. Este patrón se ve en todos los lenguajes todas las
aplicaciones, incluido front, por ejemplo con Angular, sigue esta misma implementación.

El servicio es otra clase, que se llamará Nombre-del-modelo (Bootcamper en nuestro caso)

seguido de service:

Con la anotación @Service encima de public class BootcamperService, le indicamos que esto es
un servicio. Nos pedirá que importemos la clase y se queda así:

Vamos a crear una lista de usuarios utilizando para ello un ArrayList. Va a tener una lista de
Bootcampers, y un método que será meterá un elemento en la lista. Importaremos las clases
necesarias para que no nos marque error:
El modelo models.Bootcamper ya lo tenemos creado en la carpeta modelo, y lo importamos
aquí para poder trabajar con él.

Dentro del servicio, creamos las funciones de getAll y add (obtener la lista y agregar usuario).

NOTA: Cuando creamos @Service ASEGURATE de que ponga Springboot o te va a dar error y
te dira que añadas beans que después tampoco van a rular.

Ya tenemos el servicio (si te fijas, hemos usado un get y un add, son las peticiones) , el modelo
(es donde está la “base de datos”, que tiene un constructor que tiene un método nombre que
tiene un get y un set dentro. Con get devuelve nombre con set mete un nombre y no devuelve
nada, pone void).

Vamos al archivo BootcampersController y quitamos el @GET con lo del “hola”:

Ahí mismo creamos esta variable:

El motivo de la creación de esta variable, es porque el servicio comunica al controlador con el
modelo. El controlador no sabe nada del modelo solo habla con el servicio, que a su vez dice:
ah el modelo este tiene esta info, voy a preguntarle.

Creamos también el constructor, y además haremos una indección de dependencias. Consiste

en que si voy a tener aquí un servicio, el constructor debe tener como parámetro ese servicio,
y si son 20 servicios, pues 20 parámetros.

Constructor con los parámetros

del servicio

El constructor lo que hará será inicializar la variable *

Variable inicializada

Nosotros no vamos a invocar al constructor, es mágico, se llama por debajo automáticamente.

Inicializamos los servicios y ya.
Ahora queremos que cuando alguien se meta en la página, el /Bootcampers le de alguna
información. Para ello, vamos a usar una petición de tipo @GET, con la ruta /Bootcampers y
que devolverá una lista de bootcampers:

Aquí continuamos y creamos una función, que va a devolver la lista de usuarios, que está en
services:

Bien, nos vuelve a salir un error. El error 500 SERVER INTERNAL ERROR. La solución al final, fue
fijarse MUY BIEN en lo que estábamos escribiendo. Voy a poner las capturas de pantalla para
que sea vea lo que estaba pasando:

Ante que nada decir, que el problema aquí era el package, controllers, la clase
BootcampersControllers.java. Era poner BIEN lo que está marcado en amarillo. Fijarse en lo
anterior para ver las diferencias (básicamente poner BootcamperService en minúscula,
bootcamperService):
El motivo es, que en lugar de usar el nombre de la clase, había que poner el atributo de la
mismo, que es igual pero CON LA B MINUSCULA.

Continuamos. Vamos a crear una función que nos muestra una lista de los usuarios. Para ello
lo correcto es hacer esto:

No ponemos return BootcamperService.getAll();, si no que usamos return

bootcamperService.getAll();, en minúscula, porque queremos que nos saque las cosas que
tiene metida esa lista. La función la llamamos ListarTodos(). Lo de “application/json” es para
que nos aparezca mágicamente (se hace por debajo, nosotros no tocamos nada) a través de
json cuando accedemos al localhost:puerto-nuestro/bootcampers. Como no hay nada aun en
la lista, no nos aparece nada en la web, pero ya NO SALE EL ERROR 500 DE LAS NARICES.

Vamos a meter cosas en la lista para que cuando la muestre al acceder al localhost:puerto-
nuestro/bootcampers. Haremos una ñapa, para ello, vamos al constructor en Controllers, y
metemos las siguientes líneas:
Estamos, en este caso, invocando al servicio directamente para meterle a fuego un nuevo
elemento de tipo Bootcamper (new Bootcamper). Estas llamadas que hemos metido y que se
van a ejecutar en el constructor una sola vez, van a coger el Service y van a ir rellenando el
siguiente ArrayList de forma que tenga datos de prueba:

Esto es lo que vemos en el navegador:

No nos sale tan bonito como en el vídeo, porque sale la versión Sample JSON. Ya trastearé con
esto para ponerlo bonito.

Sobre la marcha, le ponemos otro valor. Vamos ahora a nuestro package models, y en nuestro
modelo Bootcamper agregamos lo siguiente para meter un valor matemático doublé aleatorio:

Ffffff no aparece así. Lo vamos a poner de otra manera. Lo metemos como parámetro dentro
del constructor, y luego en Controllers le ponemos el valor, que será Math.random también:
Ahora, queremos crear un nuevo usuario. Para ello, en BootcampesControllers, pondremos un
método @POST, cuyo cometido será crear un nuevo usuario.

Si le envío un @GET a /bootcampers me va a devolver el listado, devuelve información, y si le

envío un @POST me va a crear un usuario. Usamos la misma URL, pero cambiamos el verbo
(de GET a POST) y al cambiar el verbo, el funcionamiento va a ser distinto.

Cuando trabajamos con este tipo de implementaciones, tenemos que devolver un nuevo tipo
de dato, que se llama Response:

Con esto de aquí, estamos metiéndolo en la lista de nuestro servicio, en la lista de memoria. El
servicio podría atacar a una BBDD MYSQL o cualquier otra cosa. Ahora, estamos usando un
ArrayList para que sea mucho más rápido y para que sea en memoria. El tipo de dato devuelta
tiene que ser Response, que tenemos que informar al emisor (al navegador o a nuestra
herramienta curl) de que esto se ha creado:
Vamos a devolver una respuesta con Response, del tipo CREATED (significa que sea ha creado).
Dentro del return Response, como primer parámetro introducimos una URL, que será una URI,
que en nuestro caso será (“/bootcampers/” + bootcamper.getNombre():

Cuando lo ejecutamos en CMD, da error al intentar –X POST para que lo saque.

Vamos a ver si es porque no le hemos metido parámetros:

Sale esto, que es algo así como que el medio(formato) no es soportado, mientras que en el
otro tenemos lo del JSON, aquí no pusimos nada, asique este es el error:

Vamos a solucionarlo poniendole el mismo, tanto en la respuesta:

Como en la petición, que se pone justo debajo con el decorador @Consumes:

ASEGURATE de que @Consumes ponga esto:

Nada, vuelve a saltar UNSOPORTED MEDIA TYPE:

Vale, esto sigue pasando porque lo que le enviamos de “nombre= Yanira” no es JSON. Hay que
ponerlo en el formato de JSON para que funcione y para ello, hay que darle la forma correcta a
la petición, que es esta de aquí abajo:

Vale, a mi me sale un error y no los saca por el navegador cuando hago la petición del
listado(que es entrar en localhost y poner /bootcampers. No sale ni mi nombre ni el de
Ernesto)
Muy bien, como estamos trabajando en Windows y no hay nadie que me lo diga, después de
buscar por Internet encontré que, al estar creando todo desde Windows, el CMD lee el
formato JSON de una forma especial, y es quitando las comillas simples de las llaves y las
dobles de las de los parámetros ‘{“nombre”:”Ernesto”}’ Esto en rojo NO.

En su lugar, donde hay comillas simples hay que ponerlas dobles y donde hay comillas dobles
hay que poner tres comillas dobles. Tal que asi:

Minuto 11. Video 4