PROJET AUTOBLOG


Sam & Max: Python, Django, Git et du cul

Site original : Sam & Max: Python, Django, Git et du cul

⇐ retour index

Multiboards a été migré

vendredi 26 septembre 2014 à 09:30

multiboards.net, la page Web qu’on trempe dans son café, a été migrée. Comme il n’y a aucune donnée associée, ben, le truc n’a pas bougé, dont vous le retrouverez tel qu’avant.

Plusieurs personnes nous ont demandé le code source. La raison pour laquelle il n’est pas publié, c’est que c’est un amas de code vraiment peu ragoutant, et qu’il faudrait vraiment le nettoyer pour éviter que la honte ne s’abatte sur nous.

Max voudrait en faire un truc personnalisable, avec des widgets, et tout, à la netwibes mais en plus simple. Je pense que ça n’arrivera jamais :)

0bin a été migré

jeudi 25 septembre 2014 à 10:09

Vous vous souvenez de 0bin, le paste bin chiffré ? Il est de nouveau en ligne sur 0bin.net.

Je suis en train de copier tous les pastes en ce moment, et il y en a 28436 donc rsync rame un peu (j’ai fait l’erreur de le faire avec scp au début…) du coup tous les pastes ne seront pas là instantanément, mais au final, on les retrouvera tous.

Bref, on répare doucement mais sûrement.

Un bot qui tweete 4992 Super-Héros à raison de un toutes les 3,14 heures peut-il sauver Internet ?

mercredi 24 septembre 2014 à 08:43

Ceci est un post invité de 01ivier posté sous licence creative common 3.0 unported.

Depuis l’Antiquité, en moyenne, environ une seule personne s’est posée cette question, dont moi.

Je me propose donc de partager avec vous mon expérience sur le sujet en vous expliquant ce que j’ai mis en œuvre pour tenter d’obtenir une réponse.

Bonsjours, je voudrais tweeter en Python, s’il vous plaît.

Il existe plusieurs bibliothèques en Python qui papotent avec l’API de Twitter. Neuf sont actuellement référencées par Twitter.

Parce qu’il y avait écrit “Actively maintained”, j’ai tenté twython .

sudo pip install twython

Il se trouve qu’elle fait très bien ce que j’attendais d’elle, donc je ne suis pas allé chercher plus loin.

Par ailleurs, le code pour envoyer un tweet est flippant de simplicité :

from twython import Twython
 
APP_KEY = "votre petite clef-clef à vous"
APP_SECRET = "une autre petite clef-clef"
OAUTH_TOKEN = "encore une petite clef-clef"
OAUTH_TOKEN_SECRET = "enfin, une dernière petite clef-clef"
 
twitter = Twython(APP_KEY, APP_SECRET, OAUTH_TOKEN, OAUTH_TOKEN_SECRET)
 
texte = 'Oh mon Dieu ! Mais cette librairie crache des flammes ! #Twython'
 
twitter.update_status(status=texte)

Et paf :

 

Pour obtenir ses petites clefs-clefs, il est nécessaire de se créer un compte sur la plate-forme de Twitter réservée aux développeurs.

Je vous la fait courte :

> My applications dans le menu de votre icône en haut à droite > Create New Apps
> Remplir le formulaire > accepter les conditions d’utilisation après les avoir lues
> Permissions > Read and Write
> API Keys > Generate my acces token

La partie la plus compliquée pour moi fut de passer les permissions en “Read and Write“.

En effet, il faut associer un numéro de téléphone au compte twitter utilisé et la manipulation doit être faite à partir du téléphone en question.
Or, je n’ai pas de téléphone portable.

Heureusement, la femme de ma Vie a eu la bonne idée de faire l’Amour il y a 17 ans et sa fille, la fille de ma Vie, possède ce genre d’appareil.
Sauvé.

Si vous n’avez pas de fille de votre Vie, ni même de femme de votre Vie, faites en sorte d’avoir un téléphone portable.

(J’ai mis Amour et Vie en gras pour gagner des points de Karma. Je ne sais pas si ça marche, mais je me dis que ce serait tout de même bien malheureux que ça ait un effet négatif.)

Bonsjours, je voudrais ajouter une image au tweet que je tweete en Python, s’il vous plaît.

En partant du principe que vous avez une image.png à côté de votre script :

