Il existe de nombreuses applications pour accéder et gérer vos photos sur Flickr depuis un client de bureau. Cela permet une plus grande souplesse et rapidité notammenent pour les opérations intensives sur plusieurs images. La meilleure application que j’ai vu à ce jour est Flickery, une application pour mac qui pemet d’accéder à son compte et ses préférences dans un environnement proche de iPhoto et qui offre un confort d’usage meilleur que le site Flickr lui même. Seulement voilà c’est un peu trop bien aux yeux de Yahoo qui a décidé de bloquer l’API en prétextant que flickery génère un usage abusif de l’API. Vous pouvez lire ici le témoignage du développeur.
Ceci dit j’apprends également que de nombreux développeurs sont dans la même situation ou attendent simplement les bons vouloirs de Yahoo pour accéder à cette API. Comment yahoo prend il ces décisions? Quelle est la place de l’arbitraire? Y a t il des critères particuliers? Bloquent ils les applications qui menacent l’utilisation du site (notamment les comptes non payants rémunérés via la publicité)? L’étrange dans cette affaire est que Yahoo a bien autorisé l’usage au départ mais à décider ensuite de le bloquer. Une chose est certaine, si Yahoo veut continuer a obtenir le soutien de la communauté des développeurs elle ne peut pas agir ainsi sans plus de transparence au risque de démotiver.
Espérons que Flickery reviendra rapidement. Merci à Jeremie pour l’info
Finalement notre conversation d’hier sur Twitter est devenue caduque toute seule.
Une API sur-utilisée ? N’est-il pas évident que ça devait arriver ? Et c’est pas fini. Par contre ce qui est fini, c’est le mythe de l’infinie “liberté de commerce” des éco-systèmes basés sur ces API… Un grain de sable dans les rouages du 2.0 côté offre ?
Les mashup et consommateurs d’API négligent trop souvent de ne pas nuire aux intêrets du fournisseur, d’une part par un usage modéré, via un cache, et d’autre part en rétro-cédant une part de son audience via des backlinks.
Des mashups qui utilisent des API en rendant complétement inutile la consultation du fournisseur sont clairement nuisibles !
La dépendance aux API est l’une des raisons (il y en avait d’autres) pour laquelle nous n’avons pas investit dans une start-up, basant son service sur un mashup de Google Maps.
Du jour au lendemain, tout peut s’envoler…
Ou alors il faut que les fournisseurs d’API proposent une version “pro” avec un deal lié à la consommation (Google le fait pour maps)
@Pierre-Olivier: par contre, chose interressante pour des super-mashup comme les lifestream ; c’est de réduire la dépendance par la mise en concurrence des API.
Ex: combiner Yahoo! Map et Google Map, Snapshot et Thumbnail.org, MyBlogLog et FriendFeed, etc.
C’est des cas vécu personnellement ; j’ai eu une coupure de SnapShot, et mon bazard a basculé sur Thumbnail.org et pourrait revenir au premier ou un autre si nécessaire. Et j’potasse pour faire un usage alterné de Yahoo! / Google / Live Map pour répartir la charge.
Et j’oubliais ; un bon système de cache permet de tenir le coup lors des coupures ;o)
Je comprends le fait que les divers services soient réticents lorsque certains mashups, applications deviennent très importants et privent le site original d’un trafic supplémentaire, mais tout de même. Ils distribuent une API, des développeurs les utilisent et basent tout leur travail sur cette API (en prenant le risque que tout s’effondre), laisser vivre l’application est la moindre des choses.
mais noooon, vous avez rien compris !
En fait, yahoo commence a préparer son intégration dans microsoft.. tout doucement…
Il commence par être un peu méchant, par ci, par la… Et comme ça, le jour ou ils seront entièrement rattaché a microsoft, tout le monde sera deja habituer a les détester
Eh ! Pas con chez Yahoo !
salut à tous
@ZeKat : Bien sûr, c’est une solution qui fonctionne et qui est courageuse… car elle te demande bien plus d’efforts (lire de temps et d’argent) que la simple utilisation d’une API.
Cela me semblait tellement bizarre que je suis allé à la pêche aux infos. C’est un peu plus facile pour moi, vu ma position dans Yahoo
D’après l’équipe Flickr, il y a eu un double effet. Flickery est devenue très visible très rapidement, d’où un nombre d’utilisateurs qui a grossit rapidement. Et l’application, même si elle est bien faite d’un point de vue interface homme-machine est loin d’être optimale quand à l’utilisation des APIs de Flickr (elle fait parfois plus de 50 requêtes là où une seule aurait suffit.).
Ces deux choses combinées font que la montée de traffic a été trop importante pour que l’on puisse réagir normalement en augmentant les capacités et il a fallu prendre une mesure drastique. Même si cette augmentation ne menaçait pas de faire tomber Flickr, cela pouvait avoir une incidence sur les autres utilisateurs des APIs.
L’equipe Flickr m’a assuré qu’ils avaient 2 personnes aidant le développeur de Flickery pour améliorer les choses.
Merci Remy. mais a ce jour cela ne semble toujours pas réglé
Euh Ouriel, nous sommes en train de parler d’une partie essentiel du soft en question: l’accès aux informations de son back-end, c’est à dire Flickr dans le cas qui nous occupe. Cette partie a sans doute été développée au fur et à mesure des besoins de l’interface, ce qui veut dire que le développeur doit retrouver comment il a programmé ces différents accès pour trouver un meilleur moyen de le faire avec l’aide de l’équipe Flickr. Et à priori, il est tout seul (d’après cette page: http://www.eternalstorms.at/staff/). Tu comprends, nous, on peut l’aider quand il pose des questions mais nous n’allons pas coder son application à sa place. Cela ne serait pas juste par rapport à tous les autres développeurs qui utilisent les APIs. En tout cas, ce serait ma position, je n’ai pas vérifié à quel point les mecs de Flickr sont impliqués dans son code.
Bref, il ne faut pas rêver: nous sommes sans doute en train de parler d’un refactoring majeur. L’effort sera plutôt de l’ordre de l’homme.mois que de l’homme.jour.