FechaVersiónDescripción
23/08/20241.0.0Versión inicial
18/02/20252.0.0Conexiones http, recogida de datos y parseo json

Servicios Rest.

1. Introducción

En esta unidad vamos a trabajar con el procesado de ficheros json. Estos los obtendremos haciendo uso de una API REST a través de la cual podremos acceder a los mismos y de paso nos vamos a familiarizar con este concepto, REST, que es ampliamente utilizado en el desarrollo actual, bien sea para desarrollos locales, web o para dispositivos móviles.

 

2. Servicios REST

Si atendemos a la definición de Wikipedia de los servicios REST encontraremos la siguiente definición:

"La transferencia de estado representacional (en inglés representational state transfer) o REST es un estilo de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo."

Si atendemos a la definición que nos hace Amazon Web Services, desde mi punto de vista más explicativa, encontramos lo siguiente:

¿Qué es API RESTful?

La API RESTful es una interfaz que dos sistemas de computación utilizan para intercambiar información de manera segura a través de Internet. La mayoría de las aplicaciones para empresas deben comunicarse con otras aplicaciones internas o de terceros para llevar a cabo varias tareas. Por ejemplo, para generar nóminas mensuales, su sistema interno de cuentas debe compartir datos con el sistema bancario de su cliente para automatizar la facturación y comunicarse con una aplicación interna de planillas de horarios. Las API RESTful admiten este intercambio de información porque siguen estándares de comunicación de software seguros, confiables y eficientes.

¿Qué es una API?

Una interfaz de programa de aplicación (API) define las reglas que se deben seguir para comunicarse con otros sistemas de software. Los desarrolladores exponen o crean API para que otras aplicaciones puedan comunicarse con sus aplicaciones mediante programación. Por ejemplo, la aplicación de planilla de horarios expone una API que solicita el nombre completo de un empleado y un rango de fechas. Cuando recibe esta información, procesa internamente la planilla de horarios del empleado y devuelve la cantidad de horas trabajadas en ese rango de fechas.

Se puede pensar en una API web como una puerta de enlace entre los clientes y los recursos de la Web.

Clientes

Los clientes son usuarios que desean acceder a información desde la Web. El cliente puede ser una persona o un sistema de software que utiliza la API. Por ejemplo, los desarrolladores pueden escribir programas que accedan a los datos del tiempo desde un sistema de clima. También se puede acceder a los mismos datos desde el navegador cuando se visita directamente el sitio web de clima.

Recursos

Los recursos son la información que diferentes aplicaciones proporcionan a sus clientes. Los recursos pueden ser imágenes, videos, texto, números o cualquier tipo de datos. La máquina encargada de entregar el recurso al cliente también recibe el nombre de servidor. Las organizaciones utilizan las API para compartir recursos y proporcionar servicios web, a la vez que mantienen la seguridad, el control y la autenticación. Además, las API las ayudan a determinar qué clientes obtienen acceso a recursos internos específicos.

¿Qué es REST?

La transferencia de estado representacional (REST) es una arquitectura de software que impone condiciones sobre cómo debe funcionar una API. En un principio, REST se creó como una guía para administrar la comunicación en una red compleja como Internet. Es posible utilizar una arquitectura basada en REST para admitir comunicaciones confiables y de alto rendimiento a escala. Puede implementarla y modificarla fácilmente, lo que brinda visibilidad y portabilidad entre plataformas a cualquier sistema de API.

Los desarrolladores de API pueden diseñar API por medio de varias arquitecturas diferentes. Las API que siguen el estilo arquitectónico de REST se llaman API REST. Los servicios web que implementan una arquitectura de REST son llamados servicios web RESTful. El término API RESTful suele referirse a las API web RESTful. Sin embargo, los términos API REST y API RESTful se pueden utilizar de forma intercambiable.

A continuación, se presentan algunos de los principios del estilo arquitectónico de REST:

Interfaz uniforme

La interfaz uniforme es fundamental para el diseño de cualquier servicio web RESTful. Ella indica que el servidor transfiere información en un formato estándar. El recurso formateado se denomina representación en REST. Este formato puede ser diferente de la representación interna del recurso en la aplicación del servidor. Por ejemplo, el servidor puede almacenar los datos como texto, pero enviarlos en un formato de representación HTML.

