Nuestra API
Daniel Rabinovich
CTO - MercadoLibre
@drabinovich
Agenda
Quiénes somos
Nuestra API
MercadoLibre
#1 sitio de e-commerce más grande del LatAm
#8 sitio de e-commerce más grande del mundo
90MM usuarios registr...
Un poco de "scalability porn”
7Gbps de tráfico
1,4 BN de hits al día en el front-end
7,2 BN de hits al día en la API
1800 ...
Un ecosistema de ecosistemas
Mercado
Pago
Publicidad
Mercado
Envios
Mercado
Shops
Agenda
Quiénes somos
Nuestra API
Contexto
Diseño
Monetización
Monolítico -> Desacoplado
Nacimos monolíticos, desacoplamos (justo) a tiempo
Monolítico Desacoplado
Monolitos -> presión creciente
Cambios en el entorno exigen flexibilidades para las que no están preparadas
Monolítico
Esc...
Comemos el pescado que vendemos
Front-end Mobile Back-end
Una única API
Developers
Compartimos exactamente la misma API qu...
Una API es una necesidad interna,
antes que una externa
Partimos MercadoLibre en 100 “celdas”
Code
Infra
structure
Data
Team
Facebook
Search
View Item Paage
Listings
Users
Orders...
Posponer soluciones
!=
No prever soluciones
"The bright side of being late is
that (if you're still alive) you
can leapfrog"
Agenda
Quiénes somos
Nuestra API
Contexto
Diseño
Monetización
REST sobre HTTP
El mundo descripto en términos de “recursos”
/sites/MLA
/users/4605484
/items/MLA473364655
/pictures/MLA30...
Sólo verbos estándar HTTP
Minimizan la necesidad de leer documentación
Obtener Crear Modificar Borrar
Verbos STD evitan DOCs
En SOAP podría ser “updateUser”, “alterUser”, etc. Sobre REST no hay duda!
PUT /users/4605484
{
las...
Una API no sólo es una
interfaz para computadoras.
Repasamos conceptos de Usabilidad
Pueden aplicarse directamente a los usuarios de una API
Learnability
Efficiency
Satisfac...
Pretty Print: la vista para el Developer
La API detecta cuando se navega desde un browser, y se “autodocumenta”
Para máqui...
Pretty Print: recursos relacionados
Los IDs se transforman en links en la vista “para humanos”
Introspection: la API se autoexplica
La API genera su propia metadata a través del verbo STD "OPTIONS"
OPTIONS /sites
Usabilidad orientada al programador
Las convenciones son el activo oculto más importante de una API
• “AR” vs “0001”
(ISO ...
Diseñar para el caso canónico
Ej: el GET /items tiene como caso canónico mostrar la página de producto
GET /items/MLA47266...
Caso canónico justifica desnormalizar
La API de un artículo resuelve la URL de la foto para evitar el request adicional
/i...
El problema “N+1”
Típico en front-ends de listados: 1 request para los IDs + uno por cada producto
Sergún REST “Kosher”
20...
Selection
La capacidad de pedir menos atributos que los dflt del recurso
/items/MLA121484389?attributes=title
{
title: "Bo...
N+1 -> Selection + Multiget
Multiget: la capacidad de obtener N recursos en un solo API call
/items?ids=MLA121484389,MLA12...
"There is no free Lunch"
Selection y Multiget
son violaciones a REST
con costos ocultos
Difícil de “cachear” y “shardear”
Amigarse con la inconsistencia
Prerrequisito básico para poder escalar horizontalmente
• Brewster’s CAP Theorem
(Consitenc...
El verbo SEARCH: reglas de convivencia
Recursos base: CRUD + push para que otros armen índices
SearchListings
Push notific...
Un ejemplo simple
Para buscar por "apodo" habría que crear un índice en el recurso USERS
/users/search?nickname=LEWIS_CARR...
Balancear requests a la “celda” correcta
Cada celda es responsable de generar sus propias reglas de balanceo
Users SearchU...
El usuario debe percibir
una sola API
Estandarización del paginado
OFFSET y LIMIT mejor que PAGE=N, permite controlar el tamaño de la página
/sites/MLA/search?q...
Caching es diseño, no optimización
Las estrategias de cacheo pueden alterar el diseño
• Validation:
Consistente, pero con ...
Autenticación y autorización
Son dos conceptos muy diferentes
Autenticación:
Confirmar la identidad del usuario
a través d...
Autenticación
OAuth 2.0 permite que aplicaciones
3 actores:
• MercadoLibre
• Usuario
• Aplicación
OAuth permite que aplica...
Recursos públicos
Son visibles para todos los actores del sistema
GET /users/46054484
Recursos privados
Son accesibles sólo para sus dueños. OAuth les provee un ACCESS_TOKEN
GET /users/me?access_token=ABC
El usuario “autoriza” las apps
A operar en su nombre. El app no obtiene acceso a sus credenciales.
Las reglas de negocio son parte de la API
Es una excelente manera de no duplicar lógica
Por ejemplo, las reglas de pricing...
Lockeos y HTTP
Un mecanismo elegante dentro del protocolo, para hacer optimistic locking
Una manera de aplicar
optimistic ...
Atómico y Stateless
Independientemente de la cantidad de pasos que tengan los front-ends
User
SYI
FrontEnd
Items
API
Selec...
HTTP return codes -> Parte de la API
Cuanto más estándares usemos, más gente sabrá usar la API sin leer la DOC
201: Object...
Push Notifications
Clientes externos pueden suscribirse a "Topics"
Versionamiento
La API debe cambiar a distintas velocidades según el tipo de app que soporta
Versionamiento
La API debe cambiar a distintas velocidades según el tipo de app que soporta
api.mercadolibre.com v1.api.me...
Comunidad
El "churn" de developers es enorme sin una comunidad fuerte detrás
developers.mercadolibre.com
github.com/mercad...
SDKs
Proveen un buen rest client y los flujos de OAuth
Agenda
Quiénes somos
Nuestra API
Contexto
Diseño
Monetización
TML-YLGDE
Fuente: Fede Procaccini
Esquemas de monetización
Compradores
17MM (2012)
Vendedores
6MM (2012)
150K profesionales
Revenue Share
(compartimos la
co...
El nicho: servicios a vendedores
Gestores de ventas, inventario, logística, integradores con ERPs, CRMs, etc
La API está tomando tracción
Retailers, Integradores, Gestores de Ventas y ERPs están usando la API
Algunos números
El segmento más activo son aplicaciones para vendedores
33K apps activas
2,6MM usuarios aceptaron al menos...
Pero.. faltaba un eslabón
Qué pasa cuando un startup no tiene dinero para empezar?
API
exitosa
Tecnología
Monetización
Com...
Creamos un fondo de US$ 10MM
Para invertir en startups que mejoren el ecosistema de MercadoLibre
Ya hicimos las primeras 3...
Agenda
Quiénes somos
Nuestra API
Recapitulando…
Recapitulando…
• La API es primero una necesidad interna.
• No es sólo una interfaz para computadoras.
• Desnormalizar int...
Gracias!
@drabinovich
Daniel rabinovich   php conference
Daniel rabinovich   php conference
Upcoming SlideShare
Loading in …5
×

Daniel rabinovich php conference

2,081 views

Published on

Daniel rabinovich php conference

  1. 1. Nuestra API Daniel Rabinovich CTO - MercadoLibre @drabinovich
  2. 2. Agenda Quiénes somos Nuestra API
  3. 3. MercadoLibre #1 sitio de e-commerce más grande del LatAm #8 sitio de e-commerce más grande del mundo 90MM usuarios registrados 23MM usuarios activos (operaron en 2012) 5,7BN de dólares transaccionados (2012) 275% de crecimiento desde el IPO (2007)
  4. 4. Un poco de "scalability porn” 7Gbps de tráfico 1,4 BN de hits al día en el front-end 7,2 BN de hits al día en la API 1800 búsquedas por segundo 95 bases de datos 930TB de data en bases de datos 120TB de fotos
  5. 5. Un ecosistema de ecosistemas Mercado Pago Publicidad Mercado Envios Mercado Shops
  6. 6. Agenda Quiénes somos Nuestra API Contexto Diseño Monetización
  7. 7. Monolítico -> Desacoplado Nacimos monolíticos, desacoplamos (justo) a tiempo Monolítico Desacoplado
  8. 8. Monolitos -> presión creciente Cambios en el entorno exigen flexibilidades para las que no están preparadas Monolítico Escalar el equipo Múltiples "pantallas" Velocidad de desarrollo Abrir la plataforma
  9. 9. Comemos el pescado que vendemos Front-end Mobile Back-end Una única API Developers Compartimos exactamente la misma API que usamos para nuestros front-ends
  10. 10. Una API es una necesidad interna, antes que una externa
  11. 11. Partimos MercadoLibre en 100 “celdas” Code Infra structure Data Team Facebook Search View Item Paage Listings Users Orders Cada “celda” funciona como si fuese una empresa independiente
  12. 12. Posponer soluciones != No prever soluciones
  13. 13. "The bright side of being late is that (if you're still alive) you can leapfrog"
  14. 14. Agenda Quiénes somos Nuestra API Contexto Diseño Monetización
  15. 15. REST sobre HTTP El mundo descripto en términos de “recursos” /sites/MLA /users/4605484 /items/MLA473364655 /pictures/MLA3004267263_082012
  16. 16. Sólo verbos estándar HTTP Minimizan la necesidad de leer documentación Obtener Crear Modificar Borrar
  17. 17. Verbos STD evitan DOCs En SOAP podría ser “updateUser”, “alterUser”, etc. Sobre REST no hay duda! PUT /users/4605484 { last_name: “Fagúndez” }
  18. 18. Una API no sólo es una interfaz para computadoras.
  19. 19. Repasamos conceptos de Usabilidad Pueden aplicarse directamente a los usuarios de una API Learnability Efficiency Satisfaction
  20. 20. Pretty Print: la vista para el Developer La API detecta cuando se navega desde un browser, y se “autodocumenta” Para máquinas Para humanos
  21. 21. Pretty Print: recursos relacionados Los IDs se transforman en links en la vista “para humanos”
  22. 22. Introspection: la API se autoexplica La API genera su propia metadata a través del verbo STD "OPTIONS" OPTIONS /sites
  23. 23. Usabilidad orientada al programador Las convenciones son el activo oculto más importante de una API • “AR” vs “0001” (ISO codes sobre códigos “inventados”) • “seller_id” vs “customer_id” (reduce ambigüedad) • “condition: used” vs“used:true” (escalable, evita cambios de firma ante nuevos valores) • Diseñar para el caso canónico (Desnormalizar inteligentemente, evita requests innecesarios)
  24. 24. Diseñar para el caso canónico Ej: el GET /items tiene como caso canónico mostrar la página de producto GET /items/MLA472660878
  25. 25. Caso canónico justifica desnormalizar La API de un artículo resuelve la URL de la foto para evitar el request adicional /items/MLA472660878
  26. 26. El problema “N+1” Típico en front-ends de listados: 1 request para los IDs + uno por cada producto Sergún REST “Kosher” 20 filas = 21 requests • 1 para los IDs • 20 requests para las descripciones
  27. 27. Selection La capacidad de pedir menos atributos que los dflt del recurso /items/MLA121484389?attributes=title { title: "Boomerang Artesanales De Alta Calidad } 2K 340b -> -84%
  28. 28. N+1 -> Selection + Multiget Multiget: la capacidad de obtener N recursos en un solo API call /items?ids=MLA121484389,MLA125002468&attributes=title [ -{ title: "Boomerang De Diseño Australiano Con Retorno" } -{ title: "Boomerang Artesanales De Alta Calidad" } ]
  29. 29. "There is no free Lunch" Selection y Multiget son violaciones a REST con costos ocultos Difícil de “cachear” y “shardear”
  30. 30. Amigarse con la inconsistencia Prerrequisito básico para poder escalar horizontalmente • Brewster’s CAP Theorem (Consitency, Availability, Partition Tolerance; pick 2) • El trade-off en realidad es A vs C. • En el 99% de los casos, elegimos A+P • Las propiedades A[C]ID no deben ser defaults • Consistencia -> Inconsistencia eventual
  31. 31. El verbo SEARCH: reglas de convivencia Recursos base: CRUD + push para que otros armen índices SearchListings Push notifications Recursos base (sólo CRUD) Consultas complejas
  32. 32. Un ejemplo simple Para buscar por "apodo" habría que crear un índice en el recurso USERS /users/search?nickname=LEWIS_CARROLL
  33. 33. Balancear requests a la “celda” correcta Cada celda es responsable de generar sus propias reglas de balanceo Users SearchUsers /users/search?nickname=LEWIS_CARROLL /users/4605484
  34. 34. El usuario debe percibir una sola API
  35. 35. Estandarización del paginado OFFSET y LIMIT mejor que PAGE=N, permite controlar el tamaño de la página /sites/MLA/search?q=boomerang&limit=2&offset=10
  36. 36. Caching es diseño, no optimización Las estrategias de cacheo pueden alterar el diseño • Validation: Consistente, pero con penalties de performance 2 HTTP Headers: Etag (If-None-Match) y Last-Modified (If-Modified-Since) • Expiration: Mucho más rápido, pero eventualmente inconsistente HTTP Header: Cache-Control: max-age=X, public
  37. 37. Autenticación y autorización Son dos conceptos muy diferentes Autenticación: Confirmar la identidad del usuario a través de ciertas credenciales (ej: pwd) Administrada por Plug-Ins centralizados Autorización: Confirmar si un usuario puede ejecutar una acción (ej: modificar un artículo) Administrara por el desarrollador (con defaults)
  38. 38. Autenticación OAuth 2.0 permite que aplicaciones 3 actores: • MercadoLibre • Usuario • Aplicación OAuth permite que aplicaciones ejecuten acciones en nombre de usuarios sin acceder a sus credenciales (pwd)
  39. 39. Recursos públicos Son visibles para todos los actores del sistema GET /users/46054484
  40. 40. Recursos privados Son accesibles sólo para sus dueños. OAuth les provee un ACCESS_TOKEN GET /users/me?access_token=ABC
  41. 41. El usuario “autoriza” las apps A operar en su nombre. El app no obtiene acceso a sus credenciales.
  42. 42. Las reglas de negocio son parte de la API Es una excelente manera de no duplicar lógica Por ejemplo, las reglas de pricing son consumidas desde el flujo de venta y desde el back-end de atención al cliente
  43. 43. Lockeos y HTTP Un mecanismo elegante dentro del protocolo, para hacer optimistic locking Una manera de aplicar optimistic locking usando HTTP - GET /users/123 - Etag = ABC - PUT /users/123 - If-match: ABC (Aplicar si nadie modificó el objeto)
  44. 44. Atómico y Stateless Independientemente de la cantidad de pasos que tengan los front-ends User SYI FrontEnd Items API Select Category Item Details Listing Types Confirmation POST Item Responsabilidad del FrontEnd Request atómico
  45. 45. HTTP return codes -> Parte de la API Cuanto más estándares usemos, más gente sabrá usar la API sin leer la DOC 201: Object Created 206: Partially created (ej: completar el pago para crear una orden) 401: Unauthorized 404: Not found 410: Gone 500: Internal Server Error 501: Not implemented
  46. 46. Push Notifications Clientes externos pueden suscribirse a "Topics"
  47. 47. Versionamiento La API debe cambiar a distintas velocidades según el tipo de app que soporta
  48. 48. Versionamiento La API debe cambiar a distintas velocidades según el tipo de app que soporta api.mercadolibre.com v1.api.mercadolibre.com Fuente: Darío Simonassi
  49. 49. Comunidad El "churn" de developers es enorme sin una comunidad fuerte detrás developers.mercadolibre.com github.com/mercadolibre (js-sdk, java-sdk, net-sdk, php-sdk) @melidevelopers #meli@irc.freenode.net
  50. 50. SDKs Proveen un buen rest client y los flujos de OAuth
  51. 51. Agenda Quiénes somos Nuestra API Contexto Diseño Monetización
  52. 52. TML-YLGDE Fuente: Fede Procaccini
  53. 53. Esquemas de monetización Compradores 17MM (2012) Vendedores 6MM (2012) 150K profesionales Revenue Share (compartimos la comisión por venta) Aplicaciones que produzcan mejoras operativas
  54. 54. El nicho: servicios a vendedores Gestores de ventas, inventario, logística, integradores con ERPs, CRMs, etc
  55. 55. La API está tomando tracción Retailers, Integradores, Gestores de Ventas y ERPs están usando la API
  56. 56. Algunos números El segmento más activo son aplicaciones para vendedores 33K apps activas 2,6MM usuarios aceptaron al menos 1 app 50% de top sellers aceptaron al menos 1 app Se hacen a través de la API: • 3% del total de compras móviles • 7% del total de publicaciones • 19% de los updates a listings
  57. 57. Pero.. faltaba un eslabón Qué pasa cuando un startup no tiene dinero para empezar? API exitosa Tecnología Monetización Comunidad Financiamiento
  58. 58. Creamos un fondo de US$ 10MM Para invertir en startups que mejoren el ecosistema de MercadoLibre Ya hicimos las primeras 3 inversiones de US$ 100.000 c/u: • Mr Presta: Microloans. Scoring basado en historial de ventas • Nubi Metrics: Business Intelligence para vendedores • Parsimotion: cloud based ERP orientado a supply-chain
  59. 59. Agenda Quiénes somos Nuestra API Recapitulando…
  60. 60. Recapitulando… • La API es primero una necesidad interna. • No es sólo una interfaz para computadoras. • Desnormalizar inteligentemente. • Amigarse con la inconsistencia. • Posponer soluciones != no preverlas. • El usuario debe percibir una sola API. • Pensar en monetización desde el día 0.
  61. 61. Gracias! @drabinovich

×