Aller au contenu principal

Qu’est-ce qu’une API ?

25/06/2009

[Préambule à l’usage de ceux qui seraient arrivés ici par hasard ou par Google : c’est un billet d’explications à l’usage des bibliothécaires par un bibliothécaire. Donc pas pour les développeurs, ni vraiment pour le grand public. Ceci étant posé, vous faites comme vous voulez ! ;-)]

Ce n’est que par une fréquentation suivie avec des API que j’ai fini par comprendre ce que c’est. Comme vous n’avez pas forcément les mêmes fréquentations que moi (que Dieu vous garde !), j’ai supposé qu’une petite explication pouvait être utile.

Ce billet est aussi un préliminaire au suivant (sur le Sudoc).

Un besoin vital pour une interrogation « en masse »

Imaginons que vous êtes un utilisateur normal, et que vous voulez savoir si Amazon, PriceMinister et la Fnac peuvent vous vendre 1 livre — à quel prix et dans quel état.

Vous allez sur chacun des trois sites, vous cherchez le livre, vous triez par prix ou par état, et vous comparez les trois sites et vous choisissez le fournisseur vous proposant le livre au meilleur état possible pour le meilleur prix possible. Vous y avez passé 15 minutes. Pour un livre.

Imaginons maintenant que vous avez besoin d’acheter 30 livres (par exemple parce que vous vous apprêtez à faire une thèse). Si vous êtes d’une patience ordinaire, vous comparerez pour deux ou trois livres, et vous choisirez un seul fournisseur pour l’ensemble de la commande.

Mais l’idéal serait de disposer d’un comparateur. Soit un quatrième site propose un tel service (il va interroger les 3 sites et vous remontera les réponses avec tris communs possibles), soit vous allez utiliser les API proposées par chacun de ces services.

A quoi ressemblent les données ?

Amazon, PriceMinister et la Fnac disposent de bases de données bibliographiques auxquelles vous n’avez pas accès directement : tout ce à quoi vous avez accès, c’est une interface web, c’est-à-dire un écran qui habille l’affichage des données et leur manipulation. L’interface sert d’intermédiaire entre vous et la base de données.

Que se passe-t-il sur cette interface ? On peut exprimer la même action de différentes manières :

  1. Quand je lance une recherche « 9782910227739 » dans le champ de recherche d’Amazon, je génère une liste de résultats (avec un seul item) affichant le livre Quel modèle de bibliothèque ?. Cette liste de résultats a une URL : http://www.amazon.fr/s/ref=nb_ss_w?field-keywords=9782910227739
  2. Donc si sur une page j’ai un lien hypertexte pointant vers cette page, et que je clique sur ce lien, c’est comme si je lançais une recherche dans la base. Donc cette URL est comme l’adresse web de la liste de résultats. [Il va de soi que cette page n’existe pas ailleurs que dans votre navigateur, le temps de l’affichage : elle n’est pas enregistrée sur les serveurs d’Amazon comme un document Word est stocké sur votre PC. Elle est créée à la volée].
  3. Donc en saisissant cette URL dans la barre d’adresse de votre navigateur, vous demandez à Amazon de générer du code HTML, comportant tout un tas de balises et de texte, et la partie la plus intéressante contenant les références au livre cherché (le reste de la page étant à peu de choses près commun à toutes les pages de résultats)
    <div class="productData">
    <div class="productTitle">
    <a href="http://www.amazon.fr/Quel-mod%C3%A8le-biblioth%C3%A8que-Anne-Marie-Bertrand/dp/2910227731/ref=sr_1_1?ie=UTF8&amp;qid=1245781881&amp;sr=1-1">Quel modèle de bibliothèque ?</a>
    <span class="ptBrand">de Anne-Marie Bertrand</span>
    <span class="binding"> (<span class="format">Broché</span> - 19 décembre 2008)</span>
    </div>
    <div class="newPrice">
    <a href="http://www.amazon.fr/Quel-mod%C3%A8le-biblioth%C3%A8que-Anne-Marie-Bertrand/dp/2910227731/ref=sr_1_1?ie=UTF8&amp;qid=1245781881&amp;sr=1-1">Acheter neuf</a>: 
    <strike>EUR 34,00</strike> <span>EUR 32,30</span>
    </div>
    <div class="fastTrack">Pas de stock; commandez maintenant et nous vous livrerons cet article lorsqu'il sera disponible</div>
    <div class="sss">
    <span class="sssFree">Livraison gratuite</span>
    <span class="sssLastLine"> possible (voir fiche produit).</span>
    </div>
    </div>

    Le code ci-dessus produit ce résultat :

  4. Bref, en utilisant l’URL http://www.amazon.fr/s/ref=nb_ss_w?field-keywords=9782910227739, vous générez le code ci-dessus.
  5. Et si vous changez l’ISBN dans l’URL, vous obtenez des informations bibliographiques différentes, liées à l’ISBN recherchées.
  6. Vous constatez donc que, quel que soit l’ISBN mis dans l’URL, le titre sera toujours au même endroit dans la page, dans la balise <a> elle-même incise dans la balise <div class= »productTitle »>, elle-même dans <div class= »productData »>.
  7. Donc en fabriquant des URL, vous lancez une requête à Amazon qui vous renvoie du code correspondant à l’URL envoyée, avec des informations intéressantes dedans, toujours structurées de la même manière.
  8. Pour manipuler les données « en masses », il serait préférable d’avoir des pages web ne comportant que les informations réellement intéressantes : après tout, le reste de la page ne vous intéresse pas !
  9. Mais en fait, dans le scénario imaginé plus haut, pour chaque ISBN vous n’avez pas vraiment besoin du titre et de l’auteur, que vous connaissez — mais des prix et états d’exemplaires, informations qui ne sont pas dans cette page.

