API:Implementation Strategy/de

Dies erklärt die Implementation der MediaWiki-API-Maschine in den Kern. Wenn du in deinem Code eine API für Klienten zum Konsumieren anbieten möchtest, lese.

Datei- / Modulaufbau

 * ist der Eingangspunkt und befindet sich im Wiki-Root. Siehe API:Hauptseite#Der Endpunkt.
 * wird alle Dateien mit Bezug zur API enthalten, jedoch wird keine von ihnen als Eingangspunkt erlaubt sein.
 * Alle API-Klassen leiten sich von einer gewöhnlichen abstrakten Klasse  ab. Die Basisklasse bietet übliche Funktionen wie das Parsen von Parametern, Profilierung und Umgang mit Fehlern.
 * ist die von  instantiierte Hauptklasse. Sie bestimmt, welches Modul basierend auf dem Parameter   ausgeführt wird.   erstellt auch eine Instanz der Klasse , die das Ausgabe-Datenarray und verwandte Hilfsfunktionen enthält. Schließlich instantiiert   die Formatierungsklasse, die die Daten aus   in XML/JSON/PHP oder einem anderen Format an den Klienten ausgibt.
 * Jedes von  abgeleitete Modul wird einen Verweis auf eine Instanz von   während der Instantiierung erhalten, sodass das Modul während der Ausführung  gemeinsame Quellen wie das Ergebnisobjekt nutzen kann.

Abfragemodule

 * verhält sich ähnlich wie, in dem es seine Submodule ausführt. Jedes Submodul leitet sich von   ab (außer   selbst, wobei es sich um ein Top-Level-Modul handelt). Während der Instantiierung erhalten Submodule einen Verweis auf die ApiQuery-Instanz.
 * Alle Abfragemodule von Erweiterungen sollten ein Präfix aus 3 oder mehr Buchstaben nutzen. Die Kernmodule nutzen Präfixe aus 2 Buchstaben.
 * Ausführungsplan:
 * Erhalte gemeinsame Abfrageparameter, um benötigte Submodule zu bestimmen.
 * Erstelle ein -Objekt und befülle es durch die  -Parameter. Das  -Objekt enthält die Liste von Seiten oder Versionen, mit denen die Abfragemodule arbeiten werden.
 * Sofern angefragt wird ein Generatormodul ausgeführt, um ein anderes  zu erstellen. Ähnlich wie die Pipingstreams in UNIX. Angegebene Seiten sind die Eingabe für den Generator, der eine andere Reihe von Seiten für alle anderen Module erstellt.
 * Voraussetzungen für eine Fortsetzung der Abfrage:
 * Die SQL-Abfrage muss vollständig korrekt sein. In anderen Worten muss die Abfrage alle Spalten der einzigartigen Schlüssel sowie Konstanten in der -Klausel oder den  -Klauseln nutzen.
 * In MySQL ist dies ein Exklusiv-oder, an dem Punkt, an dem Foo und Bar abgefragt werden, muss nach Titel, jedoch nicht nach Namensraum sortiert werden (Namensraum ist immer 0), Foo und Talk:Foo müssen nach Namensraum, jedoch nicht nach Titel sortiert werden (Titel ist immer "Foo") und Foo und Talk:Bar müssen nach Namensraum und Titel sortiert werden.
 * Die SQL-Abfrage muss nicht Dateisortieren.
 * Der an  gegebene Wert muss alle Spalten der  -Klausel enthalten.
 * Bei Fortführung sollte eine einzelne Verbindungsbedingung zur -Klausel hinzugefügt werden. Wenn die Abfrage   hat, sollte die Bedingung in etwa so aussehen:

(column_0 > value_0 OR (column_0 = value_0 AND&#xa; (column_1 > value_1 OR (column_1 = value_1 AND&#xa; (column_2 >= value_2)&#xa; ))&#xa;))

Tausche natürlich "<" durch ">" aus, wenn deine -Spalten   nutzen. Stelle sicher, SQL-Einschübe in den Werten zu vermeiden.

Interne Datenstrukturen

 * Die Abfrage-API ist in eine sehr erfolgreiche Struktur einer global verschachtelten -Struktur eingebunden. Unterschiedliche Module würden einzelne Daten zu vielen Unterschiedlichen Punkten des Arrays hinzufügen, bis sie schließlich für den Klienten durch die Ausgabe (Ausgabemodule) gerendert werden würden. Für die API schlagen wir vor, dieses Array als eine Klasse mit Hilfefunktionen einzuschließen, um einzelne Knoten anzuhängen.

Fehler- / Statusmeldungen
For now we decided to include error information inside the same structured output as normal result (option #2).

For the result, we may either use the standard HTTP error codes, or always return a properly formatted data:

void header( string reason_phrase [, bool replace [, int http_response_code]] ) The  can be used to set the return status of the operation. We can define all possible values of the, so for the failed login we may return   and  , whereas for any success we would simply return the response without altering the header.
 * Using HTTP code

Pros: It's a standard. The client always has to deal with HTTP errors, so using HTTP code for result would remove any separate error handling the client would have to perform. Since the client may request data in multiple formats, an invalid format parameter would still be properly handled, as it will simply be another http error code.

Cons: ...

This method would always return a properly formatted response object, but the error status/description will be the only values inside that object. This is similar to the way current Query API returns status codes.
 * Include error information inside a proper response

Pros: HTTP error codes are used only for the networking issues, not for the data (logical errors). We do not tied to the existing HTTP error codes.

Cons: If the data format parameter is not properly specified, what is the format of the output data? Application has to parse the object to know of an error (perf?). Error checking code will have to be on both the connection and data parsing levels.