Carnet de notes

Auteur/autrice : Éric

  • Défi­nir son API : version­ne­ment

    Toujours dans la logique de réflé­chir son API, parce qu’un jour il faudra la faire évoluer, comment gérer le version­ne­ment ?

    Plusieurs solu­tions ont émergé :

    • https://api-v2.example.com/mares­source
    • https://api.example.com/v2/mares­source
    • https://api.example.com/mares­source-v2
    • https://api.example.com/mares­source?v=2
    • https://api.example.com/mares­source avec une entête Version: 2
    • https://api.example.com/mares­source avec une entête Accept ou/et Content-type: appli­ca­tion/monfor­mat;version=2

    La solu­tion du sous-domaine n’est à mon sens à réser­ver que pour les big-bang. Elle n’est pas faci­le­ment multi­pliable à l’in­fini, mais à l’avan­tage de permettre aisé­ment d’avoir même deux plate­formes tota­le­ment sépa­rées pour les deux versions de l’API.

    Les deux suivantes se distinguent par le fait de version­ner l’API ou la ressource. J’ai tendance à penser que s’il faut version­ner la ressource en cassant la compa­ti­bi­lité, alors c’est peut être une nouvelle version de l’API qui est à publier si on ne veut pas finir avec un gros patch­work diffi­cile à main­te­nir : En gardant tout sous le même espace on s’in­ter­dit de faci­le­ment rendre obso­lète les anciennes versions.

    Quitte à parfois devoir version­ner au niveau de la ressource, l’idée d’ajou­ter un para­mètre a fini par me sembler plus propre. Il s’agit quasi­ment toujours de s’adres­ser à une repré­sen­ta­tion diffé­rente de la ressource, pas de chan­ger son sens fonda­men­tal. Le risque est que la plupart des gens conti­nuent à utili­ser la version d’ori­gine et ne pas prendre en compte le para­mètre. Rendre obso­lète des anciennes repré­sen­ta­tions risque là aussi d’être diffi­cile.

    Les possi­bi­li­tés d’ajou­ter les versions dans les entêtes sont souvent conseillées d’un point de vue théo­rique. En pratique mon retour est que c’est complexe à utili­ser, et d’une valeur ajou­tée assez discu­table. On oublie trop faci­le­ment que le bon usage de l’API tient direc­te­ment à sa simpli­cité et sa bonne compré­hen­sion. S’il y a besoin d’être expert en archi­tec­ture web pour comprendre le pourquoi des choses, c’est une mauvaise solu­tion. Le « tout dans l’URL » ajoute une faci­lité pour tester et échan­ger entre tech­ni­ciens qui vaut toutes les posi­tions acadé­miques du monde.

    Twilio a aussi une façon inté­res­sante de gérer les versions. Au lieu d’un v2 ou v3, le déve­lop­peur indique une date et c’est le serveur qui sélec­tionne la version de l’API à utili­ser en fonc­tion de la date. C’est tentant, souple, mais j’ai peur que ce ne soit pas suffi­sam­ment expli­cite sur ce qu’on utilise ou sur comment gérer ce para­mètre. Qu’est-ce qui change si je met à jour la date ?

    Des lectures et expé­riences je tire quelques recom­man­da­tions :

    • Prévoir dès le départ un système de version­ne­ment, vous en aurez besoin un jour, ne croyez pas que vos API pour­ront rester telles quelles ad vitam eter­nam
    • Impo­ser un version­ne­ment expli­cite, immé­dia­te­ment, dès la première version. Vous évite­rez les ambi­guï­tés et une partie des moules qui s’at­tachent aux adresses « sans version » par défaut
    • N’uti­li­ser que des numé­ros de version simples, pas de notion de mineur/majeur, pas de points ou virgules : Si ça change de façon non compa­tible c’est une nouvelle version et on incré­mente d’une unité. Le reste c’est du marke­ting et ça n’a rien à faire dans vos URLs.
    • Utili­ser un version­ne­ment dans l’URL, à la racine du service ; il sera temps d’uti­li­ser un autre sous-domaine si un jour il y a un vrai big bang qui le néces­site
    • Docu­men­ter (oui, c’est évident, mais pas si simple à ne pas oublier)

  • Défi­nir son API : authen­ti­fi­ca­tion

    Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes ques­tions qui font écho avec mes propres reflexions.

    Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :

    • Pas de système de session avec point d’en­trée spéci­fique pour le login. Ça demande au client de se préoc­cu­per de l’ex­pi­ra­tion de la session et de son main­tient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus impor­tante pour le serveur. Sauf besoin spéci­fique, il faut rester en state­less : Chaque connexion contient ses propres infor­ma­tions d’au­then­ti­fi­ca­tion.
    • Pas d’au­then­ti­fi­ca­tion par IP, comme je le vois trop souvent. Outre que c’est un poten­tiel problème de sécu­rité, c’est juste quelque chose de diffi­ci­le­ment main­te­nable et c’est toujours au dernier moment quand on veut faire un correc­tif, une migra­tion ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
    • L’au­then­ti­fi­ca­tion HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour amélio­rer légè­re­ment la résis­tance aux inter­cep­tions, il faut stocker le mot de passe en clair côté serveur. Une authen­ti­fi­ca­tion HTTP Basic avec du TLS pour sécu­ri­ser la commu­ni­ca­tion me semble bien plus perti­nent, et aussi plus simple à réali­ser.
    • Le système fait maison est toujours la pire solu­tion, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problé­ma­tique qui touche la sécu­rité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous commu­nique­rez avec des tiers.
    • OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solu­tion finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globa­le­ment est une sphère contrô­lée que vous devriez préfé­rer.

    Au final il reste le choix entre l’au­then­ti­fi­ca­tion HTTP Basic, l’au­then­ti­fi­ca­tion par certi­fi­cat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :

    • OAuth s’il s’agit d’avoir une authen­ti­fi­ca­tion à trois pattes. Hors de ques­tion d’im­po­ser à l’uti­li­sa­teur final de saisir ses mots de passes dans un logi­ciel tiers. Pour une API qui veut créer un écosys­tème de logi­ciels clients (type twit­ter) c’est le choix quasi­ment imposé. Oui il y a des diffi­cul­tés pour le mobile ou pour ce qui n’est pas « navi­ga­teur », mais ces ques­tions sont désor­mais large­ment docu­men­tées. Pensez bien que choi­sir ce type d’au­then­ti­fi­ca­tion demande un réel travail (par exemple trou­ver l’er­go­no­mie pour permettre à l’uti­li­sa­teur d’au­to­ri­ser et reti­rer l’au­to­ri­sa­tion d’ap­pli­ca­tions tierces sur votre propre système)
    • HTTP Basic par défaut pour quasi­ment toutes les autres situa­tions. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffi­sam­ment sécu­risé si on passe par du SSL/TLS.
    • Et les certi­fi­cats clients avec SSL/TLS ? C’est une solu­tion qui semble plus inté­res­sante que l’au­then­ti­fi­ca­tion HTTP mais qui se révèle complexe pour pas mal d’in­ter­lo­cu­teurs. La valeur ajou­tée ne semble pas valoir la complexité supplé­men­taire si vous n’in­te­ra­gis­sez pas avec des entre­prises de taille signi­fi­ca­tive. J’y croyais beau­coup, mais fina­le­ment j’ai peu d’ar­gu­ment face à la simpli­cité du HTTP Basic.

    Et vous ? vous utili­sez quoi pour l’au­then­ti­fi­ca­tion de vos services ?

  • Trajet boulot dodo

    J’ai l’im­mense chance d’ha­bi­ter près de mon job, 20 minutes à pied. Pour contre-balan­cer je suis aussi un grand fainéant. Je cherche donc à éviter cette marche à pied de 40 minutes aller-retour, soit pour la réduire en temps de trajet soit pour la rendre plus confor­table.

    Je prends souvent le tram sur deux arrêts, mais ça me laisse encore 10 grosses minutes à pied et plusieurs minutes d’at­tente. C’est plus par parce que je n’ai toujours pas rési­lié mon abon­ne­ment de trans­port en commun. Je ne gagne pas signi­fi­ca­ti­ve­ment en temps de trajet total et ça n’a d’in­té­rêt que parce que je suis assis un peu plus au chaud. Sauf très forte pluie, ça ne se justi­fie pas vrai­ment et même ma fainéan­tise ne sera pas assez forte pour que je consi­dère ça comme une solu­tion.

    L’idéal pour ce type de trajet serait une bonne trot­ti­nette mais j’ai aussi une belle pente sur la moitié du trajet. Ce n’est pas énorme, dans les 5% au jugé, mais assez pour rendre la trot­ti­nette trop peu pratique.

    Reste le vélo mais mon côté fainéant reprend le dessus consi­dé­rant la pente à 5% (la montée se ferait le soir, quand je suis crevé). Du coup je regarde l’as­sis­tance élec­trique. Ça coûte cher, surtout si je ne l’uti­lise pas tous les jours (le vélo sous la pluie ne m’at­tire pas), donc j’ai un peu de mal à vrai­ment l’en­vi­sa­ger.

    Vous voyez un autre moyen de trans­port à envi­sa­ger ? Avez-vous des recom­man­da­tions ?

  • Adieu SSII, bonjour ESN !

    Est-ce qu’un chan­ge­ment de nom de SSII vers ESN va suffire à faire oublier leur répu­ta­tion sulfu­reuse (et souvent méri­tée) ? C’est pour­tant pour moi la seule moti­va­tion crédible à cette propo­si­tion. Je doute que « service numé­rique » soit signi­fi­ca­ti­ve­ment plus perti­nent, ou que la valeur ajou­tée renta­bi­li­sait le chan­ge­ment de nom.

    Bref, c’est unique­ment du marke­ting et le Syntec ferait mieux de faire évoluer les pratiques que de chan­ger l’em­bal­lage.

    Au moins nous avons évité l’ESD : l’en­tre­prise de services digi­taux. Je ne comprends toujours pas comment on peut faire confiance à toutes ses agences qui se disent expertes du web et du numé­rique et qui pour­tant ne se rendent même pas compte qu’elles utilisent le terme « digi­tal » de travers.

  • Bomber­man massi­ve­ment multijoueur

    Un bomber­man-like massi­ve­ment multijoueur ? Je ne suis pas convaincu par l’in­té­rêt ludique. Ne pas jouer avec ses amis, ne pas tisser de liens, avoir une inter­ac­tion limi­tée à quelques minutes et faite au hasard, j’ai peur que ça ne remplisse pas de promesses sur le long terme.

    Tech­nique­ment par contre c’est inté­res­sant, pas forcé­ment si complexe que ça, mais sacré­ment inté­res­sant. Le jeu dans le navi­ga­teur n’est qu’à ses débuts.

  • L’im­plo­sion du système Dassault pour ceux qui ont raté le début

    Le tireur présumé, en fuite, s’ap­pelle Younès B. Son nom a fuité très vite. L’homme serait un proche de Serge Dassault d’après Le Point et le Canard enchaîné, qui déroule son CV :

    • chauf­feur du colis­tier de Serge Dassault, qu’il a rencon­tré en 1995 ;
    • emploi-jeune à la mairie de Corbeil ;
    • créa­teur d’une entre­prise en affaires avec la ville ;
    • homme de main de l’an­cien maire, dans les dépla­ce­ments, les soirées élec­to­rales et pour les missions plus discrètes :

    […]

    La victime, elle, fait partie (toujours selon le Canard), des jeunes de cités qui ont dénoncé en 2010 l’achat de votes par Serge Dassault, avant de se rétrac­ter.

    Si le scan­dale Dassault se confirme, je ne peux qu’es­pé­rer qu’il fasse élec­tro­choc.

    « – Je veux vous remer­cier tous de ce que vous avez fait, car c’est vrai que c’est en grande partie grâce à vous et je le sais. Les collages la nuit, etc.

    – De toute façon, pour nous monsieur le maire c’était clair et net, nous on voulait que ça soit Serge Dassault. Parce que nous on est une géné­ra­tion de personnes qui avons grandi avec vous. […] Lui il souhaite monter quelque chose en restau­ra­tion, moi c’est ma licence de taxi, on souhaite savoir si vous pouvez nous aider. […]

    – D’ac­cord. Pratique­ment pour vous aider c’est 30 000 euros ? Et vous aussi ?

    – Fran­che­ment l’idéal, moi je vous le dis, j’ai pas osé tout à l’heure, mais main­te­nant j’ose vous le dire, mais fran­che­ment la somme idéale c’est de commen­cer avec 80 000 euros.

    – Et moi mon frère, il a l’am­bi­tion de créer une société de trans­port inter­na­tio­nal. Et ça repré­sente une somme de 100 000 euros. […]

    – Mais si vous dispa­rais­sez tous, moi après j’ai plus personne !

    – Devant vous vous avez sept jeunes qui sont prêts à rele­ver leurs manches. Ils seront toujours actifs sur Corbeil parce qu’on a tous grandi à Corbeil. On ne va pas vous aban­don­ner comme vous avez vu monsieur. »

  • Fin de Google Reader – Alter­na­tive

    Notre nouveau pape est là depuis juste quelques heures, qu’on annonce déjà la fin de Google Reader. Peut être pour mettre en avant Google+, peut être simple­ment parce que ça ne permet pas d’y mettre de la pub et que ça coûte cher.

    Quelques solu­tions (je ne prends en compte que ceux qui me semblent aptes à servir d’agré­ga­teur pour un nombre de flux à trois chiffres. Les jolies vues qui présentent 10 articles avec des belles photos ou celles qui proposent une boite pour chaque flux avec ses trois derniers billets sont donc à priori exclues (je classe Netvibes dans ces caté­go­ries à priori).

    À héber­ger chez vous :

    Leed : du PHP à instal­ler avec un cron pour parcou­rir les RSS. Il y a une vue smart­phone mais il manque les raccour­cis claviers. La vue est pagi­née, une fois lu/sauté les items d’une page, il faut rafrai­chir la page en cours (pas passer à la suivante sinon les 10 items suivants passe­ront en première page et seront igno­rés). Je n’ai pas l’im­pres­sion du même côté pratique que Google Reader. La FAQ me donne aussi une petite crainte sur la jeunesse du code.

    rssLounge : Assez peu d’in­for­ma­tions, si ce n’est qu’il gère les flux de photos et qu’il permet de gérer des prio­ri­tés suivant les flux. Cette dernière fonc­tion­na­lité peut être inté­res­sante. Il y a aussi un jeu de raccour­cis clavier. Je n’ai pas testé la visua­li­sa­tion pour mobile. Le projet semble de toutes façons mort depuis novembre 2011, ce qui n’est pas un bon signe.

    TinyTi­nyRSS : L’es­sen­tiel des liens sont morts, donc diffi­cile d’en savoir plus. Si ce n’est que c’est actif (dernière version hier), qu’il y a une API, des raccour­cis, et même une appli­ca­tion Android native (payante mais open source, à vous de recom­pi­ler l’ap­pli­ca­tion si besoin). La capture d’écran par défaut semble quand même bien moche.

    Service tiers :

    The Old Reader : Peut être celui qui ressemble le plus à Google Reader, avec une vue mobile, des raccour­cis, un fonc­tion­ne­ment simi­laire. Il y a même une inté­gra­tion Pocket. Si vous souhai­tez un clone, le voilà. Le fait qu’il demande l’ac­cès au carnet d’adresse Google pour s’iden­ti­fier est toute­fois assez bloquant. Certaines actions sont aussi parfois un peu lentes et ils ne parlent à aucun moment d’une API dispo­nible pour des tiers.

    Feedly : Complet, il présente pas mal de vues diffé­rentes, des raccour­cis, des applis sur les diffé­rents navi­ga­teurs et systèmes mobiles. Il fut basé sur Google Reader mais commence une migra­tion vers ses propres solu­tions, avec pour objec­tif d’ou­vrir aussi leur API (mais pour l’ins­tant c’est une promesse). Diffi­cile de dire ce que ça donnera ensuite. Le fait d’im­po­ser des exten­sions de navi­ga­teur mais pas d’in­ter­face web directe me gêne un peu : Impos­sible à consul­ter sur le poste de quelqu’un d’autre.

  • Patterns – RubyGems guides

    Pour ma propre archives : Les conven­tions d’or­ga­ni­sa­tion des fichiers et des classes pour les gem Ruby

  • Je veux chan­ger ça, et ça, et ça

    Je pense que je ne suis pas le seul à imagi­ner régu­liè­re­ment comment créer un nouveau langage ou modi­fier les exis­tants à ma conve­nance. Sans aller jusque là, en croi­sant ce qui se fait dans les diffé­rents langages, on trouve toujours des point inté­res­sants qu’on aime­rait voir copiés.

    Voilà donc quelques unes de mes frus­tra­tions, parce que les expri­mer permet de s’en débar­ras­ser un peu et de se concen­trer sur l’im­por­tant : ce qu’on fait avec le langage.

    Persis­tance du code en PHP

    Chaque requête web recharge entiè­re­ment l’ap­pli­ca­tif PHP. APC apporte une béquille indis­pen­sable mais ça reste au niveau de la béquille. Toute l’ini­tia­li­sa­tion est à refaire à chaque fois. Ça fonc­tionne, mais j’ai­me­rai vrai­ment un mode de PHP ou un frame­work web PHP qui permette de commen­cer direc­te­ment au trai­te­ment des requêtes sans avoir à tout refaire de zéro.

    Acces­seurs en PHP

    Toujours côté PHP j’at­tends depuis bien long­temps l’ap­pa­ri­tion d’ac­ces­seurs trans­pa­rents pour les attri­buts des objets. Ruby, Python et Javas­cript ont chacun leur façon de faire. Là il ne s’agit pas de repiquer une syntaxe au langage voisin mais bien de combler un manque.
    Sérieu­se­ment, je n’en peux plus de ces getX() et setX(). C’est encore plus pénible à l’uti­li­sa­tion qu’à la créa­tion.

    Espaces de noms

    Fut un temps je râlais beau­coup contre PHP mais ce dernier une bonne partie du retard qu’il avait. Mieux : Arrivé en dernier il s’est permis de parfois faire les choses plus intel­li­gem­ment.

    Dites, pourquoi n’ai-je pas d’es­paces de nom en Javas­cript ?

    Les « use » de PHP me manquent aussi en Ruby. Ils présentent une solu­tion élégante et pour donner des noms courts en local à des classes qui viennent d’autres espaces de noms, mais ils permettent aussi les alias pour chan­ger faci­le­ment une implé­men­ta­tion par une autre sans impac­ter le code.

    Pendant qu’on y est, pourquoi pas d’auto-char­ge­ment en Ruby ? Si je charge X::Y::Z, j’ai­me­rai bien que le langage se charge tout seul d’al­ler cher­cher le fichier X/Y/Z.rb. Ça fonc­tionne dans quasi­ment tous les autres langages mais Ruby conti­nue de faire du spaghetti d’in­clu­sion manuelle de fichiers.

    Blocs et ferme­tures lexi­cales

    Les blocs sont *la* fonc­tion­na­lité qui me fait utili­ser Ruby. On peut certes faire beau­coup de choses simi­laires avec des fonc­tions anonymes en Javas­cript ou en PHP mais c’est juste moins élégant (et ça compte beau­coup pour se sentir à l’aise).

    Par contre, sérieu­se­ment, la récep­tion des para­mètres dans les blocs est vrai­ment peu lisible. Le choix de la barre verti­cale comme déli­mi­teur est juste illi­sible.

    Le pire arrive avec les ferme­tures lexi­cales. Ruby laisse bien trop faci­le­ment utili­ser par erreur une variable venant de la portée parente. La syntaxe pour forcer une variable comme locale ajoute encore plus au côté non lisible. |x, y=3; z| ? sérieu­se­ment ?

    À côté de ça PHP et Python proposent des variables en lecture seule, ce qui limite la casse. PHP impose même de décla­rer expli­ci­te­ment les variables à impor­ter de la portée parente au lieu de décla­rer les variables locales. Diffi­cile à imagi­ner en monde Ruby mais assez confor­table au final.

    Et vous ? qu’est-ce que vous chan­ge­riez en premier ?

  • L’in­ter­dic­tion du cumul des mandats va être repous­sée en 2016–2017

    Le problème pour les réformes du système poli­tique, c’est qu’il faut forcé­ment frois­ser des inté­rêts person­nels d’élus. Si on ajoute la crainte de perdre, il y a à chaque fois de bonnes raisons de recu­ler.

    Du coup…. 2016 – 2017 pour l’in­ter­dic­tion du cumul des mandats, et même proba­ble­ment un peu plus parce qu’il n’y a pas de raisons qu’on ne recule pas encore une fois.