from twython import Twython
 
APP_KEY = "votre petite clef-clef à vous"
APP_SECRET = "une autre petite clef-clef"
OAUTH_TOKEN = "encore une petite clef-clef"
OAUTH_TOKEN_SECRET = "enfin, une dernière petite clef-clef"
 
twitter = Twython(APP_KEY, APP_SECRET, OAUTH_TOKEN, OAUTH_TOKEN_SECRET)
 
texte = 'Mais quelle folie ! #Twython tweete aussi des images ! '
image = open("image.png", 'rb')
 
twitter.update_status_with_media(status=texte, media=image)

Et hop :

 

J’ai du mal à imaginer qu’on puisse faire plus simple.

Maintenant, j’aimerais tweeter toutes les 3,14 heures. C’est possible ?

Pour tweeter toutes les 3 heures, une petite crontab réglée de la sorte aurait fait l’affaire :

0 */3 * * * python chemin/vers/mon/script.py

Mais pour 3,14 heures, il faut faire dans le délicat.
Je fais donc patienter le script 11 304 secondes entre chaque envoi :

from time import sleep
 
while True:
 
	envoie_moi_donc_un_tweet_avec_une_image_de_Super_Heros_du_Net()
	sleep(11304)

Tout à fait cochon.
Tout à fait parfait.

Et pour les 4992 Super-Héros.
Comment fait-on ?

Alors là, vous n’allez pas être déçus.

Afin de d’obtenir 4992 Super-Héros, je me suis dit qu’il me suffisait de trouver 24 têtes de Super-Héros, 13 torses de Super-Héros et 16 jambes de Super-Héros puis de réaliser toutes les combinaisons possibles de ces trois éléments.

24 * 13 * 16 = 4992

Hasard de folie, il se trouve qu’afin de récolter des fonds pour mener à bien leurs actions, La Quadrature Du Net propose une petite appli de personnalisation de Super-Héros pour celles et ceux qui font un don.

Et bien, aussi incroyable que cela puisse paraître, elle propose de choisir parmi 24 têtes de Super-Héros du Net, 13 torses de Super-Héros du Net, 16 jambes de Super-Héros du Net.

L’émotion est un peu retombée, mais, sur le moment, j’ai eu la chaire de poule face à une telle coïncidence, surtout quand on sait que La Quadrature défend les droits et les libertés des citoyens sur Internet depuis 2008 et que c’est pile-poil dans la thématique de la question qui fait l’objet de cet article.

Me voilà donc parti pour trouver un moyen de récupérer tous ces morceaux de Super-Héros du Net et de reconstituer les 4992 Super-Héros entiers possibles.

Pour retrouver l’adresse de chaque morceau, un simple coup d’œil au code-source de la page a suffi.

Ensuite, en terme de n’importe quoi je vous propose un morceau de choix.

Car pour faire ma petite popote, j’ai utilisé Processing.

_ Processing ?!?!
_ Oui. Processing.
_ Mais… ça utilise une syntaxe Java, ça. Non ?
_ Oui. Mais pour Sam&Max j’ai utilisé le mode Python qui vient tout juste de sortir.
_ Utiliser un “framework Java” en Python. Excuse-moi, mais c’est un peu n’importe quoi.
_ Tout à fait.

Pour celles et ceux qui ne le connaissent pas, Processing est un logiciel/langage conçu pour que les artistes, les graphistes, les designers et les grosses bubuses comme moi puissent facilement et rapidement produire du code créatif (image, son, vidéo).

Je ne vais pas vous faire un cours. Il y a un FLOSS Manual en français pour ça.

Utilisant Processing depuis plusieurs années, je vous avoue que le mode Python m’a clairement donné l’impression de faire du skate avec des rollers, mais comme outils pédagogique, ça doit être pas mal.
Et puis ça marche !

Voici le code que j’ai pondu pour l’occasion :

# La fonction setup() est propre à Processing.
# Elle s’exécute en premier et une seule fois.
 
