Spotify的API簡單分為兩個入口：
其中所有的授權相關驗證都通過 授權入口 進行，而所有正常獲取數據的API請求都從 API入口 進行。
參考官網：Authorization Guide
參考官方Github Issues：Getting higher usage rate limits
其中只說了不同請求方式的限制次數有不同，但是沒寫具體有多少：
參考另壹篇官網文檔： /web-api/user-guide/
"Rate limiting is applied on an application basis (based on client id), regardless of how many users are using it."
即無關多少個用戶，限制次數只是和每個app掛鉤的。
前往Spotify開發者網址： /dashboard
登錄後點擊 create a client id ，生成壹個專用的 client_id 和 client_secret 。
同時必須認真設置 Redirect URIs ，因為日後授權驗證時要完全匹配才行。
在進行授權申請之前，要先確定這個app需要哪些權限，確定好了再到授權過程中通過參數進行聲明。
Spotify對權限進行了詳細的分類，全部的權限如下：
參考官方：Authorization Scopes
在之後我們對 /authorize 頁面進行GET申請授權時候，需要在URL裏加入 scope 參數，裏面的值就是我們所選擇的壹些權限申請。
每條權限名用 空格分開
只讀型 的常用權限有：
修改型 的常用權限有：
全部組合起來的請求URL是這樣的：
授權的最終目的是獲取壹個名為 access_token 的值，然後用這個 access_token 去獲取各種個樣的API信息。
參考官方：Authorization Guide
Spotify為了嚴格區分不同的用途和權限，把這個 access_token 的獲取方法分為了三種流程，各自的權限、存活期都不同。
三種流程特點如下：
這是推薦的授權流程，可以獲得全部權限，比較安全，且可以刷新token。但是交互步驟多了壹點，需要彈出頁面手動點擊“授權”按鈕才行。
具體步驟：
測試過程中，我們是用Postman。好在Postman提供了最簡單的方法，壹步到位：使用內置Oauth2.0設置。
設置方法是：
完成後，每個頁面的Header或URL中，都會自動增加壹個 access_token 值。
authentication 的值裏，已經默認加上了 Bearer 前綴及後面的base64編碼字符串。
註意：同名的參數如果以前存在，則會被覆蓋。內置oAuth 2.0的設置是灰色的，在這裏不可直接編輯。
這種流程只需要用Dashboard後臺中的 client_id 和 client_secret 可以直接獲取 access_token 。
這個不好用，因為功能太少，文檔不全，基本的Oauth還要自己手動解決，沒什麽現成的方法。
這個也構建不完全，基於async異步，但是很難走通。文檔也沒說明具體用法。