Google fournit aux développeurs toute une liste d’APIs pour accéder à différents services tels que Google Buzz, Google Task, etc… C’est très chouette, très pratique et très bien documenté. On peut retrouver tout l’environnement Google pour le développement (GWT, appEngine, Android etc…) sur ce site : Google Code. Il existe aussi un explorateur pour ces APIs, et ça se trouve ici. Alors voilà, tout cela fonctionne tellement bien qu’on est toujours tenté d’utiliser ces APIs sans se poser de questions…
Et pourtant…
Un post sur le blog de Google Code amène à se poser certaines questions : Spring cleaning for some of our APIs. Ca commence par les bonnes nouvelles tout droit sorties du Google IO, les nouvelles APIs, comme Task API, ou Prediction API. On ne sait pas trop pourquoi Task API ne sort que maintenant d’ailleurs… Comme son nom l’indique elle permet d’accéder à sa gestion des tâches en cours pour son compte Google. Pratique et efficace…
Mais voilà, le nettoyage de printemps inclue aussi le passage de certaines API en « deprecated ». Comprendre par là qu’elles ne seront plus supportées et développées. Bon, soit… Le problème c’est surtout que certaines de ces APIs vont être totalement désactivées, et en particulier l’API pour Google Translate ! Le décès est annoncé pour le 1er décembre 2011, et ça fait pas mal de bruit sur les forums diverses… D’ailleurs il n’y a qu’à voir les commentaires lors de cette annonce pour se rendre compte que pas mal de développeurs sont un peu désabusés. La raison officielle, c’est que certains ont abusé avec cette API, et qu’elle est devenue économiquement trop lourde… :
Important: The Google Translate API has been officially deprecated as of May 26, 2011. Due to the substantial economic burden caused by extensive abuse, the number of requests you may make per day will be limited and the API will be shut off completely on December 1, 2011. For website translations, we encourage you to use the Google Translate Element.
La solution de remplacement est un code à insérer dans sa page, et n’a rien de flexible ni de fonctionnel… C’est clairement pour empêcher des sites de faire de la traduction à la chaîne quoi…
Tout cela devrait quand même amener les développeurs et les décideurs à se poser beaucoup de questions sur les choix techniques qu’ils ont à faire… Peut-on vraiment et raisonnablement se reposer sur ce genre de technologies gratuites que, finalement, l’on ne maîtrise absolument pas ? A l’époque du cloud, baser son travail sur une architecture distante sans avoir la main sur l’interrupteur qui permet de tout éteindre d’un coup est un risque qui se devra d’être finement calculé… En tout cas je comprends la réticence de certains groupes face à cette philosophie…
LB.
C’est en effet une question qu’il faut se poser sur certains projets car cela peut vraiment avoir son importance !
Mais c’est tellement facile de se dire, j’appelle l’API de Google et j’ai une fonctionnalité qui ne m’a rien coûté.
Pour ma part j’utilise activement les Google Charts sur un projet, l’API est géniale, me fait des graphiques dynamiques superbes, bref le pied. Si un jour Google me dit : désolé mais on arrête de vous faire les charts et bien c’est pas grave il existe des solutions alternatives.
Ma vision est donc la suivante : ne prendre chez Google (ou autre) que des services sur lesquelles il existe une solution alternative.
Quand même Seb’, en fonction de l’impact projet, et du coût d’une éventuelle migration, le « c’est pas grave » est un peu léger !
Ce que je trouve moche, c’est que pour une API qui fait des appels serveurs comme Translate, ils puissent tout couper du jour au lendemain. C’est pas comme si c’était full client comme ton API de chart (j’imagine…)