Post on 26-May-2015
@ideup #theapihour
API como SaaSinformación como valor añadido
@ideup #theapihour
@ideup #theapihour
ideup.Experiencias digitales de máxima rentabilidadwww.ideup.com | ideupBlog | @ideup | Linkedin | Facebook | +34 91 636 63 24
Arquitecto web en ideup
E-mail: pablo.lopez@ideup.comTwitter: @plopesc
@ideup #theapihour
SaaS es un modelo de distribución de software donde el soporte lógico y los datos que maneja se alojan en servidores de una compañía, a los que se accede con un navegador web desde un cliente, a través de Internet.
Una API (Interfaz de programación de aplicaciones) es el conjunto de 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.
¿SaaS? ¿API? ¿API como SaaS?
@ideup #theapihour
¿SaaS? ¿API? ¿API como SaaS?
@ideup #theapihour
Interoperabilidad máquina-máquina
Generalmente, clientes y servidores que, siguiendo el estándar SOAP, intercambian mensajes en XML.
En los últimos años, se ha hecho muy popular un estilo arquitectónico conocido como REST.
¿Servicio Web?
@ideup #theapihour
¿Servicio Web?
RPC (Llamadas a procedimientos remotos)
SOA (Arquitectura Orientada a Servicios)
REST (Representation State Transfer)
@ideup #theapihour
¿Servicio Web?
RPC (Llamadas a procedimientos remotos)
SOA (Arquitectura Orientada a Servicios)
REST (Representation State Transfer) l Ligerol Sencillol Interoperablel Escalable
@ideup #theapihour
¿Por qué REST?
@ideup #theapihour
API en la Actualidad
@ideup #theapihour
API en la Actualidad
@ideup #theapihour
API en la Actualidad
@ideup #theapihour
API en la Actualidad
@ideup #theapihour
API REST en
En deupelegimos el estilo de arquitectura que nos ofrece REST por diversas razones:
• Nos sentimos muy cómodos con el protocolo HTTP
• La experiencia digital que tenemos nos dice que es el estilo más adecuado para muchos de nuestros clientes
• Tenemos experiencia consolidada con Drupal y Symfony y se adaptan muy bien a REST
• La arquitectura se simplifica al máximo, por lo que obtenemos más rendimiento
• Las peticiones también se simplifican, es decir, ganamos velocidad de procesamiento
• Los resultados son visualmente interpretables
• Fácilmente escalable
• Curva de aprendizaje prácticamente inexistente
@ideup #theapihour
API REST
REST está orientado a recursos:
• REST no es RPC, por lo tanto no publicamos verbos como alquilar, sino publicamos nombres como película o socio.
• Cada recurso posee un identificador único universal
• La implementación de un recurso es privada y no accesible desde el exterior
• Cada recurso tiene una interfaz o conjunto de operaciones que admite
• La interfaz es homogénea para todos los recursos
• Las operaciones son stateless
@ideup #theapihour
API REST
Los servicios REST son multimedia, es decir, podemos usar las cabeceras Accept y Content-Type para negociar qué tipo MIME vamos a usar en la comunicación
Una única URI para poder acceder al mismo recurso en diferentes formatos
http://midominio.es/rest/pelicula/43abb4bb4
@ideup #theapihour
API REST
A la hora de modelar APIs, REST nos da la facilidad de hacerlo de diferentes modos, dependiendo del fin que tengamos.
La forma más fácil de diseñar una API REST es siguiendo un estilo orientado a datos (u operaciones CRUD). Cada URI representa una tabla o entidad y mediante los verbos HTTP definimos las operaciones de edición y lectura.
HTTP CRUD Descripción
POST CREATE Crear un nuevo recurso
GET RETRIEVE Obtener la representación de un recurso
PUT UPDATE Actualizar un recurso
DELETE DELETE Eliminar un recurso
@ideup #theapihour
API REST
No es necesario acoplar API al modelo de persistencia de datos.
En muchos casos diseñar el API con este tipo de orientación sería más que suficiente, pero en muchos otros no lo es.
El API debe cumplir su principal objetivo: Ser útil para el usuario
En este punto es cuando le podemos ver la utilidad al concepto de hypermedia
@ideup #theapihour
API REST - HYPERMEDIA
Usuario no debe conocer el API completa
Cliente capaz de autodescubrir todas las posibilidades de la aplicación de forma autónoma
@ideup #theapihour
API REST: apuntes
l Concurrencia
l Etag y persistencia
l Seguridad
@ideup #theapihour
API REST: apuntes
Desde la implementación, para asegurarnos que estamos creando un aplicativo escalable, tenemos que intentar evitar el máximo de operaciones posibles.
Para ello, podemos usar o implementar un sistema de caché en la aplicación de tal modo que sólo creemos el resultado cuando el almacenado en la caché haya cambiado.
Podemos usar varios métodos entre los que destacamos los dos siguientes:
• If-None-Match y Etag: Se realiza un GET condicional de tal modo que sólo devolveremos con la nueva información si ésta ha cambiado. El código de respuesta 304 indica que el recurso solicitado no ha cambiado.
• If-Modified-Since y Last-Modified: En este caso, se comprueba la fecha de modificación del recurso y, si ha pasado, se devuelve la información del servidor. Los relojes del servidor y cliente deberían estar sincronizados.
@ideup #theapihour
Infraestructuras de Sistemas
En ideu los proyectos que realizamos (en su mayoría) están implementados bajos infraestructuras LAMP, con algunas mejoras en ciertos casos para lograr una mayor escalabilidad.
@ideup #theapihour
Caso de éxito: Agregador de cupones
@ideup #theapihour
Notas Finales
• Busca siempre la simplicidad en la implementación. Es lo que hará que el desarrollo del proyecto no se desborde.
• Nuestra API no sólo debe ser simple y fácil de usar, sino que además debe parecerlo: una buena documentación, sencilla pero completa, para que el programador tercero pueda usarla con éxito.
• Escucha a tus nuevos clientes, los programadores: el feedback es importantísimo para la madurez de la API.
• Antes de acometer la fase de diseño e implementación, hacer un estudio de lo que realmente es útil y lo que va a necesitar nuestro cliente.
• Usamos API REST para aprovechar la escalabilidad del protocolo HTTP: Respeta su semántica.
@ideup #theapihour
API como SaaSinformación como valor añadido
@ideup #theapihour