¿Qué se necesita para diseñar y ejecutar una API?

Diseñar y ejecutar una API es difí­cil, y va mucho más allá de los aspectos tecnológicos. En esta charla de APIdays Mediterranea, Manfred Bortenschlager ha tratado varios elementos crí­ticos que determinan si una API tiene éxito o no, como por ejemplo: los objetivos de la API, su diseño, la experiencia del desarrollador, los socios, los recursos, su coste o el valor que genera.

También ha mostrado una herramienta interactiva de apoyo al proceso de reflexión sobre el diseño y la ejecución de la API de forma satisfactoria: API Model Canvas.

APIModelCanvasLa charla, dirigida a actuales o futuros proveedores de APIs, ha dado una visión completa de los distintos factores clave de una API y de la estrategia relacionada con ella, así­ como una metodologí­a sencilla de seguir. En su presentación se pueden encontrar ejemplos prácticos de cómo funciona.

Manfred es un entusiasta de las APIs y trabaja para 3scale aportando soluciones para gestionarlas. Su trabajo consiste, entre otras cosas, en concienciar a los mercados sobre el valor de las APIs y enseñarles a implementarlas. Además, escribe y selecciona artí­culos sobre estrategias y tecnologí­as para APIs para API Magazine.

Fotografí­as de Mariano Cuesta.

Un marco de referencia de APIs de grafos que incorpora el panorama de los servicios basados en la nube

captura-5

Actualmente la proliferación de servicios basados en la nube ha revolucionado la manera en que la gente se comunica, conecta entre sí­, comparte sus archivos y, en última instancia, dirige sus negocios. Así­, tanto las grandes como las pequeñas empresas se ven obligadas a proveer su producto principal mediante una API.

_MG_9867El enfoque OPENi presentado por Michael Petychakis en APIdays Mediterranea analiza y clasifica en categorí­as el panorama de los servicios basados en la nube que existen hoy en dí­a, así­ como las APIs que tienen disponibles de forma pública. Mediante una serie de pasos repetitivos, se diseña un mapa de servicios basados en la nube repartidos en varias dimensiones, y se dirige un análisis en profundidad del conjunto de APIs seleccionadas.

Se propone un conjunto de APIs genéricas (junto con los objetos, funcionalidades y relaciones con otros servicios basados en la nube que aquellas llevan asociados), extrapolando la funcionalidad para varias categorí­as en las que entran otros servicios basados en la nube que unen a distintos proveedores de servicios. Para hacer que esos mapeados sean interoperables y extensibles, se propone un modelado de grafo que consiste en mapear las APIs genéricas con el vocabulario de schema.org.
Además, Michael ha presentado la herramienta API Builder, una plataforma que, sirviéndose de una comunidad, facilita a las empresas la adopción de una API grafo que unifica la experiencia de los servicios basados en la nube y los cloudlets personales. Así­, permite a las empresas construir y mantener fácilmente sus propias aplicaciones de software a pesar de los cambios que puedan realizarse en los CBS de las APIs.

En lí­nea con el debate que se presenta en primer lugar, Michael describe un enfoque novedoso que permite enriquecer los estándares actuales de APIs con las reglas de los negocios. El objetivo es aprovechar los principios REST para habilitar la creación de clientes genéricos que puedan operar como máquinas de estado finitas y navegar de forma autónoma por la enorme Web semánticamente enriquecida.

Fotografí­a de Mariano Cuesta.

Matteo Figus nos habla sobre usar los componentes como microservicios en el mundo front-end

Hoy en dí­a escribir código front-end es todo un reto cuando además debes ser resiliente y robusto dentro de una gran corporación. Tras trabajar en una web junto a docenas de ingenieros que viven en tres continentes distintos, Matteo Figus ha aprendido que la complejidad no se manifiesta solo en el propio código. Permitir a la gente desarrollar nuevas caracterí­sticas e implementar el código varias veces al dí­a, sin que dé ningún problema, es muy difí­cil de conseguir: preferimos que los equipos pequeños sean independientes y no interfieran unos con otros, para que sean rápidos y trabajen a gusto; pero a la vez también queremos optimizar la cooperación cuando esta sea necesaria.

