MediaWiki pages can have edit and move rights restricted to specific groups such as autoconfirmed or sysop.

The action API query module returns protection information for a page in the following format:

protection: [ { type: 'edit', level: 'autoconfirmed', expiry: 'infinity' }, { type: 'move', level: 'sysop', expiry: 'infinity' } ]

Example: https://en.wikipedia.org/w/api.php?action=query&format=json&formatversion=2&prop=info&inprop=protection&titles=Barack_Obama

In action=mobileview (and in MCS presumably for backward compatibility)—both used primarily by the apps—this structure is condensed:

protection: { edit: 'autoconfirmed', move: 'sysop' }

Examples:
https://en.wikipedia.org/w/api.php?action=mobileview&format=json&formatversion=2&page=Barack_Obama&prop=protection
https://en.wikipedia.org/api/rest_v1/page/mobile-sections-lead/Barack_Obama

No explanation for this change is given in the Bugzilla ticket or on Gerrit.

Question: should we continue to incorporate this condensing step in the metadata endpoint?

I think there are some good reasons to pass through the MediaWiki API output unchanged:

• the MCS/mobileview structure doesn't appear so much more convenient for clients as to justify the additional processing steps;
• the MCS/mobileview structure seems more brittle in that it opens the possibility of clients referencing an edit or move property, which may be absent, without checking for undefined values. In the action=query output, by contrast, type, level, and expiry will be defined in every case.

On the other hand, diverging from the status quo in the metadata endpoint by passing through the action=query output directly would introduce internal inconsistency into MCS (at least until the mobile-sections endpoints are deprecated and replaced).