Download - Arquitectura API Rest.

Transcript
Page 1: Arquitectura API Rest.

Arquitectura de APIs REST

Emiliano Cenizo

Page 2: Arquitectura API Rest.

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

Page 3: Arquitectura API Rest.

Lo básico

Page 4: Arquitectura API Rest.

Lo básicoRepresentational State Transfer

Arquitectura para APIs

Page 5: Arquitectura API Rest.

Lo básicoRepresentational State Transfer

Arquitectura para APIs

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

Page 6: Arquitectura API Rest.

Lo básicoRepresentational State Transfer

Arquitectura para APIs

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

Preparado para sistemas distribuidos.

Page 7: Arquitectura API Rest.

Lo básicoRepresentational State Transfer

Arquitectura para APIs

Se enfoca en los componentes y en la info que manda, pero no en los detalles 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

Page 8: Arquitectura API Rest.

Lo básico: Qué es REST?

Page 9: Arquitectura API Rest.

Qué es REST? - Json / XML

Page 10: Arquitectura API Rest.

StatelessCacheableEscalable (horizontalizable)Estandares muy bien definidosIntuitivo:

GET api.mercadolibre.com/sites/MCO

Qué es REST? - Propiedades interesantes

Page 11: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Page 12: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Page 13: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Frontends

Page 14: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Frontends Backends

Page 15: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Frontends Backends Items

Page 16: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Frontends Backends Items Preguntas

Page 17: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Frontends Backends Items Preguntas

El gordo de la

campera de cuero

Page 18: Arquitectura API Rest.

REST en MeLi: Viejo Mundo

Deploys semanales

Probar una feature nueva era complejo

Poco robusto!

Altísimo acoplamiento

Una base para controlarlos a todos

Horizontalizar era difícil

Bardos

Page 19: Arquitectura API Rest.

REST en MeLi: Nuevo Mundo

Page 20: Arquitectura API Rest.

REST en MeLi: Nuevo Mundo

Multiples APIs Rest!

Cada api controla sus responsabilidades

Page 21: Arquitectura API Rest.

REST en MeLi: Nuevo Mundo

Robusto.

Cada API usa la tecnología que necesita usar

Cosas As A Service:

VMs AASBases de datos AAS

Horizontalizar fue simple.

Foco en nuevos devices posible.

Foco en integradores posible.

Ventajas

Page 22: Arquitectura API Rest.

/items/pictures/users/sites/MCO/categories/orders...

/sites/MCO/search...

/orders/bookmarks...

REST en MeLi: Usos

Page 23: Arquitectura API Rest.

REST en MeLi: Usos

Page 24: Arquitectura API Rest.

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

Page 25: Arquitectura API Rest.

REST en MeLi: Usos

Page 26: Arquitectura API Rest.

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

Page 27: Arquitectura API Rest.

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

Page 28: Arquitectura API Rest.

Tecnologías interesantes

Page 29: Arquitectura API Rest.

Tecnologías interesantes: Elastic Search

Page 30: Arquitectura API Rest.

Plataforma de búsquedaSe comunica con REST + JSONOpen sourceDistribuidoSoporta full text searchMultitenant

Multi combo con Logstash + Kibana

Tecnologías interesantes: Elastic Search

Page 31: Arquitectura API Rest.

Plataforma de búsquedaSe comunica con REST + JSONOpen sourceDistribuidoSoporta full text searchMultitenant

Multi combo con Logstash + Kibana

Tecnologías interesantes: Elastic Search

Page 32: Arquitectura API Rest.

Sistema de cacheoFree / open sourceKey / Value por RESTFunciona en memoriaTremendamente simple de usar y adaptar

Tecnologías interesantes: Memcached

Page 33: Arquitectura API Rest.

RabbitMQ

Apache Solr

Tecnologías interesantes: Menciones

No Rest pero vale la pena mencionar:

MongoDB

Redis

Page 34: Arquitectura API Rest.

Problemas divertidos

Page 35: Arquitectura API Rest.

Problemática: Configuraciones. Donde van?

Si están en el código; requieren un deploy para cambiarlas.

Problemas divertidos: Configuraciones

Page 36: Arquitectura API Rest.

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?

Problemas divertidos: Configuraciones

Page 37: Arquitectura API Rest.

Problemas divertidos: Configuraciones

API REST!POST /configs GET /configs/KEYPUT /configs/KEY

Cacheble!

Page 38: Arquitectura API Rest.

Problemas divertidos: Configuraciones

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

Page 39: Arquitectura API Rest.

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

