Page MenuHomePhabricator

Decide on protection output format for the metadata endpoint
Closed, DeclinedPublic

Description

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).

Event Timeline

Mholloway updated the task description. (Show Details)Feb 20 2018, 11:54 PM

I'd like to hear from client teams what they think. If would be great to hear from devs familiar with the creation of the action=mobileview API.

Either approach can work. If we prefer the action=query structure we should be able to move the code which modifies the protection structure to the mobile-sections only code in MCS.

I tend to favor the action=mobileview structure but that could be because I'm more used to it. Here's why:

Use case: a client needs to check if there are any edit restrictions before displaying page content (regular pencil icons vs locked pencil icons).

  • With the structure returned by action=query a client has to iterate through all the objects to collect all the wanted ones.
  • With the structure returned by action=mobileview a client does a simple lookup of the edit key. If it doesn't exist, which happens in the majority of pages, done. If the key exists go through the list of groups and check the current user if she's in one of these allowed groups. Yes, the client needs to check if the edit key exists before checking more but this is nothing new seems pretty obvious to me.
Mholloway closed this task as Declined.EditedMar 5 2018, 6:20 PM

Looks like there are no strong feelings about this. Let's stick to the mobileview/mobile-sections convention ({ edit: 'autoconfirmed', move: 'sysop' }) until we have a good reason not to.