La interfaz uniforme impone cuatro limitaciones de arquitectura:

  1. Las solicitudes deben identificar los recursos. Lo hacen mediante el uso de un identificador uniforme de recursos.

  2. Los clientes tienen información suficiente en la representación del recurso como para modificarlo o eliminarlo si lo desean. El servidor cumple esta condición por medio del envío de los metadatos que describen el recurso con mayor detalle.

  3. Los clientes reciben información sobre cómo seguir procesando la representación. El servidor logra esto enviando mensajes autodescriptivos que contienen metadatos sobre cómo el cliente puede utilizarlos de mejor manera.

  4. Los clientes reciben información sobre todos los demás recursos relacionados que necesitan para completar una tarea. El servidor logra esto enviando hipervínculos en la representación para que los clientes puedan descubrir dinámicamente más recursos.

Tecnología sin estado

En la arquitectura de REST, la tecnología sin estado se refiere a un método de comunicación en el cual el servidor completa todas las solicitudes del cliente independientemente de todas las solicitudes anteriores. Los clientes pueden solicitar recursos en cualquier orden, y todas las solicitudes son sin estado o están aisladas del resto. Esta limitación del diseño de la API REST implica que el servidor puede comprender y cumplir por completo la solicitud todas las veces.

Sistema por capas

En una arquitectura de sistema por capas, el cliente puede conectarse con otros intermediarios autorizados entre el cliente y el servidor y todavía recibirá respuestas del servidor. Los servidores también pueden pasar las solicitudes a otros servidores. Es posible diseñar el servicio web RESTful para que se ejecute en varios servidores con múltiples capas, como la seguridad, la aplicación y la lógica empresarial, que trabajan juntas para cumplir las solicitudes de los clientes. Estas capas se mantienen invisibles para el cliente.

Almacenamiento en caché

Los servicios web RESTful admiten el almacenamiento en caché, que es el proceso de almacenar algunas respuestas en la memoria caché del cliente o de un intermediario para mejorar el tiempo de respuesta del servidor. Por ejemplo, suponga que visita un sitio web que tiene imágenes comunes en el encabezado y el pie de página en todas las páginas. Cada vez que visita una nueva página del sitio web, el servidor debe volver a enviar las mismas imágenes. Para evitar esto, el cliente guarda en la memoria caché o almacena estas imágenes después de la primera respuesta y, luego, utiliza las imágenes directamente desde la memoria caché. Los servicios web RESTful controlan el almacenamiento en caché mediante el uso de respuestas de la API que se pueden guardar en la memoria caché o no.

Código bajo demanda

En el estilo de arquitectura de REST, los servidores pueden extender o personalizar temporalmente la funcionalidad del cliente transfiriendo a este el código de programación del software. Por ejemplo, cuando completa un formulario de inscripción en cualquier sitio web, su navegador resalta de inmediato cualquier error que usted comete, como un número de teléfono incorrecto. El navegador puede hacer esto gracias al código enviado por el servidor.

 

¿Qué beneficios ofrecen las API RESTful?

Las API RESTful incluyen los siguientes beneficios:

Escalabilidad

Los sistemas que implementan API REST pueden escalar de forma eficiente porque REST optimiza las interacciones entre el cliente y el servidor. La tecnología sin estado elimina la carga del servidor porque este no debe retener la información de solicitudes pasadas del cliente. El almacenamiento en caché bien administrado elimina de forma parcial o total algunas interacciones entre el cliente y el servidor. Todas estas características admiten la escalabilidad, sin provocar cuellos de botella en la comunicación que reduzcan el rendimiento.

Flexibilidad

Los servicios web RESTful admiten una separación total entre el cliente y el servidor. Simplifican y desacoplan varios componentes del servidor, de manera que cada parte pueda evolucionar de manera independiente. Los cambios de la plataforma o la tecnología en la aplicación del servidor no afectan la aplicación del cliente. La capacidad de ordenar en capas las funciones de la aplicación aumenta la flexibilidad aún más. Por ejemplo, los desarrolladores pueden efectuar cambios en la capa de la base de datos sin tener que volver a escribir la lógica de la aplicación.

Independencia

