API como SaaS

@ideup #theapihour
API como SaaS
información como valor añadido
@ideup #theapihour

@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
Ligero
l
Sencillo
l
Interoperable
l
Escalable

@ideup #theapihour
¿Por qué REST?

@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/43
abb4bb4

@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.

API como SaaS

Más contenido relacionado

Similar a API como SaaS

Más de Pablo López Escobés

API como SaaS