MADA
Metodología Ágil de Desarrollo de APIs
Marco Antonio Sanz
¿Quienes somos?
Grupo de meetup
http://www.meetup.com/API-Addicts/
Meetups realizados
MADA. Metodología ágil de definición de APIs
Taller: Definición de APIs
Taller: Desarrolla tu primera API
Seguridad en las APIs
Las APis en el mundo Big Data
Las APis en el mundo Cloud
Apis como modelo de negocio
Define y desarrolla tu primera API
Marco Antonio Sanz:http://es.linkedin.com/pub/marco-antonio-sanz-molina-prados/18/335/97/
Patrocinadores
¿qué nos ofrece?
know - how de apis
Experiencia en el gobierno de Apis
Ejemplos de arquitecturas
Experiencia en el mundo Cloud
Calle Velasco 13
Tlf: 658 89 75 75
[email protected] · www.cloudappi.net
Objetivo
¿Cual es el objetivo del meetup?
Intercambiar conocimientos sobre todos los aspectos de las Apis, desde tecnologías, seguridad, definición...
Al pensar en una API, hay que pensar en desarrollar productos. Es un traje para varios clientes, por lo que a todos no les puede quedar bien.
Un backend se desarrolla pensando en tu cliente, es un traje hecho a medida.
Api como producto
API Backend
APIs más populares
Google Maps
Twitter
YouTube
Flickr
Amazon Product Advertising
Facebook
Datos recogidos de programmable web
Conociendo las Apis
Crecimiento de las Apis
1) Realizar un documento funcional
2) Realizar el diseño de la API
3) Realizar una implementación fake
4) Implementar la API
5) Validar la API
6) Generar documentación para developers
7) Generar casos de prueba (códigos de ejemplo)
8) Generar los SDks
Desarrollo de Apis
Pasos:
Documentación funcional
Descripción a alto nivel de la APi
Documentación
Descripción técnica de la API
- Formato de la API (SOAP vs REST)
- Seguridad de la API,métodos de autenticación y autorización. Pj: Basic, oauth1, aouth2…
- API Manager (wso2, apigee, genoa) vs ESB (Oracle Service Bus..)
Documentación
Consideraciones generales
Documentación - fakes
Implementando un fake con las interfaces de entrada y salida
- Lenguaje de programación y frameworks a utilizar (java/springmvc, php/zend framework, node/express,.net/.net asp Web API)
- Base de datos SQL vs noSQL
- Instalación en Cloud vs in-house
- Utilización de PaaS, IaaS. ¿Se deben utilizar servicios propios de los Clouds?
- Pruebas de estrés, carga, rendimiento y volumen.
Implementación
Consideraciones generales:
Una vez implementada la API, hay que validar que la implementación cumple con las especificaciones.
- Validación manual: Postman
- Validación automática (SOAPUI, jMETER)
Testing
Validación de la API
Se debe generar documentación clara y comprensible para los developers.
Documentación
Generar la documentación para el developer
Una de las cosas más importantes es generar casos de prueba para que los developers puedan guiarse en la implementación.
Documentación
Casos de prueba
SDKs
Facilitan la integración con las Apis
1) Realizar un documento funcional NO
2) Realizar el diseño de la API SI
3) Realizar una implementación fake SI
4) Implementar la API SI
5) Validar la API SI
6) Generar documentación SI
7) Generar SDKS NO (por el momento)
MADA
¿Donde aporta Valor?
Todo los pasos en el desarrollo de una API deben partir de un único documento, el de definición de la API.
Existen varios lenguaje de definición de APIs que permiten obtener nuestra meta, de los cuales los tres más importantes son
RAML, SWAGGER y BLUEPRINT
MADA
Objetivo
La API se define en RAML, un lenguaje de definición de APIs.
#%RAML 0.8
title: World Music API
baseUri: http://example.api.com/{version}
version: v1
traits:
- paged:
queryParameters:
pages:
description: The number of pages to return
type: number
- secured: !include http://raml-example.com/secured.yml
song**
Parámetros generales de la API
Permite:
Describir la API
Incluir ficheros externos
Utilizar propiedades
Incluir schemas
Definir la versión
Definir el tipo de mediaAType (pj:application/json)
Protocolos (HTTP,HTTPS)
Definir la URL base (URL en la que estará desplegada)
Definir documentación en formato Markdown [MARKDOWN].
Documento de la API
MADA
Permite:
Describir los parámetros de entrada, tanto query parameters como uriParameters, indicando tipo, descripción, valores por defecto, ejemplos de valores...
Definir los parámetros de salida (definirlo tanto como json schema como por xml). Por ejemplo:
/songs:
is: [ paged, secured ]
get:
queryParameters:
genre:
description: filter the songs by genre
delete:
description: |
This method will *delete* an **individual
responses:
200: body: application/json: example: !include examples/instagram-v1-media-popular-example.json
Definiendo métodos GET y DELETE
Documento de la API
MADA
Permite:
Describir los valores de entrada mediante schemas (ya sean json o xsd)
post:
/{songId}:
get:
responses:
200:
body:
application/json:
schema: |
{ "$schema": "http://json-schema.org/schema",
"type": "object",
"description": "A canonical song",
"properties": {
"title": { "type": "string" },
"artist": { "type": "string" }
},
"required": [ "title", "artist" ]
}
application/xml:
Definiendo métodos POST
Documento de la API
MADA
Api Designer
MADA
Desarrollo de una implementación con las interfaces de entrada y salida.
Implementando el servicio fake
MADA
Existen Herramientas para generación de parte del código automáticamente
Permite:
Generar código en Java o Node
Coexistir implementación fake con
Implementación
MADA
Creando un esquema de aplicación con Osprey
Implementación
MADA
Permite:
Generar casos de prueba
Validar los parámetros de entrada como de salida
Importando un raml desde SoapUI
Validando la API
MADA
Generando la documentación con RAML
Documentación
MADA
Desde la consola podemos generar los casos de prueba a partir del RAML
Casos de prueba
MADA
RAML RoadMAP
Generación de código de ejemplo en Java, PHP, .net.
Futuro
MADA
Ruegos y preguntas
Contacta en:
Email: [email protected]
Web: http://www.meetup.com/APIAddicts
Siguenos en:
Linkedin: ApiAddicts
Twitter: @apiaddicts
Facebook: APIAddicts
Meetup: APIAddicts
Contacta