Bref :

  1. vous voulez des données nettoyées de tout ce qui est couleur, taille de caractère, etc.
  2. vous voulez tantôt des métadonnées bibliographiques classiques, tantôt d’autres types d’informations (prix, commentaires, pages de couvertures, etc.)

Finalement, utiliser des API c’est comme afficher une liste de résultats après requête, sauf que :

  • la page obtenue est en XML au lieu d’être en HTML.
  • il n’y a pas de formulaire de recherche : vous ne pouvez interroger la base que par des URL. Mais le résultat est comparable

Pour info : « API » veut dire « Application Programming Interface« . Vous voilà bien avancés !

Que veut dire « manipuler des données en masse » ?

Grosso modo, on peut trouver deux types d’utilisation de ces API :

  1. Vous avez votre propre base bibliographique (au hasard : un catalogue de bibliothèque) et vous voulez y intégrer des contenus d’autres sources
  2. Vous avez une liste de titres (sous forme de liste d’ISBN) et vous voulez extraire d’Amazon & consorts des informations sur la base.

1. Vous avez votre base bibliographique

Quand on interroge votre catalogue, le moteur utilise une feuille modèle ressemblant à ceci :

Titre : $title
Auteur : $author
Année : $annee
ISBN : $isbn

Où les mots précédés d’un $ sont des variables : selon les notices affichées, ce sera le titre, l’auteur et l’année de publication de tel ou tel document.

L’encodage sera évidemment plus complexe, et structuré en PHP, XSL ou autre. Mais cela n’a pas d’importance, on va faire comme si.

Donc dans la notice du document qui s’affiche, vous voulez qu’apparaisse la liste des autres éditions (si existantes) du même ouvrage. WorldCat propose une API intitulée getEditions : si vous structurez une URL sous la forme : http://xisbn.worldcat.org/webservices/xid/isbn/9782765406259?method=getEditions&format=xml&fl=form,year,lang,ed, WorldCat produit la liste des ISBN de toutes les éditions de l’ouvrage auquel appartient l’ISBN 9782765406259, sous la forme d’un fichier XML :

Copie d'écran - Liste d'ISBN avec l'API getEditions de WorldCat

Si vous savez qu’on peut interroger votre catalogue avec une URL de requête sous la forme : http://catalogue.bibliotheque.fr/search?isbn=9782765406259, vous allez pouvoir bricoler le code suivant qui va générer des liens vers d’autres notices.

  • Pour une notice en cours d’affichage dans votre Opac, dont l’ISBN est connu (variable $isbn), il va interroger WorldCat pour récupérer les ISBN des autres éditions
  • Et il va générer une URL de requête dans votre catalogue contenant chacun de ces ISBN
  • Ainsi pour chaque notice détaillée dans votre Opac, des liens vers les autres éditions du même ouvrage seront proposées

