API:JSON version 2/de

leidet an einer Reihe von Mängeln, die die Verwendung stärker erschweren als nötig. Viele davon treten auf, da XML das ursprüngliche Ausgabeformat war und die zugrunde liegende Datenstruktur der API-Antworten darum herum entwickelt wurde.

Um dies zu verbessern, wurde nach einer Diskussion in MediaWiki 1.25 ein neues JSON-Antwortformat eingeführt. Es ist kein Standard, du erhältst die Ergebnisse nur in dem neuen Format, wenn du  spezifizierst und es ist nur für die Formate   und   (und die menschenlesbaren Varianten   und  ) verfügbar.

Aufrechterhaltung der Rückwärtskompatibilität

 *  API result formatting changes for JSON (formatversion=2) aus der mediawiki-api-announce-Mailingliste

Wenn  nicht spezifiziert wird, sollten die Ergebnisse in der API-Antwort, die Clients erhalten, immer rückwärtskompatibel sein. Es gibt jedoch zwei Vorbehalte:


 * Module, die zuvor unformatierte boolesche Werte in JSON ausgegeben haben, können diese Eigenschaften nun mit der Konvention ausgeben, die (für Version 1) der Standard war: Leere Zeichenkette für true und fehlender Schlüssel für false. Clientcode, der diese booleschen Werte verarbeitet, wird wahrscheinlich abbrechen oder eine Warnung ausgeben, wenn nicht auf einen fehlenden Schlüssel geprüft wird. Diese Fälle sollten im Phabricator gemeldet werden, sodass das API-Modul repariert werden kann, bitte markiere sie mit #MediaWiki-API und der Markierung für die entsprechende Erweiterung.
 * wird nun Namen von Markierungen und Attributen, die kein gültiges XML sind, verarbeiten, statt einfach ungültiges XML auszugeben.
 * Zuvor angekündigte grundlegende Änderungen, um die Formatierung von Eingabeparametern zu speichern, die kein Teil der allgemeinen Änderung der Ergebnisformatierung sind, aber zur gleichen Zeit angekündigt wurden.

API-Modul-Implementierer: Sicherstellung der Rückwärtskompatibilität

 *  XXX

Das allgemeine Thema ist, dass die ApiResult-Arrays nun mehr Metadaten enthalten, die der Code des API-Kerns nutzt, um eine rückwärtskompatible Umwandlung für Clients anzuwenden, die  nicht abfragen und optional umzuwandeln, sodass JSON-Ausgaben nicht den Beschränkungen von XML unterliegen. Gleichzeitig sind  und   für Entwickler einfacher zu nutzen.

Um Rückwärtskompatibilität sicherzustellen – d.h. dass Clients, die  abfragen, nicht die gleichen Ergebnisse wie in vorherigen Versionen erhalten – müssen Entwickler von API-Modulen möglicherweise den Code aktualisieren.


 * Unterschiedliche ApiResult-Methoden sind veraltet. Wenn deine Erweiterung in entwickelt wird, sollte dies bereits für dich erledigt sein (mit Ausnahme von T95168, woran gearbeitet wird), jedoch muss bei neuem Code vermieden werden, veraltete Methoden zu nutzen.
 * Du solltest die veralteten Methoden  und   nicht nutzen. Raw-Modus, genutzt, um anzugeben, dass ein Ergebnisdrucker Metadaten-Schlüssel wie   verwendet; nun müssen alle Drucker Daten aus dem "Raw-Modus" verarbeiten.
 * Alle ApiResult-Methoden, die mit einem übergebenen Array (statt internen Daten) arbeiten, sind nun statisch und statische Versionen aller relevanten Methoden zur Manipulation von Daten und Metadaten sind verfügbar. Dies sollte die Notwendigkeit zur Übergabe von ApiResult-Instanzen reduzieren, um Metadaten setzen zu können.
 * Eigenschaften, die mit einem Unterstrich beginnen, sind für API-Metadaten reserviert (angelehnt an die existierenden  und  ) und werden aus der Ausgabe entfernt. Du kannst mit ApiResult::setPreserveKeysList angeben, dass eine Eigenschaft, die mit einem Unterstrich beginnt, keine Metadaten ist.
 * Du kannst PHP-Arrays mit "Array-Typen" markieren, um anzugeben, ob sie als Arrays oder Hashes ausgegeben werden sollen. Dies ist besonders hilfreich, um T12887 zu beheben.
 * Die Eigenschaft  ist veraltet, stattdessen wird eine korrekt benannte Eigenschaft und spezielle Metadaten bevorzugt, um es für das XML-Format und die Rück-Umwandlung zu identifizieren. Nutze ApiResult::setContentValue statt ApiResult::setContent und alle Details werden für dich erledigt.
 * ApiFormatXml wird keine Ausnahme mehr ausgeben, wenn du vergisst, ApiResult::setIndexedTagName anzurufen!
 * ApiFormatXml wird nun Namen von Markierungen und Attributen, die kein gültiges XML sind, verarbeiten, statt Leerzeichen unumkehrbar zu verarbeiten und ungültiges XML für andere Dinge auszugeben.
 * ApiResult wird nur hinzugefügte Daten validieren (z.B. wird eine Ausnahme ausgegeben, wenn Ressourcen oder unendliche Zahlen hinzugefügt werden) und Objekte automatisch konvertieren. Die ApiSerializable-Oberfläche kann genutzt werden, um die Objekt-Konvertierung zu kontrollieren, wenn __toString oder cast-to-array unangemessen sind.
 * Du kannst nun boolesche Werte zu ApiResult hinzufügen und die API wird sie in Antworten an "Version-1"-Clients in die alte Konvention für boolesche Ergebnisparameter (leere Zeichenkette für true und keine für false) umwandeln, um Rückwärtskompatibilität sicherzustellen. Wenn du jedoch gegen diese Konventionen verstößt, indem du einen booleschen  oder   zurückgibst, werden die Clients möglicherweise abbrechen! Wenn dein API-Modul dies tut, musst du die neue Metadaten-Eigenschaft ApiResult::META_BC_BOOLS nutzen, um die Konvertierung für "Version-1"-Clients zu verhindern. Du solltest den Code deines API-Moduls darauf prüfen, ob boolesche Werte in ApiResult gesetzt werden; auch darauf, ob externe Datenstrukturen wie JSON in ApiResult eingefügt werden, da du möglicherweise  - oder  -Werte zurückgibst, ohne es zu merken.
 * Modulausgaben wie, um lange Zeichenketten in XML-Attributen zu vermeiden, können nun   ausgeben, während   im XML-Format bei Nutzung von ApiResult::META_BC_SUBELEMENTS weiterhin unterstützt wird. Neuer Code sollte stattdessen  nutzen.
 * Module, die Hashes wie  ausgeben (da die Schlüssel für XML ungültig wären) können nun als   in JSON ausgeben werden, während   im XML-Format bei Nutzung von ApiResult:setArrayType mit dem Array META_TYPE,   oder   weiterhin unterstützt wird.