Las API REST son independientes de la tecnología que se utiliza. Puede escribir aplicaciones del lado del cliente y del servidor en diversos lenguajes de programación, sin afectar el diseño de la API. También puede cambiar la tecnología subyacente en cualquiera de los lados sin que se vea afectada la comunicación.

¿Cómo funcionan las API RESTful?

La función básica de una API RESTful es la misma que navegar por Internet. Cuando requiere un recurso, el cliente se pone en contacto con el servidor mediante la API. Los desarrolladores de API explican cómo el cliente debe utilizar la API REST en la documentación de la API de la aplicación del servidor. A continuación, se indican los pasos generales para cualquier llamada a la API REST:

  1. El cliente envía una solicitud al servidor. El cliente sigue la documentación de la API para dar formato a la solicitud de una manera que el servidor comprenda.

  2. El servidor autentica al cliente y confirma que este tiene el derecho de hacer dicha solicitud.

  3. El servidor recibe la solicitud y la procesa internamente.

  4. Luego, devuelve una respuesta al cliente. Esta respuesta contiene información que dice al cliente si la solicitud se procesó de manera correcta. La respuesta también incluye cualquier información que el cliente haya solicitado.

Los detalles de la solicitud y la respuesta de la API REST varían un poco en función de cómo los desarrolladores de la API la hayan diseñado.

¿Qué contiene la solicitud del cliente de la API RESTful?

Las API RESTful requieren que las solicitudes contengan los siguientes componentes principales:

Identificador único de recursos

El servidor identifica cada recurso con identificadores únicos de recursos. En los servicios REST, el servidor por lo general identifica los recursos mediante el uso de un localizador uniforme de recursos (URL). El URL especifica la ruta hacia el recurso. Un URL es similar a la dirección de un sitio web que se ingresa al navegador para visitar cualquier página web. El URL también se denomina punto de conexión de la solicitud y especifica con claridad al servidor qué requiere el cliente.

Método

Los desarrolladores a menudo implementan API RESTful mediante el uso del protocolo de transferencia de hipertexto (HTTP). Un método de HTTP informa al servidor lo que debe hacer con el recurso. A continuación, se indican cuatro métodos de HTTP comunes:

GET

Los clientes utilizan GET para acceder a los recursos que están ubicados en el URL especificado en el servidor. Pueden almacenar en caché las solicitudes GET y enviar parámetros en la solicitud de la API RESTful para indicar al servidor que filtre los datos antes de enviarlos.

POST

Los clientes usan POST para enviar datos al servidor. Incluyen la representación de los datos con la solicitud. Enviar la misma solicitud POST varias veces produce el efecto secundario de crear el mismo recurso varias veces.

PUT

Los clientes utilizan PUT para actualizar los recursos existentes en el servidor. A diferencia de POST, el envío de la misma solicitud PUT varias veces en un servicio web RESTful da el mismo resultado.

DELETE

Los clientes utilizan la solicitud DELETE para eliminar el recurso. Una solicitud DELETE puede cambiar el estado del servidor. Sin embargo, si el usuario no cuenta con la autenticación adecuada, la solicitud fallará.

Encabezados de HTTP

Los encabezados de solicitudes son los metadatos que se intercambian entre el cliente y el servidor. Por ejemplo, el encabezado de la solicitud indica el formato de la solicitud y la respuesta, proporciona información sobre el estado de la solicitud, etc.

Datos

Las solicitudes de la API REST pueden incluir datos para que los métodos POST, PUT y otros métodos HTTP funcionen de manera correcta.

Parámetros

Las solicitudes de la API RESTful pueden incluir parámetros que brindan al servidor más detalles sobre lo que se debe hacer. A continuación, se indican algunos tipos de parámetros diferentes:

¿Qué son los métodos de autenticación de la API RESTful?

Un servicio web RESTful debe autenticar las solicitudes antes de poder enviar una respuesta. La autenticación es el proceso de verificar una identidad. Por ejemplo, puede demostrar su identidad mostrando una tarjeta de identificación o una licencia de conducir. De forma similar, los clientes de los servicios RESTful deben demostrar su identidad al servidor para establecer confianza.

La API RESTful tiene cuatro métodos comunes de autenticación:

Autenticación HTTP

