共计 3217 个字符,预计需要花费 9 分钟才能阅读完成。
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