Apple Music APIのカタログの詳細

♪ (Apple Music APIのカタログの詳細)

こんにちは WWDC 2021へようこそ 私はGraham Seyffert MusicKitのエンジニアです ここ何年かをかけて Apple Musicカタログ から新たに充実した データをフェッチできるよう デベロッパ向け機能を強化してきました 本日はそういった改善点を ご紹介したいと思います このプレゼンでは APIの検索機能の強化や リソースの関連付け 属性の拡張 リレーションシップビューの リクエストなど データを要求する 新しい方法について ご説明いたします 最後にCharts APIの 新しい機能拡張を見ていきます 検索機能の改善に触れる前に 現在の/search/hintsエンドポイント について簡単に振り返って みたいと思います 皆さんは検索語句の候補 リストをフェッチする際に すでにこのエンドポイントを お使いかもしれませんね たとえば「taylor」という 検索語で検索すると 結果はこんなふうに なります 本日ご紹介する /search/suggestionsは /search/hintsに 代わるものです このエンドポイントでは /search/hintsの場合と同じ 語句にアクセスでき リクエストにkinds=terms を指定することで 引き続きフェッチできます ただし ご覧のように このエンドポイントからの 応答は少し異なります 結果には候補の種類が 表示され リクエストで指定した種類の いずれかに一致します また 検索クエリに 使用すべき語句と ユーザーに表示すべき 語句が区別されます さらに重要なのは このエンドポイントでは 検索結果の上位候補にも アクセスできることです 先行入力結果の強化に 最適です これらはリクエストに kinds=topResults を指定すればリクエストでき 結果をフェッチしたい リソースタイプも指定できます topResultsのリソースは contentキーの下にあります 注目していただきたいのは このエンドポイントから 得られる結果は 通常の検索で得られる 結果とは大幅に 異なり得るということです なので これは通常の /searchエンドポイントの 代わりではなく むしろそれを補完する ものと言えます リソースの変更方法を 説明する前に 馴染みの薄い方々のために リソースとは何か 改めてご紹介いたします すべてのリソースには 「リソース識別子」が 割り当てられており これはAPIでリソースを 検索する際に必要な 最小限の情報です リソース識別子には リソースID そのタイプおよびその hrefが含まれます リソースの完全な表現には リソース名などの属性や includeパラメータで要求 された場合は リレーションシップも 含まれます リレーションシップとは 曲のジャンルやプレイリストの トラックなど関連するリソース の集まりのことです ここで リソースを関連付けるという 概念を紹介したいと思います relateで要求される リレーションシップは includeで要求される リレーションシップと異なり その関係にある リソースについて 前述のリソース識別子 のみを返します つまり リソースの参照への アクセスのみが必要な場合 リレーションシップを 関連付けることで より迅速な応答が可能 になります リレーションシップを 関連付けるには relateクエリパラメータを使用し 対象となるリソースタイプで分類し 取得したい リレーション名を列記します たとえば /search /suggestions エンドポイントの場合 ユーザーが曲の結果を選択した 時点でその曲が入っている アルバムページを 表示させたいとします この場合 その曲が入っている アルバムに移動するために 必要なのは そのアルバムの hrefのみなので relate=albums を指定すれば そのデータを取得できます その後で 応答内の曲の結果に それぞれのアルバムの リソース識別子が 含まれていることがわかります したがって relateは 追加の関連コンテンツを すばやく参照したい場合に 便利ですが 応答ですでに取得している リソースについて 詳しく知りたい場合は どうすればよいでしょうか 前に述べたように 今やどのリソースも デフォルトの 属性セットを持っています 名前やアートワーク などです しかしリソースには 拡張属性もあります 拡張属性は計算コストが高いか 利用頻度が低いため デフォルトで含めると 応答が著しく遅くなったり オブジェクトモデルが肥大化 する恐れがあります 先ほどご覧いただいた relateクエリパラメータと同様 extendクエリパラメータを使って リソースの拡張属性を リクエストするには リソースタイプで分類し それに続けて関心のある 属性名のリストを指定します /suggestions リクエストに 基づいて 曲の結果について ユーザがApple Musicの そのアーティストの ページにリンクできるように もできます そのためには リクエストに extend=artistUrl を追加します 実際 そうすると 応答内の曲リソースに artistUrl属性が付いた ことがわかります では リレーションシップビュー の概念をご紹介します リレーションシップに比べると ビューはリソースと 緩い結合になっています リレーションシップのように リソースに関する 真実を表すとは限りません そういった点でビューは アルバムページなど プロダクトページでの 体験の促進に向いています リレーションシップの方は たとえば 検索結果ページで役立つ ことがあるわけです ビューはデータに加え タイトルなどの属性も 持つことがあります ビューも直接的なリソースフェッチ でのみリクエスト可能です つまり2通りの フェッチ方法が あるということです viewsクエリパラメータで リストを指定するか またはリクエストパスの リソースのIDの直後に /view/{viewName} で 単一のものを指定できます 今回の応答では アーティストリソースに ランキング上位の曲ビューを 含める場合の例を ご紹介します 他の例としてはランキング上位 のミュージックビデオや アーティストのシングル などがあります リソースタイプ別に サポートされているビューの 詳細な一覧はもちろん Apple Music APIの ドキュメントで確認できます 最後に 最新のCharts API 見てみましょう 現在 Apple Musicは世界や ストアフロントごと そして最近では 特定の都市のチャートプレイリストを サポートしています ユーザーはチャートプレイリストを 自分のライブラリに追加でき 追加したリストは 自動的に更新されます types=playlistsを指定し "with"クエリパラメータを使用して dailyGlobalTopChartsか cityCharts または その両方のうちどのセットが 欲しいか指定することで これらを /chartsエンドポイントから 直接フェッチできるようになりました そしてこれらのクエリ パラメータを使った チャート応答の例を 示します 以上 本日は検索と チャートのエンドポイントの 機能拡張と 応答内で リソースのデータを フェッチする新しい方法 について説明しました Apple Music APIについて さらに詳しく知りたい方には 今年のセッション 「Apple Music APIによる コンテンツの相互参照」と APIのコアコンセプトを 詳しく説明している 2017年のビデオ「Introducing MusicKit presentation」 をぜひお勧めします ご視聴ありがとうございました 今年のWWDCをお楽しみ いただければ幸いです ♪