DEV Community: damienb-opt

Alors, ça prompte ?

damienb-opt — Thu, 18 Dec 2025 08:00:00 +0000

Qui n'a jamais croisé au hasard d'une déambulation dominicale ce fameux pêcheur, et lancé au passage un "alors, ça mord ?" Evidemment cela implique de quitter quelques minutes ses sombres écrans pour découvrir le monde de la très très grosse donnée, tellement riche que le pixel, même OLED, n'a plus de sens.

Pour ceux qui côtoient de réels collègues, pas ces succédanées d'interactions en "télétravail", il n'est pas rare de croiser de nouveaux pêcheurs 2.0, poussés par les hérauts des compétences molles à suivre une psychothérapie avec un canard en caoutchouc digitalisé. "Alors, ça prompte ?" est-on tenté de lancer !

Après tout, nous sommes sommés de devenir promptement des prompteurs. Et ce serait pêcher par orgueil de ne pas suivre cette voie disruptive. Qui n'a jamais rêvé d'être l'écran qui transforme le présentateur en simple lecteur ? Le prompteur ne serait qu'un lutrin ? Mais non, ça c'est la liseuse, qui n'a rien d'une lectrice !

Trêve de digressions et rentrons dans le vif du sujet : que se cache-t-il derrière cet apparent anglicisme ?

Les plus séniors d'entre nous se rappellent de leurs cours de BASIC, et du fameux INPUT. Dans An Introduction to Programming the Amstrad CPC464 and 664, il est écrit à ce sujet (je jaunis) :

The problem with the INPUT statement is that the simple question mark does not give any indication of what sort of input is required. To ease this problem, Locomotive BASIC has provision to include a line of text in the INPUT statement, which is printed on the screen along with the question mark, as an input prompt. When this is used, using a semi-colon between the prompt and the name of the variable will cause the question mark to be printed. Using a commas will cause it to be suppressed.

User-Friendly is a term that is much in use. It means making a program easy and pleasant to use. Input prompts are a vital part of this. They should clearly (and politely) indicate what the user is intended to type in. NAME? appearing on the screen would certainly indicate what is required, but is not very polite. “Please enter name” is better if the question mark is suppressed, otherwise “What is your name, please?” would be the best prompt to use.

One should avoid being obsequeous. If I came across an input prompt “Would you mind entering your name, please?” I personally could not resist entering NO!

It is very difficult to phrase input prompts to deal with multiple input statements, except at the very basic “enter three numbers” level.

Et bien, ça promptait sévère en 1985 il y a 40 ans !

Intéressons-nous à la traduction officielle de ce texte dans l'édition française du livre (je jaunis encore) :

L’instruction INPUT pose un problème : le point d’interrogation inscrit sur l'écran ne donne pas d'indication quant à la donnée demandée. Pour résoudre ce problème, Locomotive Basic peut insérer une ligne de texte dans l'instruction INPUT; cette ligne est inscrite avec le point d'interrogation. Lorsque l’on utilise cette possibilité, si on laisse un point-virgule entre la phrase et le nom de la variable, alors, le point d'interrogation apparaît. Sinon il est supprimé.

Les programmeurs amateurs adorent écrire des programmes distrayants et faciles d’accès ; l'emploi des lignes de texte définies ci-dessus occupent alors une place très importante. Elles doivent indiquer clairement ce que l’on demande à l’utilisateur. Si NOM ? apparaît sur l’écran, vous comprendrez très bien le sens de la question, mais il est plus poli d’écrire “indiquez votre nom s’il vous plait” ; dans ce cas, le point d'interrogation est supprimé, sinon “Quel est votre nom s’il vous plaît ?”, serait la meilleure possibilité.

Il faut toutefois éviter d’être pompeux : à la question “Auriez-vous l’amabilité de donner votre nom, s’il vous plaît ?”, il est difficile de résister à l’envie de répondre NON!

Il est très difficile de créer des phrases explicitant des instructions INPUT multiples, si ce n’est les très simples “Donnez trois nombres”.

