The easiest way would be to allow the wbgetitemsbyid module (class ApiGetItemsById) to fetch items based on revision IDs as an alternative to page IDs or site/title pairs. This should be very similar to returning items based on page ID.

Change 84187 had a related patch set uploaded by Legoktm:
[WIP] API GetEntities: Access old versions of items

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

I'm going to post some questions about the implementation here since Gerrit sucks for discussion.

1. Should we require &ids= (or &sites/&titles) to be set when getting an old revision?

2. How do we represent getting multiple old revisions? Right now a request looks like:

{

"entities": {
    "Q1": {
        "pageid": 129,
    },
    "Q2" : blah

}

I'm thinking we can add a revisions key inside each entity, and that would be an array. So like:

{

"entities": {
    "Q1": {
        "pageid": 129,
        "revisions": [
             { entity content for rev 14 }, { entity content for rev15 }
        ]
    }
},

}

Thoughts?

1. Make it consistent with what MediaWiki does for normal wikitext (IIRC it does not require to set the ids when the revid is given, so I would do the same here, but please check this statement).

2. that solution looks sensible, but make it an object so you can access them directly without having to loop over the revisions, i.e.
   
   "revisions": { "14" : { entity content for rev 14 }, "15" : { entity content for rev15 } }

instead of

"revisions": [
               { entity content for rev 14 }, { entity content for rev15 }
          ]

Change 84187 abandoned by Legoktm:
[WIP] API GetEntities: Access old versions of items

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

I don't have time to finish my patch, anyone else should feel free to restore it and do so.

IMO this is becoming more and more important....

I've been thinking about this a bit, and it would be really nice if we could just use prop=revisions and get the nice wbgetentities output. Instead of outputing the stored serialized text which is really a JSON blob, it could output the actual JSON structure. That way API clients could use the normal data access method instead of having to implement fetching old revisions, etc., again in a different manner.

In T40971#1753989, @Legoktm wrote:

I've been thinking about this a bit, and it would be really nice if we could just use prop=revisions and get the nice wbgetentities output. Instead of outputing the stored serialized text which is really a JSON blob, it could output the actual JSON structure. That way API clients could use the normal data access method instead of having to implement fetching old revisions, etc., again in a different manner.

I filed this as T143967: Expose structured Content information via the API prop=revisions.

For the record: in Special:EntityData, this has been available since I247191817f (early 2013) via the oldid or revision URL query parameter (example). It’s only missing in the API (wbgetentities). (Edit: oldid no longer used since T220826.)

I still believe T143967: Expose structured Content information via the API prop=revisions is the correct way to fix this.