ardregistry.net

Datos

Registries ARD comparados

Las mismas cuatro peticiones a cada registry público, el mismo día.

Los seis registries ARD públicos responden a POST /search, el único endpoint que exige la especificación. En lo demás se separan: /explore y /agents son explícitamente opcionales, y pocos publican un manifiesto propio. Exactamente uno responde a los cuatro. El script está publicado y la tabla lleva fecha.

Qué se midió

Cuatro peticiones a cada registry: el endpoint de búsqueda, POST /explore, GET /agents y un manifiesto en la ruta well-known del propio registry. Y una quinta comprobación: un GET contra el endpoint de búsqueda, donde la respuesta correcta es 405 y un 404 es un fallo con consecuencias reales, porque le dice a un cliente que el endpoint no existe.

Qué dice la tabla

Buscar lo hacen todos. Lo demás casi nadie.

Es el resultado correcto y no un reproche: POST /search es el único endpoint obligatorio y todo lo demás es opcional. Un registry que solo responda a la búsqueda es plenamente conforme.

Un registry no sirve la ruta de la spec

ARD Registry Hub responde a la búsqueda en /api/search en lugar de /search. Funciona y devuelve resultados, pero un cliente conforme que solo conozca la URL base no encuentra el endpoint. Esa garantía es justo lo que hace posible la federación.

El fallo de 404 en lugar de 405

Quien manda un GET a un endpoint de POST debería recibir un 405. Si recibe un 404, un cliente de SDK concluye que la dirección es incorrecta y se rinde. El fallo está extendido y cuesta handshakes que nunca ocurren.

Reproducirlo

Cada fila es una petición HTTP que puedes lanzar tú:

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

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