Comment ça rien n'a été surligné ? Les mots input et prompt n'ont pas été traduits : la tournure des phrases a été légèrement modifiée pour éviter cet écueil. Mais que voulait dire prompter en cette année 1985 ? On peut regarder dans le Penguin English dictionary contemporain :

prompt: v 1 to move to action; incite 2 to assist (somebody acting or reciting) by saying the next words of something forgotten or imperfectly learnt

prompt: adj 1a ready and quick to act as occasion demands b punctual 2 performed readily or immediately

prompt: n the act or an instance of prompting; a reminder

On voit donc plusieurs sens. Pour l'adjectif, c'est le même que l'adjectif français prompt, qui vient du latin promptus. L'autre sens, celui de déclencher l'action, d'inciter, nous vient aussi du latin, d'un mot qui signifiait "mettre en avant", et que nous avons en français avec promouvoir. Quand au sens du souffleur, il est dérivé du fait que le prompter (en anglais) est toujours prêt (au sens de l'adjectif) à assister l'acteur.

Alors, comment fallait-il traduire ce prompt en 1985 ? Attend-on que l'utilisateur souffle une réponse à la machine, ou est-on en train de lui demander quelque chose ? On peut répondre promptement : input prompt, on demande à l'utilisateur sa saisie. Les traductions officielles ont depuis consacré le mot invite ou invitation pour cette demande. Quelque part, c'est un peu gentillet, dans le sens où dans ces IHM, si l'utilisateur ne saisit rien, l'ordinateur ne fait rien ; c'est plus un ordre, "rentre #LADATA dans moi (input) ou alors... je dors".

40 ans plus tard, on en est exactement au même point. Un programme attend bêtement qu'un humain vienne saisir de #LADATA. Et propose, en boucle, de recommencer. Après ces décennies par contre, on a oublié que c'était la même bête mécanique qui était en jeu, et on s'est senti obligé de la nommer avec un faux néologisme bien digital. Alors, ça prompte ?

Peut-on encore tester comme Beizer ?

damienb-opt — Thu, 04 Dec 2025 08:00:00 +0000

Qui n'a jamais entendu cette question dans l'espace ouvert "oui, mais elle fait quelle taille ton unité ?" Et l'autre de répondre : "petite, comme... heu", et là, patatras, pas de point de comparaison. Pourtant, l'autre utilise JUnit, ou PHPUnit, ou un autre. Oui, JUnit, le cadriciel créé par Kent Beck et Erich Gamma (du GoF), LE Kent Beck du Test-Driven Development, le fameux TDA, pardon, TDD. Ne nous emportons pas, l'autre est peut-être adepte du Behavior-Driven Development, la fameuse méthodologie où ce sont les analystes métiers qui rédigent directement les cas de tests, grâce aux harnais fournis par les développeurs, et pas un dévoiement de la méthodologie où le développeur code dans un langage de concombres (même pas masqués) ? Ou simplement en écrivant des noms de méthodes de 500 caractères de long en faisant des phrases dans un anglais plus qu'approximatif ?

Soyons raisonnables : restons sur Beck et le TDD. On connaît les différents types de test : unitaire, intégration, fonctionnel, bout-en-bout (e2e). On peut dire que c'est bio, comme ces concombres, ou plutôt que c'est naturel : tout le monde est d'accord sur ce vocabulaire. Voyons donc comment Kent qualifie les tests unitaires dans "Test-Driven Development By Example" publié en 2003 (je jaunis) :

Le problème à conduire les développements avec des tests à petite échelle (je les appelle “tests unitaires”, mais ça ne correspond pas très bien à la définition acceptée des tests unitaires) est que vous courrez le risque d'implémenter ce que vous pensez être la volonté de l'utilisateur, mais qui s'avère ne pas être ce qu'ils veulent du tout.¹

Ha. Beck nous donne deux informations : d'un, une définition de "test unitaire" existe bien dans le monde professionnel et de deux, il n'en a strictement rien à faire. Le nom JUnit est donc tamponné du fameux "vu et s'en cogne".

Va-t-il falloir fouiller tel un archéologue de l'ACM pour trouver ces fameuses définitions ? Lire des dizaines d'auteurs rendant compte de manière en apparence contradictoire ? Non, il suffit de Beizer.

Je parle évidemment de Boris Beizer, un des onze distingués de l'International Software Testing Qualification Board, et auteur de deux livres de référence sur la qualité logicielle : Software Testing Techniques (1983) et Software System Testing and Quality Assurance (1984). Voyons ce qu'il écrivait à ce sujet dans la seconde édition de 1990 du premier livre ; c'est un peu long, mais vous serez récompensés de cette lecture par un eurêka de fort bon aloi.

Nous testons selon trois types distincts un système logiciel typique : test unitaire/de composant, test d'intégration, et test de système. Les objectifs de chaque classe sont différents et en conséquence, on peut s'attendre à une utilisation d'un mélange de méthodes de test. Elles sont :
Unité, Test unitaire — Une unité est le plus petit élément d'un logiciel qu'on puisse tester, c'est-à-dire qu'il peut être compilé ou assemblé, lié, chargé et mis sous le contrôle d'un banc d'essai ou d'un pilote. Une unité résulte habituellement du travail d'un programmeur et consiste en quelques centaines (ou moins) de lignes de code source. L'activité de test unitaire est effectuée pour montrer que l'unité ne satisfait pas à ses spécifications fonctionnelles et/ou que sa structure d'implémentation ne correspond pas à la conception technique. Quand nos tests mettent en évidence de telles fautes, on parle de bug unitaire.
Composant, Test de composant — Un composant est un agrégat intégré d'une ou plusieurs unités. Une unité est un composent, un composant et les sous-routines qu'il appelle est un composant, etc. Par cette définition (récursive), un composant peut-être n'importe quoi d'une unité à un système entier. L'activité de test de composant est effectuée pour montrer que le composant ne satisfait pas à ses spécifications fonctionnelles et ou que sa structure d'implémentation ne correspond pas à la conception technique. Quand nos tests mettent en évidence de telles fautes, on parle de bug de composant.
Intégration, Test d'intégration — Une intégration est un processus par lesquels les composants sont intégrés pour créer de plus grands composants. L'activité de test d'intégration est effectuée pour montrer que, en dépit du fait que les composants sont individuellement satisfaisants, comme démontré par la validation par les tests de composant, la combinaison des composants est incorrecte ou incompatible. [...]

Je suis redevable à l'un de mes étudiants de séminaire pour l'illustration élégante suivante de la problématique de tests de composants et d'intégration. Soit une sous-routine A, qui s'appelle elle-même de manière récursive. Le test de composant n'inclut pas l'appel des sous-composants ; en conséquence, la récurrence de l'appel de A à A n'est pas testé. Le test d'intégration est celui de l'appel de A et de son retour. Ce nouveau composant, intégré, est clairement différent car il implique le support des appels récursifs (par exemple avec une pile), qui n'était pas testé auparavant ; en conséquence, en tant que "nouveau" composant, il requiert une activité de test supplémentaire.

Système, Test de système — Un système est un gros composant. L'activité de test de système vise à mettre en évidence des anomalies qui ne peuvent pas être attribuées à des composants en tant que tels, comme des incompatibilités entre composants, ou des interactions prévues de composants et d'autres objets. Les tests système concernent les problèmes et les comportements qui ne peuvent être mis en évidence qu'en testant l'ensemble du système intégré ou une partie majeure de celui-ci. L'activité de test de système inclue la mise à l'épreuve des performances, de la sécurité, de la sensibilité à la configuration, du démarrage et de la récupération.²

Si pour certains tester c'est douter, avec Beizer le doute ne m'habite plus : c'est clair comme de l'eau de roche. Quelque part, ça n'est pas étonnant : après une première carrière d'ingénieur, ces livres sont le fruit de quinze ans de pratique professionnelles dans l'assurance qualité logicielle, parmi laquelle le test prend une part éminemment importante. Alors pourquoi Beizer ne fait pas partie de nos enseignements, malgré son statut ?