def setup():
 
    # On crée une image transparente de 1 pixel de côté qui sera utilisée
    # pour représenter l’absence de choix de tête, de torse et de jambes
    img_vide = createImage(1, 1, ARGB)
    img_vide.pixels[0] = color(0, 0)
 
    # On crée des listes qui contiendront les images des têtes, torses et jambes
    # et on place l'image vide crée juste avant comme premier élément.
    global liste_torses, liste_tetes, liste_jambes
    liste_tetes = [img_vide]
    liste_torses = [img_vide]
    liste_jambes = [img_vide]
 
    # On lance le téléchargement de toutes les images nécessaires.
    telechargement_images()
 
    # On fabrique les 4992 Super-Héros avec les images téléchargées.
    usine_super_heros()
 
def telechargement_images():
 
    # Sachant que chaque image est atteignable par une URL du type
    # http://soutien.laquadrature.net/images/bonus/head_01.png
 
    # On définit l'URL du dossier où sont situées les images.
    url = "http://soutien.laquadrature.net/images/bonus/"
 
    # On télécharge l'image du Super-Héros tout nu qui est placé au fond
    # de chaque image et qui sert de base à tous les autres.
    global base
    base = loadImage(url + "base.png")
 
    # On télécharge les 24 têtes, les 13 torses et les 16 jambes.
    choix_image(url, "head_", liste_tetes, 24)
    choix_image(url, "torso_", liste_torses, 13)
    choix_image(url, "legs_", liste_jambes, 16)
 
def choix_image(url, nom, liste, nb_image):
 
    # Pour chaque nombre entre 1 et nb_image (0 correspondant à img_vide),
    for i in range(1, nb_image):
 
        # on définit un numéro toujours composé de 2 chiffres. Ex: 05 pour 5,
        numero = str(i).zfill(2)
        # on récupère l'image en recomposant l'URL,
        image_recuperee = loadImage(url + nom + numero + ".png")
        # et on ajoute cette image dans la liste correspondante.
        liste.append(image_recuperee)
 
def usine_super_heros():
 
    # Sachant que toutes images récupérées ont la même taille (214x383)
    # et qu'elles sont des .png transparents dont le contenu trouve sa place
    # quand les images sont parfaitement superposées .
 
    # On définit une variable qui va compter les 4992 Super-Héros.
    compteur = 0
 
    # Pour toutes les images de têtes,
    for tete in liste_tetes:
 
        # pour toutes les images de torses,
        for torse in liste_torses:
 
            # et pour toutes les images de jambes,
            for jambe in liste_jambes:
 
                # on crée un élément graphique de 214x383,
                super_hero = createGraphics(214, 383)
                # on démarre le dessin de l'élément graphique,
                super_hero.beginDraw()
                # on place un fond blanc,
                super_hero.background(255)
                # on place le Super-Héros tout nu aux coordonnées 0, 0
                super_hero.image(base, 0, 0)
                # on place l'image des jambes en 0, 0
                super_hero.image(jambe, 0, 0)
                # on place l'image du torse en 0, 0
                super_hero.image(torse, 0, 0)
                # on place l'image de la tête en 0, 0
                super_hero.image(tete, 0, 0)
                # on clos le dessin de l'élément graphique,
                super_hero.endDraw()
                # on sauvegarde notre Super-Héros du Net dans le dossier data,
                super_hero.save("data/SuperHeros-{0}.png".format(compteur))
                # et on incrémente le compteur de 1 avant de passer
                # au Super-Héros suivant
                compteur += 1

Et hop !

Et sinon, c’est encore loin Grand Schtroumpf ?

On arrive au bout.

Pour ne pas tweeter les Super-Héros du Net dans l’ordre et pour ne pas non plus poster deux fois le même en cas de croutage du serveur, je me suis créé un petit ordre.txt comme cela :

from random import shuffle
 
tous_les_numeros = range(4992)
shuffle(tous_les_numeros)
 
with open ("ordre.txt", 'w') as base:
 
    for numero in tous_les_numeros:
 
        base.write("{0},".format(numero))

Et dont le contenu est juste :

1798,915,1402,1032,507,112,1098,600,323,787,1435,200,774,33,1419,106,1836... etc

Enfin, voici le script final, qui tweete donc toutes les 3,14 heures un des 4992 Super-Héros du Net.

# -*- coding: utf8 -*-
 
# Ce script permet d'envoyer un tweet avec une image toutes les 3,14 heures
# Il récupère dans une liste le numéro de l'image a envoyer,
# et enregistre le nombre de tweets déjà postés
# pour pouvoir changer d'image à la prochaine exécution
 
import os
from twython import Twython
from time import sleep
 
