Arquitectura API Rest.

Arquitectura de
APIs REST
Emiliano Cenizo

Índice
- Lo básico: Qué es REST?
- Rest en MELI - Viejo mundo
- Rest en MELI - Nuevo mundo
- Tecnologías interesantes
- Problemas divertidos
- Preguntas / Contacto

Lo básico
Representational State Transfer
Arquitectura para APIs

Lo básico
Se enfoca en los componentes y en la info
que manda, pero no en los detalles
específicos.

Lo básico
específicos.
Preparado para sistemas distribuidos.

Lo básico
específicos.
Preparado para sistemas distribuidos.
REST no necesariamente es a través de
Internet (http)...
Pero hoy hablaremos de REST a través de
Internet mediante los verbos

Stateless
Cacheable
Escalable (horizontalizable)
Estandares muy bien definidos
Intuitivo:
GET
api.mercadolibre.com/sites/MCO
Qué es REST? - Propiedades interesantes

REST en MeLi: Viejo Mundo
Frontends

Frontends Backends

Frontends Backends Items

Frontends Backends Items Preguntas

Frontends Backends Items Preguntas
El gordo
de la
campera
de cuero

Deploys semanales
Probar una feature nueva era complejo
Poco robusto!
Altísimo acoplamiento
Una base para controlarlos a todos
Horizontalizar era difícil
Bardos

REST en MeLi: Nuevo Mundo
Multiples APIs Rest!
Cada api controla sus responsabilidades

REST en MeLi: Nuevo Mundo
Robusto.
Cada API usa la tecnología que necesita usar
Cosas As A Service:
VMs AAS
Bases de datos AAS
Horizontalizar fue simple.
Foco en nuevos devices posible.
Foco en integradores posible.
Ventajas

/items
/pictures
/users
/sites/MCO/categories
/orders
...
/sites/MCO/search
...
/orders
/bookmarks
...
REST en MeLi: Usos

REST en MeLi: Usos
GET https://api.mercadolibre.com/items/MLA624442482

REST en MeLi: Usos
GET https://api.mercadolibre.com/questions/search?item_id=MLA624442482

REST en MeLi: Usos
GET https://api.mercadolibre.com/questions/search?item_id=MLA624442482&attributes=questions.text

Tecnologías interesantes: Elastic Search

Plataforma de búsqueda
Se comunica con REST + JSON
Open source
Distribuido
Soporta full text search
Multitenant
Multi combo con Logstash + Kibana
Tecnologías interesantes: Elastic Search

Sistema de cacheo
Free / open source
Key / Value por REST
Funciona en memoria
Tremendamente simple de usar y adaptar
Tecnologías interesantes: Memcached

RabbitMQ
Apache Solr
Tecnologías interesantes: Menciones
No Rest pero vale la pena mencionar:
MongoDB
Redis

Problemática: Configuraciones. Donde van?
Si están en el código; requieren un deploy para cambiarlas.
Problemas divertidos: Configuraciones

Problemática: Configuraciones. Donde van?
Si están en el código; requieren un deploy para
cambiarlas.
Problema puntual: Cambiar configuraciones en
caliente
Archivo de configuración?
Base de datos?

API REST!
POST /configs
GET /configs/KEY
PUT /configs/KEY
Cacheble!

GET payments/admin/config/BRADEXPDAYS_NONE_163717137?access_token=<TOKEN>

Plataforma de pago de servicios de Brasil
Mecánica: hacias un POST con un ID; asincrónicamente te hacen una
request para obtener todo el resto de los datos.
Problemas divertidos: Pago de servicios MLB

Problemas:
Documentación en
inglés mal traducida

Problemas:
Documentación en
Es un GET, no?

