{REST} API: conectando nuestra empresa

keep-calm-and-love-apis-12Si bien la creación de una API de servicios no es algo nuevo, quizás si lo es la tendencia de su generación en formato REST. Para no entrar demasiado en el detalle tecnológico de este tipo de arquitectura, diré que se consideran API REST o RESTful, aquellas interfaces de intercambio de datos o ejecución de operaciones, que son desplegadas directamente sobre el protocolo HTTP. Los formatos más estándar de intercambio para los “contratos”, son JSON o XML. Esta nueva arquitectura, puede exponer nuestros métodos pero sin las abstracciones de otros protocolos de mensaje tales como SOAP. Por todo lo anterior, este tipo de arquitectura, hace que su diseño y despliegue sea mucho más sencillo que SOAP u otros protocolos.

En esta entrada, dejaré de lado la cara más tecnológica de REST, para abordar las bondades de disponer de una API de servicios, eligiendo la arquitectura REST por su sencillez y también, porque en la actualidad, todos los fabricantes de software (por no hablar proveedores de servicios Cloud), exponen sus APIs en este formato.

El por qué de un API

Para los que estén leyendo la entrada y no estén muy en contacto con la tecnología, es posible que esto de las API REST les suene a algo de “modas” como otras muchas veces ocurre en el mundo de la informática. Nada más lejos de la realidad, este tipo de arquitectura, lleva con nosotros desde el 2000 año en el que Roy Fielding la expuso en su tesis doctoral. Si has entrado en esta entrada por medio de tu aplicación de Twitter en tu smartphone, te diré que acabas de utilizar una API REST: https://dev.twitter.com/rest/public

La imagen de los enchufes no es por casualidad. Cuando se habla de APIs el mejor ejemplo para entender qué es y cómo funcionan, es precisamente con enchufes (sin importar la tipología o la forma de los mismos). Así, podemos suponer que nuestro hub de servicios (o ESB), es una regleta de enchufes dónde la electricidad son aquellos datos que queremos compartir y nuestros clientes/preveedores se conectan a éste para consumirlos. De la misma forma, nosotros, nos “enchufaremos” a otros hub de servicios para consumir su “electricidad”.

Dicho lo anterior y abordando la integración de datos (ya sea a nivel interno o externo), considero que hoy en día cualquier empresa que se relacione con terceros ya sea por Web o mediante aplicaciones móviles (teniendo en cuenta las plataformas on-line que existen para crearlas sin tener conocimientos avanzados de programación)

Si queréis adentraos más en la parte técnica de REST, os dejo esta entrada de Asier Marqués (@asiermarques) en la que está muy bien explicado el concepto de REST: “Conceptos sobre APIs REST

Ejemplos de API

Ya he puesto un ejemplo de cómo son utilizadas las APIs por muchas de las herramientas que utilizamos a diario. Espero que con los siguientes ejemplos quede más claro el por qué de las APIs dentro de una organización o empresa.

..\api\{ Publicando nuestro catálogo }

Imaginemos que somos una empresa que dispone de un catálogo de productos/servicios que ofrecemos bien a clientes. Trabajamos de una forma dinámica, por lo que nuestro catálogo cambia constantemente para someterse a ofertas o bien para añadir o retirar items del mismo. Nuestra baza, es tratar de dar a conocer estos cambios lo más rápidamente posible. Y dado que algunos de nuestros clientes ofrecen a su vez nuestros servicios y ofertas en sus web, esta comunicación ha de ser muy fluída. Es por ello que la mejor solución pase por la publicación de nuestro catálogo mediante un servicio que puedan consumir desde sus aplicaciones, plataformas web, ESBs, etc. Una vez definido el formato de salida, ellos podrán trabajar con los datos de manera directa en sus entornos, teniendo siempre la última actualización de nuestro catálogo.

..\api\{ Estandarizando las comunicaciones entre aplicaciones }

Supongamos que estamos cambiando alguna de nuestras aplicaciones internas (CRM, ERP, etc.) por versiones más actuales de las mismas. Con toda seguridad, estas aplicaciones dispondrán de una capa de comunicación y publicación vía API. Si esto es así, podremos comenzar a sustituir los antiguos métodos de intercambio de información entre aplicaciones (en algunos casos puede que incluso con complejos desarrollos a medida o invasivos). Si además de esto, centralizamos todos estos servicios en un punto común (ESB), podremos tener controlado todo el código o desarrollo de los mismos, así, como su monitorización.

Los que hayáis escuchado hablar del IoT Internet of Things, os diré que las API REST forman la columna vertebral de este mundo y como no puede ser de otra forma, todos los proveedores de BigData, ofrecen métodos de conexión para el aprovisionamiento o comsumo de los datos en formato API REST.

Actualmente está en auge la programación de este tipo de servicios utilizando RAML de sus siglas en inglés “Restful API Modelling Language“. Tal como cita en la web oficial de RAML:

REST API Modeling Language (RAML) hace que sea fácil de gestionar todo el ciclo de vida de la API desde el diseño hasta el compartir. Es conciso sólo escribir lo que usted necesita para definir y reutilizable. Es la máquina de diseño legibles API que es amigable realidad humana.

Además de las ventajas de escribir nuestra API centrándonos en el contrato o interface que ofrecerá, se puede utilizar RAML para generar la documentación, el código cliente para consumirla, la estructura básica (scaffolding) del servicio o incluso un server que nos devuelva respuestas simuladas para hacer pruebas.

Servicio de API local o en Cloud

