Bilder mit der Play Game Services Publishing API hochladen

Mit der Play Game Services Publishing API können Sie ein Image für eine Spieleressource hochladen.

Uploadoptionen

Mit der Play Game Services Publishing API kannst du bestimmte Typen von Binärdaten oder Medien hochladen. Die spezifischen Eigenschaften der Daten, die Sie hochladen können, sind auf der Referenzseite für jede Methode aufgeführt, die Medienuploads unterstützt:

  • Maximale Upload-Dateigröße: Die maximale Datenmenge, die mit dieser Methode gespeichert werden kann.

  • Zulässige Medien-MIME-Typen: Die Typen von Binärdaten, die mit dieser Methode gespeichert werden können.

Uploadanfragen können auf folgende Arten gestellt werden: Geben Sie die Methode an, die Sie für den UploadType-Anfrageparameter verwenden.

  • Einfacher Upload: uploadType=media. Für die schnelle Übertragung kleinerer Dateien, z. B. mit maximal 5 MB.

  • Mehrteiliger Upload: uploadType=multipart. Für eine schnelle Übertragung kleinerer Dateien und Metadaten können Sie die Datei zusammen mit beschreibenden Metadaten in einer einzigen Anfrage übertragen.

  • Fortsetzbarer Upload: uploadType=resumable. Für eine zuverlässige Übertragung, besonders wichtig bei größeren Dateien. Bei dieser Methode verwenden Sie eine sitzungsinitiierende Anfrage, die optional Metadaten enthalten kann. Diese Strategie ist für die meisten Anwendungen eine gute Strategie, da sie auch für kleinere Dateien funktioniert, allerdings auf Kosten einer zusätzlichen HTTP-Anfrage pro Upload.

Wenn Sie Medien hochladen, verwenden Sie einen speziellen URI. Methoden, die Medienuploads unterstützen, haben sogar zwei URI-Endpunkte:

  • Der „/upload“-URI für die Medien. Das Format des Uploadendpunkts ist der Standardressourcen-URI mit dem Präfix „/upload“. Verwenden Sie diesen URI beim Übertragen der eigentlichen Mediendaten.

    Beispiel: POST /upload/games/v1configuration/images/resourceId/imageType/imageType

  • Der Standardressourcen-URI für die Metadaten. Wenn die Ressource Datenfelder enthält, werden diese zum Speichern von Metadaten verwendet, die die hochgeladene Datei beschreiben. Sie können diesen URI beim Erstellen oder Aktualisieren von Metadatenwerten verwenden.

    Beispiel: POST /games/v1configuration/images/resourceId/imageType/imageType

Einfacher Upload

Die einfachste Methode zum Hochladen einer Datei ist eine einfache Uploadanfrage. Diese Option ist sinnvoll, wenn eine der folgenden Bedingungen zutrifft:

  • Die Datei ist klein genug, um sie bei einem Verbindungsausfall noch einmal vollständig hochzuladen.

  • Es sind keine Metadaten zum Senden vorhanden. Dies kann der Fall sein, wenn Sie Metadaten für diese Ressource in einer separaten Anfrage senden möchten oder wenn keine Metadaten unterstützt oder verfügbar sind. Um den einfachen Upload zu verwenden, stellen Sie eine POST- oder PUT-Anfrage an den /upload-URI der Methode und fügen Sie den Abfrageparameter „uploadType=media“ hinzu. Beispiele:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media

Zu den HTTP-Headern, die bei einer einfachen Uploadanfrage verwendet werden sollen, gehören:

  • Content-Type. Er muss auf einen der zulässigen Uploadmediendatentypen der Methode festgelegt werden, die in der Referenz zur Publishing API angegeben sind.

  • Content-Length. Legen Sie als Wert die Anzahl der Bytes fest, die Sie hochladen. Nicht erforderlich, wenn Sie die aufgeteilte Transferverschlüsselung verwenden.

Beispiel: Einfacher Upload

Das folgende Beispiel zeigt die Verwendung einer einfachen Uploadanfrage für die Play Games Services Publishing API.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/png
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

PNG data

Wenn die Anfrage erfolgreich ist, gibt der Server den HTTP-Statuscode 200 OK zusammen mit allen Metadaten zurück. Beispiele:

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

Mehrteiliger Upload

Wenn Sie Metadaten zusammen mit den hochzuladenden Daten senden möchten, können Sie eine einzelne multipart/related-Anfrage stellen. Dies ist eine gute Wahl, wenn die von Ihnen gesendeten Daten klein genug sind, um sie noch einmal vollständig hochzuladen, wenn die Verbindung fehlschlägt.

Wenn Sie den mehrteiligen Upload verwenden möchten, stellen Sie eine POST- oder PUT-Anfrage an den /upload-URI der Methode und fügen Sie den Abfrageparameter uploadType=multipart hinzu. Beispiele:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart

Zu den Top-Level-HTTP-Headern, die bei einer mehrteiligen Uploadanfrage verwendet werden sollen, gehören:

-Content-Type. Setzen Sie den Wert auf multipart/related und fügen Sie den Grenzstring hinzu, mit dem Sie die Teile der Anfrage identifizieren.

-Content-Length. Legen Sie als Wert die Gesamtzahl von Byte im Anfragetext fest. Der Medienteil der Anfrage muss kleiner sein als die maximale Dateigröße, die für diese Methode angegeben wurde.

Der Text der Anfrage ist als mehrteiliger/ähnlicher Inhaltstyp RFC2387 formatiert und enthält genau zwei Teile. Die Teile werden durch einen Grenzstring identifiziert und auf den endgültigen Grenzstring folgen zwei Bindestriche.

Für jeden Teil der mehrteiligen Anfrage ist ein zusätzlicher Content-Type-Header erforderlich:

  • Metadatenteil: Muss als Erstes angegeben werden und „Content-Type“ muss einem der zulässigen Metadatenformate entsprechen.

  • Medienteil: Muss als Zweites angegeben werden und „Content-Type“ muss einem der zulässigen Medien-MIME-Typen der Methode entsprechen.

Eine Liste der zulässigen Medien-MIME-Typen und der Größenbeschränkungen für hochgeladene Dateien für jede Methode finden Sie in der Referenz zur Publishing API.

Beispiel: Mehrteiliger Upload

Das Beispiel unten zeigt eine mehrteilige Uploadanfrage für die Play Game Services Publishing API.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=foo_bar_baz
Content-Length: number_of_bytes_in_entire_request_body

--foo_bar_baz
Content-Type: application/json; charset=UTF-8

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

--foo_bar_baz
Content-Type: image/png

PNG data
--foo_bar_baz--

Wenn die Anfrage erfolgreich ist, gibt der Server den HTTP-Statuscode 200 OK zusammen mit allen Metadaten zurück:

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

Fortsetzbarer Upload

Um Datendateien zuverlässiger hochzuladen, können Sie das Protokoll für fortsetzbare Uploads verwenden. Mit diesem Protokoll können Sie einen Uploadvorgang fortsetzen, nachdem ein Kommunikationsfehler den Datenfluss unterbrochen hat. Das ist besonders nützlich, wenn Sie große Dateien übertragen und die Wahrscheinlichkeit einer Netzwerkunterbrechung oder eines anderen Übertragungsfehlers hoch ist, z. B. beim Hochladen aus einer mobilen Client-App. Außerdem kann die Bandbreitennutzung bei Netzwerkausfällen reduziert werden, da Sie Uploads großer Dateien nicht von Anfang an neu starten müssen.

Bei fortsetzbaren Uploads sind folgende Schritte erforderlich:

  1. Starten Sie eine fortsetzbare Sitzung. Stellen Sie eine erste Anfrage an den Upload-URI, der die Metadaten enthält, sofern vorhanden.

  2. Speichern Sie den URI der fortsetzbaren Sitzung. Speichern Sie den Sitzungs-URI, der in der Antwort auf die ursprüngliche Anfrage zurückgegeben wurde. Er wird für die verbleibenden Anfragen in dieser Sitzung verwendet. Lade die Datei hoch.

  3. Senden Sie die Mediendatei an den URI der fortsetzbaren Sitzung.

Außerdem müssen Apps, die den fortsetzbaren Upload verwenden, Code enthalten, um einen unterbrochenen Upload fortzusetzen. Wenn ein Upload unterbrochen wird, ermitteln Sie, wie viele Daten erfolgreich empfangen wurden, und setzen Sie den Upload dann ab diesem Punkt fort.

Fortsetzbare Sitzung starten

Um einen fortsetzbaren Upload zu starten, stellen Sie eine POST- oder PUT-Anfrage an den /upload-URI der Methode und fügen Sie den Abfrageparameter uploadType=resumable hinzu. Beispiele:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable

Bei dieser initiierenden Anfrage ist der Text entweder leer oder enthält nur die Metadaten. In den nachfolgenden Anfragen wird der tatsächliche Inhalt der Datei übertragen, die Sie hochladen möchten.

Verwenden Sie bei der ersten Anfrage die folgenden HTTP-Header:

  • X-Upload-Content-Type. Legen Sie als Wert den Medien-MIME-Typ der Uploaddaten fest, die in nachfolgenden Anfragen übertragen werden sollen.

  • X-Upload-Content-Length. Legen Sie als Wert die Anzahl von Byte an Uploaddaten fest, die in nachfolgenden Anfragen übertragen werden sollen. Wenn die Länge zum Zeitpunkt der Anfrage unbekannt ist, können Sie diesen Header weglassen.

  • Bei Bereitstellung von Metadaten: Content-Type. Legen Sie den Wert entsprechend dem Datentyp der Metadaten fest.

  • Content-Length. Legen Sie als Wert die Anzahl von Byte fest, die im Text dieser ersten Anfrage angegeben sind. Nicht erforderlich bei Verwendung der aufgeteilten Transferverschlüsselung.

Die Liste der zulässigen Medien-MIME-Typen und Größenbeschränkungen für hochgeladene Dateien für jede Methode finden Sie in der Referenz zur Publishing API.

Beispiel: Anfrage zum Starten einer fortsetzbaren Sitzung

Das folgende Beispiel zeigt, wie eine fortsetzbare Sitzung für die Play Game Services Publishing API gestartet wird.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Type: image/png
X-Upload-Content-Length: 2000000

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

Im nächsten Abschnitt wird beschrieben, wie mit der Antwort zu verfahren ist.

URI der fortsetzbaren Sitzung speichern

Wenn die Anfrage zum Starten der Sitzung erfolgreich war, antwortet der API-Server mit dem HTTP-Statuscode 200 OK. Darüber hinaus wird ein Location-Header bereitgestellt, der den URI der fortsetzbaren Sitzung angibt. Der im Beispiel unten gezeigte Header Location enthält einen Abschnitt mit dem Abfrageparameter upload_id, der die eindeutige Upload-ID für diese Sitzung liefert.

Beispiel: Antwort zum Initiieren einer fortsetzbaren Sitzung

Hier ist die Antwort auf die Anfrage in Schritt 1:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

Der Wert des Location-Headers, wie in der Beispielantwort oben gezeigt, ist der Sitzungs-URI, den Sie als HTTP-Endpunkt für den tatsächlichen Dateiupload oder die Abfrage des Uploadstatus verwenden.

Kopieren und speichern Sie den Sitzungs-URI, damit Sie ihn für nachfolgende Anfragen verwenden können.

Datei hochladen

Senden Sie zum Hochladen der Datei eine PUT-Anfrage an den Upload-URI, den Sie im vorherigen Schritt abgerufen haben. Die Uploadanfrage hat folgendes Format:

PUT session_uri

Zu den HTTP-Headern, die bei Anfragen für fortsetzbare Datei-Uploads verwendet werden sollen, gehört Content-Length. Legen Sie hier die Anzahl der Bytes fest, die Sie in dieser Anfrage hochladen. In der Regel entspricht dies der Größe der Upload-Datei.

Beispiel: Anfrage zum Hochladen einer fortsetzbaren Datei

Hier ist eine fortsetzbare Anfrage zum Hochladen der gesamten 2.000.000 Byte großen PNG-Datei für das aktuelle Beispiel.

