API:Edit/de

POST-Abfrage um eine Seite zu bearbeiten.

Beispiel
Der Beispielcode in diesem Beispiel ist in Python. Siehe für Beispiele und Antworten in.

POST-Anfrage
Bearbeitungen vorzunehmen ist wie jede POST-Abfrage ein mehrstufiger Prozess.


 * 1. Anmelden über eine der auf beschriebenen Methoden. Beachte, dass es zwar wichtig ist, die Bearbeitung dem Autor richtig zuzuordnen, viele Wikis jedoch Benutzern erlauben, ohne Registrierung oder Anmeldung mit einem Konto zu editieren.


 * 2. Ein erhalten:


 * 3. Sende eine POST-Abfrage mit dem CSRF-Token, um eine Aktion auf einer Seite vorzunehmen:

Der Antwort-Abschnitt unten ist für die finale POST-Abfrage, um die Aktion auf der Seite auszuführen. Siehe die Seiten auf und  für die JSON-Antworten früherer Schritte.

Beachte auch, dass die Tokens in den Abfragen auf dieser Seite Beispielwerte sind. Tatsächlich sind Tokens für jede Anmeldung und seitenübergreifende Abfrage einzigartig. Sie sind hier nur angegeben, um zu zeigen, welches Format eine korrekte Abfrage hat.

Bearbeitungskonflikte
Das Python-Beispiel ist eine grundlegende Implementation einer Bearbeitungs-Abfrage eines angemeldeten Benutzers. In der Realität sollte darauf geachtet werden, Bearbeitungskonflikte zu verhindern. Diese treten ein, wenn zwei oder mehr Benutzer gleichzeitig versuchen, die gleiche Seite zu bearbeiten.

Konflikte können verhindert werden, indem bei der Abfrage eines CSRF-Tokens der Zeitstempel der letzten abgerufen wird. Durch das Hinzufügen von  zur Abfrage des CSRF-Tokens in Schritt 3 können wir den Zeitstempel für die letzte Version erhalten. Dieser Zeitstempel wird als  genutzt, wenn wir die Bearbeitungs-Abfrage stellen.

Wir benötigen auch die genaue Zeit, zu der wir unsere Bearbeitung beginnen. Diese kann durch Hinzufügen von  zur CSRF-Abfrage ebenfalls erhalten werden. Dieser Wert dient als unser.

Schließlich setzen wir in der Bearbeitungs-Abfrage die Parameter  und   so:

Große Änderungen
POST-Abfragen, die eine große Menge an Text enthalten (8000+ Zeichen), sollten mit  im Header gesendet werden. Da  keine HTML-Auslassungszeichen für Leerzeichen und Satzzeichen hinzufügen muss (d.h. Prozent-Codierung), wird der Umfang von Daten wesentlich kleiner sein als beim Äquivalent der Prozent-Codierung.

Durch  wird jedoch noch eine Überschrift hinzugefügt -- etwa 160 Bytes je Parameter. Für kurze Nachrichten müssen kaum Leerzeichen hinzugefügt werden, weshalb der Umfang an Überschriften ineffizient sein kann und Prozent-Codierung bevorzugt wird.

Beachte, dass in unserem Python-Beispielcode die Abfrage standardmäßig Prozent-codiert wird.

Siehe die MDN-Web-Dokumente für eine technischere Diskussion von content-type und POST-Abfragen. Siehe die Python-Abfrage-Dokumentation dazu, wie  mit einer Syntax übergeben wird, die der in unserem Python-Beispielcode ähnelt.

CAPTCHAs
Wenn dein Ziel-Wikk nutzt, kann deine Abfrage einen Fehler zurückgeben, der eine ID-Nummer und einen einfachen Test, wie eine Frage, ein mathematisches Problem oder eine URL zu einem Bild, enthält. Um deine Bearbeitung zu beenden, musst du den Test beenden und dann deine Abfrage erneut mit der ID und der/den korrekten Antwort(en) angehängt an die ursprüngliche Abfrage-Zeichenkette ausführen, etwa so:

Andere CAPTCHA-Systeme und Erweiterungen können unterschiedliche Parameter für ähnliche Zwecke nutzen. Nutze allgemein die Feldnamen für die ID und Testfragen als Parameter in deiner zweiten Abfrage.

Parametergeschichte

 * v1.25: Eingeführt
 * v1.21: Eingeführt ,
 * v1.20: Eingeführt
 * v1.19: Eingeführt
 * v1.18: Veralteter ,
 * v1.17: Eingeführt
 * v1.16: Veralteter ,
 * v1.16: Eingeführt
 * v1.15: Eingeführt ,
 * v1.14: Eingeführt

Zusätzliche Anmerkungen

 * Die Anmeldung wird von der API nicht unbedingt gefordert, ist jedoch nötig, um die Bearbeitung korrekt ihrem Autor zuzuordnen. Eine erfolgreiche Bearbeitung eines unangemeldeten Benutzers wird der IP-Adresse zugeordnet.
 * Bots, die nicht angemeldet sind, können Bearbeitungs- und anderen Schreibeinschränkungen unterliegen; siehe für weitere Details.
 * Benutzer, die nicht angemeldet sind, erhalten immer ein leeres CSRF-Token,.
 * Der Prozess für die Abfrage eines Tokens hat sich über die Versionen hinweg mehrfach geändert. Weitere Informationen findest du unter.
 * bietet einen Weg, um auf Bearbeitungs-Tokens zurückgreifen, während Code auf einer Wiki-Seite ausgeführt wird.
 * Du kannst das gleiche CSRF-Token für alle Bearbeitungsaktionen im gleichen Wiki während einer Sitzung verwenden.
 * Es ist gute Praxis, alle Tokens einer Abfrage am Ende der Abfrage-Zeichenkette oder zumindest nach dem Text-Parameter anzugeben. Auf diesem Weg wird der Token nicht übergeben, wenn die Verbindung unterbrochen wird und die Bearbeitung schlägt fehlt. Wenn du das -Objekt nutzt, um Abfragen zu stellen, geschieht dies automatisch.
 * Obwohl  und   technisch gesehen seit v1.18 aus API:Edit entfernt wurden, hat  API:Edit erweitert, um mit CAPTCHAs zu funktionieren. Wenn ConfirmedEdit installiert ist, sind diese Parameter weiterhin verfügbar. ConfirmEdit ist im Paket der MediaWiki-Software v1.18+ enthalten.

Siehe auch

 * - Enthält nützliche Links zum Bearbeiten von Artikeln.
 * - beschreibt, wie man sich über eine vereinfachte Oberfläche anmeldet, während man über Skripte oder Anwendungen auf Wikis zugreift, anstatt über die GUI.
 * - weitere Details zur Nutzung eines Bots zur automatischen Bearbeitung von Seiten.
 * - bietet einen Weg, um auf Bearbeitungs-Tokens zurückzugreifen, während JavaScript auf einer MediaWiki-Seite ausgeführt wird.
 * - hat weitere Details zur Nutzung von Tokens zum Anmelden oder Stellen von POST-Abfragen.
 * - eine missbilligte API, verschieden von, zur Abfrage von Tokens in früheren Versionen von MediaWiki.
 * - erlaubt dir, zwischen Bearbeitungen auf einer Seite zu unterscheiden.
 * - ändert Markierungen auf einer Seite.
 * - macht eine Reihe von Bearbeitungen rückgängig.
 * - setzt Dateien auf einen früheren Status zurück.
 * - löscht und stellt Versionen einer Seite wieder her.