L'unité n'a rien à voir avec la taille : vous pouvez faire un test unitaire de monolithe, ce qui compte c'est qu'est-ce que vous cherchez à mettre à l'épreuve, à tester. La performance ? Ce ne sera normalement jamais un test unitaire, à moins que vous ne soyez en train de contrôler votre implémentation jusqu'au matériel de la complexité algorithmique : soyons franc, c'est extrêmement rare. Les phrases de trois kilomètres given_a_gendarmerie_stamp_on_a_pepper_when_a_mandatory_comes_to_the_voting_office_then_heshe_should_be_able_to_vote_for_the_other_people ça nous situe où ? Deux choses sont certaines, plus près du code que dans les tests d'une part, et très loin des spécifications fonctionnelles d'autre part. Discuter d'outillage, de nomenclature, de "bonne pratique" sans s'être positionné par rapport au type de test, c'est mettre la charrue avant les bœufs. Tester comme Beizer c'est encore possible, il suffit de mettre du smart dans le work.

Si Beizer est une référence, c'est pour la communauté des testeurs, en particulier pour la génération qui s'est professionnalisée dans les années 80 et 90. Malheureusement, en termes de nombre, cette commu' n'a pas explosé comme celle des codeurs-doux heurt-mais cœur. Et par ce simple effet de masse, sur la métrique du rayonnement, on peut dire que Beizer n'est pas un bon coup. Pour faire du travail de programmation de qualité, on a pourtant tout à gagner à lire Beizer encore et encore, jusqu'au bout de la nuit.

Citations en langue d'origine

The problem with driving development with small-scale tests (I call them “unit tests,” but they don’t match the accepted definition of unit tests very well) is that you run the risk of implementing what you think users want, but having it turn out not to be what they wanted at all. ↩
We do three distinct kinds of testing on a typical software system: unit/component testing, integration testing, and system testing. The objectives of each class is different and therefore, we can expect the mix of test methods used to differ. They are:
Unit, Unit Testing — A unit is the smallest testable piece of software, by which I mean that it can be compiled or assembled, linked, loaded, and put under the control of a test harness or driver. A unit is usually the work of one programmer and it consists of several hundred or fewer, lines of source code. Unit testing is the testing we do to show that the unit does not satisfy its functional specification and/or that its implemented structure does not match the intended design structure. When our tests reveal such faults, we say that there is a unit bug.
Component, Component Testing — A component is an integrated aggregate of one or more units. A unit is a component, a component with subroutines it calls is a component, etc. By this (recursive) definition, a component can be anything from a unit to an entire system. Component testing is the testing we do to show that the component does not satisfy its functional specification and/or that its implemented structure does not match the intended design structure. When our tests reveal such problems, we say that there is a component bug.
Integration, Integration Testing — Integration is a process by which components are aggregated to create larger components. Integration testing is testing done to show that even though the components were individually satisfactory, as demonstrated by successful passage of component tests, the combination of components are incorrect or inconsistent. [...] ↩

I’m indebted to one of my seminar students for the following elegant illustration of component and integration testing issues. Consider a subroutine A, which calls itself recursively. Initial component testing does not include the called subcomponents; therefore the recursive call of A by A is not tested. Integration testing is the test of the A call and return. The new, integrated component is clearly a different kind of component because it invokes the recursive call support mechanisms (e.g., the stack), which were not tested before; therefore, as a “new” component, it needs additional testing.

System, System Testing — A system is a big component. System testing is aimed at revealing bugs that cannot be attributed to components as such, to the inconsistencies between components, or to the planned interactions of components and other objects. System testing concerns issues and behaviors that can only be exposed by testing the entire integrated system or a major part of it. System testing includes testing for performance, security, accountability, configuration sensitivity, start-up, and recovery.

Affordance trompeuse : la Cyber

damienb-opt — Tue, 17 Dec 2024 15:28:58 +0000

