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. The   object contains the list of pages or revisions that query modules will work with.
 * If requested, a generator module is executed to create another . Similar to the piping streams in UNIX. Given pages are the input to generator that produces another set of pages for all other modules to work on.
 * Requirements for query continuation:
 * The SQL query must be totally ordered. In other words, the query must be using all columns of some unique key either as constants in the  clause or in the   clauses.
 * In MySQL, this is an exclusive or, to the point where querying Foo and Bar must order by title but not namespace (namespace is constant 0), Foo and Talk:Foo must order by namespace but not title (title is constant "Foo"), and Foo and Talk:Bar must order by both namespace and title.
 * The SQL query must not filesort.
 * The value given to  must include all the columns in the   clause.
 * When continuing, a single compound condition should be added to the  clause. If the query has , this condition should look something like this:

(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;))

Of course, swap ">" for "<" if your  columns are using. Be sure to avoid SQL injection in the values.

Internal data structures

 * Query API has had very successful structure of one global nested  structure passed around. Various modules would add pieces of data to many different points of that array, until, finally, it would get rendered for the client by one of the printers (output modules). For the API, we suggest wrapping this array as a class with helper functions to append individual leaf nodes.

Error/status reporting
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.