Die meisten Änderungen an Erweiterungen, die für diese Änderungen erforderlich waren, befinden sich im Gerrit-Änderungssatz I7b372... und topic:api-cleanup-PS25.

Änderungen am XML-Format
hat kein neues Ergebnisformat. Es gibt einige Änderungen an XML-Ergebnissen:


 * Aus API/Architecture_work/Planning

Änderungen gibt es hauptsächlich am Backend; die Datenausgabe Clients soll soweit möglich gleich bleiben. Clients sollten sich jedoch auf folgendes vorbereiten:
 * Die Ergebnisstruktur stimmt möglicherweise nicht mit dem JSON-Format überein.
 * Namen von Markierungen und Attributen können codiert werden, wenn sie XML-Anforderungen nicht erfüllen.
 * Abhängig von der jeweiligen Abfrage kann sich die Ergebnisstruktur ändern. Wenn beispielsweise rvprop=content und rvdiffto=prev an prop=revisions übergeben werden, wäre zuvor der Diff des Ergebnisses weggelassen worden (bug 55371) (es sollte ein Fehler ausgegeben werden, dies ist jedoch ein anderer Fehler). Nun wird der Inhalt als Wert des Knotens &lt;rev> ausgegeben, wenn  nicht übergeben wird und als Wert eines Unterknotens &lt;content> des Knotens &lt;rev>, wenn er übergeben wird.

For example, bug 43221 was fixed by changing the names of attributes such as "4::foo" to fit XML's restrictions. In the future, this would be fixed by either encoding the name (e.g. "_4.3A..3A.foo") or by changing the structure of output in only the XML format (e.g. ).

On the MediaWiki code side, developers will see the following changes:


 * The XML formatter will no longer die if ApiResult::setIndexedTagName is forgotten. Instead, it will act as if that were called with something generic (e.g. ApiResult::setIndexedTagName( $array, '_v' )).
 * The XML formatter will no longer (be supposed to) raise an error when a node has both node content (ApiResult::setContent) and non-scalar attributes. Instead, it will simply shove the intended node content into a subnode.
 * Anything that's hard-coding '*' should be updated to use ApiResult::setContentValue.
 * Additional metadata is available to hint at improved XML output.

The future of "version 1" JSON response format
In some future release the old format=json will be deprecated, and may eventually be removed.

Using the new JSON results format
You can use  in your requests in, but do note that the output formatting isn't entirely stable yet and might change in MediaWiki 1.26.

Changes to JSON output format

 *  XXX from mediawiki-api-announce mailing 

With, we can make some useful changes:


 * Return booleans as boolean true instead of empty-string. Where appropriate, return boolean false instead of omitting the property.
 * Return empty objects in JSON as {}, rather than [].
 * Have action=query's "pages" be an array, instead of an object with page ids as keys that can be difficult to iterate.
 * Provide useful property names instead of '*'.
 * Eliminate useless indirection, e.g.  instead of   and   instead of.
 * The existing  option is the default. A new   request parameter has been introduced for clients who need all non-ASCII codepoints escaped.

If you see missed opportunities to make the above changes in existing  output, or if there are other changes that would make API output easier to use in JSON, please let MediaWiki API developers know! Phabricator would be ideal (tag with #MediaWiki-API, and the appropriate extension's tag if applicable), or reply on the mediawiki-api mailing list.