Notre monde est complètement cyber : cybermafia, cyberporn, cybersécurité, cybertrafic de drogue, cyberécologie, cybermarchands d'arme ; il était donc logique que les ESN et autres cabinets de conseil (ce qui n'a rien à voir avec la petite bibliothèque dans vos toilettes) s'engouffrent dans la brèche.

D'où vient ce mot à consonance anglophone, qu'on prononcera d'ailleurs volontiers saille-beurre ? La première réponse est que cela vient de cybernétique, et tout de suite, cela sonne moins anglophone. La première vie de ce mot vient de Ampère, oui, le même que celui de l'intensité du courant électrique. Ampère écrivait dans la seconde partie de son Essai sur la philosophie des sciences :

Les relations de peuple à peuple, étudiées dans les deux sciences précédentes, ne sont que la moindre partie des objets sur lesquels doit veiller un bon gouvernement ; le maintien de l'ordre public, l'exécution des lois, la juste répartition des impôts, le choix des hommes qu'il doit employer, et tout ce qui peut contribuer à l'amélioration de l'ordre social, réclament à chaque instant son attention. Sans cesse il a à choisir entre diverses mesures celle qui est la plus propre à atteindre le but ; et ce n'est que par l'étude approfondie et comparée des divers éléments que lui fournit, pour ce choix, la connaissance de tout ce qui est relatif à la nation qu'il régit, à son caractère, ses mœurs, ses opinions, son histoire, sa religion, ses moyens d'existence et de prospérité, son organisation et ses lois, qu'il peut se faire des règles générales de conduite, qui le guident dans chaque cas particulier. Ce n'est donc qu'après toutes les sciences qui s'occupent de ces divers objets qu'on doit placer ici celle dont il est question et que je nomme Cybernétique, du mot χυϐερνετιχή, qui, pris d'abord, dans une acceptation restreinte, pour l'art de gouverner un vaisseau, reçut, chez les grecs même, la signification, tout autrement étendue, de l'"art de gouverner en général".

En deuxième lettre de ce χυϐερνετιχή on reconnaît bien sûr un upsilon, qui en majuscule s'écrit ϒ, et qui en fonction du contexte se prononcera u ou y, ou v. Ou f. C'est important le contexte. Le kappa initial a pour translitération la lettre k, mais, il est arrivé pour le grec ancien d'avoir la lettre c à la place : "cyber", "kuber", c'est du pareil au même, juste une histoire de cartographie entre alphabets.

Plus tard et de manière indépendante apparaît dans les années 40 le mot cybernetics dans "Cybernetics: or Control and Communication in the Animal and the Machine" de Norbert Wiener :

Nous avons décidé d'appeler l'ensemble du domaine de la théorie du contrôle et de la communication, que ce soit chez la machine ou chez l'animal, par le nom de "Cybernétique", que nous formons du grec "χυβερνήτης" ou "timonier". En choisissant ce terme, nous souhaitons reconnaître que le premier article significatif sur les mécanismes de rétroaction est un article sur les gouverneurs, qui a été publié par Clerk Maxwell en 1868, et que "gouverneur" est dérivé d'une corruption latine de χυβερνήτης. Nous souhaitons également faire référence au fait que les moteurs d'assistance de direction d'un navire sont en effet l'une des formes les plus anciennes et les mieux développées de mécanismes de rétroaction.

We have decided to call the entire field of control and communication theory, whether in the machine or in the animal, by the name "Cybernetics", which we form from the Greek "χυβερνήτης" or "steersman". In choosing this term, we wish to recognize that the first significant paper on feedback mechanisms is an article on governors, which was published by Clerk Maxwell in 1868, and that "governor" is derived from a Latin corruption of χυβερνήτης. We also wish to refer to the fact that the steering engines of a ship are indeed one of the earliest and best-developed forms of feedback mechanisms.

