Spotify的API简单分为两个入口：
- 授权入口：https://accounts.spotify.com/api/....
- 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/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挂钩的。
Developer 创建开发者身份
前往Spotify开发者网址：https://developer.spotify.com/dashboard
登录后点击create a client id，生成一个专用的client_id和client_secret。
同时必须认真设置Redirect URIs，因为日后授权验证时要完全匹配才行。
Scopes 权限选择
在进行授权申请之前，要先确定这个app需要哪些权限，确定好了再到授权过程中通过参数进行声明。
Spotify对权限进行了详细的分类，全部的权限如下：
在之后我们对/authorize页面进行GET申请授权时候，需要在URL里加入scope参数，里面的值就是我们所选择的一些权限申请。
每条权限名用空格分开
只读型的常用权限有：
user-library-readuser-follow-readuser-top-readuser-read-privateplaylist-read-privateuser-read-playback-state
修改型的常用权限有：
user-follow-modifyuser-library-modifyplaylist-modify-publicplaylist-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信息。
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
