我需要一个用于聊天应用的简单 Link Preview API，于是我自己构建了一个

发布: 1天前 (2025年12月15日 GMT+8 03:39)

7 min read

Source: Dev.to

从构建一个极简、可预测的 URL 预览 API 中得到的经验教训

我们正在打造一个将宠物主人与宠物护理服务提供者连接起来的平台。平台上最活跃的功能之一是用户之间的实时双向聊天系统——每天会发送成千上万条消息。当有人粘贴链接时，应该像 Facebook Messenger 或 WhatsApp 那样展开为一个整洁的预览（标题、描述、图片、图标）。

我原以为这很简单——市面上有很多 URL 预览 API，对吧？结果……并非如此。

研究 URL 预览 API 时发现的情况

1. 与我们使用模式不匹配的每小时限制

聊天流量呈波动式。对我们的用户（主要在美国西部）而言，活跃时间集中在上午 10 点至下午 2 点（MST），而在晚上 6 点后会下降。许多 API 按小时计费或强制突发限制，这与我们的流量模式不符。即使月度使用量在理论上合理，短期上限也可能在高峰期导致预览失效。

2. 我们不需要的功能

很多 API 提供截图、基于 AI 的解析、非常大的 JSON 响应等。这些功能固然强大，但对于我们只需要的简易预览卡来说显得过于臃肿，且定价也反映了这种复杂性。

3. 入门成本高

我找到的最便宜的商业套餐大约是 $25 / month。入门价统一，但配额各不相同。对于独立开发者和小型自筹资金的企业来说，这笔持续的费用可能成为障碍。

为什么决定自己动手实现

动机并不是“我能做得更好”，而是“我需要一个简单、可靠且价格亲民的方案”。现有服务存在每小时限制、不必要的复杂度以及不符合我们使用场景的定价。最初作为内部工具的项目，最终演变成一个小型独立服务，现在已在 URLPreview 上提供。

遵循的规则

API 简洁 – 单一端点、简单认证，返回的 JSON 仅包含标准链接卡所需的字段。
配额简洁 – 没有每小时限制。月度配额可随时使用；只有在威胁系统稳定性时才会临时限制突发流量。
细分定价 – 小用户不应被迫进入大套餐。URLPreview 起价为 $9 / month，提供 5 万次请求，而其他服务同等配额则要 $25 / month。
可靠的元数据提取 – 低价不等于不可靠。对失效站点和边缘案例进行持续监控和修复，常常依据用户反馈进行。
各层级功能一致 – 唯一的区别在于请求次数。那些成本不随使用量增长的功能对所有用户开放。

故意避免的功能

截图及附加功能 – 对大多数预览场景并非必需，会额外增加基础设施和存储需求。
基于 AI 的提取 – 非确定性响应以及对 GPU 支持的基础设施需求会显著提升成本。
每小时限制 – 会惩罚聊天应用常见的突发流量模式。

这些功能并非“坏”，在特定场景下非常有用。只是对我所针对的大多数预览需求来说并不必要，去除它们有助于保持价格亲民。

早期上线与用户反馈

在 Reddit 评论中随意提到该项目几天后，我就收到了第一个付费用户——足以验证问题的存在。随后在 Product Hunt 和 Uneed 的上线又带来了数十个注册。现在大部分流量来自 Google 的自然搜索，几乎不需要营销投入。该服务能够轻松覆盖运营成本，并为投入的时间带来回报。

工作原理

API 响应故意保持极简：

GET https://api.urlpreview.com/v1/preview?url=youtube.com&key=YOUR_KEY

{
  "access": "public",
  "title": "YouTube",
  "description": "Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.",
  "image": "https://www.youtube.com/img/desktop/yt_1200.png",
  "icon": "https://www.youtube.com/s/desktop/31c2c151/img/favicon.ico",
  "url": "https://youtube.com"
}

这正是大多数应用在链接卡中实际需要的内容。

经验教训

简洁取胜 – 大多数用例不需要截图或 AI；保持最小化让 API 更易维护且更实惠。
可预测的定价很重要 – 突发限制会让开发者沮丧，固定月度配额更符合真实使用场景。
免费层促进采纳 – 让个人项目和测试无摩擦地使用，能鼓励实验和反馈。
专注可靠性 – 即使是低价服务也必须可靠；监控和告警值得投入。
小缺口可以变成机会 – 构建专注的工具来解决真实痛点，能够为他人创造价值。

为什么分享这些

许多开发者最终都会需要链接预览——无论是聊天应用、仪表盘、书签工具、浏览器扩展还是自动化脚本。我想把在构建这个小而极简的 URL 预览 API 过程中学到的经验分享出来，帮助遇到类似服务、定价模型或 API 限制问题的朋友。如果你有不同的解决方案，欢迎分享你的做法或对我的实现提出反馈。经验的交流能让我们共同发现更好的方案。