Publicité
Contenu connexe
Similaire à Api mobile first (20)
Plus de Chris Saez (8)
Publicité
Api mobile first
- 1. API mobile ”Les best practices pour désigner une API orientée mobile first”
- 2. Problématique mobile • 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…)
- 3. Solution : Api mobile first
- 4. Best practice n°1 Limiter 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
- 5. Best practice n°2 Reduire 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é)
- 6. 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)
- 7. 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/)
- 8. Best practice n°5 Documentation • Documentation claire, à jour, testable dans les conditions mobiles: • Swagger (ou autre) • Configuration Charles Proxy