Magic Quadrant for Enterprise Integration Platform as a ServiceLas grandes empresas suelen tener desplegados una serie de servicios para conectar de una u otra manera. Normalmente se utilizan herramientas de integración o ESB y con toda seguridad hasta el momento muchos de estos servicios publicados corresponden al estándar de SOA. Este tipo de herramientas, definidas más como ESB por su perfil de utilización, han ido evolucionando con la tecnología, permitiendo la adopción del estándar REST sin problema alguno. Por ello, las empresas que ya dispongan de un ESB, no deberán preocuparse por ello. Pero, ¿y si no tengo un ESB definido o infraestructura dónde alojarlo?.

Es en este punto en el que surge la posiblidad de un uso de estas herramientas en Cloud (lo que se llama iPaaS Integration platform as a service). Muchos son los proveedores de este tipo de herramientas ya ofrecen sus plataformas de esta forma y con precios en algunos casos muy asequibles. En la imagen, podéis ver el posicionamiento de los proveedores de este tipo tecnología en el Magic Quadrant de Gartner for Enterprise integration platform as a service [05/2015]

Pero si en lugar de utilizar este tipo de herramientas, somos de los que trabajamos con lenguajes y frameworks de desarrollo para servicios Web como Ruby on Rails, Restlet (Java), Django (Python) o VisualStudio (.NET) y no tenemos infraestructura para soportar quizás un alto tráfico de peticiones, podemos usar plataformas de publicación de servicios en la nube tales como Microsoft Azure, Amazon Web Services.

Nuestra infraestructura actual, nuestra evaluación de consumo de los servicios que publiquemos, así como factores tecnológicos, evolutivos y económicos, serán los que marquen las pautas a seguir en uno u otro caso (local, cloud o por qué no híbrido) a la hora de desplegar nuestros servicios REST.

REST API o SOAP

Otro punto que quisiera aclarar sin entrar en detalles, es, si REST API, sustituye a SOAP. Existen debates abiertos entre arquitectos que defienden una u otra postura. Yo soy de los que considera que ambos mundos pueden convivir juntos, puesto que cada uno, aporta diferentes soluciones para la extensión de los servicios dentro de las empresas. Existe un documento en pdf de Rafael Navarro Marset publicado en la Universitat Politècnica de València, dónde podemos ver las diferencias entre las dos APIs: “REST vs Web Services

En cualquier caso, tal como comentaba antes, si trabajamos con herramientas de integración con las que desarrollamos SOAP, ya soportarán REST sin problema, por lo que podremos comenzar a desplegar servicios con este nuevo formato. En caso de trabajar con entornos de desarrollo de código, sólo tendremos que importar las librerías necesarias o instalar los frameworks oportunos para disponer de los objetos y métodos que nos permitan la adopción de REST en nuestros desarrollos.

Principios de los servicios

Aunque se trata de recomendaciones que no son nuevas, hemos de tratar cumplir en la medida de lo posible las mismas a la hora de realizar la definición de nuestra API

  • Hacer los servicios lo más accesibles posible

– Sin barreras de entrada al servicio
– Publicando el servicio a toda la audiencia posible
– Haciendo que el servicio pueda ser consumido por el mayor número posible de agentes

  • Asegurando la evolución de los datos y servicios

– Extendiendo el sistema como un runtime, que trabaje en tiempo de ejecución
– Alterando los recursos sin afectar a los clientes. Que el comportamiento del cliente sea cambiado dinámicamente

  • Creando un sistema escalable, confiable y de alta disponibilidad

– Que sea simple, cacheable y atómico

Si en el diseño de nuestros servicios REST, somos capaces de abstraernos de la capa de seguridad, haciendo que ésta sea parte de una implementación rehusada, podremos tener con el mismo código tanto los contratos de consumo interno, como aquellos que estemos publicando para dar servicio a nuestros clientes o partners. De esta forma nuestro mantenimiento será aún más rápido.

Referencias

Conceptos básicos del lenguaje RAML

Beeva

La interfaz de programación de aplicaciones, abreviada como API (del inglés: Application Programming Interface), es el conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Son usadas generalmente en las bibliotecas de programación.

Wikipedia

La Transferencia de Estado Representacional (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.

Wikipedia

SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por Dave Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros. Está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web.

Wikipedia

iPaaS Integration platform as a service, es un servicio en la nube, que provee una plataforma para el soporte de proyectos de aplicaciones, datos y procesos de integración. Normalmente  que implica una combinación de aplicaciones basadas en la nube, APIs y sistemas on-premises

Gartner

SOA and API Convergence Strategy and Tactics

 , Chief Architect at Karux LLC at dZone

Directorio de APIs

http://www.programmableweb.com/apis/directory

Espero haber ayudado a aclarar qué es esto de REST y el cómo poco a poco este concepto se está convirtiendo en el gran driver de comunicación entre sistemas a lo largo y ancho de “La red”…

I-Love-APIs-300x300

Nos leemos!

Anuncios

Acerca de DaniT20
Arquitecto (antes de Integración de Datos) en una de las compañías punteras de software de gestión a nivel mundial. Involucrado en proyectos de integración empresarial, despliegue de entornos, mejoras de procesos... Amante de la F1, de las tecnologías, de la ciencia, de la música electrónica Como alguien dijo una vez, necesitamos retos en la vida para saber, hasta dónde podemos llegar.

One Response to {REST} API: conectando nuestra empresa

  1. Pingback: Los datos y su contexto | innov@2.0

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: