Ta strona została przetłumaczona przez Cloud Translation API.

Przesyłanie obrazów za pomocą interfejsu Play Games Services Publishing API

Interfejs Play Games Services Publishing API umożliwia przesłanie obrazu zasobu gry.

Opcje przesyłania

Interfejs Play Games Services Publishing API umożliwia przesyłanie niektórych typów danych binarnych lub multimediów. Szczegółowe informacje o danych, które możesz przesłać, znajdziesz na stronie referencyjnej dla każdej metody umożliwiającej przesyłanie multimediów:

Maksymalny rozmiar przesyłanego pliku: maksymalna ilość danych, które możesz przechowywać za pomocą tej metody.
Akceptowane typy MIME multimediów: typy danych binarnych, które możesz przechowywać za pomocą tej metody.

Możesz wysyłać prośby o przesłanie w jednym z tych sposobów: Określ metodę, której używasz, za pomocą parametru żądania uploadType.

Proste przesyłanie: uploadType=media. Szybkie przesyłanie mniejszych plików, np. mniejszych niż 5 MB.
Przesyłanie w wielu częściach: uploadType=multipart. Do szybkiego przesyłania mniejszych plików i metadanych; przesyła plik wraz z metadanymi, które go opisują, w ramach jednego żądania.
Przesyłanie z możliwością wznowienia: uploadType=resumable. Zapewnia niezawodne przesyłanie, co jest szczególnie ważne w przypadku większych plików. W tej metodzie używasz żądania inicjującego sesję, które może opcjonalnie zawierać metadane. Jest to dobra strategia w przypadku większości aplikacji, ponieważ działa również w przypadku mniejszych plików, a jedynym kosztem jest jedno dodatkowe żądanie HTTP na każde przesłanie.

Podczas przesyłania multimediów używasz specjalnego identyfikatora URI. Metody obsługujące przesyłanie multimediów mają 2 punkty końcowe URI:

Identyfikator URI /upload dla multimediów. Format punktu końcowego przesyłania to standardowy identyfikator URI zasobu z prefiksem „/upload”. Użyj tego identyfikatora URI podczas przenoszenia danych multimediów.

Przykład: POST /upload/games/v1configuration/images/resourceId/imageType/imageType
Standardowy identyfikator URI zasobu dla metadanych. Jeśli zasób zawiera pola danych, są one używane do przechowywania metadanych opisujących przesłany plik. Możesz go używać podczas tworzenia lub aktualizowania wartości metadanych.

Przykład: POST /games/v1configuration/images/resourceId/imageType/imageType

Przesyłanie proste

Najprostszą metodą przesyłania plików jest wysłanie zwykłego żądania przesyłania. Ta opcja jest dobrym wyborem, jeśli spełniony jest jeden z tych warunków:

Plik jest na tyle mały, że można go przesłać ponownie w całości, jeśli połączenie się nie powiedzie.
Brak metadanych do wysłania. Może się tak zdarzyć, jeśli planujesz wysłać metadane tego zasobu w osobnym żądaniu lub jeśli metadane nie są obsługiwane lub niedostępne. Aby użyć prostego przesyłania, wyślij żądanie POST lub PUT do adresu URI metody /upload i dodaj parametr zapytania uploadType=media. Na przykład:

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

Nagłówki HTTP, których należy używać podczas wysyłania prostego żądania przesyłania:

Content-Type. Ustaw jedną z akceptowanych metod przesyłania danych mediów, określoną w dokumentacji interfejsu Publishing API.
Content-Length. Ustaw na liczbę bajtów, które przesyłasz. Nie jest wymagane, jeśli używasz kodowania transferu w porcjach.

Przykład: proste przesyłanie

Ten przykład pokazuje użycie prostego żądania przesyłania w interfejsie 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

Jeśli żądanie zakończy się powodzeniem, serwer zwróci kod stanu HTTP 200 OK wraz z metadanymi. Na przykład:

HTTP/1.1 200
Content-Type: application/json

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

Przesyłanie wieloczęściowe

Jeśli masz metadane, które chcesz przesłać razem z danymi, możesz wysłać jedną prośbę multipart/related. To dobry wybór, jeśli dane, które wysyłasz, są na tyle małe, że można je ponownie przesłać w całości, jeśli połączenie się nie powiedzie.

Aby przesłać pliki w wielu częściach, wyślij żądanie POST lub PUT do identyfikatora URI metody /upload i dodaj parametr zapytania uploadType=multipart. Na przykład:

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

Nagłówki HTTP najwyższego poziomu, których należy używać podczas przesyłania żądania przesyłania wieloczęściowego:

-Content-Type. Ustaw na multipart/related i uwzględnij ciąg znaków granicznych, którego używasz do identyfikowania części żądania.

-Content-Length. Ustaw na łączną liczbę bajtów w ciele żądania. Część multimedialna żądania musi być mniejsza niż maksymalny rozmiar pliku określony dla tej metody.

Treść żądania jest sformatowana jako typ treści wieloczęściowych lub powiązanych zgodnie ze standardem RFC 2387 i zawiera dokładnie 2 części. Części są identyfikowane za pomocą ciągu granicznych, a po ostatnim ciągu granicznym występują 2 łączniki.

Każda część żądania wieloczęściowego musi mieć dodatkowy nagłówek Content-Type:

Część metadanych: musi być pierwsza, a typ treści musi być zgodny z jednym z obsługiwanych formatów metadanych.
Część dotycząca multimediów: musi być drugą częścią, a typ treści Content-Type musi być zgodny z jednym z obsługiwanych typów MIME multimediów metody.

Aby poznać listę akceptowanych typów MIME multimediów i limity rozmiarów przesłanych plików dla każdej metody, zapoznaj się z dokumentacją interfejsu Publishing API.

Przykład: przesyłanie w wielu częściach

Przykład poniżej przedstawia żądanie przesyłania multipart w interfejsie Play Games 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--

Jeśli żądanie zakończy się powodzeniem, serwer zwróci kod stanu HTTP 200 OK wraz z metadanymi:

HTTP/1.1 200
Content-Type: application/json

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

Przesyłanie z możliwością wznowienia

Aby przesyłać pliki danych w bardziej niezawodny sposób, możesz użyć protokołu przesyłania możliwego do wznowienia. Ten protokół umożliwia wznowienie operacji przesyłania po tym, jak awaria komunikacji przerwała przepływ danych. Jest to szczególnie przydatne, gdy przesyłasz duże pliki i jest duże prawdopodobieństwo przerwania połączenia lub innego błędu transmisji, na przykład podczas przesyłania z aplikacji klienta mobilnego. Może to też zmniejszyć wykorzystanie przepustowości w przypadku awarii sieci, ponieważ nie musisz ponownie rozpoczynać przesyłania dużych plików.

Aby przesłać pliki za pomocą przesyłania możliwego do wznowienia:

Rozpocznij sesję, którą można wznowić. Prześlij początkowe żądanie do identyfikatora URI przesyłania, który zawiera metadane (jeśli istnieją).
Zapisz identyfikator URI sesji, którą można wznowić. Zapisz identyfikator URI sesji zwrócony w odpowiedzi na początkowe żądanie. Będziesz go używać w pozostałych żądaniach w tej sesji. Prześlij plik.
Prześlij plik multimedialny do identyfikatora URI sesji z możliwością wznowienia.

Aplikacje korzystające z przesyłania możliwego do wznowienia muszą też zawierać kod umożliwiający wznowienie przerwanego przesyłania. Jeśli przesyłanie zostanie przerwane, sprawdź, ile danych zostało odebranych, a potem wznów przesyłanie od tego miejsca.

Rozpoczęcie sesji z możliwością wznowienia

Aby rozpocząć przerywane przesyłanie, wyślij żądanie POST lub PUT do identyfikatora URI /upload metody i dodaj parametr zapytania uploadType=resumable. Na przykład:

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

W przypadku tej inicjującej prośby treść jest pusta lub zawiera tylko metadane. Rzeczywisty zawartość pliku, który chcesz przesłać, prześlesz w kolejnych prośbach.

Użyj tych nagłówków HTTP w pierwszym żądaniu:

X-Upload-Content-Type. Ustaw typ MIME multimediów danych przesyłanianych w kolejnych żądaniach.
X-Upload-Content-Length. Ustaw liczbę bajtów danych przesyłanych do przeniesienia w kolejnych żądaniach. Jeśli długość jest nieznana w momencie wysłania prośby, możesz pominąć ten nagłówek.
Jeśli przesyłasz metadane: Content-Type. Ustaw zgodnie z typem danych metadanych.
Content-Length. Ustaw na liczbę bajtów podanych w ciele tego wstępnego żądania. Nie jest wymagane, jeśli używasz kodowania transferu w porcjach.

Aby poznać listę obsługiwanych typów MIME multimediów i limity rozmiarów przesłanych plików dla każdej metody, zapoznaj się z dokumentacją interfejsu Publishing API.

Przykład: żądanie zainicjowania sesji z możliwością wznowienia

Z tego przykładu dowiesz się, jak zainicjować sesję z możliwością wznowienia w przypadku interfejsu Play Games Services Publishing API.

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
}

W następnej sekcji znajdziesz informacje o tym, jak postępować w przypadku otrzymania takiej odpowiedzi.

Zapisz identyfikator URI sesji, którą można wznowić

Jeśli żądanie zainicjowania sesji zakończy się powodzeniem, serwer interfejsu API odpowie kodem stanu HTTP 200 OK. Dodatkowo zawiera nagłówek Location, który określa identyfikator URI sesji z możliwością wznowienia. Nagłówek Location, pokazany w przykładzie poniżej, zawiera część parametru zapytania upload_id, która zawiera unikalny identyfikator przesyłania do użycia w tej sesji.

Przykład: odpowiedź na żądanie zainicjowania sesji z możliwością wznowienia

Oto odpowiedź na żądanie z kroku 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

Wartość nagłówka Location, jak pokazano w powyższym przykładzie odpowiedzi, to identyfikator URI sesji, którego użyjesz jako punktu końcowego HTTP do faktycznego przesyłania plików lub sprawdzania stanu przesyłania.

Skopiuj i zapisz identyfikator URI sesji, aby móc go użyć w kolejnych żądaniach.

Przesyłanie pliku

Aby przesłać plik, wyślij żądanie PUT do identyfikatora URI przesyłania, który został uzyskany w poprzednim kroku. Format żądania przesyłania:

PUT session_uri

Nagłówki HTTP, których należy używać podczas przesyłania plików z możliwością wznowienia przesyłania, to Content-Length. Ustaw tę wartość na liczbę bajtów przesyłanych w tym żądaniu, czyli zazwyczaj rozmiar pliku do przesłania.

Przykład: prośba o przesyłanie plików z możliwością wznowienia

Oto przykładowa prośba o przesłanie całego pliku PNG o rozmiarach 2 000 000 bajtów, która może być wznowiona.

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

Jeśli żądanie się powiedzie, serwer odpowie HTTP 201 Created, wraz z metadanymi powiązanymi z tym zasobem. Jeśli początkowe żądanie sesji możliwej do wznowienia to PUT, aby zaktualizować istniejący zasób, odpowiedź na żądanie będzie zawierać 200 OK wraz z metadanymi powiązanymi z tym zasobem.

Jeśli żądanie przesyłania zostanie przerwane lub otrzymasz odpowiedź HTTP 503 Service Unavailable lub inną odpowiedź 5xx od serwera, postępuj zgodnie z instrukcjami w artykule Wznawianie przerwanego przesyłania.

Przesyłanie pliku w porcjach

Dzięki możliwości wznawiania przesyłania możesz podzielić plik na części i wysłać serię żądań, aby przesłać każdą część w kolejności. Nie jest to preferowane podejście, ponieważ dodatkowe żądania wiążą się z kosztami związanymi z wydajnością, a zazwyczaj nie jest to konieczne. Może jednak być konieczne podzielenie danych na mniejsze części, aby zmniejszyć ilość danych przesyłanych w ramach pojedynczego żądania. Jest to przydatne, gdy w przypadku poszczególnych żądań obowiązuje określony limit czasu, jak ma to miejsce w przypadku niektórych klas żądań Google App Engine. Pozwala też na wyświetlanie informacji o postępie przesyłania w starszych przeglądarkach, które nie obsługują domyślnie postępu przesyłania.

Jeśli przesyłasz dane w kawałkach, wymagany jest również nagłówek Content-Range, a także nagłówek Content-Length wymagany w przypadku przesyłania pełnych plików:

Content-Length. Ustaw na rozmiar fragmentu lub mniejszy, co może być wymagane w przypadku ostatniego żądania.
Content-Range. Ustaw, aby wyświetlić, które bajty w przesyłanym pliku. Na przykład Content-Range: bytes 0-524287/2000000 oznacza, że przesyłasz pierwsze 524 288 bajtów (256 x 1024 x 2) z pliku o rozmiarach 2 000 000 bajtów.

Rozwiń, by zobaczyć więcej informacji

Jeśli przesyłasz dane w porcjach, wymagany jest też nagłówek Content-Range, a także nagłówek Content-Length wymagany do przesyłania pełnych plików:

Content-Length. Ustaw na rozmiar fragmentu lub mniejszy, co może być wymagane w przypadku ostatniego żądania.
Content-Range: ustaw, aby wyświetlić bajty w przesyłanym pliku. Na przykład Content-Range: bytes 0-524287/2000000 wskazuje, że przesyłasz pierwsze 524 288 bajtów (256 x 1024 x 2) z pliku o rozmiarach 2 000 000 bajtów.

Ograniczenie rozmiaru fragmentu: wszystkie fragmenty muszą mieć rozmiar wielokrotny 256 KB (256 x 1024 bajtów), z wyjątkiem ostatniego fragmentu, który kończy przesyłanie. Jeśli korzystasz z podziału na fragmenty, ważne jest, aby rozmiar fragmentu był jak największy, aby przesyłanie było efektywne.

Przykład: prośba o przesyłanie plików w kawałkach z możliwością wznowienia przesyłania

Żądanie, które wysyła pierwsze 524 288 bajtów, może wyglądać tak:

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

bytes 0-524288

Jeśli żądanie zostanie zrealizowane, serwer odpowie 308 Resume Incomplete wraz z nagłówkiem Range, który identyfikuje łączną liczbę bajtów, które zostały do tej pory zapisane:

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

Aby określić, od którego miejsca ma się zaczynać kolejny fragment, użyj większej wartości zwracanej w nagłówku Range. Kontynuuj PUT każdego fragmentu pliku, aż zostanie przesłany cały plik.

Jeśli żądanie PUT dotyczące dowolnego fragmentu zostało przerwane lub jeśli serwer zwrócił kod HTTP 503 Service Unavailable lub inny kod 5xx, wykonaj czynności opisane w artykule Wznawianie przerwanego przesyłania, ale zamiast przesyłać pozostałą część pliku, kontynuuj przesyłanie fragmentów od tego miejsca.

Ważne uwagi:

W odpowiedzi użyj nagłówka Range, aby określić, od którego miejsca ma się zacząć kolejny fragment. Nie zakładaj, że serwer otrzymał wszystkie bajty wysłane w poprzednim żądaniu.
Każdy URI przesyłania ma ograniczony czas ważności i ostatecznie wygasa (około 1 dnia, jeśli nie zostanie użyty). Dlatego najlepiej rozpocząć przerywane przesyłanie zaraz po uzyskaniu identyfikatora URI przesyłania i wznowić przerwane przesyłanie zaraz po przerwaniu.
Jeśli wyślesz żądanie z identyfikatorem sesji przesyłania, który wygasł, serwer zwróci kod stanu 404 Not Found. Jeśli podczas sesji przesyłania wystąpi nieodwracalny błąd, serwer zwróci kod stanu 410 Gone. W takich przypadkach musisz rozpocząć nowe przesyłanie możliwe do wznowienia, uzyskać nowy identyfikator URI przesyłania i rozpocząć przesyłanie od początku, używając nowego punktu końcowego.

Gdy przesłanie całego pliku zostanie zakończone, serwer odpowie, zwracając odpowiedź HTTP 201 Created wraz z metadanymi powiązanymi z tym zasobem. Gdyby to żądanie miało na celu zaktualizowanie istniejącego elementu zamiast utworzenia nowego, kod odpowiedzi HTTP dla zakończonego przesyłania byłby 200 OK.

Wznawianie przerwanego przesyłania

Jeśli żądanie przesyłania zostało przerwane przed otrzymaniem odpowiedzi lub jeśli serwer zwrócił odpowiedź HTTP 503 Service Unavailable, musisz wznowić przerwane przesyłanie. Aby wznowić przerwany proces przesyłania:

Stan żądania. Aby sprawdzić bieżący stan przesyłania, wyślij puste żądanie PUT do identyfikatora URI przesyłania. W przypadku tego żądania nagłówki HTTP powinny zawierać nagłówek Content-Range, który wskazuje, że bieżąca pozycja w pliku jest nieznana. Jeśli np. całkowita długość pliku wynosi 2 000 000, ustaw wartość parametru Content-Range na */2000000. Jeśli nie znasz pełnego rozmiaru pliku, ustaw Content-Range na */*.

Uwaga: stan możesz sprawdzić między fragmentami, a nie tylko wtedy, gdy przesyłanie zostało przerwane. Jest to przydatne, jeśli chcesz wyświetlać informacje o postępie przesyłania dla starszych przeglądarek.
Pobierz liczbę przesłanych bajtów. Przetworzenie odpowiedzi na zapytanie o stan. Serwer w odpowiedzi używa nagłówka Range, aby określić, które bajty zostały do tej pory odebrane. Na przykład nagłówek Range 0-299999 wskazuje, że otrzymano pierwsze 300 tys. bajtów pliku.
Prześlij pozostałe dane. Teraz, gdy już wiesz, od którego miejsca ma być wznowione przesyłanie żądania, prześlij pozostałe dane lub bieżący fragment. Pamiętaj, że w obu przypadkach pozostałe dane należy traktować jako oddzielny fragment, więc podczas wznawiania przesyłania musisz wysłać nagłówek Content-Range.

Przykład: wznawianie przerwanego przesyłania

Poproś o stan przesyłania. Poniższe żądanie używa nagłówka Content-Range,aby wskazać,że bieżąca pozycja w pliku o rozmiarze 2 000 000 bajtów jest nieznana.
```
PUT {session_uri} HTTP/1.1
Content-Length: 0
Content-Range: bytes */2000000
```
Wyodrębnij z odpowiedzi liczbę przesłanych do tej pory bajtów. Odpowiedź serwera używa nagłówka Range, aby wskazać, że do tej pory otrzymał pierwsze 43 bajty pliku. Aby określić, od którego miejsca ma się rozpocząć wznowione przesyłanie, użyj górnej wartości nagłówka zakresu.
```
HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42
```
Uwaga: po zakończeniu przesyłania stan może być 201Utworzono lub 200 OK. Może się tak zdarzyć, jeśli połączenie zostało zerwane po przesłaniu wszystkich bajtów, ale przed otrzymaniem przez klienta odpowiedzi od serwera.
Wznów przesyłanie od miejsca, w którym zostało przerwane. Poniższe żądanie wznawia przesyłanie, wysyłając pozostałe bajty pliku, zaczynając od bajtu 43.
```
PUT {session_uri} HTTP/1.1
Content-Length: 1999957
Content-Range: bytes 43-1999999/2000000

bytes 43-1999999
```

Obsługa błędów

Podczas przesyłania multimediów warto zapoznać się ze sprawdzonymi metodami dotyczącymi obsługi błędów.

wznowić lub ponownie spróbować przesłać dane, które nie zostały przesłane z powodu przerwania połączenia lub błędu 5xx, w tym:
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
Użyj strategii wykładniczego zmniejszania wartości, jeśli podczas wznawiania lub ponownego próby przesyłania żądań wystąpi błąd serwera 5xx. Te błędy mogą wystąpić, jeśli serwer jest przeciążony. Zmniejszanie szybkości z wzrostem liczby żądań może pomóc w rozwiązaniu tego typu problemów w okresach dużego natężenia ruchu w sieci.
Inne rodzaje żądań nie powinny być obsługiwane przez wykładniczy czas oczekiwania, ale możesz je powtórzyć. Gdy ponownie wysyłasz te żądania, ogranicz liczbę prób. Na przykład Twój kod może ograniczyć liczbę prób do 10 lub mniej, zanim zgłosi błąd.
Rozpatrywanie błędów 404 Not Found i 410 Gone podczas przesyłania z możliwością wznowienia, które polega na ponownym rozpoczęciu całego przesyłania od początku.

Wzrastający czas do ponownej próby

Wzrost czasu do ponowienia jest standardową strategią obsługi błędów w przypadku aplikacji sieciowych, w których klient okresowo powtarza nieudane żądanie z coraz dłuższym opóźnieniem. Jeśli duża liczba żądań lub duży ruch w sieci powodują, że serwer zwraca błędy, dobrym rozwiązaniem może być zrzut dziesiętny. Z drugiej strony nie jest to odpowiednia strategia postępowania w przypadku błędów niezwiązanych z objętością sieci lub czasem odpowiedzi, np. błędów nieprawidłowych danych uwierzytelniających lub błędów „Nie znaleziono pliku”.

Właściwie stosowany algorytm Exponential back-off zwiększa wydajność wykorzystania przepustowości, zmniejsza liczbę żądań wymaganych do uzyskania odpowiedzi oraz maksymalizuje przepustowość żądań w środowiskach o wielu klientach.

Schemat implementacji prostego wzrastającego czasu do ponowienia:

Wyślij żądanie do interfejsu API.
Otrzymasz odpowiedź HTTP 503, która wskazuje, że należy ponownie wysłać żądanie.
Zaczekaj 1 sekundę + random_number_milliseconds i ponów prośbę.
Otrzymasz odpowiedź HTTP 503, która wskazuje, że należy ponownie wysłać żądanie.
Zaczekaj 2 sekundy + random_number_milliseconds i ponownie prześlij żądanie.
Otrzymasz odpowiedź HTTP 503, która wskazuje, że należy ponownie wysłać żądanie.
Zaczekaj 4 sekundy + random_number_milliseconds i ponownie prześlij żądanie.
Otrzymasz odpowiedź HTTP 503 response, która oznacza, że musisz ponownie wysłać żądanie.
Zaczekaj 8 sekund + random_number_milliseconds i ponownie prześlij żądanie.
Otrzymasz odpowiedź HTTP 503 response, która oznacza, że musisz ponownie wysłać żądanie.
Zaczekaj 16 sekund + random_number_milliseconds i ponownie prześlij żądanie.
Zatrzymaj. zgłaszać lub rejestrować błędy;

Na liście powyżej parametr random_number_milliseconds jest losową liczbą milisekund mniejszą od 1000 lub równą 1000. Jest to konieczne, ponieważ wprowadzenie niewielkiego opóźnienia losowego pomaga rozłożyć obciążenie bardziej równomiernie i uniknąć możliwości narzucenia na serwer znacznika czasowego. Po każdym opóźnieniu należy zmienić wartość parametru random_number_milliseconds.

Algorytm jest ustawiony tak, aby zakończyć działanie, gdy n = 5. Ten limit zapobiega nieskończonemu powtarzaniu prób przez klientów i powoduje opóźnienie około 32 sekund, zanim żądanie zostanie uznane za „nieodwracalny błąd”. Większa maksymalna liczba prób jest dopuszczalna, zwłaszcza jeśli trwa długie przesyłanie; pamiętaj tylko, aby ustawić rozsądny czas oczekiwania na ponowne próby, np. mniej niż minutę.