Sprawdzone metody korzystania z usług internetowych interfejsu Address Validation API

Usługi internetowe Google Maps Platform to zbiór interfejsów HTTP do usług Google, które dostarczają dane geograficzne do aplikacji mapowych.

W tym przewodniku opisano kilka typowych praktyk przydatnych podczas konfigurowania żądań usługi internetowej i przetwarzania odpowiedzi usługi. Pełną dokumentację interfejsu Address Validation API znajdziesz w przewodniku dla deweloperów.

Co to jest usługa internetowa?

Usługi internetowe Google Maps Platform to interfejs do wysyłania żądań danych z interfejsu API Map Google z usług zewnętrznych i używania tych danych w aplikacjach Map Google. Zgodnie z ograniczeniami licencji opisanymi w Warunkach korzystania z usługi Google Maps Platform te usługi są przeznaczone do używania w połączeniu z mapą.

Usługi internetowe interfejsów API Map Google używają żądań HTTP(S) do określonych adresów URL, przekazując parametry adresu URL lub dane POST w formacie JSON jako argumenty do usług. Zwykle te usługi zwracają dane w treści odpowiedzi w formacie JSON do przeanalizowania lub przetworzenia przez aplikację.

Sprawdź adres, wysyłając żądanie HTTP POST do metody validateAddress:

https://addressvalidation.googleapis.com/v1:validateAddress

Przekaż treść JSON do żądania definiującego adres do zweryfikowania.

Uwaga: wszystkie aplikacje Address Validation API wymagają uwierzytelniania. Dowiedz się więcej o danych uwierzytelniających.

Dostęp SSL/TLS

Protokół HTTPS jest wymagany w przypadku wszystkich żądań Google Maps Platform, które używają kluczy interfejsu API lub zawierają dane użytkownika. Żądania wysyłane przez HTTP, które zawierają dane wrażliwe, mogą zostać odrzucone.

Tworzenie prawidłowego adresu URL

Może się wydawać, że „prawidłowy” adres URL jest oczywisty, ale nie do końca tak jest. Adres URL wpisany na przykład na pasku adresu w przeglądarce może zawierać znaki specjalne (np. "上海+中國"). Przeglądarka musi wewnętrznie przetłumaczyć te znaki na inne kodowanie przed ich przesłaniem. Z tego samego powodu każdy kod, który generuje lub akceptuje dane wejściowe w formacie UTF-8, może traktować adresy URL ze znakami UTF-8 jako „prawidłowe”, ale musi też przetłumaczyć te znaki przed wysłaniem ich do serwera WWW. Ten proces nazywa się kodowaniem URL lub kodowaniem procentowym.

Uwaga: przeglądarki lub usługi mogą automatycznie kodować identyfikator URI żądania przed wysłaniem. W przypadku interfejsów API, które używają kryptograficznego podpisywania żądań, może to unieważnić podpis, jeśli kodowanie adresu URL zmieni żądanie po podpisaniu. Aby uniknąć tego problemu, zawsze stosuj kodowanie URL do ciągu zapytania przed podpisaniem żądania.

Znaki specjalne

Znaki specjalne muszą zostać przetłumaczone, ponieważ wszystkie adresy URL muszą być zgodne ze składnią określoną w specyfikacji Uniform Resource Identifier (URI). W efekcie adresy URL mogą zawierać tylko specjalny podzbiór znaków ASCII: znane symbole alfanumeryczne i niektóre znaki zarezerwowane do użycia jako znaki sterujące w adresach URL. Te znaki są podsumowane w tabeli:

Ustaw	znaków	Zastosowanie adresu URL
Znaki alfanumeryczne	a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9	ciągi tekstowe, użycie schematu (http), port (8080) itp.
Niezarezerwowane	- _ . ~	Ciągi tekstowe
Zarezerwowane	! * ' ( ) ; : @ & = + $ , / ? % # [ ]	znaki kontrolne lub ciągi tekstowe,

Podczas tworzenia prawidłowego adresu URL musisz upewnić się, że zawiera on tylko znaki podane w tabeli. Dostosowanie adresu URL do tego zestawu znaków zwykle prowadzi do 2 problemów – pominięcia i zastąpienia:

• Znaki, które chcesz obsłużyć, nie należą do powyższego zestawu. Na przykład znaki w językach obcych, takie jak 上海+中國, muszą być zakodowane za pomocą powyższych znaków. Zgodnie z powszechną konwencją spacje (które nie są dozwolone w adresach URL) są często reprezentowane przez znak plusa '+'.
• Znaki istnieją w powyższym zbiorze jako znaki zarezerwowane, ale muszą być używane dosłownie. Na przykład znak ? jest używany w adresach URL do oznaczania początku ciągu zapytania. Jeśli chcesz użyć ciągu „? i Mysterions”, musisz zakodować znak '?'.

Wszystkie znaki, które mają być zakodowane na potrzeby adresu URL, są kodowane za pomocą znaku '%' i dwuznakowej wartości szesnastkowej odpowiadającej ich znakowi UTF-8. Na przykład 上海+中國 w kodowaniu UTF-8 będzie zakodowany w adresie URL jako %E4%B8%8A%E6%B5%B7%2B%E4%B8%AD%E5%9C%8B. Ciąg znaków ? and the Mysterians zostanie zakodowany w adresie URL jako %3F+and+the+Mysterians lub %3F%20and%20the%20Mysterians.

Typowe znaki wymagające kodowania

Oto kilka typowych znaków, które muszą być zakodowane:

Niebezpieczny znak	Wartość zakodowana
Spacja	%20
”.	%22
<	%3C
>	%3E
#	%23
%	%25
|	%7C

Konwertowanie adresu URL otrzymanego od użytkownika bywa trudne. Użytkownik może na przykład wpisać adres „5th&Main St.”. Zasadniczo adres URL należy tworzyć z jego części, traktując wszelkie dane wejściowe użytkownika jako znaki dosłowne.

Dodatkowo adresy URL są ograniczone do 16 384 znaków we wszystkich usługach internetowych i statycznych interfejsach API Google Maps Platform. W przypadku większości usług ten limit znaków rzadko zostanie osiągnięty. Pamiętaj jednak, że niektóre usługi mają kilka parametrów, które mogą powodować, że adresy URL będą długie.

Zasady korzystania z interfejsów API Google

Źle zaprojektowane klienty API mogą niepotrzebnie obciążać zarówno internet, jak i serwery Google. Ta sekcja zawiera sprawdzone metody dotyczące klientów interfejsów API. Stosowanie tych sprawdzonych metod może pomóc Ci uniknąć zablokowania aplikacji z powodu niezamierzonego nadużycia interfejsów API.

Wzrastający czas do ponowienia

W rzadkich przypadkach podczas obsługi żądania może wystąpić błąd. Możesz otrzymać kod odpowiedzi HTTP 4XX lub 5XX albo połączenie TCP może po prostu nie zostać nawiązane między klientem a serwerem Google. Często warto spróbować ponownie, ponieważ kolejne żądanie może się powieść, nawet jeśli pierwotne się nie udało. Ważne jest jednak, aby nie wysyłać żądań do serwerów Google w pętli. Takie zapętlenie może przeciążyć sieć między klientem a Google, co może powodować problemy dla wielu stron.

Lepszym rozwiązaniem jest ponawianie prób z coraz dłuższymi przerwami między nimi. Zwykle opóźnienie jest zwiększane o mnożnik przy każdej próbie. Takie podejście jest znane jako wzrastający czas do ponowienia.

Załóżmy na przykład, że aplikacja chce wysłać do interfejsu Time Zone API takie żądanie:

https://maps.googleapis.com/maps/api/timezone/json?location=39.6034810,-119.6822510&timestamp=1331161200&key=YOUR_API_KEY

Poniższy przykład w języku Python pokazuje, jak wysłać żądanie z wykorzystaniem wzrastającego czasu do ponowienia:

import json
import time
import urllib.error
import urllib.parse
import urllib.request

# The maps_key defined below isn't a valid Google Maps API key.
# You need to get your own API key.
# See https://developers.google.com/maps/documentation/timezone/get-api-key
API_KEY = "YOUR_KEY_HERE"
TIMEZONE_BASE_URL = "https://maps.googleapis.com/maps/api/timezone/json"


