1. Nuestra API
Daniel Rabinovich
CTO - MercadoLibre
@drabinovich

2. Agenda
Quiénes somos
Nuestra API

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. 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. Un ecosistema de ecosistemas
Mercado
Pago
Publicidad
Mercado
Envios
Mercado
Shops

6. Agenda
Quiénes somos
Nuestra API
Contexto
Diseño
Monetización

7. Monolítico -> Desacoplado
Nacimos monolíticos, desacoplamos (justo) a tiempo
Monolítico Desacoplado

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

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

11. Una API es una necesidad interna,
antes que una externa

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

13. Posponer soluciones
!=
No prever soluciones

14. "The bright side of being late is
that (if you're still alive) you
can leapfrog"

15. Agenda
Quiénes somos
Nuestra API
Contexto
Diseño
Monetización

16. REST sobre HTTP
El mundo descripto en términos de “recursos”
/sites/MLA
/users/4605484
/items/MLA473364655
/pictures/MLA3004267263_082012

17. Sólo verbos estándar HTTP
Minimizan la necesidad de leer documentación
Obtener Crear Modificar Borrar

18. Verbos STD evitan DOCs
En SOAP podría ser “updateUser”, “alterUser”, etc. Sobre REST no hay duda!
PUT /users/4605484
{
last_name: “Fagúndez”
}

19. Una API no sólo es una
interfaz para computadoras.

20. Repasamos conceptos de Usabilidad
Pueden aplicarse directamente a los usuarios de una API
Learnability
Efficiency
Satisfaction

21. Pretty Print: la vista para el Developer
La API detecta cuando se navega desde un browser, y se “autodocumenta”
Para máquinas Para humanos

22. Pretty Print: recursos relacionados
Los IDs se transforman en links en la vista “para humanos”

23. Introspection: la API se autoexplica
La API genera su propia metadata a través del verbo STD "OPTIONS"
OPTIONS /sites

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

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

26. Caso canónico justifica desnormalizar
La API de un artículo resuelve la URL de la foto para evitar el request adicional
/items/MLA472660878

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

28. 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%

29. 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"
}
]

30. "There is no free Lunch"
Selection y Multiget
son violaciones a REST
con costos ocultos
Difícil de “cachear” y “shardear”

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

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

34. Un ejemplo simple
Para buscar por "apodo" habría que crear un índice en el recurso USERS
/users/search?nickname=LEWIS_CARROLL

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

36. El usuario debe percibir
una sola API

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

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

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

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

41. Recursos públicos
Son visibles para todos los actores del sistema
GET /users/46054484

42. Recursos privados
Son accesibles sólo para sus dueños. OAuth les provee un ACCESS_TOKEN
GET /users/me?access_token=ABC

43. El usuario “autoriza” las apps
A operar en su nombre. El app no obtiene acceso a sus credenciales.

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

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

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

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

48. Push Notifications
Clientes externos pueden suscribirse a "Topics"

49. Versionamiento
La API debe cambiar a distintas velocidades según el tipo de app que soporta

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

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

52. SDKs
Proveen un buen rest client y los flujos de OAuth

53. Agenda
Quiénes somos
Nuestra API
Contexto
Diseño
Monetización

54. TML-YLGDE
Fuente: Fede Procaccini

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

56. El nicho: servicios a vendedores
Gestores de ventas, inventario, logística, integradores con ERPs, CRMs, etc

57. La API está tomando tracción
Retailers, Integradores, Gestores de Ventas y ERPs están usando la API

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

59. Pero.. faltaba un eslabón
Qué pasa cuando un startup no tiene dinero para empezar?
API
exitosa
Tecnología
Monetización
Comunidad
Financiamiento

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

61. Agenda
Quiénes somos
Nuestra API
Recapitulando…

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

63. Gracias!
@drabinovich