# Clef d'authentification à obtenir sur https://dev.twitter.com
APP_KEY = "votre petite clef-clef à vous"
APP_SECRET = "une autre petite clef-clef"
OAUTH_TOKEN = "encore une petite clef-clef"
OAUTH_TOKEN_SECRET = "enfin, une dernière petite clef-clef"
 
twitter = Twython(APP_KEY, APP_SECRET, OAUTH_TOKEN, OAUTH_TOKEN_SECRET)
 
ordre = []
combien_deja_poste = 0
 
# Récupère le répertoire courant
chemin_dossier = os.path.dirname(os.path.realpath(__file__))+"/"
 
def envoie_moi_donc_un_tweet_avec_une_image_de_Super_Heros_du_Net():
 
    # Récupère l'ordre des images à poster
    with open (chemin_dossier+"ordre.txt", 'r') as contenu:
 
            ordre = contenu.readline().rstrip('\n').split(",")
 
    # Récupère le nombre d'images déjà postées
    with open (chemin_dossier+"deja_poste.txt", 'r') as contenu:
 
        combien_deja_poste = int(contenu.readline().rstrip('\n\r'))
 
    # Récupère le numéro de l'image
    numero = int(ordre[combien_deja_poste])
 
    # Construit le chemin vers cette image
    # Sachant que le dossier AllStar contient les 4992 Super-Héros du Net
    chemin_image = chemin_dossier+"AllStar/SuperHeros-{0}.png".format(numero)
 
    # Charge l'image
    image = open(chemin_image, 'rb')
 
    # Forme le texte du tweet
    texte = ("Voici le Super-Héros du Net n°{0}\n"
             "Si ce n'est pas déjà fait, aidez-le, lui et ses 4992 amis\n"
             "soutien.laquadrature.net").format(numero+1)
 
    # Envoie le tweet composé d'un texte et d'une image
    twitter.update_status_with_media(status=texte, media=image)
 
    # Met à jour le nombre d'images déjà postées
    with open (chemin_dossier+"deja_poste.txt", 'w') as contenu:
 
        contenu.write(str(combien_deja_poste + 1))
 
while True:
 
    envoie_moi_donc_un_tweet_avec_une_image_de_Super_Heros_du_Net()
 
    # Patiente pendant les 3,14 heures, soit  les 11 304 secondes
    sleep(11304)
 
    # Le script plantera dans 2 ans quand les 4992 Super-Héros du Net
    # aurons tous été postés, et c'est très bien ainsi...

Et voilà, il ne reste plus qu’à choper 10 Millions de followers sur ce compte et à espérer que 3,14% d’entre eux filent 10€ à LQDN pour que l’on puisse augmenter les chances de répondre positivement à la question posée dans le titre.
Une simple formalité…

Je précise que La Quadrature n’a absolument rien à voir avec ce compte Twitter, c’était juste l’occasion pour moi de pondre un article de plus ici tout en soutenant une cause qui me tient hackeur (humour).

À la prochaine…

Information complémentaire :
Le Monde en date du 12 août – Près d’un compte Twitter sur 10 est alimenté automatiquement

Le blog a été migré (enfin presque)

mardi 23 septembre 2014 à 14:18

Max a pris l’hébergement et a setup Varnish (sans lequel le WP s’écroule sous la masse de vos pattes velues), puis j’ai installé WP 4, et migré la DB et les images.

En gros, vous pouvez de nouveau lire vos articles techniques préférés. Et les autres aussi.

Par contre, feu notre ancien thème (snif, il était si… si… attachant…), et donc tous les easter eggs qui vont avec.

Vous noterez donc un blog moins fun, avec des bugs graphiques et surtout, sans plugins, donc ouvert aux 4 vents aux spams mais sans formulaire de contact. Mouarf.

Je vais corriger ça petit à petit, mais je ne me presse pas, l’avantage d’écrire un blog bénévole est qu’on ne doit rien à personne, donc on peut se gratter les couilles.

0bin, multiboards et allthatcount vont suivre. Je vais probablement les migrer avant de m’attaquer à la corrections des petits problèmes du blog d’ailleurs.

La base de données complète a été migrée. Félicitation à l’équipe de WP pour avoir mis en œuvre un outil de conversion des tables d’une version à l’autre parfaitement transparent. C’est pas facile à faire, et ça marche super bien. Mettez l’article en favoris, je ne dirais pas souvent du bien de cet outil.

