Google Maps Platform ウェブサービスは、Google サービスへの HTTP インターフェースの集合であり、地図アプリケーションの地理データを提供します。
このガイドでは、ウェブサービスのリクエストの設定やサービス応答の処理に役立つ一般的なプラクティスについて説明します。Geocoding API の詳細については、デベロッパー ガイドをご覧ください。
ウェブサービスとは
Google Maps Platform ウェブサービスは、外部サービスから Maps API データをリクエストし、そのデータをマップ アプリケーションで使用するためのインターフェースです。これらのサービスは、Google Maps Platform 利用規約のライセンス制限に従って、マップと組み合わせて使用するように設計されています。
Maps API ウェブサービスは、特定の URL に HTTP(S) リクエストを使用し、URL パラメータや JSON 形式の POST データを引数としてサービスに渡します。通常、これらのサービスは、アプリケーションで解析や処理を行うために、JSON または XML のいずれかの形式でレスポンス本文のデータを返します。
Geocoding API リクエストは通常、次の形式になります。
https://maps.googleapis.com/maps/api/geocode/output?parameters
ここで、output
はレスポンス形式(通常は json
または xml
)を示します。
注: すべての Geocoding API アプリケーションは認証が必要です。認証情報の詳細を確認する。
SSL/TLS アクセス
API キーを使用する、またはユーザーデータが含まれるすべての Google Maps Platform リクエストに HTTPS が必要です。機密データを含む HTTP 経由のリクエストは拒否される可能性があります。
有効な URL の作成
「有効」な URL とは何か、説明の必要はないと考えられるかもしれませんが、それほど単純なことではありません。ブラウザのアドレスバーに入力される URL には特殊文字("上海+中國"
など)が含まれている場合があります。このような特殊文字は、ブラウザで別のエンコードに内部的に変換してから送信する必要があります。同様に、UTF-8 入力を生成するコードや受け付けるコードでは、UTF-8 の文字が使用された URL を「有効」な URL として扱うことがありますが、それらの文字を Web サーバーに送信する前に変換する必要があります。このプロセスは、URL エンコードまたはパーセント エンコードと呼ばれます。
特殊文字
すべての URL は URI(Uniform Resource Identifier)仕様で規定されている構文に従う必要があるため、特殊文字を変換する必要があります。つまり、URL には、ASCII 文字の特別なサブセット(よく使用される英数記号および URL 内で制御文字として使用される予約文字)のみを含める必要があります。次の表は、こうした特殊記号をまとめたものです。
セット | 文字数 | URL での使用法 |
---|---|---|
英数字 | 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 | テキスト文字列、スキームでの使用(http )、ポート(8080 )など |
未予約 | - _ . ~ | テキスト文字列 |
予約済み | ! * ' ( ) ; : @ & = + $ , / ? % [ ] | 制御文字やテキスト文字列 |
有効な URL を作成するときは、有効な URL 文字の概要表に記載されている文字のみを使用する必要があります。URL でこの文字セットを使用すると、一般的に 2 つの問題が発生します。1 つは省略、もう 1 つは置き換えです。
- 処理する文字が上記のセットに含まれない場合。たとえば、「
上海+中國
」のような英語以外の文字は、上記の文字を使用してエンコードする必要があります。一般的な命名規則では、URL 内で使用できないスペースもプラス記号'+'
を使用して表します。 - 文字は上記のセットに予約文字として含まれるが、文字どおりに使用する必要がある場合。たとえば、
?
は URL 内でクエリ文字列の先頭を示すために使用されます。文字列「? and the Mysterions」を使用する場合は、'?'
文字をエンコードする必要があります。
URL エンコードが必要なすべての文字を、'%'
文字と、UTF-8 文字に対応する 2 文字の 16 進数値を使用してエンコードします。たとえば、UTF-8 の「上海+中國
」は、「%E4%B8%8A%E6%B5%B7%2B%E4%B8%AD%E5%9C%8B
」として URL エンコードされます。文字列 ? and the Mysterians
は、%3F+and+the+Mysterians
または %3F%20and%20the%20Mysterians
として URL エンコードされます。
エンコードが必要な一般的な文字
エンコードする必要がある一般的な文字は次のとおりです。
危険な文字 | エンコードされた値 |
---|---|
宇宙空間 | %20 |
」 | %22 |
< | %3C |
> | %3E |
# | %23 |
% | %25 |
| | %7C |
ユーザー入力から受け取った URL の変換は難しい場合があります。たとえば、ユーザーが「5th&Main St.」という住所を入力することがあります。通常は、ユーザー入力をリテラル文字として処理して、URL をパーツから作成する必要があります。
さらに、URL は、すべての Google Maps Platform ウェブサービスと Static Web API で 8,192 文字に制限されています。ほとんどのサービスでは、この文字制限に達することはめったにありません。ただし、複数のパラメータを持つ特定のサービスでは、URL が長くなる可能性があります。
Google API の適切な使用
設計が不十分な API クライアントは、インターネットと Google のサーバーの両方で必要以上の負荷をかける可能性があります。このセクションでは、API を利用するクライアントのベスト プラクティスについて説明します。これらのベスト プラクティスに従うことで、アプリケーションでの API の意図しない不正使用を防止できます。
エラーの対処と再試行
Geocoding API の UNKNOWN_ERROR
または OVER_QUERY_LIMIT
レスポンス コードについては、エラーと再試行の管理をご覧ください。
指数関数的バックオフ
まれに、リクエストへの対応で問題が発生することがあります。4XX または 5XX HTTP レスポンス コードが返されることがあります。また、クライアントと Google のサーバー間の TCP 接続でエラーが発生することもあります。最初のリクエストは失敗してもフォローアップ リクエストが成功する可能性があるため、リクエストを再試行する価値は大いにあります。ただし、Google のサーバーにリクエストを繰り返しループさせるのは重要です。このループ動作により、クライアントと Google の間のネットワークが過負荷状態になり、多くの関係者にとって問題が発生する可能性があります。
再試行の間隔を延ばして再試行することをおすすめします。通常、遅延は試行ごとに乗数係数で増加します。これは指数バックオフと呼ばれます。
たとえば、Time Zone API にこのリクエストを送信するアプリケーションについて考えてみましょう。
https://maps.googleapis.com/maps/api/timezone/json?location=39.6034810,-119.6822510×tamp=1331161200&key=YOUR_API_KEY
次の Python の例では、指数関数的バックオフを使用してリクエストを実行する方法を示しています。
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}")
また、アプリケーション呼び出しチェーンの上位にコードを再試行しないようにすると、リクエストが連続して繰り返し行われることはありません。
同期されたリクエスト
Google の API への同期リクエストは、Google のインフラストラクチャに対する分散型サービス拒否(DDoS)攻撃のように見える可能性があり、それに応じて対処します。これを回避するため、クライアント間で API リクエストが同期されないようにする必要があります。
たとえば、現在のタイムゾーンで時刻を表示するアプリケーションについて考えてみましょう。このアプリケーションでは、クライアント オペレーティング システムで毎分最初にアラームが鳴り、表示時刻を更新できるようにアラームを設定するはずです。アプリは、そのアラームに関連する処理の一環として API 呼び出しを行ってはなりません。
固定アラームに応答して API 呼び出しを行う場合、時間をかけて均等に分散されるのではなく、異なるデバイス間でも API 呼び出しが 1 分の開始時刻に同期されるため、不適切です。適切に設計されていないアプリケーションでは、毎分開始時に通常の 60 倍のトラフィックの急増が発生します。
代わりに、ランダムに選択した時刻に 2 つ目のアラームを設定することもおすすめします。この 2 番目のアラームが発生すると、アプリは必要な API を呼び出し、結果を保存します。アプリが 1 分の開始時に表示を更新する場合、API を再度呼び出すのではなく、以前に保存された結果を使用します。この方法では、API 呼び出しは時間の経過とともに均等に分散されます。さらに、API 呼び出しは、ディスプレイが更新されてもレンダリングを遅延しません。
毎分の開始時刻を除く、その他の一般的な同期時刻は正時、および毎日午前 0 時です。
レスポンスの処理
このセクションでは、これらの値をウェブサービス レスポンスから動的に抽出する方法について説明します。
Google マップのウェブサービスは、わかりやすくしていますが、正確にはユーザー フレンドリーではないレスポンスを提供します。クエリを実行する場合、一連のデータを表示するのではなく、特定の値をいくつか抽出することをおすすめします。一般に、ウェブサービスからのレスポンスを解析し、関心のある値のみを抽出します。
使用する解析スキームは、出力を XML と JSON のどちらで返すかによって異なります。JSON レスポンスは、すでに JavaScript オブジェクトの形で、クライアント上の JavaScript 自体内で処理される場合があります。XML 形式の要素は、XML プロセッサと XML クエリ言語を使用して、XML 形式内の要素に対応させる必要があります。次の例では、XML 処理ライブラリでよくサポートされている XPath を使用します。
XPath による XML の処理
XML は、データの交換に使用される比較的成熟した構造化データ形式です。JSON ほど軽量ではありませんが、XML はより多くの言語をサポートし、より堅牢なツールを提供します。たとえば、Java で XML を処理するコードは、javax.xml
パッケージに組み込まれています。
XML レスポンスを処理する場合、要素が XML マークアップ内の絶対位置にあると想定するのではなく、XML ドキュメント内のノードを選択する際に適切なクエリ言語を使用する必要があります。XPath は、XML ドキュメント内のノードと要素を一意に記述するための言語構文です。XPath 式を使用すると、XML レスポンス ドキュメント内の特定のコンテンツを識別できます。
XPath 式
XPath の使用に慣れると、堅牢な解析スキームの開発に大いに役立ちます。このセクションでは、XML ドキュメント内の要素を XPath でアドレス指定し、複数の要素を使用して複雑なクエリを作成できるようにする方法を中心に説明します。
XPath では、式を使用して、ディレクトリ パスと同様の構文を使用して、XML ドキュメント内の要素を選択します。この式は、XML ドキュメント ツリー(DOM に似た階層ツリー)内の要素を識別します。一般に、XPath 式は格差であり、指定された条件に一致するすべてのノードに一致することを示します。
以下の例では、次の抽象 XML を使用しています。
<WebServiceResponse> <status>OK</status> <result> <type>sample</type> <name>Sample XML</name> <location> <lat>37.4217550</lat> <lng>-122.0846330</lng> </location> </result> <result> <message>The secret message</message> </result> </WebServiceResponse>
式でのノード選択
XPath では、[ノード] を選択します。ルートノードにはドキュメント全体が含まれます。このノードは特別な式「/
」を使用して選択します。ルートノードは XML ドキュメントの最上位ノードではありません。実際には、このトップレベル要素の 1 つ上のレベルに位置します。
要素ノードは、XML ドキュメント ツリー内のさまざまな要素を表します。たとえば、<WebServiceResponse>
要素は、上記のサンプル サービスで返された最上位要素を表します。先頭の「/
」文字の有無で示される絶対パスまたは相対パスを使用して、個々のノードを選択します。
- 絶対パス: 式「
/WebServiceResponse/result
」は、<WebServiceResponse>
ノードの子であるすべての<result>
ノードを選択します。(これらの要素は両方ともルートノード「/
」の子孫です)。 - 現在のコンテキストからの相対パス: 式「
result
」は、現在のコンテキスト内の任意の<result>
要素と一致します。通常、ウェブサービスの結果は 1 つの式で処理されるため、コンテキストを気にする必要はありません。
どちらの式も、二重のスラッシュ(「//
」)で示されるワイルドカード パスを追加して拡張できます。このワイルドカードは、中間パスで 0 個以上の要素が一致する可能性があることを示します。たとえば、XPath 式「//formatted_address
」は、現在のドキュメントにあるその名前のすべてのノードと一致します。式 //viewport//lat
は、<viewport>
を親としてトレースできるすべての <lat>
要素と一致します。
デフォルトでは、XPath 式はすべての要素と一致します。角かっこ([]
)で囲んだ述語を指定することで、特定の要素に一致する式を制限できます。XPath 式 /GeocodeResponse/result[2]
は、常に 2 番目の結果を返します。
式のタイプ | |
---|---|
ルートノード | XPath 式:「
/ 」選択:
<WebServiceResponse> <status>OK</status> <result> <type>sample</type> <name>Sample XML</name> <location> <lat>37.4217550</lat> <lng>-122.0846330</lng> </location> </result> <result> <message>The secret message</message> </result> </WebServiceResponse> |
絶対パス | XPath 式:「
/WebServiceResponse/result 」選択:
<result> <type>sample</type> <name>Sample XML</name> <location> <lat>37.4217550</lat> <lng>-122.0846330</lng> </location> </result> <result> <message>The secret message</message> </result> |
ワイルドカード付きパス | XPath 式:「
/WebServiceResponse//location 」選択:
<location> <lat>37.4217550</lat> <lng>-122.0846330</lng> </location> |
述語付きパス | XPath 式:「
/WebServiceResponse/result[2]/message 」選択:
<message>The secret message</message> |
最初の result のすべての子 |
XPath 式:「
/WebServiceResponse/result[1]/* 」選択:
<type>sample</type> <name>Sample XML</name> <location> <lat>37.4217550</lat> <lng>-122.0846330</lng> </location> |
type テキストが「サンプル」である result の name 。 |
XPath 式:「
/WebServiceResponse/result[type/text()='sample']/name 」選択:
Sample XML |
要素を選択する際は、オブジェクト内のテキストだけでなく、ノードも選択する点に注意することが重要です。一般に、一致するすべてのノードを反復処理し、テキストを抽出します。テキストノードを直接照合することもできます。後述のテキストノード をご覧ください。
XPath では属性ノードもサポートされますが、Google マップ ウェブサービスはすべて属性なしで要素を提供するため、属性の照合は必要ありません。
式でのテキスト選択
XML ドキュメント内のテキストは、テキストノード演算子を使用して XPath 式で指定されます。この演算子「text()
」は、指定されたノードからのテキストの抽出を示します。たとえば、XPath 式「//formatted_address/text()
」は、<formatted_address>
要素内のすべてのテキストを返します。
式のタイプ | |
---|---|
すべてのテキストノード(空白を含む) | XPath 式:「
//text() 」選択:
sample Sample XML 37.4217550 -122.0846330 The secret message |
テキストの選択 | XPath 式:「
/WebServiceRequest/result[2]/message/text() 」選択:
The secret message |
コンテキスト依存の選択 | XPath 式:「
/WebServiceRequest/result[type/text() = 'sample']/name/text() 」選択:
Sample XML |
また、式を評価して一連のノードを返した後、その「ノードセット」に対して反復処理を行い、各ノードからテキストを抽出することもできます。次の例でこの方法を使用します。
XPath の詳細については、XPath W3C 仕様をご覧ください。
Java での XPath の評価
Java では、XML の解析と、javax.xml.xpath.*
パッケージ内の XPath 式の使用が広くサポートされています。そのため、このセクションのサンプルコードでは、XML の処理方法と、XML サービス レスポンスからのデータの解析方法を示します。
Java コードで XPath を使用するには、まず XPathFactory
のインスタンスをインスタンス化し、そのファクトリで newXPath()
を呼び出して XPath
オブジェクトを作成する必要があります。このオブジェクトでは、渡された evaluate()
メソッドを使用して、渡された XML および XPath 式を処理できます。
XPath 式を評価する場合は、返される可能性のある「ノードセット」を反復処理してください。この結果は Java コードで DOM ノードとして返されるため、NodeList
オブジェクト内でこのような複数の値をキャプチャし、そのオブジェクトを反復処理して、これらのノードからテキストまたは値を抽出する必要があります。
次のコードは、XPath
オブジェクトを作成して XML と XPath 式を代入し、式を評価して関連コンテンツを出力する方法を示しています。
import org.xml.sax.InputSource; import org.w3c.dom.*; import javax.xml.xpath.*; import java.io.*; public class SimpleParser { public static void main(String[] args) throws IOException { XPathFactory factory = XPathFactory.newInstance(); XPath xpath = factory.newXPath(); try { System.out.print("Web Service Parser 1.0\n"); // In practice, you'd retrieve your XML via an HTTP request. // Here we simply access an existing file. File xmlFile = new File("XML_FILE"); // The xpath evaluator requires the XML be in the format of an InputSource InputSource inputXml = new InputSource(new FileInputStream(xmlFile)); // Because the evaluator may return multiple entries, we specify that the expression // return a NODESET and place the result in a NodeList. NodeList nodes = (NodeList) xpath.evaluate("XPATH_EXPRESSION", inputXml, XPathConstants.NODESET); // We can then iterate over the NodeList and extract the content via getTextContent(). // NOTE: this will only return text for element nodes at the returned context. for (int i = 0, n = nodes.getLength(); i < n; i++) { String nodeString = nodes.item(i).getTextContent(); System.out.print(nodeString); System.out.print("\n"); } } catch (XPathExpressionException ex) { System.out.print("XPath Error"); } catch (FileNotFoundException ex) { System.out.print("File Error"); } } }