Apple Maps Server APIの紹介

♪ 穏やかな音楽 ヒップホップミュージック♪ ♪ こんにちは 私はAnkur Soniと申します ここAppleの Maps Servicesチームで エンジニアの マネージャーをしています 本日は Mapsのデベロッパ エコシステムに搭載される 興味深い 新機能をご紹介します では 始めましょう 当社のマップAppは 世界中のAppleのお客様に さまざまなユーザー 体験を提供しています MapKitと MapKit JSの提供により デベロッパは Appやウェブサイトで 美しいジオロケーション 体験を実現できます 当社のAppleマップの デベロッパ向けサービスは 常にクライアント志向で 提供していますが 私たちは 皆さまの貴重なご意見を すべて注意深く確認しています 性能やパワーを損ねることなく MapKit上で独自のデータを 補強する方法が知りたい という意見がありました そこで 当社のエコシステムを 完成させるために Apple Maps Server APIを 導入することにしました Geocoding Reverse Geocoding ／Search ETA （Estimated Time of Arrival）の 4つの新しいサーバーAPI を導入します これらのAPIは Appに マップを統合した際の さまざまなユースケースに 役立ちます Geocoding APIを 使用すると住所を 地理座標の緯度と 経度に変換できます 同様に Reverse Geocodingでは 地理座標から住所への 変換を行うことができます Search APIを使うとユーザーは 検索文字列を入力して 会社の所在地や 見どころ情報などの 場所を見つけることが できます データを独自に オーバーレイして ユーザーに見せたいと 思うことがあるかもしれません ETA APIを介して 顧客が会社の所在地から どのくらい離れているのか を把握したり 最寄りの店舗を 調べることができます 可能性は無限にあります 3つの重要な理由からサーバーAPIを 気に入っていただけると思っております MapKit／MapKit JS／新しい Apple Maps Server APIを活用することで シームレスな体験を 提供できるようになります これらはAppの アーキテクチャを簡素化し Appleマップの フルスタックを提供します これは人生を より楽にしてくれます 本当にこれは役立っています 私が言っても 偏った意見 だと思われるかもしれませんね 他の利点としては ネットワークの呼び出し数を削減します iPhoneやiPad ウェブサイトなど ユーザーのデバイスから 繰り返し冗長な リクエストをされる状況 になることがよくあります さまざまなユーザーのデバイスで 実行されているAppから 同じアドレスを何度も 検索している可能性があります これにより ネットワークの呼び出しが 多くなり 帯域が無駄になります この一般的な操作を サーバーに委任し サーバーAPIを使って バックエンドで1度だけ行うことで Appが消費する 帯域幅を少なくすることができます Apple Maps Server APIを使用して 一部の処理をサーバーに 委任するため Appの電力効率も向上します では これらのAPIを いくつか使ってみましょう 例えば 店舗検索App用に このような連絡先カードを 構築するとします ここには 3つの店舗の住所と 顧客の現在地からの 距離が表示されています この例では お客様が位置情報を 提供した場合を 想定しています では これらの連絡先カードの 1つを構築していきます これらの住所が コミック書店の所在地を 保存および提供する サーバー上にあると仮定します これを構築する方法は たくさんありますが 例えば これらの新しいサーバー APIがないと仮定してみます 基本的なアーキテクチャは どのようなものになるでしょうか クライアントAppは どのようにこのデータを取得しますか この図では Appが サーバーを呼び出し 店舗所在地リストを 取得しています バックエンドサーバーは 店舗所在地リストを クライアントデバイスに 返します この例では サーバーAPIがないため クライアントAppは 所在地に対して様々なアクションを行い 連絡先カードを構築する 必要があります 1つのタスクを 実行するために クライアントは様々な バックエンドサービスを 複数回呼び出す 必要があるかもしれません ここでは クライアントAppが MapKitまたは MapKit JSを使って Apple Maps Serverを 直接呼び出しています クライアントとバックエンド間の このようなやり取りは Appのパフォーマンスおよび スケールに悪影響を 与える可能性があります 一般的に高いレイテンシの 携帯電話ネットワークでは このように個々のリクエストを 使用することは非効率であり 接続が切れたり リクエストが 不完全になったりする 可能性があります 各リクエストは並行して 実行されるかもしれませんが 失敗する可能性が 高くなります Appは各リクエストのデータを 別々の接続で 送信／待機／処理する必要があり クライアントですべてのレスポンスを マージする必要があります これらの呼び出しが 生じた際 ユーザーに対して スピナーを表示することになります クライアントのデバイスは これらの呼び出しのために より多くの帯域幅と 電力を使用します それではユーザー体験として 適切ではありません では Apple Maps Serverの APIにアクセスする モデルアーキテクチャ を見てみましょう クライアントとサービス間の やり取りを減らすために バックエンドサーバーをゲートウェイとして 活用することができます 前回と同様に ここではクライアントから 表示する店舗の リストをリクエストします 次に サーバーからジオコーディングを 行うためのリクエストを行います そして Apple Maps Serverから 各APIのレスポンスを 受信します コミック本のサーバーは 各サービスからの レスポンスを組み合わせて Appに送信します このパターンの場合 Appが バックエンドサービスに行う リクエストの数を減らし 高レイテンシの ネットワーク上で Appのパフォーマンスを 向上させることができます 要約すると クライアントはサーバーに 1度だ呼び出すだけで 店舗リストを取得できす その後 サーバーが適切な APIの呼び出しを行い ユーザーに最適な レスポンスを作成します ここで ケーススタディに戻りましょう GeocodingとETA APIを使って 店舗までの距離を取得します Geocode APIを使って 店舗の住所の緯度と 経度を求め 後ほどETAの 算出に利用します この例では 最初に コミック書店の住所を取り出し URLをエンコードします 次に Geocode APIを使って このURLがエンコードされた 住所をクエリパラメータ として渡します 認証の詳細については 今回は省略し 後ほど振り返ることにします レスポンスには 返された住所の 緯度および経度が 表示されています 同じ処理を繰り返して 顧客の住所の緯度および 経度を探します これは後ほど ETAの算出に使われます ご覧のように レスポンスの フィールドがさらにあります 以下のResources セクションに 詳細なドキュメントを リンクします ここで Geocode APIで 取得したデータを用いて ETA APIで出発地と 目的地を設定します 先ほど述べたように 出発地の緯度および経度 目的地の緯度および 経度があります 必要に応じて ここでは最大10件まで 目的地を指定することができます それをETA APIに URLをエンコードした 送信元と送信先の クエリパラメータとして フィードします APIへのレスポンスは 提供された目的地ごとに 1つのETAの リストとなります この場合 宛先は1つのため 1つしかありません この例では 店舗までの 距離を算出するために distanceMetersが 有効でしょう これを使うと 店舗所在地と ユーザーが店舗に たどり着くまでの 距離という 必要な情報を 得ることができます また このデータに営業時間など 独自の店舗情報を追加したり オーバーレイすることも可能です このように 異なる サーバーAPIを活用して Appを構築することができます 他のAPIについては このトークの下に リンクされているドキュメントを ご覧ください ここで重要なのが 認証についてです すべてのApple Maps Server APIは 認証されています MapKit JSを 使用する場合は すでにその半分まできています Apple Maps Server APIは MapKit JSと 同じ仕組みで 認証を行っています まずは デベロッパアカウントから 秘密鍵をダウンロードします この秘密鍵を使って JWT形式のMaps認証トークンを 生成します 生成方法については 以下のリンクに 詳細なドキュメント があります このMaps認証トークンを トークンAPIで交換することで Mapsアクセストークンを 取得することができます バックエンドでMaps認証トークンを認証し Mapsのアクセストークンを 送り返します これはJWT形式であり すべてのAPIインタラクションで 使用されます このアクセストークンは 30分ごとに更新する必要があり ここで重要な 処理を繰り返します 認証の流れを見てきましたが ここでは トークンAPIを使って アクセストークンを 取得する簡単な 例を紹介します ここでトークン APIを 使用します Maps認証トークンをヘッダとして 渡します APIにアクセスする ために使用する Mapsアクセストークンが 返ってきます これはJWT形式で expiry／issuedAtなどの 標準フィールドを 持つことになります expiresInSecondsフィールドは 便利なことに トークンがどのくらいの 期間有効であるかを示します この場合 30分です Maps認証トークンは Mapsのアクセストークンと 同じではないことに 注意してください Maps認証トークンを 交換して サーバーAPIに アクセスするための 30分間のMapsアクセストークンを 取得します Mapsアクセストークンを使った APIインタラクションが どのように見えるか 簡単に見ていきます サーバーAPIの呼び出しと一緒に Mapsアクセストークンを渡します これは 以前のスライドで 見たのと同じように APIの呼び出しのヘッダとして 追加されます Apple Maps Serverは Mapsアクセストークンを検証します 検証が成功すると Apple Maps Serverは APIレスポンスで応答します APIと認証について 説明してきましたが 次に使用制限について 説明します 大きなパワーには 大きな責任が伴うため 考えながら割当を 活用してください 1日のAPIの呼び出し回数の 上限が決まっており それは大きなものです 1日合計25,000件のサービス呼び出し が割り当てられます MapKit JS経由の サービス呼び出しと サーバーAPIは同じ割当を使用することに 注意してください もっと必要な場合は お問い合わせください では どのようにして このすべてを記録しますか Mapsのデベロッパダッシュボードで 利用状況を確認できます MapKit JSを 使用したことがあれば これには非常に 親しみがあるかと思います サーバーAPIの使用は Serviceに分類され ここに強調されている ことがわかります 1日の割当を超えた場合 （サーバーAPIの呼び出しが 25,000回を超えた場合） 新しいサービスの呼び出しを 拒否するようになり リクエストが多い事を 意味する HTTPステータス429を リスポンスします このようなシナリオでは Appの体験が ゆっくりと低下することを 認識する必要があります まれにあるシナリオで サービスが異常な量の リクエストをした際の コードやインフラのバグが 原因かもしれません この場合も HTTPステータス429が 発生する可能性があります HTTP 429を受け取ったら リクエストを ループさせないことが重要です より良いアプローチ方法は 試行間の遅延を増やして 再試行することです このアプローチ方法は 指数関数的 バックオフとして知られています 本日何を学びましたか ４つの新しいサーバーAPIを リリースしました Geocoding Reverse Geocoding Search／ETAです これらのAPIをMapKitや MapKit JSと組み合わせて使うことで Apple Mapsスタックを使った Appをより良く 構築することができます Apple Maps Server APIを使用して これらのタスクを バックエンドサーバーに委任することで 冗長で繰り返しの多い呼び出しを 最適化することができます これらのAPIの1日の 使用量の上限は25,000であり MapKit JSサービスの使用量と共有されます これが新しいApple Maps Server APIとなります ここで説明した 他のセッションや 下記のリンク先にある 詳細ドキュメントをご覧ください 皆さまがどのように活用されるか 楽しみにしています ありがとうございます! ♪