def timezone(lat, lng, timestamp):

    # Join the parts of the URL together into one string.
    params = urllib.parse.urlencode(
        {"location": f"{lat},{lng}", "timestamp": timestamp, "key": API_KEY,}
    )
    url = f"{TIMEZONE_BASE_URL}?{params}"

    current_delay = 0.1  # Set the initial retry delay to 100ms.
    max_delay = 5  # Set the maximum retry delay to 5 seconds.

    while True:
        try:
            # Get the API response.
            response = urllib.request.urlopen(url)
        except urllib.error.URLError:
            pass  # Fall through to the retry loop.
        else:
            # If we didn't get an IOError then parse the result.
            result = json.load(response)

            if result["status"] == "OK":
                return result["timeZoneId"]
            elif result["status"] != "UNKNOWN_ERROR":
                # Many API errors cannot be fixed by a retry, e.g. INVALID_REQUEST or
                # ZERO_RESULTS. There is no point retrying these requests.
                raise Exception(result["error_message"])

        if current_delay > max_delay:
            raise Exception("Too many retry attempts.")

        print("Waiting", current_delay, "seconds before retrying.")

        time.sleep(current_delay)
        current_delay *= 2  # Increase the delay each time we retry.


if __name__ == "__main__":
    tz = timezone(39.6034810, -119.6822510, 1331161200)
    print(f"Timezone: {tz}")

Uważaj też, aby w łańcuchu wywołań aplikacji nie było kodu ponownej próby, który prowadzi do powtarzania żądań w krótkich odstępach czasu.

Żądania zsynchronizowane

Duża liczba zsynchronizowanych żądań do interfejsów API Google może wyglądać jak rozproszony atak typu DoS (DDoS) na infrastrukturę Google i zostać odpowiednio potraktowana. Aby tego uniknąć, upewnij się, że żądania do interfejsu API nie są synchronizowane między klientami.

Weźmy na przykład aplikację, która wyświetla czas w bieżącej strefie czasowej. Ta aplikacja prawdopodobnie ustawi alarm w systemie operacyjnym klienta, który wybudzi go na początku minuty, aby można było zaktualizować wyświetlany czas. Aplikacja nie powinna wykonywać żadnych wywołań interfejsu API w ramach przetwarzania związanego z tym alarmem.

Wykonywanie wywołań interfejsu API w odpowiedzi na stały alarm jest nieprawidłowe, ponieważ powoduje, że wywołania interfejsu API są synchronizowane z początkiem minuty, nawet między różnymi urządzeniami, zamiast być równomiernie rozłożone w czasie. Źle zaprojektowana aplikacja, która tak robi, na początku każdej minuty wygeneruje skok ruchu 60 razy większy niż normalnie.

Zamiast tego można ustawić drugi alarm na losowo wybraną godzinę. Gdy ten drugi alarm się uruchomi, aplikacja wywołuje wszystkie potrzebne interfejsy API i zapisuje wyniki. Gdy aplikacja chce zaktualizować wyświetlane informacje na początku minuty, używa wcześniej zapisanych wyników, zamiast ponownie wywoływać interfejs API. Dzięki temu podejściu wywołania interfejsu API są rozłożone równomiernie w czasie. Ponadto wywołania interfejsu API nie opóźniają renderowania podczas aktualizowania wyświetlacza.

Oprócz początku minuty innymi typowymi momentami synchronizacji, których nie należy wybierać, są początek godziny i północ na początku każdego dnia.

Przetwarzanie odpowiedzi

Uwaga: ponieważ nie ma gwarancji, że format poszczególnych odpowiedzi na żądanie usługi internetowej będzie zawsze taki sam (niektóre elementy mogą być niedostępne lub znajdować się w kilku miejscach), nie należy zakładać, że format zwrócony w przypadku danej odpowiedzi będzie taki sam w przypadku różnych zapytań. Zamiast tego należy przetworzyć odpowiedź i wybrać odpowiednie wartości za pomocą wyrażeń.

W tej sekcji dowiesz się, jak dynamicznie wyodrębniać te wartości z odpowiedzi usługi internetowej.

Usługi internetowe Map Google dostarczają odpowiedzi, które są łatwe do zrozumienia, ale nie są zbyt przyjazne dla użytkownika. Podczas wykonywania zapytania zamiast wyświetlać zbiór danych, prawdopodobnie chcesz wyodrębnić kilka konkretnych wartości. Zazwyczaj będziesz analizować odpowiedzi z usługi internetowej i wyodrębniać tylko te wartości, które Cię interesują.

Używany schemat analizy zależy od tego, czy zwracasz dane wyjściowe w formacie JSON. Odpowiedzi JSON, które są już w postaci obiektów w JavaScripcie, mogą być przetwarzane w JavaScripcie na kliencie.