Protections collection in ApiProtect result needs stronger naming
Open, Needs TriagePublic

Description

The protection result values coming from ApiProtect could potentially be ambiguous in the sense that the names of the values aren't fixed.

To give a concrete example from the API page:

"protections": [
            {
                "edit": "autoconfirmed",
                "expiry": "2015-02-24T12:34:56Z"
            },
            {
                "move": "sysop",
                "expiry": "2015-03-25T13:06:20Z"
            }
        ]

In order to know what the protection type applied was, you have to do one of a few things:

  • go back to your input, in which case why worry about the result at all?
  • assume that the protection type will be the first entry in the result, which isn't future-proof
  • examine all possible restriction types and look for keys with those names, which is needlessly arcane
  • get truly inventive and remove all other known values, and assume the remaining one must be the protection type/level

This would be better formed, more future-proof, and closer to the output from ApiQueryInfo with inprop=protections if it were structured as:

"protections": [
            {
                "type": "edit",
                "level": "autoconfirmed",
                "expiry": "2015-02-24T12:34:56Z"
            },
            {
                "type": "move",
                "level": "sysop",
                "expiry": "2015-03-25T13:06:20Z"
            }
        ]
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 16 2016, 5:01 PM
Anomie added a subscriber: Anomie.Dec 16 2016, 5:28 PM

The difficulty, of course, is that this would be a breaking change. We'll have to try to look into how much effect this change might have on existing clients.

Yeah, I'd thought of that. It's a kludge, but you could potentially just add the type and leave the existing information alone. A client could then read the type, and from that, they'd have the key to read in the value.