En el mundo front-end los componentes son unidades muy pequeñas de código que proveen de funcionalidades a la aplicación, y todas estas unidades están conectadas para ofrecer una página web completa.

Durante su charla, Matteo ha hablado sobre cómo intentan enfocar los componentes en OpenTable. Siguiendo los principios SOA, elevan los componentes a la categorí­a de servicios, para hacer que los ingenieros puedan crearlos y consumirlos mediante contratos e interfaces claros y bien definidos. Esta manera de trabajar les permite poner en práctica la infraestructura necesaria para optimizar el testeo y para llevar a cabo cientos de cambios cada dí­a sin generar un solo conflicto.

Fotografí­as de Mariano Cuesta.

Marcos Placona, de twilio, nos habla sobre APIs de comunicación

¿Cuántas veces has tenido que hacer que dos APIs distintas se comuniquen entre ellas y te has preguntado cuál serí­a la mejor manera de conseguir que se hablen? ¿Por XML? ¿JSON? ¿HTTP?

¿Te resulta familiar esta situación?

Has usado arquitectura orientada a servicios, pero resulta que tus proyectos hablan idiomas diferentes. Así­ que te toca la ardua tarea de hacer de traductor entre ellos.

Sin embargo, la vida es muy corta y ¡solo se vive una vez! Ya puedes haber dado con la tecnologí­a más apropiada, un correcto patrón de diseño y unos algoritmos optimizados al máximo, que si no consigues que tus aplicaciones hablen correctamente, harán su trabajo igual que lo harí­a un plato de espaguetis.

_MG_9711En esta presentación de APIdays Mediterranea Marcos Placona de Twilio nos ha enseñado el secreto que muchas compañí­as llevan años guardándose y que les permite ser capaces de escalar y responder más rápido a las peticiones. Por ejemplo, una de las caracterí­sticas que debes procurar que tenga tu API es autonomí­a: que dependa del menor número posible de servicios externos para funcionar.

También ha explicado los factores a tener en cuenta en el momento de elegir cuál será nuestro sistema de mensajerí­a y en el de cómo desarrollarlo.

Fotografí­as de Mariano Cuesta.

Arranca APIdays Mediterranea 2015 de la mano de Mike Amundsen

«De Stacia a Hyperion y de vuelta a casa: la historia del héroe hipermedia» es el tí­tulo de la conferencia inaugural de Mike Amundsen en APIdays Mediterranea, de la que ya os hablamos hace unas semanas. Esta edición de APIdays Mediterranea comienza hoy y en Wwwhatsnew tenemos la oportunidad de contaros en directo estos dos dí­as de qué van algunas de las charlas.

Como os habréis podido imaginar por el tí­tulo, la intervención de Amundsen es más bien una invitación a una aventura, una alegorí­a sobre aprender a crear tecnologí­as que ayuden a las personas.

_MG_9381En esta historia, nuestro héroe cambiará las comodidades del tranquilo pueblo de Stacia por el barullo y la emoción de la mágica ciudad de Hyperion, lo cual implica intentar cruzar la Gran Extensión: un bosque misterioso y en constante cambio, lleno de criaturas encantadas y obstáculos que nadie vive para contar. ¿Qué aprenderá por el camino nuestro protagonista? ¿Conseguirá volver a casa sano y salvo?

Con la fuerza que transmiten los mitos antiguos y el poder de la narración, Mike Amundsen lleva a la audiencia a un viaje que nos introduce de lleno en los retos y las maravillas de la programación en la era de la información, y que, al final, nos alienta a todos a embarcarnos en nuestro propio viaje.

Un Babelfish salido del pantano de POX