Précision : ce code n’existe pas, il ne correspond à rien. Je me suis inspiré de langages existants pour produire un truc à peu près compréhensible pour n’importe qui. Ce qui se trouve après les caractères # est du commentaire, non pris en compte par le programme

new variable FichierWorldcat = concat(« http://xisbn.worldcat.org/webservices/xid/isbn/ &raquo;, $isbn)
# à partir de l’ISBN en cours, il structure l’URL d’interrogation vers WorldCat

for each $FichierWorldcat.rsp.isbn
# pour chaque contenu de balise « isbn » trouvée dans le fichier XML de WorldCat, il crée un lien vers votre catalogue

{ print <a href= »http://catalogue.bibliotheque.fr/search?isbn=$FichierWorldcat.rsp.isbn« >Autre édition</a>;

};

Evidemment, il serait préférable qu’un lien n’apparaisse que si le document existe réellement. Donc il faudrait que votre propre catalogue propose des API, pour que l’affichage du lien soit conditionné à la vérification d’existence d’un fichier XML dont l’adresse web serait : http://catalogue.bibliotheque.fr/api/isbn/9782765406259, par exemple. Ce fichier renverrait un certain message (infos bibliographiques, par exemple) si le livre est présent, et un autre message (balise <unknown/> par exemple) s’il n’est pas trouvé.

Bref, sur cet exemple les données de WorldCat vous permettraient de FRBRiser votre opac.

Autres exemples (rapidement)

De la même manière, en indiquant à LibraryThing, Amazon ou WorldCat un ISBN, ces bases vous proposent les données qu’ils sont capables d’associer à cet ISBN :

  • page de couverture
  • commentaires, notations, tags
  • prix (coût, mais aussi prix littéraires ou autres)
  • etc.

Les improbables API du Sudoc

<update>Les API Sudoc n’ont plus rien d’improbable, finalement. Je suis trop pessimiste et trop mauvaise langue (et j’aime me tromper !)</update>

Vous avez remarqué la fin de l’URL de WorldCat ? http://xisbn.worldcat.org/webservices/xid/isbn/9782765406259?method=getEditions&format=xml&amp;fl=form,year,lang,ed. Le paramètre fl permet de préciser les informations à fournir comme attributs. Ici, le format, l’année de publication, la langue et le numéro d’édition.

Maintenant, imaginons que le Sudoc propose les données de son catalogue sous forme d’API.

Par exemple, si vous avez un ISBN (toujours 9782765406259), l’URL http://www.sudoc.abes.fr/api/isbn/9782765406259 génèrerait un fichier XML ressemblant à ceci :

A cela, rajoutez la possibilité d’avoir un paramètre permettant de préciser quelles informations vous voulez voir ou non figurer (le PPN, etc.) sous la forme : http://www.sudoc.abes.fr/api/isbn/9782765406259&attributs=ti,au,year,ppn,isbn,loc

Vous pourriez ainsi disposer facilement de la liste des bibliothèques proposant le même exemplaire. Mieux : vous pourriez proposer un lien vers les catalogues de ces bibliothèques (dont l’URL serait donnée dans le fichier XML produit). Mieux encore, vous pourriez, si votre bibliothèque et vos lecteurs sont à Paris, ne générer de lien que pour les bibliothèques de la région Ile-de-France.

Bref, vous pourriez faire l’économie du message standard : « Vous n’avez pas trouvé ? Allez voir dans le Sudoc ». En fait, les données elles-mêmes du Sudoc seraient visibles directement sur votre Opac.

Bon alors, ces API Sudoc, c’est pour quand ?… La réponse sera peut-être : attendez que le Sudoc soit dans WorldCat et utilisez alors les API WorldCat en filtrant sur les réponses émanant du Sudoc… Wait and see !

2. Vous avez une liste de titres (sous forme de liste d’ISBN) et vous voulez extraire d’Amazon & consorts des informations sur la base

[vous vous souvenez ? J’avais supposé deux scénarios possibles pour l’utilisation d’API, le premier étant la gestion d’un catalogue de bibliothèque en ligne et ses possibilités d’enrichissement]

L’utilisation d’API est intéressante aussi pour prospecter sur le contenu des bases bibliographiques disponibles sur le web. C’est ce qui m’a d’ailleurs amené à découvrir un peu les API WorldCat et LibraryThing.

Par exemple vous envisagez d’enrichir votre Opac avec diverses données. Vous hésitez entre Google Book Search, Amazon, WorldCat ou LibraryThing. Et vous excluez de les utilisez tous les trois parce que, pour un lecteur, voir 2 nuages de tags et une liste de mots clés (plus l’indexation Rameau), c’est cruel !

La question ne se posera pas seulement quant à la nature des contenus que chaque fournisseur, mais aussi quand au taux de recouvrement de ces bases avec votre catalogue. Ainsi, LibraryThing a peut-être beaucoup plus d’ouvrages, mais surtout en anglais — ou autres considérations de ce genre. Par ailleurs, peut-être que, pour votre collection, WorldCat vous proposera plus de commentaires mais moins de couvertures, etc.

Donc vous pouvez définir quel genre de contenus vous voulez proposer à vos lecteurs ; puis voir, pour chacun de ces contenus, quel pourcentage de vos livres chaque base contient.

C’est ce que j’ai fait avec mon échantillon de 1000 ISBN : j’ai mis cette liste dans un fichier XML, et pour chaque ISBN, j’ai généré des requêtes en API.

Que sont les API Key ?

J’ai été bloqué chez Amazon et WorldCat : il faut être enregistré (mais c’est gratuit) pour pouvoir vraiment utilisé leurs API. Lors de l’enregistrement, ces sites me fournissent un identifiant (une série de chiffres, voire un truc alphanumérique).

Chaque fois que vous voulez lancer une requête par API (sous forme d’URL contenant un ISBN), il faut rajouter quelque chose comme : « &key=1234425767897 », afin qu’Amazon ou WorldCat sache que c’est vous et pas un autre qui a fait cette requête. Cela facilite leurs statistiques et — si nécessaire — leur facturation…

Bon, il y a un autre intérêt, qui l’est aussi pour nous : une API permet aussi de manipuler les données elles-mêmes pour les modifier. Par exemple si vous avez un blog sous WordPress, certains programmes vous permettent de modifier vos articles, d’en créer de nouveaux, de rajouter des tags, etc. sans passer par l’interface en ligne : cela signifie que WordPress expose vos données sous forme de fichiers XML. Il faut donc que l’accès à ces fichiers soit conditionné à la fourniture d’un identifiant, surtout si vous voulez modifier lesdites données. D’où l’utilité de la clé.

En outre (mais j’ai l’impression que ce n’est pas systématique), une clé peut être associée à un site web. C’est-à-dire que si vous voulez enrichir vos notices de commentaires issus d’Amazon, l’URL de votre catalogue doit être indiquée à Amazon pour que celui-ci vous renvoie les résultats XML demandés.

Si bien que pour tester le contenu des bases par propulsions de listes XML d’ISBN stockées dans des fichiers sur mon PC — impossible !

Conclusion

Un informaticien (ou quelqu’un de plus compétent que moi) trouvera(it) certainement beaucoup d’erreurs et d’approximations dans ce billet, qui ne ressort que de la pratique que j’ai eu de tous ces outils.

Je les invite à réagir (avec leur indulgence coutumière) en commentaire. De toute façon, mon objectif n’est pas que toutes les personnes ayant lu ce billet soient capables de manipuler des API, mais qu’elles soient capables de comprendre ce dont on parle quand le mot arrive dans la conversation.

Je signalerai enfin que les API sont une forme de web services (ou, si vous préférez : dans les web services, on trouve notamment les API). Comme c’est le cas le plus fréquent, les deux expressions en viennent à être interchangeables.

<update après ce commentaire>Les web services sont les développements fait sur un site pour exploiter les API d’un autre site.</update>

Mais je ne développerai pas davantage sur ce terrain. <update>Et je fais bien !</update>

27 commentaires
  1. Damiano permalink
    25/06/2009 09:23

    L’API du SUDOC, ça pourrait être un celle d’un serveur SRU (bien que ça soit un peu « bas niveau »).
    Mais aux dernières nouvelles ils n’avaient pas prévu de mettre en place un tel service…

  2. 25/06/2009 09:50

    @Damiano : pour être sûr moi-même, et pour les autres éventuellement :
    le Z39.50, c’est un échange entre ordinateurs qui ne passe pas par Internet (protocole HTTP) mais par un autre protocole (Z39.50, en fait).
    Donc les données qui s’échangent par Z39.50 sont « brutes » (pas de couleurs, de mise en forme, etc. Donc pas de mise à jour en cas de changement d’interface, comme lors de la mise à jour de l’interface publique du Sudoc).
    En revanche, comme elles ne passent pas par Internet, elles sont inaccessibles à tous les « outils » qui utilisent Internet — notamment les manipulations de données par API.

    SRU, c’est le même échange de données que z39.50, mais par des fichiers XML. Donc on y retrouve le même type de données que quand on interroge une base par API.

    Et je doute effectivement que le Sudoc fasse évoluer ses données et sa manière de les proposer : attendre WorldCat me semblerait une stratégie logique de leur part.

  3. 25/06/2009 11:39

    @Lully
    Non, on ne voit pas la fin de la commande worldcat, il n’y a pas de troncature de cette loooooongue adresse… 🙂
    Un découpage à la mano serait bienvenu.

    Définition résumée d’une API

    Api est un dieu de l’Égypte antique : il est le scarabée lumineux et ailé qui va chercher de l’information chez un « fournisseur » de l’au-delà numérique et vous la ramène.

    En réalité, une API, c’est une sorte de robot interface à qui vous donnez un ordre, et qui va l’exécuter chez un « fournisseur » sans que vous ayez à connaître sa façon d’organiser et de traiter l’information.

    En plus clair : c’est un bibliothécaire informatique à qui vous demandez un livre et qui vous le ramène, quelle que soit la bibliothèque et sa codification interne !

    Bien cordialement
    Bernard Majour

  4. amarois permalink
    25/06/2009 11:58

    Merci pour l’article, très long pour bibliothécaire (« Paix à leurs âmes »).
    Juste un point de sémantique à ce stade (mais j’imagine que c’est déjà repéré) :
    @Lully concernant ton commentaire : Internet protocole TCP/IP; HTTP est plutôt le protocole qui définie le Web, et est à un plus haut niveau.
    Quand au « couleurs » et à la « mise en forme », je ne suis pas certain de comprendre de quoi tu parle, c’est la couche supérieure, qui n’est plus du domaine des protocoles (HTML, CSS,….)

    Bon, je vais lire l’article maintenant….;-)

  5. 25/06/2009 12:07

    @amarois : quant à la mise en forme, je pensais notamment au code Amazon que j’ai recopié dans le corps du billet : on y trouve des <span class= »XXX »>.
    Ce genre d’informations n’a pas lieu d’être dans une API.

    @B. Majour : oui, merci. Je sais que web et internet sont deux choses précieusement différentes et qu’il ne faut pas les confondre, mais j’oublie toujours laquelle est quoi ;-)…
    Pour la définition de l’API, en fait je le savais aussi. Mais j’ai préféré ne pas aborder la question sous cet angle : ça me semblait être des concepts plus difficiles à manier (même si plus exacts) que la manière dont j’ai voulu présenter les choses.
    Mais les lecteurs qui liraient aussi les commentaires sont invités à confirmer si la définition de B. Majour leur « parle » davantage ou non !

  6. SynT4XX_3rr0r permalink
    25/06/2009 19:07

    La tentative part d’un bon sentiment, l’effort est louable, malheureusement le résultat me paraît trop flou et trop technique à la fois pour être compréhensible par le public auquel il s’adresse.

    Je pense d’ailleurs qu’il est non seulement à peu près impossible mais également inutile de comprendre ce qu’est réellement une API si l’on n’est pas développeur (il faut au moins avoir des bases solides). Une API est une notion à la fois relativement abstraite et très vague … en fait, pour être franc cela ne veut pas dire grand chose en soi. La première ligne de la définition donnée par Wikipédia me paraît bien … eh oui comme je l’ai dit c’est vague.
    Quand à la définition de BB elle est encore plus fausse et je dirais même : complètement à coté de la plaque (désolé).

    Ce que vous tentez d’expliquer dans ce billet c’est en fait le fonctionnement d’un protocole de communication, mais une API ne sert pas forcément à cela, il y en a – par exemple – destinées à l’affichage de graphismes en 3D, d’autres à l’interrogation de bases de données SQL, etc etc …

    Pour finir, SRU et Z39.50 sont deux protocoles aux fonctionnalités à peu près équivalentes, le fait que le vieux Z39.50 soit basé sur TCP/IP là ou SRU est basé sur HTTP (lui-même basé sur TCP/IP) ne change rien : il est tout à fait possible d’écrire des API exploitant Z39.50 (d’ailleurs cela existe depuis belle lurette), elle seront juste un peu plus difficile à écrire pour les programmeurs … on pourrait donc très bien intégrer dans un site web une API utilisant Z39.50 pour aller interroger à la volée le serveur du SUDOC.

    Si je puis me permettre : dans l’objectif de dévulgaristion informatique à destination des bibliothécaires que semblez poursuivre (et vous méritez une médaille pour cela) il serait à mon avis plus efficace d’oublier ce terme d’API qui ne concerne que les développeurs « purs » et de créer des tutoriels beaucoup plus simple du type « Comment intégrer une recherche Amazon sur son site sous le CMS X en 5min » avec captures d’écran à l’appui, et laisser les APIs et protocoles TCP/IP aux sites spécialisés en développement.

    Bravo quand même pour vos efforts, même si ce coup-ci je trouve que c’est raté, mais ce n’est heureusement pas dans vos habitudes.

  7. 25/06/2009 19:19

    @SynT4XX_3rr0r : je vais me concentrer sur l’idée que « c’était vraiment très bien toutes les autres fois » pour n’en retenir que le compliment que ça comporte… 😉
    Merci pour ces remarques : ça m’aidera à m’ajuster pour la suite.

    Toutefois, si j’ai raté mon coup, et si je suis d’accord sur les autres idées de tutoriels que vous proposez, je ne suis pas sûr que l’objectif initial était illégitime. Je veux dire par là : est-il inutile de vouloir expliquer à des bibliothécaires ce qu’est une API ? Peut-on « oublier » ce qu’est une API ?
    Et mon propre parcours — qui n’a rien de représentatif, mais qui peut ressembler à celui de quelques-uns tout de même par quelques aspects… — m’incite à penser le contraire.
    En effet les fournisseurs de SIGB proposent (ou non) des API. Nous devons les réclamer dans les cahiers des charges. Pour cela il vaut mieux savoir ce que c’est, à quoi ça sert et si c’est réellement utile, par exemple quand on est responsable d’un catalogue collectif national ou d’une médiathèque de ville moyenne.
    C’est un terme récurrent ensuite dès qu’on dialogue avec des informaticiens. Et il est très difficile de dialoguer avec des informaticiens… (soit dit en toute amitié d’ailleurs : je me suis toujours très bien entendu avec ceux que j’ai croisés !). Donc dans cette optique là aussi, il est souhaitable de comprendre à peu près de quoi on parle.

    Pourquoi ai-je présenté les choses sous cet ordre (en foirant, je veux bien vous l’accorder puisque ce n’est pas à moi d’en décider) ? Parce que j’ai voulu aborder la question sous l’angle sous lequel il se présente aux bibliothécaires : à quel moment le mot API intervient dans une discussion autour d’un Opac, et pour faire quoi ?
    Je ne recommencerai sans doute pas sur cette question-là, mais je ne trouverais pas inutile que quelqu’un d’autre, plus tard, s’efforce de nouveau, et à sa manière, d’expliquer les API aux bibliothécaires.

    Merci encore (pour les « efforts ») 😉

  8. SynT4XX_3rr0r permalink
    25/06/2009 19:22

    En relisant votre billet jusqu’à la fin, j’ai compris pourquoi il est faux : vous faites une énorme confusion :
    « Je signalerai enfin que les API sont une forme de web services (ou, si vous préférez : dans les web services, on trouve notamment les API). Comme c’est le cas le plus fréquent, les deux expressions en viennent à être interchangeables. »
    => désolé, mais c’est ARCHI-FAUX !!!
    Les APIs que vous essayez de décrire sont des outils qui se trouvent chez vous et permettent d’exploiter les webservices mis à dispositions par Woldcat, Amazon &cie.
    La différence est fondamentale et les deux termes ne sont pas DU TOUT interchangeables.
    OK, c’est bon j’arrête d’être méchant …

  9. SynT4XX_3rr0r permalink
    25/06/2009 19:27

    « est-il inutile de vouloir expliquer à des bibliothécaires ce qu’est une API ? Peut-on “oublier” ce qu’est une API ? » => absolument !

    En fait, il n’y a rien d’illégitime dans votre tentative – bien au contraire – le problème est que vous partez sur un malentendu. Tout le long de votre billet vous ne parlez non pas d’API mais de webservice. J’ai fini par comprendre votre erreur, mais je crains que dans l’esprit d’un néophyte cela n’embrouille encore plus les choses et lui pose des problèmes par la suite, ce qui est l’exact contraire du but recherché.

  10. 25/06/2009 19:29

    @SynT4XX_3rr0r : vous rigolez, c’est super important et il fallait me corriger !
    Et moi-même je vais corriger le billet.
    Non, vous n’êtes pas méchant, vous êtes constructif.
    Pour mon excuse : vers la fin de mon billet, j’ai pensé que je ne pouvais pas ne pas dire un mot des web services (pour les situer par rapport aux API). Je suis donc aller contrôler ma « conviction » de départ sur Wikipedia (en anglais) qui indique : « Web services are frequently just Internet application programming interfaces (API) ».

    Sinon, deux remarques pour compléter ma réponse précédente à votre commentaire précédent : je ne vise pas comme lectorat tous les bibliothécaires de France, mais plutôt ceux qui ont maille à partir avec l’informatique, ou, pour le dire autrement, qui sont entre autres amenés à dialoguer avec des informaticiens (enfin, ça dépend des billets, évidemment. Mais disons que là, c’était plus ou moins le cas).
    Enfin, j’ai oublié de vous remercier : j’ignorais qu’on pouvait développer des web services avec du z39.50 (comme s’il y avait des API, donc). Et j’ignorais que ça se faisait déjà depuis longtemps.

    Vous voyez, j’ai bien fait d’écrire ce billet : j’apprends plein de choses !
    Tous les bloggueurs vous le diront (les bénévoles à Emmaüs aussi) : on croit donner et on reçoit encore plus !

  11. 25/06/2009 19:36

    @SynT4XX_3rr0r : soit dit en passant, j’aime votre indignation.
    C’est pas si grave, confondre web services et API ! C’est pas comme si j’avais confondu les champs 200 et 201 dans une notice, quoi ! 😉

    Et je vais signaler une des utilités du moteur de recherche Biblioblogs francophones : il permet de retrouver des commentateurs. Ainsi, je trouve votre réaction un peu différente (mais comparable par plusieurs points) de ce que vous aviez écrit ici.

  12. SynT4XX_3rr0r permalink
    25/06/2009 19:49

    Je suis donc aller contrôler ma “conviction” de départ sur Wikipedia (en anglais) qui indique : “Web services are frequently just Internet application programming interfaces (API)”. => je suis admiratif de l’esprit qui anime Wikipedia et de son formidable apport dans la transmission du savoir, mais également conscient de ses limites … malheureusement les voici qui éclatent au grand jour car cette phrase est une énormité, je l’ai signalée.

    Dans le sens communément admis, un web service utilise un protocole basé sur HTTP ce qui n’est pas le cas de Z39.50.
    Cependant, cela n’enlève rien au fait qu’une API (je l’ai déjà dit : ce terme est très vague).peut très bien être développée pour utiliser des service Z39.50. On peut – par exemple – imaginer écrire une telle API en PHP et s’en servir pour développer un « module » ou « plugin » à intégrer dans un CMS du type Drupal, SPIP, Joomla ou autre … en fait cela existe déjà !
    Par exemple, si votre site est sous Drupal, vous pouvez y intégrer des recherches sur le Sudoc avec ce plugin : http://drupal.org/project/z3950
    Il y en a certainement d’autres et probablement pour d’autres CMS …

  13. 25/06/2009 20:02

    @SynT4XX_3rr0r : vous remarquerez que lorsque vous m’avez dit que je (donc la Wikipedia) m’étais trompé, ce n’est pas votre parole (et vos compétences) que j’ai remise en doute !

  14. B. Majour permalink
    25/06/2009 23:44

    « Quand à la définition de BB elle est encore plus fausse et je dirais même : complètement à coté de la plaque (désolé). »

    Elle n’est pas fausse, elle est orientée métier. 🙂

    Métier de bibliothécaire, ici.

    Parce que je sais, bien sûr, qu’on peut programmer des API Windows, pour beaucoup de choses. (des bonnes, comme des mauvaises)
    Et si j’utilise la notion de robot interface, c’est bien parce que ça parle aux néophytes… sans qu’il soit besoin d’entrer dans les arcanes de la technologie objet, des fonctions et des procédures, ou dans la diversité des API. (autant d’éléments galimatias pour un non informaticien, comme l’est cette définition wikipedia : http://fr.wikipedia.org/wiki/Interface_de_programmation)

    Un robot interface bibliothécaire peut aller vous chercher un livre, aussi bien qu’un café… ou encore fermer la lumière, ou afficher un tableau sur l’écran de votre ordinateur. Sauf que ce ne sont pas les mêmes API qui seront utilisées à chaque fois. Pas les mêmes fonctionnalités.

    Et si, maintenant, on confond Web Services et API, c’est parce que celles développées pour les Web Services sont de plus en plus nombreuses, ou alors les plus publicisées… hors du monde informatique. (API Google, par exemple)

    Non sens pour l’informaticien, vérité pour les néophytes. 😉

    Wikipedia ne se trompe pas, c’est l’expression hors jargon d’un ressenti ou d’une expérience. Ou encore d’une dérive du sens, incompréhensible, vers une autre réalité plus… palpable.

    Bien cordialement
    B. Majour

  15. Laurent permalink
    26/06/2009 11:00

    Merci pour ce billet!

    Pour info, des définitions tirées du livre de Tosca Consultants « Le catalogue de la bibliothèque à l’heure du Web 2.0 » :

    API :
    ====
    (Application Programming Interface)
    Ensemble de programmes documentés destiné à faciliter le développement d’applications. Les éditeurs de progiciel mettent ces API à la disposition des programmeurs, notamment chez leurs clients, afin de faciliter l’interfaçage avec leurs progiciels.

    Web service:
    ========
    Logiciel prenant en charge une fonction limitée, conçu pour être réutilisé par diverses applications, indépendant à cette fin tant du système d’exploitation que du langage de programmation utilisé par ces applications.
    Il vise à faciliter le développement de sites web et l’interopérabilité des sites. Il s’appuie sur XML pour la description des informations, sur WSDL pour spécifier l’interface et sur SOAP pour l’échange des données et des services.

    WSDL :
    (Wev Services Description Language).
    Langage de description de services web. Il permet de définir les modalités d’appel et d’utilisation de services web. Avec SOAP, il s’inscrit dans la recherche de l’interopérabilité des sites.

    SOAP :
    (Simple Object Access Protocol)
    Protocole d’échange de données et de services entre sites web, contribuant à l’interopérabilité des sites. Il utilise HTTP pour le transport des données transmises.

  16. 29/06/2009 10:57

    Des API Sudoc ont été annoncées aux journées Abes 2009. C’est visible dans ce diaporama (format PDF – le lien pointe directement à la diapo 46) : les autorités d’abord, le reste après si possible. Les échéances envisagées sont à la diapo 54.

    Merci à Yann Nicolas pour l’info.

  17. secretstory6 permalink
    25/11/2011 14:53

    Comment télécharger un API ?

  18. 25/11/2011 15:29

    @SecretStory6 : un API s’exploite en ligne, il ne se télécharge pas.
    Comme je suis persuadé que vous avez pris la peine de lire intégralement ce billet, votre question me prouve que je suis un exécrable pédagogue (ce ne sera jamais qu’une confirmation de plus…).

Trackbacks

  1. Vérifier la présence de ses ISBN dans Amazon (et GBS) « Encore un biblioblog…
  2. Bouillon collaboratif : Lien “traduction” Google « Encore un biblioblog…
  3. API: c’est quoi, comment ça marche « pintiniblog
  4. Le web des données « Bibliothèques [reloaded]
  5. Envoyer une info Google Reader vers Google Wave « Bibliothèques [reloaded]
  6. Sudoc or not Sudoc ? IdRef « Bibliothèques [reloaded]
  7. Nouvelles API Zotero : produire des zolies références bibliographiques formatées « Bibliothèques [reloaded]
  8. Petite utilisation de l’API Sudoc isbn2ppn « Bibliothèques [reloaded]
  9. Intégrer un fonds dans un catalogue : utilisation systématique d’API (Sudoc, WorldCat, Aleph, Primo, et des ratons laveurs) « Bibliothèques [reloaded]

Commentaires fermés