Que es una REST API?

REpresentational State Transfer (REST) es un estilo arquitectónico que maneja la relación entre cliente y servidor, con el propósito de obtener velocidad y rendimiento utilizando componentes reutilizables.

REST cómo tecnología fue introducida en 2000 en la tesis doctoral de Roy Fielding. Hoy en día se ha implantado de tal forma que es preferida a la tecnología SOAP (Simple Object Access Protocol) ya que usa menos ancho de banda y es más simple y flexible para su uso en internet. Podemos usarlo para recoger o suministrar información desde un web service y se hace vía petición HTTP al API REST.

Qué es un API REST?

Un API REST es una forma de acceder a un servicio web sin tener exceso de procesamiento. Cada vez que se llama a un API REST, el servidor transfiere al cliente una representación del estado de recurso solicitado.

¡De hecho usamos API REST todos los días! Cuando buscamos videos sobre ciclismo en youtube. Tecleas "ciclismo" en el campo de búsqueda de youtube, al presionar enter y se ve una lista de videos sobre ciclismo. Esta es la forma en que trabaja un API REST. Buscamos algo y obtenemos una lista desde el servicion web con los resultados de la busqueda solicitada.

Un API(application programming interface) es un conjunto de reglas que permite a un programa comunicarse con otro. Un desarrollador crea un API en un servidor y permite a otros programas hablar con ella.
REST determina el aspecto del API. Esto es, las reglas que los desarrolladores siguen cuando crean el API y cuando lo utilizan. Una de estas reglas establece que deberías obtener unos datos determinados cuando enlazas con una URL. A esta URL se le llama punto de entrada.
La URL es llamada request (petición) y los datos devueltos se llaman response (respuesta).

Arquitectura RESTful

Las características fundamentales de un API REST, son:

• Sin estado: Ningún dato del cliente se almacena en el servidor. Lo necesario para mantener la sesión entre cliente y servidor se almacena en el cliente, típicamente en sessión storage.
• Client<->eServidor: Hay clara separación de lo que hace el cliente(front-end) y lo que hace el servidor(back-end). Estos operan independientemente y son reemplazables.
• Cache: Los datos provenientes del servidor se cachean en el cliente, esto mejora la velocidad de obtención de datos.
• Composición de la URL: Se usa un enfoque estándar para la composición de las URLs. Por ejemplo, una petición con método GET "http://servidor/ciudades" devuelve una lista de ciudades mientras que "http://servidor/ciudades/burgos" desvuelve los datos de la ciudad de Burgos. Las APIS REST también ejecutan acciones para añadir, modificar o borrar datos como se explica a continuación.

REST en acción

La petición se envía desde el cliente al servidor vía HTTP como una URL que enlaza con una web. Está petición usa los métodos http GET, POST, PUT o DELETE. Entonces la respuesta es enviada desde el servidor en forma de recurso que puede ser HTML, XML, imagen o JSON. JSON es el más popular.

HTTP tiene entre otros los métodos: POST, GET, PUT, y DELETE. Estos métodos corresponden con las operaciones crear(create), leer(read), actualizar (update) y borrar (delete). Estas son llamadas las operaciones CRUD y son muy habituales en los aplicativos. Cada uno de estos métodos opera de la siguiente manera:

• POST: Este método se usa para crear un nuevo recurso. Si todo va bien devuelve un código 201 con una cabecera conteniendo el enlace al nuevo recurso.
• GET: Este método se usa para recuperar un recurso. Si todo va bien GET devuelve por ejemplo un XML o JSON con los datos solicitados y un código de respuesta 200. Si algo va mal devuelve un código de error, por ejemplo 404 Not Found o 400 Bad Request.
• PUT: Se usa principalmente para actualizar un recurso o en casos especiales para crearlo. Un update que se ejecuta con éxito retorna un 200 o 204 sino devuelve ningún contenido en el body. Si se usa para creación y acaba bien devuelve un 201.
• DELETE: Borra un recurso, normalmente se suministra el identificador. Después de un borrado con éxito devuelve 200.

Las operaciones CRUD se envían desde el cliente al servidor escribiendo una URI en un browser o haciendo un fetch en un programa. En los servidores se instalan servicios que responden a estas peticiones mediante distintos puntos de entrada. Un ejemplo de como son habitualmente estos puntos de entrada es:

GET  /device-management/devices      : recupera todos los devices
POST  /device-management/devices      : crea un nuevo device
GET  /device-management/devices/{id} : recupera el device con identificador id
PUT  /device-management/devices/{id} : actualiza el device con identificador id
DELETE /device-management/devices/{id} : borra el device con identificador id

Trabajando con los datos del API REST

También es una práctica habitual que el API REST devuelva datos en formato JSON. El formato  JSON (JavaScript Object Notation), cuando se reciben datos de un API Rest tienen el siguiente aspecto:

{

    title: "Hola, Soy JSON",
    content: [
        chapter: "1",
        page: "100",
        firstParagraph: "Soy JSON, este es mi aspecto cuando me devuelve el API."
    ],
    author: "Bruce Smithesson"
}

¿Dónde se pueden encontrar APIs REST? ¡¡¡Por todos los lados!!! Twitter. Google. Open Weather Map. YouTube.  La mayoría de los servicios más populares que se usan actualmente utilizan una arquitectura RESTful. Así que ¡adelante!, explorad el mundo de añadir funcionalidad de API a vuestros sitios WEB.

Conclusión

Hemos echado un vistazo a lo que es un API REST e indagado en lo que es arquitectura RESTful. Hemos visto como funciona un API REST a través de puntos de entrada y visto como es un fichero en formato JSON.

Este Post es una traducción e interpretación a mi entender del POST
https://itnext.io/javascript-fundamentals-an-introduction-to-rest-apis-7cbe8a809d3b

Qué es el "Chaos Monkey"

Chaos Monkey es una herramienta software que de forma aleatoria detiene instancias y contenedores que están ejecutándose en el entorno de producción. El objetivo es exponer a los sistemas a fallos para ayudar a los ingenieros a proveer servicios que sean capaces de reaccionar a caídas y otros problemas inesperados.

La herramienta es de uso libre y se puede descargar en https://github.com/Netflix/chaosmonkey

Gareth Bowles, antiguo empleado de Netflix, en su presentación de 2015  "I Don't Test Often ... But When I Do, I Test in Production" que se puede consultar en https://www.youtube.com/watch?v=xkP70Zhhix4 explica los motivos que condujeron a Netflix a desarrollar una herramienta basada en la ingeniería del caos.

Gareth explica que debido a las características del servicio que proporciona Netflix, se hacía muy difícil probar en un entorno que no fuese el de producción. A veces la cuota de internet que ocupan los clientes de Netflix supone hasta un 34% del total del tráfico de Internet. Simular esto en un entorno de pruebas era imposible.

Entonces se les ocurrió que podían hacer varias cosas:

1. Chaos Monkey
2. Coverage en producción
3. Canary deployment

1. Chaos Monkey 

Es una herramienta software que provoca la caída de servicios en producción. De esta forma los ingenieros pueden experimentar las consecuencias de la caída y aprender a que hacer para preveer los efectos no deseados de la caída. Las caídas provocadas se hacen a horas de trabajo, donde todos los ingenieros están en la oficina y pueden ponerse manos a la obra para arreglar los problemas inmediatamente. Esto es una ventaja frente a caídas fuera de horas, que hacen que los desarrolladores y operadores tengan que salir corriendo y trabajar a deshoras o en jornadas interminables.

Cómo Chaos Monkey funcionó bien, se decidieron a desarrollar otros monkeys: Chaos Gorilla simula la caida de una zona completa de servidores y Chos Kong de una región que agrupa zonas. 

También idearon otros monkeys que por ejemplo degradan el tiempo de respuesta Latency Monkey o simulan que un servidor no cumple los estándares de configuración Conformity Monkey.

2. Coverage en producción

Es una forma de telemetría, en la que se mide que líneas de código se ejecutan en producción y cuantas veces se ejecutan.
Estas mediciones permiten saber cúal es la parte de código que se debe de probar más porque se ejercita más veces. Es decir, se pueden planificar, construir y ejecutar pruebas más efectivas.

3. Canary deployment

Se trata de desplegar software inicialmente en solo algunos servidores. Con este despliegue se comprueba si el nuevo software responde a las expectativas: funciona bien, no degrada el servicio, los usuarios lo encuentran útil, etc. El nombre de este tipo de despliegue proviene del uso de canarios en las minas para controlar la calidad del aire. En el caso de que el canario se viese afectado por la calidad del aire, las personas tenían tiempo de escapar antes de que la mala calidad del aire les afectase a ellos.

Una vez comprobado que el software cumple con las expectativas se procede a desplegarlo en el resto de los servidores. O no desplegarlo si no cumplió las expectativas.