Uno de los aspectos fundacionales de la Web es el concepto de que, aunque el cliente (el navegador) y el servidor no se hayan «conocido» nunca, deberí­an ser capaces de entenderse e interactuar sin mayor problema.

Este era uno de los problemas clave que Tim Berners-Lee y Robert Cailliau querí­an resolver cuando definieron el hipertexto como «enlazar y hacer accesible información de distintos tipos, en una red de nodos por la que el usuario pueda navegar según le plazca».

La Web programable de hoy en dí­a quizá haya empezado a alejarse de este pilar universal, y en la sesión que Ross Garrett, de Axway, ha presentado en APIdays Mediterranea hemos reflexionado sobre el lenguaje de las APIs web y por qué los desarrolladores y los clientes deberí­an esforzarse por entenderlo.

Para crear un ecosistema que sea sencillo y fácil de acceder nos recomienda que no solo dividamos nuestro gran sistema en pequeñas unidades fácilmente manejables, sino también usar todos los verbos HTTP para responder a las expectativas y evitar complicaciones innecesarias. Nos recuerda que no estamos atados al XML y que no debemos dudar en utilizar el formato que más nos convenga.

Fotografí­as de Mariano Cuesta.

Las APIs desde la trinchera

Empezamos con las charlas simultáneas en APIdays Mediterranea. Después de la pausa para el café, Simon Wood de Holiday Extras nos ha hablado de herramientas para testear nuestras APIs.

Simon ha observado que la gente pasa mucho tiempo depurando las APIs: los programadores tienen que utilizar algo que ni han diseñado ni han escrito, y cuya documentación no siempre es suficiente.

Para un usuario de APIs puede resultar muy frustrante intentar entender la API que quiere usar para su trabajo, y esa frustración empieza en el momento de la selección. Por ejemplo, al buscar una API para el tiempo atmosférico, la oferta de APIs de este tipo puede ser abrumadora. Puede que elijas una inadecuada y que te genere muchas complicaciones luego en el proceso de desarrollo. O puede que te veas obligado a usar una API determinada, porque tu empresa trabaje con otra empresa que le ha ofrecido una API con la que interactuar, y no puedas ni siquiera conectarte a ella por problemas en la red.

Afortunadamente, gracias a los avances en herramientas disponibles hoy en dí­a contamos con múltiples opciones. Así­, para diagnosticar y resolver problemas de conexión podemos usar herramientas como TraceRoute o MTR.
Continúa leyendo «Las APIs desde la trinchera»

Patrick Heneise nos cuenta cómo hacer las APIs (y su rendimiento) escalables

Patrick Heneise, en su charla en APIdays Mediterranea, ha dado una visión general de los retos y dificultades de una API a pleno rendimiento, cuáles son los componentes que cumplen cada papel y cómo se pueden optimizar y escalar apropiadamente estos componentes.

Nos ha guiado en el proceso de identificar los componentes de bajo rendimiento y ha presentado algunas de las herramientas que pueden hacerle la vida más fácil a un arquitecto de APIs. Ha diferenciado entre lo que una API de hoy en dí­a debe y no debe hacer, presentando nuevos patrones y sistemas de optimizar su funcionamiento y, en última instancia, la experiencia del usuario a través de los dispositivos finales.

_MG_9636Dada la amplia variedad de tecnologí­as, lenguajes y paradigmas distintos con los que puede operar una API, Patrick ha pretendido mantener un punto de vista agnóstico en cuanto a plataformas, y no meterse en demasiados detalles de cada plataforma concreta.

Como arquitecto de software y CEO de blended.io, Patrick diseña y crea APIs escalables de alto rendimiento, y aptas para móviles, para distintas startups y compañí­as que trabajan con tiempos de respuesta de 25 ms. y millones de peticiones. Ha escalado sistemas para centros de datos de todo el mundo, garantizando una experiencia de usuario óptima a los consumidores de las APIs.

Fotografí­as de Mariano Cuesta.