Ça signifie que vos commentaires sont là, les pages statiques aussi, et bien entendu, pour les contributeurs, leurs comptes utilisateurs également. Il y a eu un bug de login ce matin, mais c’est réparé.

Si vous voyez des trucs qui pètent, merci de les lister en comment ici que je puisse avoir une check list à jour et sans doublons. Avec les URLS c’est mieux.

Parmi les problèmes que je vois venir : les iframes qui marchent pas, la barre de menu de droite qui déconne, et autres joyeusetés, des médias de mauvaise taille.

Et bonne lecture :)

Qu’est-ce qu’une API ?

samedi 6 septembre 2014 à 21:13

L’API, pour Application Programming Interface, est la partie du programme qu’on expose officiellement au monde extérieur pour manipuler celui-ci. L’API est au développeur ce que l’UI est à l’utilisateur : de quoi entrer des données et récupérer la sortie d’un traitement.

L’API au sens original

Initialement, une API regroupe un ensemble de fonctions ou méthodes, leurs signatures et ordre d’usage pour obtenir un résultat.

Par exemple, imaginons que je fasse une lib pour botter des culs en Python, bottage.py :

def senerver(moment):
    # ...
 
def botter(cul):
    # ...
 
def init():
    # ...
 
if __name__ == "__main__":
    init()

Je vais l’utiliser ainsi :

from bottage import senerver, botter
 
senerver(now)
botter(le_cul_de_ce_con)

Les deux fonctions senerver() et botter() sont mes points d’entrée pour cette action. Je n’utilise pas init(), qui est un code interne à la lib et ne me regarde pas.

Donc leurs noms et leurs paramètres ainsi que leurs types sont l’API de ma lib, ce qui m’est exposé pour l’utiliser.

Si on veut rentrer dans des subtilités, on dira en fait que senerver() et botter() font partie de l’API publique, c’est à dire de ce qui est manipulable par un utilisateur de la lib. A l’inverse, init() fait partie de l’API privée, c’est à dire ce qui est manipulable par les développeurs de la lib. Mais quand on parle d’API sans préciser, on parle de l’API publique.

Changement d’API

En informatique, on peut généralement exposer les choses de plusieurs manières différentes. Je peux changer mon API :

import datetime
 
def senerver(moment=None):
    if not moment:
        moment = datetime.datetime.utcnow()
    # ...
 
def botter(cul):
    # ...
 
def init():
    # ...
 
if __name__ == "__main__":
    init()

Ici, j’ai changé mon API pour rendre le paramètre moment facultatif afin de faciliter la vie des utilisateurs de la libs.

Et là on aborde un point très important du concept : la stabilité d’une API.

Puisque l’API est ce qu’on expose au monde extérieur, le monde extérieur va l’utiliser d’une certaine façon. Si on change cette manière de l’utiliser dans une version suivante, au moment de la mise à jour, on va casser leur code si on ne fait pas attention.

Par exemple, ici je rends un paramètre facultatif : ça ne craint pas grand-chose. Mais si j’avais fait l’inverse ? J’avais un paramètre facultatif, et soudain je le rends obligatoire. Toutes les personnes qui n’ont pas passé le paramètre vont soudain avoir un plantage s’ils passent à la nouvelle version de la lib car l’API a changé.

C’est donc une seconde définition de l’API : l’API est une promesse, un contrat entre l’auteur d’un code et ceux qui vont utiliser ce code. Cette promesse est “voici ce que vous pouvez utiliser sereinement dans votre programme, je ne vais pas tout péter demain”.

Cette promesse est plus ou moins bien respectée selon les projets. Python, par exemple, a un historique exemplaire de stabilité d’API, et n’a cassé la compatibilité qu’une fois, avec Python 3, donnant 10 ans aux développeurs pour s’adapter.

Dans tous les cas, si une lib est beaucoup utilisée et que son développeur a le sens des responsabilités, elle évolue plus doucement. Pour cette raison, il faut faire attention au choix qu’on fait dans le style de son API, sous peine de ne pas pouvoir le changer plus tard.