Conclusión

Estas iniciativas han contribuido al éxito de Netflix que sin duda es una plataforma ampliamente utilizada. Por lo tanto aprendamos de ellos y quizás en otros ámbitos algunas de estas técnicas puedan usarse para ayudar a mejorar.

¿Qué es un doble de pruebas?

Las apps, las webs y otros tipos de aplicativos, están compuestos por un conjunto de módulos que funcionando todos de forma armoniosa nos ofrecen las funcionalidades que tan útiles nos resultan para realizar múltiples operaciones. Me refiero a aplicaciones cómo por ejemplo las de los bancos. Hoy en día gracias a ellas somos capaces de resolver muchas gestiones sin movernos de donde estemos.

Los distintos módulos que componen estas aplicaciones se han de probar antes de ponerlos a disposición de los clientes. No nos haría ninguna gracia perder dinero de nuestras cuentas por errores informáticos, Verdad?. Los módulos se pueden probar de forma manual o de forma automática. Para probar módulos de forma automática lo que se hace es escribir un módulo que es capaz de probar. Es decir, hacemos programas que prueban programas.

El automatizar las pruebas de los programas es una tendencia actual. Múltiples organizaciones han demostrado las múltiples ventajas que supone tener automatizadas las pruebas. Con pruebas automatizadas las aplicaciones se:

• Desarrollan mejor
• Cambian y actualizan mejor
• Funcionan mejor

Para escribir programas de pruebas existen múltiples librerías que ayudan al programador. Hay librerías tanto de pago cómo gratuitas para casi todos los lenguajes de programación.

Desde hace mucho tiempo el tema de las pruebas ha sido una preocupación para los profesionales de la informática. Para abordar su ejecución hay un estándar de facto sobre los tipos de pruebas a las que se debe someter a un aplicativo. En primera instancia se diferencias la pruebas funcionales de las no funcionales. Las pruebas funcionales se dividen en:

• Pruebas unitarias
• Pruebas de integración
• Pruebas del sistema
• Pruebas de aceptación 

Una vez establecido este escenario, se puede entender lo que es un doble de prueba. Primero se centra el discurso en la pruebas unitarias.

Las pruebas unitarias tienen el objetivo de asegurar el buen funcionamiento de cada uno de los módulos que componen el aplicativo de forma aislada, es decir no se quieren probar las interacciones con otros módulos. Es aquí donde los dobles de prueba son necesarios. Si se quiere probar un módulo que para funcionar necesita de otros pero se quiere probar de forma aislada, una solución es dotar a la prueba de suplantadores de los módulos necesarios para que el módulo bajo prueba pueda llevar a cabo su función. Estos suplantadores son los dobles de prueba. Es decir, son simulacros de módulos que implementan funcionalidades diversas.

Por ejemplo en el aplicativo del banco, podemos estar probando un módulo que recoge de una base de datos la información sobre la cuenta corriente de un cliente dado y los envía a un fichero de log. Suponiendo que el módulo bajo prueba para recoger esos datos hace uso de otro módulo que es el que accede a los datos, para la prueba unitaria se crea un doble de prueba que suplanta al módulo que accede a los datos. Esto independiza la prueba del módulo bajo prueba del módulo con el que interacciona. Aunque el módulo de acceso a datos auténtico deje de funcionar, la prueba del módulo que escribe en el fichero de log seguirá funcionando correctamente.

Los dobles de prueba son imprescindibles para conseguir hacer pruebas unitarias ya que consiguen aislar la prueba de cada modulo ciñiendose a probar solo ese módulo. Sin ellos esta sería una labor imposible.

Al igual que para construir pruebas unitarias para los otros tipos de pruebas los dobles también tienen utilidad. Un ejemplo en las pruebas de integración un conjunto de módulos se invoca a otro sistema para solicitar las coordenadas de una ubicación. Se puede hacer un doble de prueba que suplante al sistema de ubicaciones, de esta forma aunque el sistema de ubicaciones no esté disponible podemos ejecutar la prueba de nuestro conjunto de módulos.

Un doble de prueba es un módulo que suplanta a otro y simula su funcionalidad con el objetivo de poder hacer una prueba de otro que interacciona con él.

Para información más detallada y con ejemplos de código, ver el post "Pruebas software. Dobles de prueba con ejemplos (Java, Junit y Mockito)" publicado en este mismo blog el 29/9/2019.