PUT https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: image/png

bytes 0-1999999

Wenn die Anfrage erfolgreich ist, antwortet der Server mit einem HTTP 201 Created zusammen mit allen Metadaten, die dieser Ressource zugeordnet sind. Wenn die ursprüngliche Anfrage der fortsetzbaren Sitzung eine PUT war, um eine vorhandene Ressource zu aktualisieren, lautete die Erfolgsantwort 200 OK, zusammen mit allen Metadaten, die mit dieser Ressource verknüpft sind.

Wenn die Uploadanfrage unterbrochen wird oder der Server eine HTTP 503 Service Unavailable- oder eine andere 5xx-Antwort vom Server erhält, folgen Sie der Anleitung unter Unterbrochenen Upload fortsetzen.

Datei in Teilen hochladen

Mit fortsetzbaren Uploads können Sie eine Datei in Blöcke aufteilen und eine Reihe von Anfragen senden, um die einzelnen Blöcke nacheinander hochzuladen. Dies ist nicht der bevorzugte Ansatz, da mit den zusätzlichen Anfragen Leistungskosten verbunden sind und in der Regel nicht benötigt wird. Möglicherweise müssen Sie jedoch die Aufteilung verwenden, um die in einer einzelnen Anfrage übertragene Datenmenge zu reduzieren. Dies ist hilfreich, wenn es für einzelne Anfragen ein festes Zeitlimit gibt, wie es bei bestimmten Klassen von Google App Engine-Anfragen der Fall ist. Außerdem haben Sie damit die Möglichkeit, für Legacy-Browser, die den Uploadfortschritt nicht standardmäßig unterstützen, eine Anzeige des Uploadfortschritts bereitzustellen.

Wenn Sie die Daten in Teilen hochladen, sind außerdem der Header „Content-Range“ und der Header „Content-Length“ erforderlich, der für vollständige Dateiuploads erforderlich ist:

  • Content-Length. Legen Sie als Wert die Chunk-Größe oder einen kleineren Wert fest, wie es bei der letzten Anfrage der Fall sein kann.

  • Content-Range: Legen Sie fest, dass angezeigt werden soll, welche Bytes in der Datei hochgeladen werden. Content-Range: bytes 0-524287/2000000 gibt beispielsweise an, dass Sie die ersten 524.288 Byte (256 × 1024 × 2) in einer Datei mit 2.000.000 Byte bereitstellen.

Beispiel: Anfrage für fortsetzbaren, aufgeteilten Datei-Upload

Eine Anfrage, die die ersten 524.288 Byte sendet, könnte wie folgt aussehen:

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: image/png
Content-Range: bytes 0-524287/2000000

bytes 0-524288

Wenn die Anfrage erfolgreich ist, antwortet der Server mit 308 Resume Incomplete zusammen mit einem Range-Header, der die Gesamtzahl der bisher gespeicherten Byte identifiziert:

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: bytes=0-524287

Verwenden Sie den oberen Wert, der im Header Range zurückgegeben wird, um zu bestimmen, wo der nächste Teil beginnt. Führen Sie PUT für die einzelnen Teile der Datei aus, bis die gesamte Datei hochgeladen wurde.

Wenn die PUT-Anfrage eines Teils unterbrochen wird oder Sie eine HTTP-Antwort vom Typ 503 Service Unavailable oder eine andere 5xx-Antwort vom Server erhalten, folgen Sie der Anleitung unter Unterbrochenen Upload fortsetzen. Statt den Rest der Datei hochzuladen, fahren Sie aber einfach mit dem Hochladen der Blöcke fort.

