Skip to content

spec: distinguish base URL from search endpoint for ai-registry+json urls (§5.3) - #99

Merged
mindpower merged 1 commit into
ards-project:mainfrom
sachinsharma3191:fix/91-registry-url-semantics
Oct 11, 2026
Merged

mindpower merged 1 commit into
ards-project:mainfrom
sachinsharma3191:fix/91-registry-url-semantics

Conversation

@sachinsharma3191

Copy link
Copy Markdown
Contributor

Fixes #91, taking option 1 from the issue.

§5.3 says the registry base URL is discovered from entries of type application/ai-registry+json, while RegistryReferral.url (OpenAPI and the prose examples) is the search endpoint itself. Nothing told a client which it held, so appending /search to a referral URL gives /search/search and a 404.

This states the split explicitly: a well-known entry's url is a base URL; a referral's url is the complete search endpoint and MUST NOT have /search appended. It also updates the OpenAPI RegistryReferral.url description. This matches what hf-discover and go-ard already do and doesn't break the published examples or live registries.

Docs-only; no schema shape change. Happy to switch to option 3 (clients accept either) if maintainers prefer.

@mindpower mindpower left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. This keeps the prose consistent with the existing referrals[] examples and ard.openapi.yaml without breaking current implementations.

LGTM, thanks!

@mindpower
mindpower merged commit ca551a5 into ards-project:main Oct 11, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

§5.3 and the OpenAPI give two meanings to a url of type application/ai-registry+json

2 participants