Spotify 的 API 简单分为两个入口：
授权入口：https://accounts.spotify.com/…
API 入口：https://api.spotify.com/v1/….
其中所有的授权相关验证都通过授权入口进行，而所有正常获取数据的 API 请求都从 API 入口进行。
Requests Rate Limit 请求限制次数
参考官网：Authorization Guide 参考官方 Github Issues：Getting higher usage rate limits
其中只说了不同请求方式的限制次数有不同，但是没写具体有多少：
Implicit Grant：次数最少，不能刷新 token，数量未知。Rate limits for requests are improved but there is no refresh token provided.
Client Credentials：次数较多一些，数量未知. The advantage here … is that a higher rate limit is applied.
Authorization Code：次数最多，具体数量未知。网友回答：With 400 users, this would work out at one request every 3.6 seconds, which I’m sure wouldn’t trigger Spotify’s rate limiting policy. 也就是说一个 app 大约 100 requests/second，或 6000 requests/minute。
参考另一篇官网文档：https://developer.spotify.com…”Rate limiting is applied on an application basis (based on client id), regardless of how many users are using it.” 即无关多少个用户，限制次数只是和每个 app 挂钩的。
Developer 创建开发者身份
前往 Spotify 开发者网址：https://developer.spotify.com…
登录后点击 create a client id，生成一个专用的 client_id 和 client_secret。
同时必须认真设置 Redirect URIs，因为日后授权验证时要完全匹配才行。
Scopes 权限选择
在进行授权申请之前，要先确定这个 app 需要哪些权限，确定好了再到授权过程中通过参数进行声明。
Spotify 对权限进行了详细的分类，全部的权限如下：
参考官方：Authorization Scopes
在之后我们对 /authorize 页面进行 GET 申请授权时候，需要在 URL 里加入 scope 参数，里面的值就是我们所选择的一些权限申请。每条权限名用 空格分开
只读型的常用权限有：
user-library-read
user-follow-read
user-top-read
user-read-private
playlist-read-private
user-read-playback-state
修改型的常用权限有：
user-follow-modify
user-library-modify
playlist-modify-public
playlist-modify-private
全部组合起来的请求 URL 是这样的：
https://accounts.spotify.com/authorize?…&…&…&scope=user-library-read user-follow-read user-top-read user-read-private playlist-read-private user-read-playback-state user-follow-modify user-library-modify playlist-modify-public playlist-modify-private
Authentication 授权
授权的最终目的是获取一个名为 access_token 的值，然后用这个 access_token 去获取各种个样的 API 信息。
参考官方：Authorization Guide
Spotify 为了严格区分不同的用途和权限，把这个 access_token 的获取方法分为了三种流程，各自的权限、存活期都不同。
三种流程特点如下：
Authorization Code Flow: 授权码。主要方法，可刷新 token。需要弹出网页让用户登录并点击授权。
Client Credentials Flow: app 级 token。获取非常简单。但不可获取用户资源，也不可刷新。过期需再申请。
Implicit Grant Flow: 临时授权。可获取用户资源，不可刷新。存活期比较短。
Flow-1: Authorization Code Flow
这是推荐的授权流程，可以获得全部权限，比较安全，且可以刷新 token。但是交互步骤多了一点，需要弹出页面手动点击“授权”按钮才行。
具体步骤：
向 /authorize 发送 GET 请求，包括 client_id 和 redirect_uri 等
Spotify 弹出页面，用户手动登录并点击允许授权
Spotify 把页面跳转至自己设定的 callback 网址，并明文传输一个 Code 码
用 Code 码向 /token 发送 POST 请求，并在 header 中包括一个动态生成并 base64 编码的 Authorization 字符串，格式为 Authorization: Basic *<base64 encoded client_id:client_secret>*
从 Spotify 获得 access_token 和 refresh_token
在 access_token 过期后，用 refresh_token 向 /token 发送 POST 请求，获得新的 access_token。
测试过程中，我们是用 Postman。好在 Postman 提供了最简单的方法，一步到位：使用内置 Oauth2.0 设置。
设置方法是：
在 Collection 上右键点开 Edit
选择 Authentication
Type 选择 Oauth 2.0
Add to 根据需求选择把认证添加到 headers 还是 url
点击 Get new access token，添加 token flow
Token name 填上 url 或 header 中的参数的指定名称，一般为 access_token。
Grant type 上选择 Authentication Code
填入所有相关内容，注意 callback 必须与 spotify 后台中设置一致
点击 request token
然后 Postman 会弹出一个页面，需要你登录 Spotify 并点击允许授权。只需这一次，以后每次 Postman 都会帮你登录了
然后 Postman 就会生成一个全局的 access_token
之后每个页面的 Authentication 栏，都直接选择 Inherit auth from parent 继承自父级即可自动完成验证。
完成后，每个页面的 Header 或 URL 中，都会自动增加一个 access_token 值。
authentication 的值里，已经默认加上了 Bearer 前缀及后面的 base64 编码字符串。注意：同名的参数如果以前存在，则会被覆盖。内置 oAuth 2.0 的设置是灰色的，在这里不可直接编辑。
Flow-2: Client Credentials Flow
这种流程只需要用 Dashboard 后台中的 client_id 和 client_secret 可以直接获取 access_token。
SDK
spotipy
这个不好用，因为功能太少，文档不全，基本的 Oauth 还要自己手动解决，没什么现成的方法。
$ pip install spotipy –user
spotify.py
这个也构建不完全，基于 async 异步，但是很难走通。文档也没说明具体用法。
$ pip3 install spotify –user