C'est le retour du fameux Kubernetes ou timonier / pilote ; et le passage par le latin nous apprend que kuber- et gouver- c'est le même combat. On voit donc que dans le monde scientifique, le cyber / kuber c'est une question de gouvernance, voire de pilotage. Pour une entreprise de conseil, la cyber devrait donc s'incarner dans les prestations de conseil opérationnel et de gestion du changement. La cybersécurité, quel rapport avec la choucroute ?

Arrive 1982 et la nouvelle Burning Chrome par William Gibson.

That meant we were clearing fiberoptic lines with the cybernetic equivalent of a fire siren, but in the simulation matrix we seemed to rush straight for Chrome's data base.

L'équivalent cybernétique d'une alarme à incendie ? C'est ce qu'on appelle un signal tout simplement, rien de bien compliqué. Sauf si "cybernetic" est utilisé de façon trompeuse, ou que l'auteur utilise son droit d'artiste à jeter des mots au hasard. Mais est-ce vraiment un hasard ? Qu'en dit l'auteur ? Il s'est justement exprimé à ce sujet en 2013, et on peut voir l'extrait significatif ici, où il parle de son arène, du monde dans lequel allaient se passer ses histoires de science-fiction, à une époque où on délaissait le "space opera".

J'ai commencé à entendre parler de personnes qui connectaient des ordinateurs à distance avec des téléphones et parce que, heureusement, je ne connaissais absolument rien aux ordinateurs, j'ai été capable de mélanger tout ça et d'avoir cette vague vision de mon arène pour laquelle j'avais alors besoin d'un nom qui claque. "Dataspace" ça n'allait pas marcher et "Infospace" non plus mais "Cyberspace"... ça sonnait comme si cela signifiait quelque chose ou que cela pourrait signifier quelque chose... mais alors que je le regardais écrit au feutre rouge sur mon bloc-notes, tout mon plaisir était de savoir que cela ne signifiait absolument rien.

I started hearing about people who connected home computers distantly via telephones and because fortunately I knew absolutely nothing about computers I was able to sort of mush that all together and get this vague vision of my arena which I then needed a really hot name for. "Dataspace" wouldn't work and "Infospace" wouldn't work but "Cyberspace"... it sounded like it meant something or it might mean something but as I stared at it in red sharpie on a yellow legal pad my whole delight was that I knew it meant absolutely nothing.

Nous voilà rassuré, la Cyber, dérivée de la popularité du cyberespace de Gibson, vient donc d'une ignorance totale à la fois du monde du numérique mais aussi de la racine cyber- / kuber-. On peut parler d'ignorance², et remercier les cyberdivinités d'avoir échappé au Dataspace.

L'utilisation courante de la Cyber dans les ESN et autres cabinets de conseil est donc très "sale" (ou "commerciale" si vous ne parlez pas le "French for entrepreneurs") et dérivée non pas du produit des sciences concernées vendues par ces entreprises, mais du renouveau de la science-fiction des années 80 aux states.

REST In Peace

damienb-opt — Mon, 09 Dec 2024 08:00:00 +0000

Dans le monde numérique d’aujourd’hui, l’architecture REST (Representational State Transfer, 2000) est devenue un pilier fondamental pour le développement du Web. Cette architecture, conceptualisée par Roy Fielding dans sa thèse de doctorat soutenue en 2000, a transformé la manière dont les systèmes distribués communiquent et interagissent. Avant cette révolution, l’Internet était déjà en pleine effervescence grâce à une série de technologies et de protocoles qui ont jeté les bases des communications en ligne. Cet article explore l’évolution de ces technologies précurseurs, la vision novatrice du Web décrite par Fielding, et la récupération du titre de sa thèse dans le paysage numérique actuel.

L’avant Web

Avant l’émergence du World Wide Web, plusieurs technologies ont été fondamentales pour le développement des communications sur Internet. Parmi celles-ci, des protocoles comme FTP (File Transfer Protocol, 1971), Telnet (1983), et SMTP (Simple Mail Transfer Protocol, 1980) ont joué un rôle crucial. FTP permettait le transfert de fichiers entre ordinateurs, Telnet offrait un accès à distance aux systèmes, et SMTP facilitait l’envoi de courriels, établissant ainsi les bases des communications numériques.

