action=query&prop=imageinfo is one of the most heavily used modules in the MediaWiki Action API. A large part of its value -- particularly the extmetadata property -- is provided by the GetExtendedMetadata hook, whose primary and most complete implementation is the CommonsMetadata extension. This hook fills in the file metadata information with structured, machine-readable fields like license, author, description, and credit (parsed from Commons templates).
Providing an equivalent REST endpoint will allow us to have some of the tools use a stable REST infrastructure that allows for better cacheability and error handling, and will reduce stress on our servers by migrating one of the most highly used Action API endpoint into a REST one. A potential user for this endpoint is "Popups" extension, that loads the pages (and imageinfo) for readers multiple times in an article; providing a cacheable endpoint can be impactful for this use case.
Problem with a core REST endpoint
The natural next step is to provide an equivalent REST endpoint. However, REST APIs must have stable, predictable response shapes — a consumer must be able to trust the schema regardless of which extensions are installed. This rules out putting the endpoint in core and relying on a hook to fill in the content, because it would create a conditional structure. This conditional shape violates REST API design principles and makes schema documentation, client caching, and contract testing unreliable.
Because CommonsMetadata is the meaningful owner of the extended metadata content, the REST endpoint belongs in CommonsMetadata, not in core. Placing it there means the response shape is always complete and authoritative when the module is available.
Proposed endpoint
A new REST module registered in CommonsMetadata:
GET /w/rest.php/commonsmetadata/v0-beta/file/{title}/info
Response structure
json
{
"requested_title": "File:Example.jpg",
"title": "Example.jpg",
"canonical_title": "File:Example.jpg",
"page_id": 46,
"timestamp": "2026-05-01T18:45:19Z",
"comment": null,
"parsed_comment": null,
"size": 2728817,
"width": 1536,
"height": 1024,
"mime": "image/png",
"media_type": "BITMAP",
"repo": null,
"url": "/w/images/9/9b/Example.jpg",
"description_url": "/wiki/File:Example.jpg",
"page_count": null,
"duration": null,
"description_short_url": "/w/index.php?curid=46",
"sha1": "...abcd...",
"technical": {
"metadata": { ... },
"common_metadata": null,
"bit_depth": 8,
"bad_file": false
},
"uploader": {
"id": 2,
"name": "Admin",
"anon": false,
"temp": false
},
"extended": {
"DateTime": {
"value": "2026-05-01 18:45:19",
"source": "mediawiki-metadata",
"hidden": ""
},
"Categories": { ... },
"ImageDescription": { ... },
"LicenseShortName": { ... },
"Artist": { ... },
}
}extended is always present (nullable if no metadata is available). It is populated by FormatMetadata::fetchExtendedMetadata(), which is the method that triggers the GetExtendedMetadata hook -- meaning it is the data provider for the pipeline used by prop=imageinfo&iiprop=extmetadata in the Action API.
Acceptance criteria
- GET /w/rest.php/commonsmetadata/v0-beta/file/{title}/imageinfo returns HTTP 200 with the documented schema for an existing file
- Returns HTTP 404 for a nonexistent file title
- Returns HTTP 403 when the requesting user lacks read permission on the file page
- extended contains CommonsMetadata fields (description, license, author, etc.) for files with CommonsMetadata templates
- extended is null for files with no parseable metadata
- Response schema is stable — no fields appear or disappear based on file content
Questions
The work is currently marked as "WIP" while the questions are explored; feedback (and ideas) are welcome to make sure the endpoint answers the base needs of the biggest use cases so it is impactful primarily for the production systems.
- extended relies on formatMetadata->fetchExtendedMetadata( $file ) which takes the information from the templates, but it might not be completely stable/consistent between different image types. Is this an issue for the REST API? should we create a base array with all possible values being null, and merge those with the fetchExtendedMetadata($file) response so we always get the same reponse shape?
- Would this work for non commons images? does it need to? This seems to reproduce the behavior of the action API for the extended metadata, but would mean that for base details it would only work where the extension is available -- meaning, in Commons or through the InstantCommons. Is that sufficient for base use cases to be impactful on migrating some of the tools to this endpoint to reduce the load (can Popups use this consistently.)