HTTP define algunos esquemas de autenticación que se pueden utilizar directamente cuando se implementa la API REST. A continuación, se indican dos de estos esquemas:

Autenticación básica

En la autenticación básica, el cliente envía el nombre y la contraseña del usuario en el encabezado de la solicitud. Los codifica con base64, que es una técnica de codificación que convierte el par en un conjunto de 64 caracteres para su transmisión segura.

Autenticación del portador

El término autenticación del portador se refiere al proceso de brindar el control de acceso al portador del token. El token del portador suele ser una cadena de caracteres cifrada que genera el servidor como respuesta a una solicitud de inicio de sesión. El cliente envía el token en los encabezados de la solicitud para acceder a los recursos.

Claves de la API

Las claves de la API son otra opción para la autenticación de la API REST. En este enfoque, el servidor asigna un valor único generado a un cliente por primera vez. Cada vez que el cliente intenta acceder a los recursos, utiliza la clave de API única para su verificación. Las claves de API son menos seguras debido a que el cliente debe transmitir la clave, lo que la vuelve vulnerable al robo de red.

OAuth

OAuth combina contraseñas y tokens para el acceso de inicio de sesión de alta seguridad a cualquier sistema. El servidor primero solicita una contraseña y luego solicita un token adicional para completar el proceso de autorización. Puede verificar el token en cualquier momento y, también, a lo largo del tiempo, con un alcance y duración específicos.

¿Qué contiene la respuesta del servidor de la API RESTful?

Los principios de REST requieren que la respuesta del servidor contenga los siguientes componentes principales:

Línea de estado

La línea de estado contiene un código de estado de tres dígitos que comunica si la solicitud se procesó de manera correcta o dio error. Por ejemplo, los códigos 2XX indican el procesamiento correcto, pero los códigos 4XX y 5XX indican errores. Los códigos 3XX indican la redirección de URL.

A continuación, se enumeran algunos códigos de estado comunes:

Cuerpo del mensaje

El cuerpo de la respuesta contiene la representación del recurso. El servidor selecciona un formato de representación adecuado en función de lo que contienen los encabezados de la solicitud. Los clientes pueden solicitar información en los formatos XML o JSON, lo que define cómo se escriben los datos en texto sin formato. Por ejemplo, si el cliente solicita el nombre y la edad de una persona llamada John, el servidor devuelve una representación JSON como la siguiente:

'{"name":"John", "age":30}'

Encabezados

La respuesta también contiene encabezados o metadatos acerca de la respuesta. Estos brindan más contexto sobre la respuesta e incluyen información como el servidor, la codificación, la fecha y el tipo de contenido.

3. Apis públicas para trabajar

El objetivo de este módulo no es el desarrollo de servicios REST por lo tanto vamos a hacer uso de APIS públicas que se ofrecen para poder realizar nuestros propios desarrollos ya bien sean profesionales o de aprendizaje.

Existen múltiples APIS públicas para practicar:

4. Conexiones http

Para crear una conexión http en Java haremos uso del paquete java.net el cual nos va a permitir realizar una conexión http.

java.net.http Este paquete nos proporcionará todo lo necesario para conectar con un servicioWeb.

Dentro de este paquete haremos uso de las siguientes clases:

Imaginemos que nos creamos un método estático en una clase encargado de la conexión:

Como se puede observar en el código y en los comentarios, lo que realizamos es establecer la cadena de conexión con un tipo URL.

Luego establecemos la conexión, especificamos que vamos a realizar con esta conexión, un GET, y si esta es correcta y ha funcionado el GET, lo devolvemos.

 

Una vez dispongo de la conexión con los datos, lo que voy a realizar es leer estos. Para ello haré uso de BufferedReader e InputStreamReader. Haré uso de un StringBuilder para concatenar resultados:

En el programa principal vemos que invoco al último método creado que me devuelve el String con los datos de tipo JSON y los muestro por pantalla:

 

En el siguiente apartado vamos a aprender a como manejar el componente gson de google que nos va a permitir recorrer y realizar el parseo de la información que contiene el json que hemos obtenido y poderlo tratar.

 

5. Tratamiento JSON con Gson

Para este apartado vamos a trabaja con la librería de Google, Gson, la cual facilita el desarrollo y el tratamiento de estas estructuras de datos.

