hmm intéressant.

fournir une liste de valeurs pour « rel » dans une documentation et dire de façon humaine quelle valeur correspond à quoi

ou permettre de le découvrir par l’API. Il s’agit là de la documentation de l’API. La différence est que tu ne te retrouve pas prisonnier des URIs que tu as définies initialement. Alors que tu peux avoir un rel contenant deux valeurs ou plus rel= »fou barre ». Disons 1-1.

fournir l’adresse du point d’entrée en fonction de la version attendue pour commencer à découvrir l’API.

Oui même chose avec la documentation de l’API, il faudra bien donner l’adresse de la documentation pour la coder dans le client :) 1-1.

déterminer le format de sortie du point d’entrée (ou la liste des « Accept » à laquelle il sait répondre)

Oui même chose pour la façon dont les APIs sont conçus habituellement. Tu trouves dans la documentation les formats de sorties. 1-1.

déterminer comment on code les liens hypermédia dans ce format (pour html on a « link » et « a », pour d’autres soit il n’existe rien de standard soit il y a beaucoup de choix et il faut sélectionner) et comment on lit le « rel » (équivalent d’un attribut si ça n’existe pas dans le format de sortie)

Ah bah non. :) C’est sûr qu’utiliser un format non hypermedia pour faire une API hypermedia cela pose des problèmes. Il y a les efforts pour rendre hypermedia JSON. Je ne suis pas sûr de la pertinence mais au moins des personnes essaient. Donc les deux formats hypermedias disponibles pour l’instant sont Atom et HTML. Note aussi qu’il y a la découverte possible de Link: <uri>; rel="blablabla". Là cela revient au choix de la techno de départ. Tu n’as pas peut-être pas besoin de 1. Hypermedia 2. ni même de HTTP. :) C’est pour cela que j’ai posé la question à propos des clients. Et puis la question réelle de ton billet sur le versionning. En environnement social distribué, le versionning ne fonctionne pas sauf si tu controlles vraiment le client.

coder un robot qui fait l’exploration en question pour savoir quoi lancer suivant la ressource que tu demandes

l’exploration non. l’interprétation des valeurs oui. mais qui sont détachées des identifiants. En quelque sorte tu changes le versionning du côté du client. C’est le serveur qui s’adapte au client, plutôt que le client qui doit s’adapter au serveur.

fournir une liste de liens dans une documentation et dire de façon humaine quel lien correspond à quoi

oui on parle de la même chose, mais pas de la même façon.

soit fournir une liste par version soit déterminer une racine ou un paramétrage systématique permettant de choisir la version/compatibilité

Même chose.

ça permet de faire évoluer les URLs à contenu identique sans faire de redirection mais c’est un besoin qui apparait finalement assez rarement sur une API.

Donc elle n’évolue pas cet API. :) Mais que fait Ducros ?

Donc je comprends ce que tu dis et je ne pense pas qu’il y ait beaucoup de différences. Merci de prendre le temps d’expliquer un peu plus.

Je pense que ceci est le plus proche de ce que tu veux réaliser

https://api.example.com/maressource avec une entête Accept ou/et Content-type: application/monformat;version=2

MAIS je pense également que tu penses trop au serveur à la place de penser au client. Je serais curieux de savoir comment tu envisagerais le problème avec le client contrôlant la démarche. Imagine un client V1 accédant à des informations pour réaliser quelquechose, comment mon client V2 peut réagir à serveur V1 ayant évoluer. Ce n’est pas tout à fait le même enjeu. Le client initie la requête, le serveur ne fait que répondre.