目的
尽管对于一个博客而言,最主要的是文章的内容质量,相较而言,作为装饰的图片,就显得不是那么重要了。但实际上大多数时候,图片才是决定博客美观的最重要因素。只不过当一个博客内的图片过多时,就会让用户无法去选择,因此最好开发一个通用的,随机图片API,来减少用户找图片的烦恼。
基于以上需求,因此我决定开发一个随机图片 API,用来为所有的用户提供一个方便快捷的自动图片API。
要求
基于先决条件,图片 API 需要有以下特点
- 返回 JSON 格式,可以根据用户的需求返回张数,所以应该为数组。然后应该包含一些基础信息,所以最好为对象数组
- 图片可以由用户上传,但不可删除
- 可以指定是哪个用户,哪个相册,哪个分类下的图片
- 用户可以选择按顺序展示图片还是随机展示(
这是不是就不算随机图了) - 对于某个用户请求同样的数据,在一定时间内应该保持同一组
设计
接口暂定为 api/images
参数名 | 参数值 | 参数说明 | 是否必填 |
---|---|---|---|
type | urls(图片链接列表)(默认) list (除了图片的列表,例如用户、相册、分类) detail(详细信息) url(直接获取某个随机图片或指定图片) | 接口二级分类 | 是 |
itype | image(图片) user(用户) album(相册)(默认) category(分类) | 接口三级分类 | 否 |
id | 1. 当 type 为 urls 时,根据 itype,有不同的情况: itype 为 user 时,为用户名 itype 为 album 时,相册编号 itype 为 category 时,分类urlKey 当itype 不填时,从图片列表随机读取 2. 当 type 为 list 时, 不需要ID 3. 当 type 为 detail 时,根据 itype,有不同的情况: itype 为 user 时,为用户名 itype 为 album 时,相册编号 itype 为 category 时,分类urlKey itype 为 image 时,为图片编号 4. 当 type 为 url 时,根据 itype 的不同,具有不同的状态 itype 为 user 时,为用户号。接口将在用户中随机一个图片返回 itype 为 album 时,为相册编号。接口将在相册中随机一个图片返回 itype 为 category 时,为分类 url_key,接口将在分类中随机一个图片返回 itype 为 image 时,为图片编号,接口将返回指定的图片 | 接口请求标识 | 否 |
kind | random(随机) order(顺序) | 图片是随机从图库中查找,还是按顺序返回,当 type 为 urls 时生效 | 否 |
count | 10(默认值) | 返回的图片数量,当 type 为 urls 时生效 | 否 |
satrt | 0(默认值) | 图片开始位置,仅当 kind 为 order 时生效。若开始值大于图片数量,则查询最后 count 个 | 否 |
接口
截止 2020/12/1 起,接口已经上线,访问地址 https://api.lixingyong.com/api/images ~但未集成在主题中。另外接口使用文档也未完善。静待。【除 url 功能】~【sakura 1.3.0 已实装】
缓存
为了提供更快速的服务,系统将默认启用 redis 缓存。其中,针对于图片服务,redis 缓存机制如下:
- 对于同一个 referer 下,同一个请求,将启用 1 小时的数据缓存配置。(可以采用 r 随机字符串的方式来取消此缓存)
- 对于同一个数据库查询方式,将启用 30 分钟的数据缓存配置。(此缓存无法取消,固定 30 分钟,此期间可能会导致图库数据无法及时更新)
webp
使用接口获取的图片,默认将全部支持 Webp 格式,在保证减少网络请求大小的同时不降低图片质量。考虑到用户可能需要原图,因此支持在 Webp 格式的图片上保存下载原图。
cdn
尽管我服务器的带宽还可以,但也许还是比较慢的。因此对于随机图 API,我将使用我个人的 CDN 来进行加速支持。
上传支持
以往的随机图 API,用户都无法上传/使用自己心仪的图片。而本随机图 API 将采用我的 Chevereto 图床,便于支持用户心仪图片的上传、检索、下载等功能。任何想使用自己心仪图片的用户,都可以上传图片至图床,然后使用随机图 API 来进行读取。(由于缓存原因,在 0 - 30 分钟内,上传的图片可能不会刷新,静待即可。)
要求
为了防止垃圾图片,因此需要用户注册,然后验证邮箱之后才可使用。我保证不会恶意删除任何用户的图片。
目前将不会开启图片审核,除非有任何违规图片的出现。
【API 将不会读取任何私密图片】
补充功能
2020/12/11 补充
- 补充 type 为 url 的情况。
当 type 为 url 时,根据 itype 的不同,具有不同的状态
• itype 为 user 时,为用户号。接口将在用户中随机一个图片返回
• itype 为 album 时,为相册编号。接口将在相册中随机一个图片返回
• itype 为 category 时,为分类 url_key,接口将在分类中随机一个图片返回
• itype 为 image 时,为图片编号,接口将返回指定的图片
当 type 为 url 时,新增一个图片类型选项。 暂定 qn
• 当 qn 为 1 时,返回中等大小图
• 当 qn 为 2 时,返回缩略图
• 其他情况均返回原图 - 补充 type 为 urls 时,图片返回的接口增加三种类型的图片。
a. 原图
b. 中等大小
c. 缩略图