Effective Network Layer: API Lovers and Apps

¿Somos eficientes en las peticiones de red de nuestras apps?

1. @durbon Effective Network Layer API Lovers and Apps José María Rodríguez Hurtado Android Developer
2. José Manuel Pereira García ANDROID TEAM LEAD www.jmpergar.com @JMPergar jm.pereira.g@gmail.com +JoseMPereira José María Rodríguez Hurtado ANDROID DEVELOPER & API LOVER @durbon chema@durbon.com + +JoséMRodríguez
3. We are hiring https://www.jobandtalent.com/es/careers
4. “Casi cualquier app necesita una conexión de red para funcionar”
5. AGENDA 1. API RESTful 2. ¿Somos eficientes en las peticiones de red? 3. Herramientas para desarrollador móvil
6. “Las APIs son el pegamento entre las apps e Internet”
8. Roy Fielding definió REST en el 2000 “Un framework para construir aplicaciones web respetando HTTP…” ahora lo usamos en móviles
9. Herramientas para Trabajar con APIs (y no acabar con los dedos pegados) API RESTful 1. HTTP Verbs 2. Resources URI 3. Hypermedia
10. 1. HTTP Verbs GET POST PUT DELETE read insert update remove CRUD operation (Create, Remove, Update, Delete)
11. 2. Resources URI Usar nombres en plural Seguir una jerarquía /jobs >> /job /candidate/12/job/78 No usar verbos GET /getAllJObs GET /createNewJob GET /deleteJob GET /jobs POST /jobs DELETE /jobs/78
12. Resource GET read POST create PUT update DELETE /jobs Devuelve un listado de trabajos Crear un nuevo trabajo Actualiza masivamente los trabajos Borra todos los trabajos /jobs/24 Devuelve un trabajo específico Method not allowed (405) Actualiza un trabajo concreto Borra un trabajo específico
13. 3. Hypermedia HATEOAS Hypermedia as the Engine of Application State API navegable a través links incluidos en sus recursos Atributos: • “rel”: relación de ese link con el resource • “href”: URL única que define el resource
14. { "content": [ { "price": 599.00, "description": "Google Nexus", "name": "Nexus 6P", "links": [ { "rel": "self", "href": "http://localhost:8080/product/1" } ], "attributes": { "connector": "socket" } } ], "links": [ { "rel": "product.search", "href": "http://localhost:8080/product/search" } ] }
16. Problema La API de tus apps no debería ser una interfaz CRUD de tu Base de Datos
17. REST pone énfasis en acciones aplicadas a los recursos, pero el problema, es la representación
18. En Nuestro día a día Ser estrictos con RESTful nos obliga hacer MÚLTIPLES llamadas para pintar datos de distintos resources
19. Latencia en HTTP sobre 3G es ~ 1 sg Cada llamada cuenta Lo ideal es 1 pantalla = 1 llamada REST
20. La API es una facade de tu BBDD y modelo de objetos de backend. No lo propagues por HTTP
21. Des-normaliza Tu API debe desnormalizar los datos almacenados en distintas tablas a modelo de datos para tu aplicación Nada impide que crees nuevos Resources agrupando, pensar eso es un Anti patrón Y recuerda siempre, la API no forma parte de tu dominio
22. Estrategia 1. Piensa en pantallas 2. Desnormaliza tus resources 3. Diseña modelos de entidad 4. Diseña pensando en servicios Domain Driven Design for RESTful Jim Webber https: //yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047
23. Herramientas para Trabajar con APIs (y no acabar con los dedos pegados) ¿Somos eficientes usando las peticiones de red en nuestras Apps?
24. 1. Velocidad 2. Errores de red 3. Offline 4. Notificaciones push 5. Seguridad
25. 1. Velocidad de conexión La red (puede ser) lenta • Ajustes de conexión según si estamos en WiFi, 3G, 4G: ◦ Calidad de las imágenes. Solicitar resoluciones, formatos al API ◦ Descarga de datos pesados sólo en WiFi. Ajustes de aplicación ◦ Usa datos en caché siempre que puedas: ▪ Cache-control ▪ ETag • Usa siempre GZIP, reduce hasta un 70%
26. 2. Errores de red Gestionar los errores 4xx y 500. • Enviar errores a Crashlytics o Analytics para analizarlo. ¿fallos de backend? • Mensajes informativos, intenta recoger feedback del usuario ¿hay algo incorrecto? • Payload con mensaje de error: localized message, validar fields • No reinventar la rueda con los códigos de error
27. 2. Errores de red Información 1XX Éxito 2XX Redirección, Proxy o Caché 3XX Error del cliente 4XX Error del servidor 5XX 418 I’m a teapot
28. Status code HTTP 2XX OK 200 Creado 201 Aceptada 202 4XX Bad request 400 No autorizado 403 Ya no disponible 410 Error servidor 500
29. 2. Errores de conexión Timeout • Gestionar los tiempos de espera: nunca más de 10 seg • Feedback de loading o fallo. Evitar el loading infinito Evitar Timeout de trabajos pesados en backend • Peticiones con ticket. Token que nos indica si una acción se ha completado
30. 2. Errores de conexión (Retries) • Reintentos manuales. Botón de reintento UI ◦ Respetar la transaccionalidad de las acciones. Rollback de las acciones y comprobar status • Cola de reintentos en segundo plano. Diferenciar acciones que no requieren más interacción de usuario. • Batch de acciones
31. 3. Funcionamiento offline Offline First: http://offlinefirst.org/ Probar a usar la app en modo avión (sin conexión) Caché de los datos más usados. Equilibrio entre el modelo de negocio en la app y directa del backend Persistir todos los datos posibles de la App Sincronización del uso offline. Colas de sincronización
32. 4. Notificaciones Push Utilizar SaaS que nos faciliten la vida • Parse • Firebase • Google Cloud Messages Diferenciar entre Tipos de notificaciones: bulk, topic, personalizadas Sincronización en background usando push
33. Sincronización en background usando push NOTIFICADOR DISPOSITIVO API PUSH SERVER PUSH 1. Worker Trigger 2. Nuevos datos 3. Envío de push 4. Solicitud de datos 5. Descarga de datos trigger
34. 5. Seguridad Utilizar HTTPS para TODAS las llamadas Uso de OAuth2. Olvida las API Key fijas Signature en llamadas para no poder repetir llamadas si alguien intenta crawlear nuestra API
35. Herramientas para Trabajar con APIs (y no acabar con los dedos pegados) Herramientas para Trabajar con APIs (y no acabar con los dedos pegados)
36. Las frustraciones del desarrollador de apps móviles • Falta de documentación • Parseo de respuestas y gestión de errores • El API aún no está desarrollada (mocks) • “Manual testing” • Versionado y mantenimiento de APIs • Seguridad de las peticiones
37. ¿Documentación estática o sandbox interactivos? • Definición de endpoints, parámetros, response, errores, etc.. (actualizada, por favor) ..pero también necesitamos... • Entorno trasteable y testable.
38. Swagger: agnostic framework for APIs “The goal of Swagger™ is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection” swagger.io
39. Sandbox interactivo
40. Network Traffic Inspection ¿Cómo visualizar que envío y recibo al hacer peticiones a un API? ...y también sirve para “descubrir” APIs
41. • Debug traffic: request, response, header, cache- control, etc.. • Man-in-middle: desencriptar HTTPS visualizando y modificando request. Reverse proxy SSL • Performance testing: lag
42. Herramientas Network Traffic Inspection Charles charlesproxy.com/
43. Herramientas Network Traffic Inspection Fiddler telerik.com/fiddler
44. API Workflow Herramientas para almacenar colecciones de llamadas APIs • Crear peticiones de forma simple y reproducibles • Documentar llamadas y exportarlas • Trabajar con distintos entornos staging y pro • Utilizar helper de autenticación • Crear script de pruebas • En definitiva, un Sandbox de pruebas
45. Herramientas API Workflow POSTMAN getpostman.com
46. Mock server • Evita el bloqueo mientras se está desarrollando una API • Adelantar trabajo y definir JSON al equipo de Backend • Pruebas en local sin necesidad de conexión de red. Mock server integrado. • Y los más importante… TESTING
47. Mockweb server https://github.com/square/okhttp/tree/master/mockwebserver MockResponse. Simular respuestas: header, body, tiempo de respuestas RecorderRequest. Similar al verify podemos comprobar el orden y si se hacen las request correctas. Dispatcher. Crear un pequeño dispatcher para dar lógica a los test.
48. Construir un cliente API ¡NO REINVENTES LA RUEDA! Mantenible y extensible Usa OkHttp y Retrofit
49. OKHttp • Soporta HTTP/2 y SPDY • GZIP shrinks • Response caching evitando repetir llamadas innecesarias. Cache-control • Pinnear certificados • Interceptors http://square.github.io/okhttp/
50. OKHttp Interceptors Autentication. Servicio adhoc con la seguridad del API Parámetro comunes Header con app version, ids Caché Logging y debugging
51. OKHttp Interceptors
52. Conclusiones Define un API REST adaptada a tu proyecto (si puedes) Cuida la capa de red de las aplicaciones. Dedicale tiempo Utiliza herramientas para debuggear la API al igual que usas un IDE
53. Referencias Android Tech Talk: HTTP In A Hostile World Jesse Wilson https://www.youtube.com/watch? v=tfD2uYjzXFo Offline First http://offlinefirst.org/ OkHTTP Recipes https://github.com/square/okhttp/wiki/Recipes Retrofit http://square.github.io/retrofit/ charla sobre DDD for RESTful https://yow.eventer.com/yow-2011-1004/domain-driven-design-for- restful-systems-by-jim-webber-1047 Errores comunes http://www.programmableweb.com/news/api-anti-patterns-how-to-avoid- common-rest-mistakes/2010/08/13 Buil
54. Preguntas @durbon chema@durbon.com + +JoséMRodríguez