Wichtige Hinweise:

  • Achten Sie darauf, in der Antwort den Header Range zu verwenden, um zu bestimmen, wo der nächste Teil beginnt. Gehen Sie nicht davon aus, dass der Server alle Byte erhalten hat, die in der vorherigen Anfrage gesendet wurden.

  • Jeder Upload-URI hat eine begrenzte Lebensdauer und läuft möglicherweise innerhalb von einem Tag ab, wenn er nicht verwendet wird. Aus diesem Grund ist es am besten, einen fortsetzbaren Upload zu starten, sobald Sie den Upload-URI erhalten haben, und einen unterbrochenen Upload kurz nach der Unterbrechung fortzusetzen.

  • Wenn Sie eine Anfrage mit einer abgelaufenen Uploadsitzungs-ID senden, gibt der Server den Statuscode 404 Not Found zurück. Wenn in der Uploadsitzung ein nicht behebbarer Fehler auftritt, gibt der Server den Statuscode 410 Gone zurück. In diesen Fällen müssen Sie einen neuen fortsetzbaren Upload starten, einen neuen Upload-URI abrufen und den Upload unter Verwendung des neuen Endpunkts von Anfang an starten.

Wenn der gesamte Datei-Upload abgeschlossen ist, gibt der Server HTTP 201 Created zusammen mit allen Metadaten zurück, die dieser Ressource zugeordnet sind. Wenn mit dieser Anfrage eine vorhandene Entität aktualisiert und keine neue erstellt wurde, hätte der HTTP-Antwortcode für einen abgeschlossenen Upload 200 OK gelautet.

Unterbrochenen Upload fortsetzen

Wenn eine Uploadanfrage beendet wird, bevor eine Antwort eingeht, oder wenn Sie vom Server eine HTTP 503 Service Unavailable-Antwort erhalten, müssen Sie den unterbrochenen Upload fortsetzen. So setzen Sie einen unterbrochenen Upload fort:

  1. Anfragestatus: Fragen Sie den aktuellen Status des Uploads ab, indem Sie eine leere PUT-Anfrage an den Upload-URI senden. Bei dieser Anfrage sollten die HTTP-Header einen Content-Range-Header enthalten, der angibt, dass die aktuelle Position in der Datei unbekannt ist. Legen Sie beispielsweise Content-Range auf */2000000 fest, wenn die Gesamtdateilänge 2.000.000 beträgt. Wenn die Gesamtgröße der Datei nicht bekannt ist, legen Sie „Content-Range“ (Content-Range) auf */* fest.

  2. Rufen Sie die Anzahl der hochgeladenen Byte ab. Verarbeiten Sie die Antwort der Statusabfrage. Der Server verwendet den Header Range in seiner Antwort, um anzugeben, welche Byte bisher empfangen wurden. Der Header Range mit dem Wert 0-299999 gibt beispielsweise an, dass die ersten 300.000 Byte der Datei empfangen wurden.

  3. Verbleibende Daten hochladen Da Sie nun wissen, wo Sie die Anfrage fortsetzen sollen, können Sie die verbleibenden Daten oder den aktuellen Block senden. Die verbleibenden Daten müssen in beiden Fällen als separater Block behandelt werden. Sie müssen also den Content-Range-Header senden, wenn Sie den Upload fortsetzen.

Beispiel: Unterbrochenen Upload fortsetzen

  1. Fordere den Uploadstatus an. In der folgenden Anfrage wird der Header „Content-Range“ verwendet,um anzugeben,dass die aktuelle Position in der 2.000.000 Byte großen Datei unbekannt ist.

    PUT {session_uri} HTTP/1.1
Content-Length: 0
Content-Range: bytes */2000000

  2. Extrahieren Sie die Anzahl der Byte, die bisher hochgeladen wurden, aus der Antwort. In der Antwort des Servers wird mit dem Header Range angegeben, dass er bisher die ersten 43 Byte der Datei empfangen hat. Legen Sie anhand des oberen Werts des „Range“-Headers fest, von wo aus der fortgesetzte Upload gestartet werden soll.

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42
  1. Setzen Sie den Upload an der Stelle fort, an der er angehalten wurde. Die folgende Anfrage setzt den Upload fort, indem die verbleibenden Byte der Datei ab Byte 43 gesendet werden.
PUT {session_uri} HTTP/1.1
Content-Length: 1999957
Content-Range: bytes 43-1999999/2000000

bytes 43-1999999

Best Practices