NNTP (Network News Transfer Protocol, 1986) a été utilisé pour la distribution, l’interrogation, la récupération et la publication de messages dans les groupes de discussion Usenet. Ce protocole a permis le partage d’informations et de discussions à grande échelle, bien avant l’apparition des forums en ligne modernes.

IRC (Internet Relay Chat, 1988) a introduit la communication en temps réel, permettant aux utilisateurs de discuter en ligne dans des canaux publics ou privés. Cela a ouvert la voie à des interactions instantanées et à la formation de communautés en ligne.

En parallèle, des outils comme HyperCard (1987) ont introduit des concepts d’hypertexte et de navigation par liens, préfigurant les fonctionnalités qui deviendront centrales dans le Web. HyperCard permettait de créer des "empilements" de cartes interconnectées, offrant une expérience interactive et multimédia.

À la même période, le RPC (Remote Procedure Call, 1986) présenté par Nelson propose une approche différente des protocoles ci-dessus, en s’intéressant à l’expérience programmeur. Son application directe sera en revanche limitée au monde de l’entreprise.

Ces technologies et concepts ont préparé le terrain pour les innovations qui suivront, en posant les bases de la communication et de l’interaction numérique avant l’avènement du Web.

La thèse de Roy Fielding

Le World Wide Web (W3, 1989) arrive porté par Tim Berners-Lee, et en 1993 à rebours de ce qui est fait côté Gopher (1991), les technologies du W3 sont mises dans le domaine public. 1993 est aussi l'année où Roy Fielding obtient son Master of Science et s'implique dans le W3 dans le cadre de son travail à l'université de Californie. Il participe ainsi à l'élaboration de HTTP, de HTML et d'URI. C'est en 2000 qu'il publie sa thèse de doctorat, intitulée "les styles d'architecture et la conception des architectures logicielles en réseau" ("Architectural styles and the design of network-based software architectures").

Cette thèse étudie les différents styles d'architecture répandus jusqu'alors dans l'optique de leur utilisation dans un système hypermédia en réseau, en particulier à l'échelle d'Internet. Pour cela il définit les contraintes d'architectures essentielles à respecter pour être pertinent, et examine les différents styles existants à la lumière de celles-ci. Il faut être sur une base client / serveur, sans état, avoir des possibilités de mise en cache, une uniformité d'interface, un système en couche et donner la possibilité d'avoir du code à la demande.

La spécificité de cette dernière contrainte, celle du code à la demande ("Code-On-Demand") (notre bien connu JavaScript dans le navigateur), est que c'est la seule à être optionnelle. Dans REST, on peut se passer du code côté agent utilisateur, alors que du reste, non.

La thèse a également précisé la notion d’API (Application Programming Interface, 1968), en requalifiant le terme d'origine d'API de bibliothèque ("library-based API"), et en présentant les API réseau ("network-based APIs"), qui facilitent l’interaction entre différentes applications sur le réseau.

Caractéristiques des APIs réseau

Une API de bibliothèque (§6.5.1) se définit par un ensemble de points d'entrée ainsi que les paramètres associés en entrée ou en sortie. En langage courant, on parlera d'opérations pour les points d'entrée (comme des fonctions, des méthodes ou des procédures), de paramètres et de type de retour. C'est la façon standard de décrire une interface (ou un entête) qui permet de compiler un programme appelant une implémentation de l'opération, sans connaître le code source de l'implémentation.

C'est aussi le formalisme retenu par RPC, parce que cette métaphore de l'opération locale (i.e. non distribuée, et en particulier sans réseau) était usuelle pour les programmeurs de l'époque. En RPC en revanche on parlait d'IDL (Interface Definition Language, implémentation 1981, le nom viendra après), qui permet de générer l'API dans le langage de programmation cible.

