您使用过这些有趣的 API 吗?
最近在逛ProductHurt时,发现一些好玩又有趣的API,你可能会觉得花里胡哨,but 作为开发者也需要乐趣的!
当然调试API离不开API管理工具,随手也给大家安利一个最近很热门的接口管理工具:Apifox
????️ Clearbit
Clearbit提供了网站Logo访问API,只要你输入你想要寻找网站图标的域名,就可以返回域名的相关logo图片~
以前要去爬域名的图标,还要浏览器右键点击查看,然后选择元素找到logo的位置,现在找logo图标链路是不是缩短了!
API接口:GET https://logo.clearbit.com/:domain
比如我最近访问的几个站点:
- logo.clearbit.com/apifox.cn
- logo.clearbit.com/u.tools 用接口管理工具Apifox调试一下 ????
???? Lorem Picsum (随机风景图)
我们可以通过访问以下API接口获取风景图
- 返回风景图片列表:picsum.photos/v2/list
- 随机返回一张风景图:picsum.photos/200/300
- 返回一张虚化的风景图:picsum.photos/200/300/?bl…
用Apifox
做对接口做个调试演示
???? dog.ceo
喜欢狗狗的朋友可以使用下面这个API,调用接口会随机返回Dog相关的图片
API接口:
- 随机返回一张狗狗图片:dog.ceo/api/breeds/…
- 根据狗的种类返回图片列表:dog.ceo/api/breed/h… (这里以猎狗 hound为例)
???? TheCatApi
更喜欢猫?安排!TheCatApi 提供了猫仔相关的API,可以根据你喜欢的猫种类返回图片~
API接口
:
- 根据狗的种类返回图片列表:api.thecatapi.com/v1/images/s…
???? API Hub (API集合)
上面介绍了几种花里呼哨的API,那接下来就整点干货!日常开发中,我们经常需要对接一下第三方文档,诸如微信、钉钉、飞书等等。文档很零散,甚至联调起来效率也不高。
官网下载地址:www.apifox.cn
你可以试试用 Apifox 推出的 API Hub,定位是开放 API 共享平台。不仅具备常用的开放API文档,同时还能结合Apifox强大的接口管理功能,一站式服务!方便开发者接入开放平台的API
现在已经接入的开放API项目有:
-
开发工具类
:GitHub API,Gitlab API,JIRA API,Coding API,小鹅通API -
企业协作类
:企业微信API,飞书开放API,钉钉API,Teambition API,用友U8开放平台,Moka开放平台 -
生活服务类
:拼多多开放API,高德地图开放api,快递100,韵达开放api,创蓝云智开放api,客如云,纷享销客API -
娱乐社交类
:快手开放API,抖音开放API 等等 还有很多没列出来的,大家可自己去到搜下自己需要的,没有的话也可以申请让官方去收录。
其他开放API
网易云音乐:binaryify.github.io/NeteaseClou…
知乎专栏:github.com/TonnyL/Zhih…
天气API:www.tianqiapi.com/index
讯飞语音:www.xfyun.cn/doc/
聚合数据:www.juhe.cn/docs
人脸识别Face++:www.faceplusplus.com.cn/
百度AI开放平台:ai.baidu.com/
推荐阅读
-
您使用过这些有趣的 API 吗?
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。