En effet, on peut tout à faire écrire le même code dans des tas de styles différents. Ainsi, je pourrais botter des culs avec une API orientée objet :

 
class Colere:
 
    @classmethod
    def global_init():
        # ...
 
    def __init__(moment):
        # ...
        self._senerver(moment)
 
    def _senerver():
        # ...
 
    def botter(cul):
        # ...
 
if __name__ == "__main__":
    Colere.global_init()

Mon bottage de cul n’a plus du tout le même goût à l’usage :

from bottage import colere
c = Colere(now)
c.botter(un_aperi_cul)

Mon programme fait la même chose, mais mon API est différente. Notez le _senerver() qui est préfixé d’un underscore, une convention en Python pour dire que cette méthode doit être considérée comme ne faisant pas partie de l’API publique, donc à ne pas utiliser depuis l’extérieur. En effet, il n’y a pas de méthode privée en Python.

Qualités d’une API

On a vu que la stabilité était une qualité importante d’une API. Mais il y en a d’autres. Notamment la performance et l’ergonomie, généralement deux notions qui s’affrontent.

Pour l’ergonomie, il s’agit de rendre facile les usages qu’on fait le plus couramment, et rendre possible les usages les plus ardus. Prenez l’exemple d’une requête HTTP avec paramètre POST sur un site qui a besoin de cookies d’une requête précédente. Pas un usage incroyablement complexe a priori…

Avec la stdlib de Python, ça donne ça :

import urllib
import urllib2
import cookielib
 
cookie_jar = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookie_jar))
urllib2.install_opener(opener)
urllib2.urlopen('http://site.com')
 
data = urllib.urlencode({"nom": "valeur"})
rsp = urllib2.urlopen('http://site.com/autre/page', data)
print(rsp.read())

La même chose avec la lib requests :

import requests
 
request.get('http://site.com')
res = request.post('http://site.com/autre/page', data={"nom": "valeur"})
print(res.content)

Il ne s’agit pas juste du fait qu’il y ait beaucoup moins de lignes pour le faire. La facilité à découvrir comment faire dans le deuxième cas est exemplaire : en lisant, on comprend le code. En bidouillant dans le shell, on peut sans doute trouver tout ça. On n’a pas besoin de se poser la question de ce qu’est une jar, l’url encoding, etc.

Le premier exemple est non seulement verbeux, mais très, très difficile à trouver soi-même. En fait, même avec la doc sous les yeux, ce n’est pas évident d’arriver à ce résultat, et on y arrivera après des essais douloureux.

Le deuxième exemple est plus ergonomique que le premier.

Mais l’ergonomie a généralement un coût : celui de la performance.

Imaginez que j’ai la lib de bottage de fion sous forme fonctionnelle :

import datetime
 
def senerver(moment=None):
    if not moment:
        moment = datetime.datetime.utcnow()
    # ...
 
def botter(cul):
    # ...
 
def init():
    # ...
 
if __name__ == "__main__":
    init()

Je veux la rendre plus ergonomique. Je sais qu’il faut obligatoirement s’énerver pour botter un cul, et je décide donc de cacher cette fonction et l’appeler automatiquement :

import moment
 
def _senerver(moment=None):
    if not moment:
        moment = datetime.datetime.utcnow()
    # ...
 
def botter(cul, moment=None):
    _senerver(moment)
    # ...
 
def init():
    # ...
 
if __name__ == "__main__":
    init()

Dans la plupart des cas, ça va aider mon public :

Au lieu de devoir savoir qu’il faut s’énerver avant de botter, ils ont juste à botter :

from bottage import botter
botter(cul_de_jatte)

J’ai identifié que c’était l’usage le plus courant, donc c’est une amélioration. Mais ça a un prix pour une petite partie de mes utilisateurs : les très gros botteurs de cul. Ceux qui bottent des culs par centaine.

Avant, ils pouvaient faire :

from bottage import senerver, botter
senerver()
for cul in rang_doigons:
    botter(cul)

Mais maintenant, faisant :

from bottage import botter
for cul in rang_doigons:
    botter(cul)

Ils ont un appel à _senerver() à chaque tour de boucle, et donc un appel à datetime.utcnow() aussi !

Bien entendu, il est possible de remédier à cette situation, mais cet article n’est pas là pour vous expliquer comment créer une belle API. Ce serait néanmoins un très bon article.

Ici, je vous montre simplement qu’en facilitant, on suppose d’un usage, et ça peut se faire au détriment des autres. L’automatisme a tendance à retirer de la marge de manœuvre.