L'API de bibliothèque n'est pas très intéressante au sens de REST. Elle est bien connue, et elle a montré ses limitations dans le développement du Web. Ce qui intéresse Roy Fielding est l'API réseau, qui en conséquence n'est pas une liste d'opération avec des paramètres en entrée et en sortie. Toujours dans le chapitre §6.5.1 de sa dissertation, il la décrit comme une syntaxe des échanges réseaux, avec des sémantiques définies, pour les interactions inter-applicatives.

Il donne deux exemples de ces API réseaux : FTP et HTTP. Il cite aussi en contre-exemple CORBA (1991), pour lequel il argumente que la sémantique n'est pas définie par le protocole réseau (IIOP) mais par l'IDL. L'IDL est dans le cas de REST un marqueur de dépossession de l'hypermédia : on sort du cadre de la thèse.

L’après thèse, le blog

Ce travail de Roy Fielding, personnalité déjà connue par ses participations aux travaux du consortium W3, n'est pas passé inaperçu. A l'époque, les mécaniques RPC sur HTTP étaient portées par XML-RPC (1998) et son descendant indirect SOAP (2000). Surfant sur la vague anti-XML, langage trop lié aux méchants Microsoft et IBM entre autres, certains ont profité de la visibilité de Fielding pour s'approprier le mot REST et donner écho à leurs marottes.

En 2007 paraît le livre "RESTful Web Services" de Leonard Richardson et Sam Ruby, suivi en 2013 par "RESTful Web APIs" de Richardson, Mike Amundsen et Ruby. Ils seront un des vecteurs principaux de la diffusion du terme "RESTful". REST n'est ni une bibliothèque, ni une méthodologie : il ne répond pas aux besoins immédiats des codeurs. C'est à cet enjeu que ces livres s’attaquent, mais avec l'hypermédia loin au second plan du premier livre, le plus populaire.

Une incompréhension fréquente de la centralité de l’hypermédia dans REST a conduit à des implémentations incomplètes ou erronées de ce style d'architecture. Fielding a souvent critiqué le retour en force du RPC, sur son blog ou sur Twitter, soulignant que beaucoup de développeurs ne comprenaient pas pleinement les principes de REST, ce qui a donné lieu à des débats animés dans la communauté.

Laissez REST en paix : REST In Peace

Aujourd’hui, bien que le terme REST soit largement adopté, les détournements multiples de son contenu, que ce soit l'abandon de son principe structurel de l'hypermédia, de la contradiction de l'expression "REST API" avec l'API réseau ou du caractère désormais obligatoire du code à la demande, devraient faire hésiter à prôner ces termes. L'immense majorité des codeurs pensent à Swagger (2011), ou à sa normalisation OpenAPI (2016), quand ils entendent les expressions "REST API" ou "RESTful".

Pourtant, la spécification OpenAPI est uniquement une grammaire d'IDL, avec les paramètres dispersés façon puzzle. Les termes "REST" et "RESTful" sont d'ailleurs absent de la spécification OpenAPI. Et du côté des "API Gateways", Kong a déprécié en 2018 le terme "API" de son modèle, au profit des termes "route" et "service".

De son côté Roy Fielding a annoncé sur son blog l'abandon de toute volonté de vulgariser sa thèse en 2008. Il continue de temps en temps à évoquer le sujet sur X, mais n'en parle plus sur Twitter. Le cas trivial d'une "API REST" qui se restreint à lancer du JSON sans hyperlien sur HTTP n'est même plus abordé. Les vulgarisateurs de REST, subtilement appelés RESTafarians par les pseudo-RESTfuliens, sont considérés par ces derniers comme des cryptos fascistes ne comprenant rien au monde de l'informatique.

Il est nécessaire désormais de laisser REST en paix, en respectant ses concepts originaux pour garantir des systèmes robustes et évolutifs : la fameuse toile à l'échelle d'Internet, qui résiste pour l'instant à tout, même aux développeurs TypeScript, preuve de la qualité de son architecture.

Cet article fait partie du "Advent of Tech 2024 Onepoint", une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.
Voir tous les articles du Advent of Tech 2024.