Beim Hochladen von Medien ist es hilfreich, sich mit einigen Best Practices zur Fehlerbehandlung vertraut zu machen.

  • Fortsetzen oder Wiederholen von Uploads, die aufgrund von Verbindungsunterbrechungen oder 5xx-Fehlern fehlgeschlagen sind, darunter:

    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout

  • Verwenden Sie einen exponentiellen Backoff, wenn beim Fortsetzen oder Wiederholen von Uploadanfragen ein Serverfehler des Typs 5xx zurückgegeben wird. Diese Fehler können auftreten, wenn ein Server überlastet ist. Ein exponentieller Backoff kann dazu beitragen, diese Art von Problemen in Zeiten mit hohem Anfragevolumen oder hohem Netzwerkverkehr zu lösen.

  • Andere Arten von Anfragen sollten nicht vom exponentiellen Backoff verarbeitet werden. Sie können jedoch eine Reihe von Anfragen wiederholen. Begrenzen Sie dabei die Anzahl der Wiederholungen. Beispielsweise kann der Code auf maximal zehn Wiederholungen begrenzen, bevor ein Fehler gemeldet wird.

  • Wenn bei fortsetzbaren Uploads Fehler des Typs 404 Not Found und 410 Gone auftreten, starten Sie den gesamten Upload von Anfang an neu.

Exponentieller Backoff

Der exponentielle Backoff ist eine standardmäßige Fehlerbehandlungsstrategie für Netzwerkanwendungen, bei der der Client eine fehlgeschlagene Anfrage regelmäßig über einen immer längeren Zeitraum wiederholt. Wenn eine hohe Anzahl von Anfragen oder ein hoher Netzwerkverkehr dazu führen, dass der Server Fehler zurückgibt, kann ein exponentieller Backoff eine gute Strategie für die Behebung dieser Fehler sein. Umgekehrt ist sie keine relevante Strategie für den Umgang mit Fehlern, die nicht im Zusammenhang mit dem Netzwerkvolumen oder den Reaktionszeiten stehen, z. B. durch ungültige Autorisierungsanmeldedaten oder Fehler vom Typ „Datei nicht gefunden“.

Bei ordnungsgemäßer Anwendung erhöht der exponentielle Backoff die Effizienz der Bandbreitennutzung, reduziert die Anzahl der Anfragen, die für eine erfolgreiche Antwort erforderlich sind, und maximiert den Durchsatz von Anfragen in Umgebungen, die gleichzeitig ausgeführt werden.

Der Ablauf zur Implementierung eines einfachen exponentiellen Backoffs sieht so aus:

  1. Stellen Sie eine Anfrage an die API.
  2. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen sollten.
  3. Warten Sie 1 Sekunde + random_number_milliseconds und wiederholen Sie die Anfrage.
  4. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen sollten.
  5. Warten Sie 2 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
  6. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen sollten.
  7. Warten Sie 4 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
  8. Sie erhalten eine HTTP 503 response, die angibt, dass Sie die Anfrage wiederholen sollten.
  9. Warten Sie 8 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
  10. Sie erhalten eine HTTP 503 response, die angibt, dass Sie die Anfrage wiederholen sollten.
  11. Warten Sie 16 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
  12. Stopp Melden oder protokollieren Sie einen Fehler.

In der obigen Liste steht random_number_milliseconds für eine zufällige Anzahl von Millisekunden, die kleiner oder gleich 1.000 ist. Das ist erforderlich, da eine kleine zufällige Verzögerung dazu beiträgt, die Last gleichmäßiger zu verteilen und die Möglichkeit eines Überstempels des Servers zu vermeiden. Der Wert von random_number_milliseconds muss nach jeder Wartezeit neu definiert werden.

Der Algorithmus ist so eingestellt, dass er endet, wenn n 5 ist. Diese Obergrenze verhindert, dass Clients es unendlich wiederholen, und führt zu einer Gesamtverzögerung von etwa 32 Sekunden, bevor eine Anfrage als „nicht behebbarer Fehler“ gilt. Eine größere maximale Anzahl von Wiederholungen ist in Ordnung, insbesondere wenn ein langer Upload läuft. Achten Sie nur darauf, die Wiederholungsverzögerung auf einen angemessenen Wert zu begrenzen, z. B. weniger als eine Minute.

Anleitungen für API-Clientbibliotheken