원래 계획은이를 Spotify Metadata API의 비효율적 인 제목 인 블로그 게시물로 작성하거나 Jackson 5가 내 브라우저를 어떻게 죽였는지를 마지막으로 생각을 바꾸 었습니다 설명서에 분명한 내용을 놓치고있는 습관이 있기 때문에 필자가 놓친 문서화되지 않은 기능이 있거나 다른 사람이 문제를 해결 한 것일 수 있습니다. 따라서이 질문에 대해서는 블로그 포스트가 있습니다.Spotify Metadata API : 아티스트 검색
대부분 소규모 그룹을 대상으로하는 작은 웹 앱을 개발 중이며 누구나 Spotify 재생 목록을 업데이트 할 수 있습니다. 모든 사람들이 Spotify를 사용하고있는 것은 아니지만 (이유는 모르겠지만), 내 랩톱에서 Spotify로 실행중인 앱이 데이터베이스를 폴링하여 Spotify Apps API를 사용하고 재생 목록이 업데이트됨에 따라 페이지가 노래로 데이터베이스를 업데이트합니다. , 재생 목록에 가입 한 사람은 업데이트를받습니다. 설문 조사보다는 푸시를 사용하고 싶지만 괜찮습니다.하지만 다른 날의 주제입니다.
Spotify Metadata API와 함께 사용할 Javascript 라이브러리를 검색했으며 기본적으로 래퍼 였지만 여전히 JSON을 직접 구문 분석해야했지만 하나 (https://github.com/palmerj3/SpotifyJS)를 발견했습니다. 내가 가장 잘 나가고 가장 일반적인 필드 (제목, 아티스트, 앨범, Spotify URI)에 대한 기본 구문 분석을 추가 할 수 있다고 생각했습니다. 내 자신의 라이브러리/JQuery 플러그인 작업을 시작했습니다.
트랙 검색은 spotify 메타 데이터 API에 대한 단일 호출이며, 결과는 쉽게 파싱됩니다. 반환 된 아티스트와 요청 아티스트 (있는 경우)가 일치하면 제목/아티스트별로 쉽게 검색 할 수 있습니다.
아티스트 (모든 아티스트의 모든 노래 목록 가져 오기)로 검색하면 pain-in-the-* * 인 것처럼 보입니다! 문서에서 알 수있는 최선의 방법은 프로세스입니다. 작가에 대한
- 검색 :이, 각 아티스트에 대한 쿼리
- 일치하는 아티스트의 목록을 반환 자신의 앨범을 조회합니다 :이 목록 앨범
- 조회 각 앨범을 반환하고 트랙 목록을 검색합니다 이 출력을 일치하면
- 는 검색 아티스트와 트랙마다 아티스트 비교
, 푸 전투기 아티스트 일치 작은 목록을 반환하는 첫 번째 단계는, 2 갖는다 실버 체어 1 및 잭슨 5 갖는다 4.이 작은 목록은 더 많은 앨범 일치로 바뀝니다. 메모리에서 Foo Fighters는 112를 돌려주었습니다. 그런 다음 더 많은 수의 트랙 목록으로 바뀝니다. Javascript/JQuery의 관점에서 볼 때, 이것은 각 단계마다 데이지 체인 방식의 AJAX 요청과 Spotify 서버에 대한 거의 동시적인 GET 요청의 각 단계에서 발생합니다.
동기식 AJAX를 사용하고 동기식 AJAX를 사용하여 작성한 초기 버전은 다음 요청이 완료되기 전에 각 요청이 완료 되어야만 정상적으로 작동하지만 브라우저가 잠시 동안 잠기고 피드백을 사용할 가능성이 없어졌습니다. 시스템이 실행중인 사용자. 그런 다음 비동기 요청으로 전환하고 모든 지옥이 느슨해졌습니다! 당신은 즉각적으로 Spotify 끝의 속도 제한에 관한 문제를 쳤습니다. 502 게이트웨이를 가진 resoponses (상태에 따라 spotify 문서에 나열되지 않음) 또는 503 - JQuery가 상태 코드 0으로 해석 한 - 흥미로운 Firebug에서 디버깅이 필요합니다. 클라이언트 측에서 요청을 줄였습니다. 속도가 느려지는 것을 방지하고 매번 데이터가 포함 된 응답을받을 수 있도록 매초 1 초가 적당하다는 것을 알았지 만, 브라우저에서 방대한 양의 잠금을 발생시킵니다. 30 또는 40 GET 요청을 동시에 처리 할 수 있습니다. 일부 요청은 15 초 이상 응답하지만 모든 JSON 응답을 파싱합니다.
서버 측 접근법을 사용하여로드를 완화하는 방법을 살펴 보았습니다. 여기에는 다음과 같은 단점도 있습니다. 1. API가 효율적인 방식으로 태스크를 처리 할 수 없다는 기본 문제를 피하지 마십시오. 2. 사용량이 많은 사이트의 경우 대역폭 사용량이 서버에 대한 것이므로 하나의 IP가 제공됩니다. 여러 사용자의 경우 평행 사용자로 인해 속도 제한에 곧 도달합니다.
서버 측에서는 캐싱을 제공하지만 이 목적을 달성하기 위해 PHP 라이브러리 - metatune (https://github.com/mikaelbr/metatune)이 "Spotify Metadata API를위한 최고의 PHP 래퍼"라고 광고했지만, 유감스럽게도 Spotify Metadata API와 동일한 기본 조회/검색 만 제공합니다. 예 : 아티스트의 모든 노래 목록 없음.
따라서 적합한 솔루션을 찾을 때까지 아티스트별로 검색을 중지했습니다.
Spotify 서버에 많은 요청을 할 것을 권장하기 때문에 나는 적어도 뭔가 놓치지 않았다고 가정하면, 적어도 효율적인 API 디자인이 아닌 것처럼 보입니다. 제게는 좋지 않습니다. 클라이언트로, Spotify가 서버로 적합하지 않습니다. 다음 문제를
을 추적 =
ws.spotify.com/search/1/artist.json?q=foo+fighters & 엑스트라 : 나는 도움이되지만 요청 등이 있다면 생각하지 수 단일 요청은 현재 3 세트의 다중 요청을 요구하는 것을 커버 할 것입니다; 속도 제한은 큰 문제가되지 않을 것입니다. 클라이언트에서 데이터를 처리하는 오버 헤드가 크게 줄어 듭니다. 처리 할 Spotify의 오버 헤드가 줄어들고 전체 서비스가 더 효율적으로됩니다. API가 이미 데이터를 "페이지"로 분할하기 때문에 요청이 매우 큰 데이터 세트를 반환한다는 사실은 문제가 아닙니다.
그래서 내 군중에 대한 질문 : 1. 설명서에서 분명한 내용을 놓쳤습니까? 아니면 비밀 요청이 있습니까? 2. API 요청이 없으면 내 시스템을보다 효율적으로 만드는 방법에 대한 제안이있는 사람이 있습니까? 3. 이전에이 문제를 해결 한 사람이 있습니까?
읽어 주셔서 감사합니다. 질문을하기까지는 오랜 시간이 걸렸지 만, 가장 좋은 해결책을 찾기 위해 충분한 추론을 제공해야한다고 생각했으며, API의 결함을 보여주었습니다. Spotify의 누군가가 알아 차리기를 바랍니다.
마지막으로, 이와 같은 프로젝트를 통해 Flash를 Javascript로 바꾼 것처럼 느껴지 긴하지만 성능은 여전히 저조합니다! 다른 사람도 같은 느낌입니까?
건배! sockThief
은 더 밝습니다! 왜 메타 데이터 api 문서에 나와 있지 않은가? –
모두에게 Spotify 직원 1. 지난 며칠 동안 내 요청으로 서버에 DOS를 시도하는 것을 유감스럽게 생각합니다. 2. 개발자 문서를 업데이트하십시오! –
문서는 Wayback Machine을 통해 연결해야한다는 사실에서 알 수 있듯이 현재 다소 부족합니다. 우리는 문서를 긁어 모으기 위해 노력하고 있습니다! – iKenndac