Si vamos al repositorio de Maven: https://mvnrepository.com/artifact/com.google.code.gson/gson

podemos ver que nos indica lo siguiente:

"Gson es una biblioteca Java que se puede utilizar para convertir objetos Java en su representación JSON. También se puede utilizar para convertir una cadena JSON en un objeto Java equivalente."

Una parte importante es que nos permite una serialización directa. Podemos ver un poquito de información aquí: https://es.wikipedia.org/wiki/Gson

Un poquito más de información, aquí:

https://javadoc.io/doc/com.google.code.gson/gson/2.12.0/com.google.gson/com/google/gson/Gson.html

Para poder gestionar nuestras dependencias en un proyecto, podemos hacer uso de Maven, un gestor de dependencias que nos va a facilitar la tarea de desarrollo.

Cuando creamos un proyecto, debemos seleccionar Maven:

Proyecto_Maven

 

¿Cómo añadir una dependecia?

Esto se hace editando el fichero pom.xml y añadiendo en la sección las nuevas dependencias ():

Maven_Dependency

Pulsamos a actualizar y se conecta al repositorio de maven y descarga esta dependencia.

Con este método podemos recoger los datos. Aquí está el código y en los comentarios el funcionamiento:

 

Dejo aquí el resultado final de la explicación. Parto de la siguiente organización en paquetes:

Organizacion_Proyecto_http

En la imagen he dejado el paquete connect que contiene la clase Conexion la cual implementará el get para obtener los datos.

En el paquete pojo, implemento la recogida de datos y obtención del ArrayList de los Pokemon, en la clase ApiPokemon. Además, en este paquete me dejo las clases que me harán falta, para este ejemplo Pokemon.

Recuerda que debemos añadir la dependencia en maven, esto lo haremos en el pom.xml.

 

Contenido de la clase Conexion:

Contenido de la clase ApiPokemon:

 

Contenido de la clase Pokemon:

 

Programa principal, Main:

 

API de Marvel

Para aprender un poquito el manejo de las mismas, vamos a hacer uso del API de Marvel. Para ello nos daremos de alta en la misma.

https://developer.marvel.com/

Marvel

Pulsamos en GET STARTED

Colocamos nuestro correo:

Marvel2

Indicamos el nombre, apellidos y contraseña:

Marvel3

Y pulsamos en Agree & Continue

Marvel4

Deberás introducir la fecha de nacimiento en formato Inglés.

Aceptamos los términos y nos llevará a una página en la cual dispondremos de los datos de acceso al API. En este dispondremos de un ID, una clave pública y otra privada.

Marvel5

 

Como podemos observar tan solo disponemos de 3000 llamadas diarias.

Si pulsamos a la opción de Interactive Documentation nos llevará al apartado en el cual podemos ver las llamadas GET que podemos realizar.

Marvel6

Si pulsamos dentro de la primera llamada, nos permitirá ver la información del servicio REST que nos permite obtener una lista de personajes de Marvel, como invocar el servicio y los resultados, así como errores, puede devolvernos. También lo podemos testear:

Marvel7

 

Marvel8

Marvel9

 

Vemos un ejemplo de como debemos implementar la conexión y la obtención de in registro de un personaje de Marvel.

 

Partimos de que has accedido al entorno de Marvel y te has creado una cuenta de desarrollador y por lo tanto dispones de unas credenciales para el uso de la API.

Deberemos crear en InteliJ IDEA un proyecto de Java en el que se haga uso del gestor de dependencias Maven.

Una vez hecho esto, debemos añadir las dependencias de las que se hará uso. Esto lo haremos en el fichero pom.xml:

POM

Maven nos detectará en este proyecto que nos faltan las dependencias. Le indicaremos que las descargue.

Con estas, introduciremos el código en el MAIN. Aquí disponéis de este para que podáis probar.

Debemos tener en cuenta que para la conexión se necesita un hash para el cual se hace uso de un timestamp así como de nuestra clave privada y pública.

Se utilizará la clase MessageDigest de Java para generar el hash.

Una vez compilamos y ejecutamos veremos que obtenemos por pantalla la información de este personaje:

 

result

Recuerda cambiar tus claves en el código.