Problemas:
Documentación en
Es un GET, no?
No… :’(

Lecciones aprendidas:
● Cuando te integras contra otra API, no
está de más pedir ejemplos. Muchos.

está de más pedir ejemplos. Muchos.
● Mientras + burocrático un proveedor;
normalmente mejor adaptada la
documentación.

está de más pedir ejemplos. Muchos
● Mientras + burocrático un proveedor;
normalmente mejor adaptada la
documentación.
● Que vos respetes un estándar, no quiere
decir que el resto lo haga.

Problemática: un medio de pago en Colombia que requería
procesamiento complejo.
Problemas divertidos: Transferencias Bancarias

Problemática: un medio de pago en Colombia que requería
procesamiento complejo.
1)Teníamos que crear una nueva transacción por API.
2)Hacia un redirect a la página del banco.
3)Luego, teníamos que periódicamente hacer llamadas al server de
ellos para saber el estado del pago.
4)Resolvemos el pago (payment; el objeto de negocio de Mercado
Pago).

FRONTEND PAYMENTS PROVIDER
Bueno, generemos una API periférica a payments, que lleve eso!
SEMIONLINE
PAYMENTS
bankUrl

FRONTEND PAYMENTS PROVIDER
Bueno, generemos una API periférica a payments, que lleve eso!
SEMIONLINE
PAYMENTS
bankUrl
Pagina del banco

SEMIONLINE
PAYMENTS
PROVIDER
crearTrx
traerTrx
cancelarTrx
PAYMENTS API
aprobarPago
rechazarPago
fondearPago

Problemas:
● Si fallaba algo al medio, el pago quedaba pendiente para siempre.
● Muy difícil de trackear.
● Sumarle un segundo medio a la api, fue un lío.

Solución:

Solución: DESACOPLAR!

SEMIONLINE
PAYMENTS PROVIDER
crearTrx
traerTrx
cancelarTrx
BigQ
POST
Sistema de colas (BigQ)
Por REST, escucha cuando hay cambios en SOP; y notifica
a quien se suscriba.

PAYMENTS API
aprobarPago
rechazarPago
fondearPago
SEMIONLINE
CONSUMER
BigQ
POST
Recibió notificación
Creamos SEMIONLINE CONSUMER

Semionline_payments se ocupaba de las transacciones.
Semionline_consumer de la relación entre transacciones y payments.

Semionline_payments se ocupaba de las transacciones.
Semionline_consumer de la relación entre transacciones y payments.
SOP notifica cambios; SOC escucha los cambios.
Cuando una transacción se aprueba en SOP, SOC actua contra
payments.
De haber inconsistencias o problemas, SOC es el que se encarga de
resolverlos / avisar.

SEMIONLINE
PAYMENTS PROVIDER
crearTrx
traerTrx
cancelarTrx
PAYMENTS API
aprobarPago
rechazarPago
fondearPago
SEMIONLINE
CONSUMER
BigQ
POST
POST

Hoy:
* La API de semionline_payments maneja 5 conexiones a proveedores; con una
6ta en camino (interna); y más de 30 bancos de Latinoamérica.
* Los tiempos son estables, la API robusta; cuando se cae un proveedor aislamos
el problema en esa capa.
* Posteamos toda la data de las transacciones a un elastic search para la rápida
visualización.

Hoy:
* La API de semionline_payments maneja 5 conexiones a proveedores; con una
6ta en camino (interna); y más de 30 bancos de Latinoamérica.
* Los tiempos son estables, la API robusta; cuando se cae un proveedor aislamos
el problema en esa capa.
* Posteamos toda la data de las transacciones a un elastic search para la rápida
visualización.
* Asíncrono = BUENO.
* REST es mejor cuando las responsabilidades están bien definidas y
separadas.
* Desacoplar ES clave: REST se beneficia mucho de no estar; bueno,
acoplado, a los tiempos y particularidades de la contraparte (que lo que te
haga renegar sean tus problemas, no los de otros).

Gracias!
emiliano.cenizo@mercadolibre.com
@EmilianoCenizo
Kanyenke#11899

Arquitectura API Rest.

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Arquitectura API Rest.

Similar a Arquitectura API Rest. (20)

Más de melidevelopers

Más de melidevelopers (20)

Último

Último (16)

Arquitectura API Rest.