APIs de données : choisir une approche générique ou spécialisée ?

La fin de l’API générique ?

À l’origine, créer une API de données est un principe permettant de réduire le nombre de points d’entrée dans un système back-end, et de rationaliser le développement et la maintenance des interfaces. L’autre avantage de cette réduction du nombre d’interfaces en est la facilité d’administration, de sécurisation, de contrôle et de supervision d’une API unique.

La plupart des APIs de données ont été conçues et créées comme un ensemble complet de ressources dont une partie est utilisée par l’ensemble des utilisateurs front-end, tandis que l’autre partie ne sert que certains utilisateurs spécifiques, dans le cadre de scénarios précis. De plus en plus souvent, l’introduction d’une fonctionnalité spécifique nécessite un ajout ou un changement au niveau de l’API. Cependant, cette dernière ne s’applique pas à l’ensemble des utilisateurs. Par exemple, l’identification Touch ID d’Apple est une fonctionnalité réservée aux iPhones : le service back-end et les ressources d’API à implémenter pour la prendre en charge sont complètement inutiles pour un autre terminal client.

Par conséquent, il est possible de séparer les APIs selon leurs fonctionnalités, en créant par exemple une API à part pour Touch ID à laquelle seule l’application pour iPhone fait appel. Faute de quoi, la problématique sera de se trouver rapidement dans l’incapacité de maintenir et d’administrer le système dans son intégralité.

Une API spécifique à un device client

Une meilleure approche consiste à séparer les APIs de données en fonction du device. Au lieu de déployer une seule API invoquée par l’ensemble des appareils, l’option est d’en déployer une pour les clients iPhone, une pour Android, une pour les front-ends Web/HTML5, une pour les objets connectés sans écran, etc.

Chacune de ces APIs aura beaucoup d’éléments en commun avec les autres. Elles peuvent notamment partager une logique back-end et du code. Mais les stratégies de transfert de données, de filtrage, de taille de batch, et même les fonctions back-end pouvant être invoquées, varieront selon l’API. Par exemple :

•    Il n’est pas possible d’afficher le même niveau de détail pour chaque élément sur l’écran d’un smartphone que sur celui d’une tablette. Ainsi, récupérer moins d’informations et des images de tailles réduites permet d’améliorer les temps de réponse et de réduire la consommation en bande passante.
•    Fournir des informations géocontextuelles à un appareil non équipé de GPS est inutile, et solliciter des coordonnées qui produiront un code d’erreur est une perte de temps.
•    Pour les clients connectés en permanence (ex. : front-end Web), les stratégies de préchargement de données et de défilement doivent être différentes de celles dédiées aux appareils mobiles.

Au-delà de performances améliorées, ces APIs spécialisées auront également un impact important sur le cycle applicatif et sur l’agilité en matière de publication d’applications. Lorsque l’on prend en charge des dizaines, voire des centaines de terminaux différents, aligner sur le même calendrier la publication de toutes les applications clients, des systèmes back-end et de l’API générique est du domaine de l’impossible. En outre, cette approche n’offre assurément pas l’agilité nécessaire pour prendre en charge rapidement les nouvelles fonctionnalités des appareils et de leurs systèmes d’exploitation.

À l’inverse, le cycle de vie d’une API spécifique à un appareil peut être mis en alignement étroit avec celui de l’application ou du terminal en question. On bénéficie ainsi de délais de commercialisation de nouvelles fonctionnalités raccourcis, ainsi que de systèmes plus attrayants. Adopter une stratégie de développement axée avant tout sur la conception ou sur les APIs permet également de profiter d’une meilleure agilité.

Certes, cela présente assurément des contraintes supplémentaires, et peut rendre la gestion du système global plus complexe. En revanche, adopter cette stratégie optimise la performance des entreprises leur permettant d’être plus efficace et d’accélérer les processus de livraison d’applications adaptées aux besoins des utilisateurs.