Tweet
Tweet

Slide 1

Slide 1 text

@durbon Effective Network Layer API Lovers and Apps José María Rodríguez Hurtado Android Developer

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

We are hiring https://www.jobandtalent.com/es/careers

Slide 4

Slide 4 text

“Casi cualquier app necesita una conexión de red para funcionar”

Slide 5

Slide 5 text

AGENDA 1. API RESTful 2. ¿Somos eficientes en las peticiones de red? 3. Herramientas para desarrollador móvil

Slide 6

Slide 6 text

“Las APIs son el pegamento entre las apps e Internet”

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Roy Fielding definió REST en el 2000 “Un framework para construir aplicaciones web respetando HTTP…” ahora lo usamos en móviles

Slide 9

Slide 9 text

Herramientas para Trabajar con APIs (y no acabar con los dedos pegados) API RESTful 1. HTTP Verbs 2. Resources URI 3. Hypermedia

Slide 10

Slide 10 text

1. HTTP Verbs GET POST PUT DELETE read insert update remove CRUD operation (Create, Remove, Update, Delete)

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

{ "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" } ] }

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Problema La API de tus apps no debería ser una interfaz CRUD de tu Base de Datos

Slide 17

Slide 17 text

REST pone énfasis en acciones aplicadas a los recursos, pero el problema, es la representación

Slide 18

Slide 18 text

En Nuestro día a día Ser estrictos con RESTful nos obliga hacer MÚLTIPLES llamadas para pintar datos de distintos resources

Slide 19

Slide 19 text

Latencia en HTTP sobre 3G es ~ 1 sg Cada llamada cuenta Lo ideal es 1 pantalla = 1 llamada REST

Slide 20

Slide 20 text

La API es una facade de tu BBDD y modelo de objetos de backend. No lo propagues por HTTP

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Herramientas para Trabajar con APIs (y no acabar con los dedos pegados) ¿Somos eficientes usando las peticiones de red en nuestras Apps?

Slide 24

Slide 24 text

1. Velocidad 2. Errores de red 3. Offline 4. Notificaciones push 5. Seguridad

Slide 25

Slide 25 text

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%

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Status code HTTP 2XX OK 200 Creado 201 Aceptada 202 4XX Bad request 400 No autorizado 403 Ya no disponible 410 Error servidor 500

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Herramientas para Trabajar con APIs (y no acabar con los dedos pegados) Herramientas para Trabajar con APIs (y no acabar con los dedos pegados)

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Sandbox interactivo

Slide 40

Slide 40 text

Network Traffic Inspection ¿Cómo visualizar que envío y recibo al hacer peticiones a un API? ...y también sirve para “descubrir” APIs

Slide 41

Slide 41 text

● Debug traffic: request, response, header, cache- control, etc.. ● Man-in-middle: desencriptar HTTPS visualizando y modificando request. Reverse proxy SSL ● Performance testing: lag

Slide 42

Slide 42 text

Herramientas Network Traffic Inspection Charles charlesproxy.com/

Slide 43

Slide 43 text

Herramientas Network Traffic Inspection Fiddler telerik.com/fiddler

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Herramientas API Workflow POSTMAN getpostman.com

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

Construir un cliente API ¡NO REINVENTES LA RUEDA! Mantenible y extensible Usa OkHttp y Retrofit

Slide 49

Slide 49 text

OKHttp ● Soporta HTTP/2 y SPDY ● GZIP shrinks ● Response caching evitando repetir llamadas innecesarias. Cache-control ● Pinnear certificados ● Interceptors http://square.github.io/okhttp/

Slide 50

Slide 50 text

OKHttp Interceptors Autentication. Servicio adhoc con la seguridad del API Parámetro comunes Header con app version, ids Caché Logging y debugging

Slide 51

Slide 51 text

OKHttp Interceptors

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

Preguntas @durbon chema@durbon.com + +JoséMRodríguez