L’API Flickr et l’API Wikimedia
Avant de commencer quoi que ce soit, il faut regarder ce qu’on peut obtenir via l’API, et comment. C’est la base du modèle de données, ainsi que de la liste des fonctions qu’on va utiliser pour récupérer les données.
Trouver la documentation de l’API Flickr
Ergonomie, quand tu nous tient… les liens vers l’API se trouvent tout en bas de la page, qui, lorsqu’on est sur l’accueil, met un temps fou à se charger complètement à cause de ce [censuré] d’auto-load. Il y a un raccourci dans les menus, mais bien caché, puisqu’il faut penser à sélectionner “Explorer” et ensuite “App Garden” (pour toutes les applications).
Bref, on arrive sur la page de l‘App Garden qui donne un lien vers la documentation de l’API.
La doc donne l’ensemble des méthodes (les fonctions utilisées), mais ne donne pas a priori de descriptif complet des données disponibles. On va donc pêcher ce dont on a besoin dans les méthodes. Et pour chaque méthode, il faudra “tester” les données renvoyées.
Les données des images
C’est bien entendu la liste des méthodes la plus complète. J’ai enlevé tout ce qui concerne le traitement des photos proprement dit (ajouter de l’information, modifier, supprimer), voici ce qui reste et qui va être intéressant à examiner :
- flickr.photos.getExif
- flickr.photos.getInfo
- flickr.photos.getSizes
- flickr.photos.search, éventuellement, dans un troisième temps, pour rechercher des photos à partir de l’admin du blog.
Mais d’autres données, dont on a aussi besoin, sont rattachées à d’autres méthodes. En effet, la licence, qui nous intéresse particulièrement, est simplement un code numérique, dont on va avoir la liste en utilisant flickr.photos.licenses.getInfo,
Les données utilisateurs
La liste des méthodes disponibles montre qu’on peut chercher des utilisateurs selon certains critères, récupérer de l’info, et les “objets” attachés à l’utilisateur.
- flickr.people.findByEmail
- flickr.people.findByUsername
- flickr.people.getInfo
- flickr.people.getPhotos
Dans notre cas précis, ce qui nous intéresse, c’est a priori flickr.people.getInfo et éventuellement flickr.people.findByUsername
Le reste ?
Beaucoup de méthodes permettent de travailler sur les groupes, les galeries, les informations diverses des photos. A priori, on ne va pas les utiliser. La seule méthode qui peut aussi nous intéresser, c’est flickr.photos.comments.addComment pour laisser un message de remerciement sur la photo.
Comment ça marche
Il faut disposer d’une clé d’API. Ce sera donc une des options du plugin
L’API utilise l’UTF-8 (ça tombe bien WordPress aussi en général)
De nombreuses actions (dont celle de poster un message de remerciement) exigent que l’utilisateur s’authentifie.
L’API renvoie en php les données sous forme sérialisée, c’est le plus simple à utiliser.
(NB : il existe un projet sur github, phpflickr, mais c’est un peu lourd, puisqu’il reprend la totalité des méthodes de l’API, alors qu’on ne va en utiliser que quelques unes. Il en existe une autre sur SourceForge, mais qui exige que Curl soit installé, ce qui n’est pas le cas sur tous les serveurs… comme c’est un plugin destiné à être diffusé, on va s’en passer).
Pour le plugin :
Une bonne nouvelle, et une mauvaise nouvelle.
La bonne nouvelle : à l’exception de la création de commentaire, aucune de ces méthodes n’exige l’authentification. C’est bien, car celle-ci est plutôt complexe, on va donc pouvoir laisser de côté, sur un coin de table, en attendant d’arriver à la fin.
Une très mauvaise nouvelle : “bad coding” et “problème de modèle de données“.
La liste des licences gérées par Flickr n’est pas directement utilisable.
C’est une liste qui a été faite “au fur et à mesure”, qui contient des licences “autres”, et qui n’est pas à jour par rapport aux licences CC.
<licenses> <license id="0" name="All Rights Reserved" url="" /> <license id="1" name="Attribution-NonCommercial-ShareAlike License" url="http://creativecommons.org/licenses/by-nc-sa/2.0/" /> <license id="2" name="Attribution-NonCommercial License" url="http://creativecommons.org/licenses/by-nc/2.0/" /> <license id="3" name="Attribution-NonCommercial-NoDerivs License" url="http://creativecommons.org/licenses/by-nc-nd/2.0/" /> <license id="4" name="Attribution License" url="http://creativecommons.org/licenses/by/2.0/" /> <license id="5" name="Attribution-ShareAlike License" url="http://creativecommons.org/licenses/by-sa/2.0/" /> <license id="6" name="Attribution-NoDerivs License" url="http://creativecommons.org/licenses/by-nd/2.0/" /> <license id="7" name="No known copyright restrictions" url="http://flickr.com/commons/usage/" /> <license id="8" name="United States Government Work" url="http://www.usa.gov/copyright.shtml" /> </licenses>
Alors que les licences CC en sont à la version 4. Si on se limitait à la gestion des images Flickr, ce ne serait pas grave, mais je veux pouvoir aussi utiliser le plugin pour des images trouvées ailleurs, avec des versions de licence 3.0 ou 4.0, comme j’en vois sur Wikipedia.
De plus, Flickr a une définition “verbeuse” des licences, qui ne correspond pas aux codes utilisés par Creative Commons.
CreativeCommons appellera cc-by-nc-nd ce que Flickr appelle Attribution-NonCommercial-NoDerivs License, qui est une abbréviation en anglais, que je ne peux utiliser nulle part.
Bref, il va falloir “mapper”, faire une table de correspondance entre les licences que je gère dans le plugin et les licences de Flickr. C’est un grand classique dans les systèmes de gestion, les ERP, mais ce n’est jamais une très bonne nouvelle, parce que cela rajoute de la complexité dans les données et de la maintenance.
L’API Wikimedia Commons
C’est donc le moment d’aller vérifier ce qui existe sur l’autre grande source de medias en CC : Wikimedia. Car si je vais au début me concentrer sur les fonctions Flickr, j’aimerais bien vérifier qu’il n’y a pas d’énormes divergences avec Wikimedia.
La documentation de l’API est disponible en anglais, on est censé pouvoir l’afficher dans d’autres langues, mais elle n’est pas traduite !
Fondamentalement, par rapport à Flickr, la grosse différence c’est que l’API travaille par rapport au contenu d’une page. Elle permet d’en rapatrier tous les éléments. Une recherche rapide sur le thème “license information” donne cette information
Unfortunately right now both author and license information is not stored in a structured way that would allow fetching it from the MediaWiki API.
Malheureusement, actuellement, ni les informations sur l’utilisateur ni les informations sur la license ne sont stockées d’une façon structurée qui permettrait de les importer à partir de l’API MediaWikie
Ce qui veut dire, concrètement :
- qu’il faudra extraire l’information de la page, via un parser (un exemple est donné)
- qu’on n’a pas, par contre, de contrainte de format ou de clé.
On peut donc désormais bâtir notre modèle de données. Cela va devenir concret à partir du prochain article.
(Les deux maisons italiennes aux couleurs de Flickr sont une une photo sous licence CC BY John Fawler )
Coucou,
Pour se faire je recommande de passer par l’API http de WordPress pour le transport des données. La librairie en question est assez lourde en effet. WP gère BCP mieux le transport que PHP de base.
Surtout mettez en cache !! N’allez pas exploser les quotas.
Enfin et surtout utilisez effectivement des images libre de droits, cela peut vous coûter cher en cas fraude même si vous ne l’avez pas fait intentionnellement. Nul n’est censé ignorer la loi comme on dit.
Evidemment tout ce que j’ai dit c’est dans une prespective dév où ma personne va dialoguer avec l’API. Je n’ai pas fait l’inventaire des plugins existants. Il doit y en avoir mais utilisent-ils les bonnes APIS… une autre question, soyons optimiste cela doit exister tout de même depuis le temps que l’API est ouverte :)
Hello,
non, il n’y a pas de bons plugins, la plupart se contentent de permettre des recherches, ce qui n’est pas vraiment ce qui m’intéresse ici :) Il y en avait un ou deux, mais ils ont été abandonnés par leurs auteurs, pas finalisés… Crois moi, étant fan de CC, j’ai cherché, cherché, cherché… donc il VA y en avoir un :D
l’API HTTP de WordPress est effectivement sans doute la solution pour la partie Wikimedia, mais ça ça venir à la fin :)
Le problème des quotas se pose surtout en cas de recherches ou d’import intensif non ?
Non, une API a des quotas. Si tu dépasses ces quotas de requêtes tu es grillé. Si tu ne mets pas en caceh la requête se fait à chaque lancement de la page => ça peut aller très très vite.
Certes :) mais en l’occurrence l’API sera lancée uniquement à l’importation du media, ou par clic volontaire sur un bouton. Le but du jeu n’est pas d’afficher les données Flickr directement dans la page, mais de les importer dans la structure WordPress. Il faut juste faire attention à ne pas activer sur les autosave, ou les modifications. Sur le principe, tu as parfaitement raison, mais pas dans ce cas. (ou alors je n’ai rien compris).
Par contre, mettre en cache est effectivement la méthode qui est utilisée par les plugins qui affichent des données Amazon.
C’est une très mauvaise pratique que d’essayer d’aller parser l’HTML des pages il faut impérativement passer par l’API. En cas de changements chez le provider t’es cuit !
En effet le contexte de la requête est particulier mais il faut prendre d’autres éléments :
Et on ne sait pas combien de personnes sont suceptibles d’utiliser la fonctionnalité en même temps ou presque.
D’ailleurs, côté “quota” de l’API Flickr, les limites sont larges
J’aime bien le “raisonnable” :)
En tout cas, étant donné le mode de fonctionnement prévu pour le plugin, il faudrait intégrer plus de 1.000 à 2.000 photos à l’heure (chacune déposée par un auteur différent) pour dépasser les quotas.
Un fou peut le faire… ça sera sa clé API qui sera bloquée :)
Il faut malgré tout une erreur en cas de dépassement, j’ai peut-être l’air d’en faire des caisses mais cela fait partie des bonnes pratiques que j’essaie de promouvoir avec les APIs.
C’est 3600 requêtes heure par clé, il peut y avoir d’autres codes qui font appel à Flickr sur la même install, on ne peut pas ne pas le prévoir pour un plugin.
Mettre en cache le srésultats de recherche, enfin des queries n’est pas si absurdes, m’enfin dsl si j’ai mal saisi ton idée, c’est vrai ici on n’affiche pas sur une page.
En fait, d’une manière générale, il faut une gestion des erreurs : il n’y a pas que les dépassements qui peuvent donner lieu à retour. Je suis totalement d’accord sur la théorie.
@ Julien : pour le parsage HTML, de quoi tu parles ?
Il y a deux “API” différentes, pour deux sources différentes :
API Flickr -> utilisation uniquement de l’API
API Wikimedia -> pas de méthode pour récupérer l’auteur et la license, eux même conseillent de parser ou alors de faire à la main :)
De plus, comme n’importe quel plugin WP, la clé d’API ne sera pas fournie, elle sera à demander par chacun, et à renseigner dans les options du plugin. Donc, si, j’ai une relativement bonne idée du nombre de personnes qui feront appel au service simultanément. Une à deux par blog et par clé d’API.
Ecoute je te dis que c’est une très mauvaise pratique, je le maintiens, Si eux-même le conseillent alors là par contre y a un souci mais c’est pas grave. Dsl encore si j’ai mal lu, la fatigue de la journée de travail sûrement :). Allez a +
Je le dis à tous : NE JAMAIS utiliser des endpoints non officiels à moins que ce soit votre bon plaisir perso mais sûrement pas en prod ou pour un plugin.
C’est eux qui le disent, j’ai mis la citation, avec le lien, ça se termine avec “In the case of Wikimedia Commons (commons.wikimedia.org, the media repository for Wikipedia) there is a somewhat structured way to extract it from the generated HTML.”
ça veut bien dire “parser” non ? “Conseiller” est peut être un peu fort, mais quand on te dit que c’est le seul moyen de le faire…
Cela dit, je peux aussi utiliser une API qui fait le boulot de parser :D http://tools.wmflabs.org/magnus-toolserver/commonsapi.php
Ce n’est pas du tout l’API Flickr qui le dit. C’est un wiki que tout le monde peut éditer attention.
T’es fatigué
… il y a DEUX cas de figure
Flickr -> API Flickr
Wikimedia -> Api Wikimedia
Parce que les images CC ce n’est pas seulement sur Flickr
Proposition :) tu te reposes un peu, tu relis et on en recause ?
N’importe quoi je te contredis depuis tout à l’heure alors que le fournisseur n’est pas Flickr mais bien Wikimedias #moimpmoimpmoimp cela dit s’ils conseillent de parser leur HTML c’est alors qu’ils ne le changeront donc jamais? Cela me parraît peu probable.
:D ça veut surtout dire que c’est “y’a pas mieux”
Ils expliquent sur la page, situation historique, machin pas structuré, tout ça, vous pouvez vous débrouiller de cette façon là si vous voulez.
Donc ce que je vais faire, c’est parser et “proposer” le résultat à l’intégration avec validation avant. Comme ça le jour où le HTML change, tu vois qu’il y a une couille. ça plus la vérification sur l’intégrité des données, pour un truc qui a vocation a être utilisé manuellement, ça me parait suffisamment bordé.
Mais je suis d’accord, ça serait mieux autrement.