Une bonne API va donc proposer un moyen automatique de faire les opérations de tous les jours, va lui donner une forme (nom, ordre des actions, organisation, etc) ET un moyen de faire des choses compliquées ou performantes. Ce qui va rendre l’API plus riche, donc plus lourde, avec une plus grosse doc, etc.

Tout a un coût.

API Web

Jusqu’ici vous avez vu l’API d’une bibliothèque, mais il existe d’autres genres d’API. L’un est devenu particulièrement populaire depuis le milieu des années 2000 : l’API Web.

L’API Web est comme l’API précédente ce qui est exposé à l’extérieur pour manipuler un programme. Entrées. Sorties. Mais il y a plusieurs différences :

Il existe de nombreux protocoles qui permettent de faire une API Web : SOAP, REST, XML RPC, WAMP etc.

Aujourd’hui, les API Web les plus populaires utilisent majoritairement un protocole pseudo-REST avec en encoding JSON.

Hum, je vous vois sourciller.

Oui, c’est clair que la phrase est un peu tordue du cul, comme si elle avait été bottée.

Prenons donc un exemple : un service Web de bottage de cul !

Vous êtes donc asskicker.io, leader mondial du bottage de cul en ligne. Et vous exposez votre processus de bottage de cul exclusif à tous les programmeurs.

Pour ce faire, vous mettez à disposition une API WEB sous forme pseudo REST. Au lieu d’appeler des méthodes, les développeurs vont envoyer des requêtes HTTP Get et Post à des URLs représentant les culs à botter.

Je ne vais pas rentrer dans les détails de ce qu’est du (pseudo) REST ou JSON exactement, mais un exemple de requêtes à faire pour botter des culs via notre API Web serait :

import json
import requests
 
# On fait une requête GET vers l'URL du service pour obtenir de quoi s’énerver
colere = requests.get('http://asskicker.io/colere/')
 
# Je créer un nouveau bottage de cul
data = json.dumps({'cul': 'de bouteille', 'colere': colere['id']})
headers = {'content-type': 'application/json'}
res = requests.post('http://asskicker.io/bottage/', data=data, headers=headers)

Et supposons qu’on veuille connaître le dernier bottage de cul fait :

res = requests.get('http://asskicker.io/bottage/last')
print(res.json()) # et la réponse JSON du service :
# {
#     "bottage": 89080,
#     "cul": "de bouteille",
#     "colere": 99943,
#     "date": "2014-09-06 20:38:11"
# }

Les URLs sont fictives, complètement inventées, et ne correspondent à rien.

Ici, notre API est donc la collections d’URLs (http://asskicker.io/bottage/, http://asskicker.io/bottage/last, etc.) qui permet de manipuler notre service, ainsi que les nom set types des paramètres à envoyer via data et le contenu de la réponse.

Le but de l’API Web est de permettre de manipuler du code sur une machine distante à travers le Web, depuis n’importe quel langage capable d’envoyer une requête HTTP. L’API Twitter permet de de lister des tweets et en envoyer. Par exemple, si on est authentifié, faire une requête GET sur http://api.twitter.com/1.1statuses/show/787998 permet d’obtenir en retour un JSON contenant les informations sur le tweet numéro 787998

L’API Google permet de faire des recherches. L’API flicker permet d’uploader des photos. Toutes les APIS ont des formes différentes, certaines sont plus ou moins faciles, plus ou moins efficaces, utilisent tels ou tels formats, mais au final, c’est la même chose : un moyen de manipuler le service en faisant des requêtes.

La manière classique de créer un site est de générer le HTML final sur le serveur. Or, comme il est possible d’envoyer des requêtes HTTP depuis une page Web en utilisant Ajax, on voit aujourd’hui des sites codés en Javascript qui vont chercher leurs données sur le serveur via l’API du site. Le navigateur reçoit ainsi un HTML incomplet, et le JS appelle l’API pour reconstruire la page.

Ainsi, on code la logique une seule fois : récupérer les informations, effectuer des actions… Et on utilise l’API pour tout ça, que ce soit pour faire le site Web, ou pour laisser d’autres programmeurs utiliser le site.

Évidemment, une vraie API Web est complexe, possède des problématiques de sécurité, d’authentification… Encore un bon article à écrire.