Api mobile first
Click here to load reader
-
Upload
christopher-saez -
Category
Mobile
-
view
346 -
download
0
Transcript of Api mobile first
![Page 1: Api mobile first](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/1.jpg)
API mobile”Les best practices pour désigner une API orientée mobile first”
![Page 2: Api mobile first](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/2.jpg)
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](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/3.jpg)
Solution : Api mobile first
![Page 4: Api mobile first](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/4.jpg)
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](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/5.jpg)
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](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/6.jpg)
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](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/7.jpg)
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](https://reader037.fdocuments.fr/reader037/viewer/2022100801/5899fb721a28abc5778b6195/html5/thumbnails/8.jpg)
Best practice n°5 Documentation
• Documentation claire, à jour, testable dans les conditions mobiles:
• Swagger (ou autre)
• Configuration Charles Proxy