Page 40: Arquitectura API Rest.

Problemas:

Documentación en inglés mal traducida

Problemas divertidos: Pago de servicios MLB

Page 41: Arquitectura API Rest.

Problemas:

Documentación en inglés mal traducida

Es un GET, no?

Problemas divertidos: Pago de servicios MLB

Page 42: Arquitectura API Rest.

Problemas:

Documentación en inglés mal traducida

Es un GET, no?

No… :’(

Problemas divertidos: Pago de servicios MLB

Page 43: Arquitectura API Rest.

Lecciones aprendidas:

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

Problemas divertidos: Pago de servicios MLB

Page 44: Arquitectura API Rest.

Lecciones aprendidas:

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

●Mientras + burocrático un proveedor; normalmente mejor adaptada la documentación.

Problemas divertidos: Pago de servicios MLB

Page 45: Arquitectura API Rest.

Lecciones aprendidas:

●Cuando te integras contra otra API, no 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.

Problemas divertidos: Pago de servicios MLB

Page 46: Arquitectura API Rest.

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

Problemas divertidos: Transferencias Bancarias

Page 47: Arquitectura API Rest.

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

Problemas divertidos: Transferencias Bancarias

Page 48: Arquitectura API Rest.

Problemas divertidos: Transferencias Bancarias

FRONTEND PAYMENTS PROVIDER

Bueno, generemos una API periférica a payments, que lleve eso!

SEMIONLINE PAYMENTS

bankUrl

Page 49: Arquitectura API Rest.

Problemas divertidos: Transferencias Bancarias

FRONTEND PAYMENTS PROVIDER

Bueno, generemos una API periférica a payments, que lleve eso!

SEMIONLINE PAYMENTS

bankUrl

Pagina del banco

Page 50: Arquitectura API Rest.

Problemas divertidos: Transferencias Bancarias

SEMIONLINE PAYMENTS

PROVIDER

crearTrxtraerTrxcancelarTrx

PAYMENTS API

aprobarPagorechazarPagofondearPago

Page 51: Arquitectura API Rest.

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.

Problemas divertidos: Transferencias Bancarias

Page 52: Arquitectura API Rest.

Solución:

Problemas divertidos: Transferencias Bancarias

Page 53: Arquitectura API Rest.

Solución: DESACOPLAR!

Problemas divertidos: Transferencias Bancarias

Page 54: Arquitectura API Rest.

Solución: DESACOPLAR!

Problemas divertidos: Transferencias Bancarias

SEMIONLINE PAYMENTS PROVIDER

crearTrxtraerTrxcancelarTrx

BigQ

POST

Sistema de colas (BigQ)Por REST, escucha cuando hay cambios en SOP; y notifica a quien se suscriba.

Page 55: Arquitectura API Rest.

Solución: DESACOPLAR!

Problemas divertidos: Transferencias Bancarias

PAYMENTS API

aprobarPagorechazarPagofondearPago

SEMIONLINE CONSUMER

BigQ

POST

Recibió notificación

Creamos SEMIONLINE CONSUMER

Page 56: Arquitectura API Rest.

Solución: DESACOPLAR!

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

Problemas divertidos: Transferencias Bancarias

Page 57: Arquitectura API Rest.

Solución: DESACOPLAR!

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.

Problemas divertidos: Transferencias Bancarias

Page 58: Arquitectura API Rest.

Solución: DESACOPLAR!

Problemas divertidos: Transferencias Bancarias

SEMIONLINE PAYMENTS PROVIDER

crearTrxtraerTrxcancelarTrx

PAYMENTS API

aprobarPagorechazarPagofondearPago

SEMIONLINE CONSUMER

BigQ

POST

POST

Page 59: Arquitectura API Rest.

Solución: DESACOPLAR!

Problemas divertidos: Transferencias Bancarias

SEMIONLINE PAYMENTS PROVIDER

crearTrxtraerTrxcancelarTrx

PAYMENTS API

aprobarPagorechazarPagofondearPago

SEMIONLINE CONSUMER

BigQ

POST

POST

Page 60: Arquitectura API Rest.

Hoy:

Problemas divertidos: Transferencias Bancarias

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

Page 61: Arquitectura API Rest.

Hoy:

Problemas divertidos: Transferencias Bancarias

Lecciones aprendidas:

* 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).

Page 62: Arquitectura API Rest.

Preguntas?

Page 63: Arquitectura API Rest.

Gracias!

[email protected]@EmilianoCenizoKanyenke#11899