ardregistry.net

Données

Les registries ARD comparés

Les mêmes quatre requêtes vers chaque registry public, le même jour.

Les six registries ARD publics répondent tous à POST /search, le seul endpoint exigé par la spécification. Sur le reste ils divergent  /explore et /agents sont explicitement facultatifs, et rares sont ceux qui publient leur propre manifeste. Exactement un répond aux quatre. Le script est publié et le tableau est daté.

Ce qui a été mesuré

Quatre requêtes vers chaque registry  l'endpoint de recherche, POST /explore, GET /agents et un manifeste sur le chemin well-known du registry lui-même. Plus une cinquième vérification  un GET sur l'endpoint de recherche, où la bonne réponse est 405 et où un 404 est un défaut aux conséquences réelles, puisqu'il annonce à un client que l'endpoint n'existe pas.

Ce que dit le tableau

La recherche, tous. Le reste, presque personne.

C'est le résultat correct et non un reproche  POST /search est le seul endpoint obligatoire, tout le reste est facultatif. Un registry qui ne répond qu'à la recherche est pleinement conforme.

Un registry ne sert pas le chemin de la spec

ARD Registry Hub répond à la recherche sur /api/search au lieu de /search. Ça fonctionne et ça renvoie des résultats, mais un client conforme qui ne connaît que l'URL de base ne trouve pas l'endpoint. C'est précisément cette garantie qui rend la fédération possible.

Le défaut du 404 au lieu du 405

Envoyer un GET sur un endpoint POST devrait donner un 405. Si c'est un 404, un client de SDK en conclut que l'adresse est fausse et abandonne. Le défaut est répandu et coûte des handshakes qui n'ont jamais lieu.

Reproduire

Chaque ligne est une requête HTTP que vous pouvez lancer vous-même 

curl -s -o /dev/null -w "%{http_code}" -X POST \
  https:///search \
  -H 'content-type: application/json' \
  -d '{"query": {"text": "lire un pdf"}}'

Last reviewed 2026-09-07. Checked against ARD v0.91 (Proposal, 2026-08-26).