이전 게시글과 함께 WWDC에서 소개한 MusicKit 관련 영상에 대한 글을 작성해보겠습니다.
이 세션에서는 API의 검색 기능 개선 사항과 리소스 연관, 속성 확장, 응답에서 리소스에 대한 관계 뷰 요청을 통해 데이터를 요청하는 새로운 방법에 대해 살펴봅니다. 마지막으로 차트 API의 몇 가지 새로운 개선 사항에 대해 살펴보겠습니다.
Search enhancements
몇 가지 검색 개선 사항을 살펴보기 전에 현재의 /search/hints 엔드포인트를 간략히 요약해 보겠습니다. 이미 이 엔드포인트를 사용해 추천 검색어 목록을 가져오고 계실 수도 있습니다. 예를 들어, 다음은 taylor라는 검색어에 대해 얻을 수 있는 몇 가지 결과입니다.
오늘은 /search/hints 엔드포인트를 대체하는 /search/suggestions 엔드포인트를 소개합니다. 이 엔드포인트는 /search/hints 엔드포인트와 동일한 용어에 대한 액세스를 제공하며, 요청에 kinds=terms를 지정하여 이러한 용어를 계속 가져올 수 있습니다.
그러나 이 엔드포인트의 응답이 약간 다르다는 것을 알 수 있습니다. 이제 제안된 결과는 요청에 지정된 종류 중 하나와 일치하는 종류를 표시합니다. 또한 검색 쿼리에 사용되어야 하는 용어와 사용자에게 표시되어야 하는 용어를 구분합니다.
더 중요한 것은 이제 이 엔드포인트에서 상위 추천 검색 결과에 대한 액세스도 허용한다는 점으로, 자동 완성 기능을 강화하는 데 이상적입니다. 이러한 검색 결과는 요청에 kinds=topResults 를 지정하여 요청할 수 있으며, 결과를 가져오고자 하는 일부 리소스 유형도 지정할 수 있습니다.
topResults 종류에 대한 리소스는 콘텐츠 키 아래에서 찾을 수 있습니다. 이 엔드포인트에서 얻을 수 있는 결과는 폭보다는 속도를 우선시하므로 일반 검색에서 얻을 수 있는 결과와 눈에 띄게 다를 수 있다는 점에 유의할 필요가 있습니다. 따라서 이 엔드포인트는 일반 /search 엔드포인트를 대체하기 위한 것이 아니라 이를 보완하기 위한 것입니다.
Relating resouces
리소스를 수정하는 방법을 살펴보기 전에 리소스가 무엇인지 잘 모르시는 분들을 위해 다시 한 번 소개해 드리고자 합니다. 모든 리소스에는 API에서 리소스를 조회하기 위해 필요한 최소한의 정보인 resource identifiler 라는 것이 있습니다. 리소스 식별자에는 리소스의 id, type, href가 포함됩니다. 리소스의 전체 표현에는 이름과 같은 리소스의 attributes와 포함 매개변수를 사용하여 요청된 경우 잠재적으로 relationships도 포함됩니다. 관계는 노래의 장르나 재생 목록의 트랙과 같은 관련 리소스의 모음입니다.
이제 연관 리소스의 개념을 소개하겠습니다. 관련으로 요청된 관계는 해당 관계에 있는 리소스에 대해 앞서 언급한 리소스 식별자만 반환한다는 점에서 포함으로 요청된 관계와 다릅니다.
즉, 리소스의 참조만 액세스해야 하는 경우 관계를 연관시키면 더 빠른 응답을 얻을 수 있습니다.
relate 쿼리 매개변수를 사용하고 대상 resourceType으로 관계를 분류한 다음 반환하려는 관계 이름 목록을 지정하여 관계를 연관시킬 수 있습니다.
예를 들어 /search/suggestions 엔드포인트에서 사용자가 노래 결과를 선택하면 해당 노래의 앨범 페이지로 이동하고 싶다고 결정할 수 있습니다. 이 경우 해당 노래의 앨범에 대한 href만 있으면 해당 페이지로 이동할 수 있으므로 relat[songs]e=albums 을 지정하여 해당 데이터를 가져올 수 있습니다.
이렇게 하면 이제 응답의 노래 결과에 해당 앨범의 리소스 식별자가 포함된 것을 볼 수 있습니다.
따라서 관련 콘텐츠를 추가로 빠르게 참조하고 싶을 때 relate를 사용하면 좋지만 이미 응답에서 반환된 리소스에 대해 자세히 알고 싶다면 어떻게 해야 할까요?
Extending attributes
앞서 언급했듯이 오늘날 모든 리소스에는 이름, 아트웍 등과 같은 기본 속성 집합이 있습니다. 하지만 리소스에는 확장 속성이 있을 수도 있습니다.
확장 속성은 계산 비용이 더 많이 들거나 필요 빈도가 낮기 때문에 기본적으로 포함하면 응답 속도가 눈에 띄게 느려지거나 개체 모델이 부풀어 오를 수 있습니다.
방금 관련 쿼리 매개변수에서 살펴본 것과 유사하게, 확장 쿼리 매개변수를 사용하여 resourceType으로 분류하고 그 뒤에 관심 있는 attributeName 목록을 추가하여 리소스에 대한 확장 속성을 요청할 수 있습니다.
/suggestinos 요청을 기반으로 노래 결과에 대해 사용자가 Apple 음악에서 해당 아티스트의 페이지로 연결할 수 있는 기능도 허용하고 싶다고 결정할 수 있습니다. 이렇게 하려면 요청에 extend[songs]=artistUrl을 추가하기만 하면 됩니다.
실제로 이 작업을 수행한 후 응답의 노래 리소스에 artistUrl 속성이 포함된 것을 볼 수 있습니다.
Using relationship views
이제 관계 보기의 개념을 소개하겠습니다.
관계에 비해 뷰는 리소스와 더 느슨하게 연결되어 있습니다. 뷰는 관계처럼 리소스에 대한 어떤 근거가 되는 진실을 나타내는 것은 아닙니다.
따라서 뷰는 앨범 페이지와 같은 제품 페이지 경험을 유도하는 데 이상적입니다.
예를 들어 검색 결과 페이지에서 사용하기에 유용한 관계와 비교해 보세요. 또한 보기에는 데이터뿐만 아니라 제목과 같은 속성이 포함될 수 있습니다.
또한 뷰는 직접 리소스 가져오기에서만 요청할 수 있습니다.
즉, 보기를 가져오는 방법에는 두 가지가 있습니다. 조회 쿼리 매개변수를 사용하여 목록을 지정하거나, 요청 경로에서 리소스 ID 바로 뒤에 /view/{viewName}을 통해 단일 항목을 지정할 수 있습니다.
이 응답에는 아티스트 리소스에 인기곡 보기를 포함시키는 예가 나와 있습니다. 다른 예로는 인기 뮤직 비디오 또는 아티스트의 싱글이 있습니다. 물론 특정 리소스 유형에 대해 지원되는 보기의 전체 목록은 공식 Apple 음악 API 문서에서 확인할 수 있습니다.
Storefront and city charts
마지막으로 차트 API의 업데이트에 대해 살펴보겠습니다. 현재 Apple 음악은 전 세계, 스토어, 그리고 최근에는 특정 도시에 대한 차트 재생 목록을 지원합니다.
사용자는 이러한 차트 재생 목록을 라이브러리에 추가하면 자동으로 업데이트됩니다. 이제 /charts 엔드포인트에서 type=playlists를 지정하고 with 쿼리 매개변수를 사용하여 원하는 세트(dailyGlobalTopCharts, cityCharts 또는 둘 다)를 지정하여 직접 가져올 수 있습니다.
여기에는 이러한 쿼리 매개변수를 사용한 차트의 응답이 어떻게 표시되는지 보여주는 예가 있습니다.
마무리
이 글을 작성하면서 정리글보다는 번역본에 가까운 형태가 되었습니다. 저처럼, 아직 한글 자막이 없는 영상을 이해하기 어려운 분들에게 도움이 되길 바랍니다.
조금 더 자연스럽게 표현할 수 있는 부분이 있으면 댓글로 남겨주세요!!
