Change #1028487 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] WIP: REST: Emit machine readable directory of available modules

https://gerrit.wikimedia.org/r/1028487

Perhaps use https://apisjson.org/? See https://github.com/apis-json/api-json/blob/develop/spec/schema_0.17.yml

Or better, https://datatracker.ietf.org/doc/draft-ietf-httpapi-api-catalog/ and https://datatracker.ietf.org/doc/rfc9264/

See https://apiexpert.medium.com/ietf-api-catalog-vs-apis-json-9072e96b8722 and https://apichangelog.substack.com/p/using-apisjson-to-create-a-catalog

Google uses something like this: https://discovery.googleapis.com/discovery/v1/apis

After looking more closely, I'm of the opinion that we should start with something very minimalist, at least as lean as the Google approach, and maybe a lot leaner.

I'd be agreeable to just a bit of site metadata and an array of module objects, where each module object contains only one two fields:

1. name: (in the case of a core or extension module, this would be the module id)
2. base url
3. spec url

Starting lean, and under a /v0/specs url (or maybe a specs.v0 module) would give us an opportunity to address the most important need, machine-readable discovery of modules, while we learn what other information callers might actually care about.

Change #1028487 merged by jenkins-bot:

[mediawiki/core@master] REST: Introduce discovery endpoint

https://gerrit.wikimedia.org/r/1028487