Api mobile first

8

Click here to load reader

Transcript of Api mobile first

Page 1: Api mobile first

API mobile”Les best practices pour désigner une API orientée mobile first”

Page 2: Api mobile first

Problématiquemobile

• Puissance toujours inférieure que sur desktop

• Data limitée en usage et vitesse (2g et 3g fréquente)

• Une app mobile est contraignante par défaut

• Système de recyclage de vues dans les listes

• Temps de rafraîchissement des apps limité

• Réactivité des applications mobiles exigée par les utilisateurs (durée de rafraichissement, blocage UI, perte de batterie…)

Page 3: Api mobile first

Solution : Api mobile first

Page 4: Api mobile first

Best practice n°1Limiter l’overhead

• Enlever un maximum d’headers inutiles

• Ne pas systématiser l’envoi de json si ça grossit la data (form-encode, querystring).

• Rétrécir les JSON aux maximum (ne pas choisir des clés à rallonge, ne pas envoyer des données inutiles car trop ce n’est pas mieux que moins)

• Utilisation de Rest pour le routing

Page 5: Api mobile first

Best practice n°2Reduire le nombre d’appel API• Envoyer le max d’information dans un seul json (ie: {..."user": 1...} à

bannir) car cela implique plus qu’une requête pour un affichage et est contraire à la règle d’or: 1 appel API par écran!

• Pour l’upload des images « logo, avatar » avec un JSON, privilégier le Base64 pour l’image {"avatar":"tgzh68545dqugeug257fsg","name":"name"}

• Pour l’upload de grosses images, 2 solutions en POST:

• multipart/form-data (http://stackoverflow.com/questions/4083702/posting-a-file-and-associated-data-to-a-restful-webservice-preferably-as-json)

• Base64 (mais risque de gros d’overhead : +33% taille - ne pas privilégier si la taille de l’input n’est pas limité)

Page 6: Api mobile first

Best practice n°3 Bonne anatomie

• API Versionnée : pour être toujours rétro-compatible avec les toutes les clients. Devrait être un réflexe comme faire une branche Git develop au début d’un projet.

• API flexible: si besoin le rajout ou la suppression d’un champ dans la réponse se fait sans douleurs ni rustines (pas de changement de la structure de la réponse)

Page 7: Api mobile first

Best practice n°4 Privilégier la performance

• Pas d’intelligence sur mobile, pure consommateur (même logique que pour un client navigateur).

• Protocole buffers > JSON sur mobile (crée par Google, validation sur schema et deserialisation sans parsing, taille minuscule) (http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/)

• D’autres alternatives comme MessagePack, Thrift, Avro (https://www.igvita.com/2011/08/01/protocol-buffers-avro-thrift-messagepack/)

Page 8: Api mobile first

Best practice n°5 Documentation

• Documentation claire, à jour, testable dans les conditions mobiles:

• Swagger (ou autre)

• Configuration Charles Proxy