NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - AI模型在线查看 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割 - 3D道路快速建模
首先，简单介绍一下我建立的业务：Listen Notes 是一个播客搜索引擎，它允许人们按人物或主题搜索近 200 万个播客和超过 8900 万集节目。我们还为开发人员提供了一个播客 API，称为 Listen API。它已成为我们业务的核心部分。
1、意外的 API 业务
2017 年 9 月，我离开了之前失败的创业公司。经过几天的修修补补，我接手了一个刚刚起步的业余项目，稍微完善了一下 UI。
那个业余项目是 Listen Notes，一个播客搜索引擎网站，它只是一个单页 React JS 应用程序，运行在三个每月 10 美元的 DigitalOcean droplet 上。
几年前，我并不知道，这个被忽视的小业余项目会发展成如今这样一项有益的业务。
我继续全职从事 Listen Notes 的工作，并于 2017 年 10 月将 Listen Notes 合并为特拉华州 C 公司。我的目标之一是尽可能多地体验商业的各个方面，而不仅仅是在幕后编写代码。
我最初的计划如下：（别笑我！）
- 建立一个播客搜索引擎网站，并通过广告赚钱，就像谷歌一样。很简单！
- 如果这个 Listen Notes 东西在两三个月内不起作用，那么我就会用光现金，我会背上信用卡债务来维持一个月左右。如果还是不行，那么我就得找一份全职工作。尽管杰夫·贝佐斯的父母在早期的亚马逊投资了 30 万美元，马克·扎克伯格的父母借给了早期的 Facebook 10 万美元，但并不是每个家庭都能随意地在网络项目上投入六位数的现金。
然后发生了一些事情。
2017 年 11 月 20 日，我收到了一封来自新播客应用开发者的电子邮件，他询问 Listen Notes 是否提供了 API。他希望能够在他的应用中搜索剧集，但他不想构建整个后端。
我问了几个问题（例如，端点是什么样子的，他需要哪些数据字段，他愿意支付多少钱……）。我得到了他的答案。几天之内，一切都在电子邮件线程中。
2017 年 11 月 30 日，我快速实现了三个端点（ GET /search、 GET /podcasts/{id} 和 GET /episodes/{id}），它们基本上是三个 Django 视图。
我用 Google 搜索“API 网关”或类似的东西，找到了一项名为 Mashape 的服务，这是一个处理支付、用户管理和 API 文档的 API 市场。
因此，我将我的三个端点放在 Mashape 上，并在那里创建了两个计划：免费版和专业版。我给开发人员回了电子邮件，告诉他 API 已准备好使用。
然后什么都没发生。播客应用程序开发人员没有使用我们的 API，而是逐步淘汰了他们的项目。
最终，我转而主要专注于 listennotes.com 的开发。 API 在开放网络上基本上处于无人驾驶模式。任何偶然发现我们 API 的人都可以注册，而无需与任何人交谈。
2018 年 1 月 14 日，我获得了第一个付费用户。同年又有几位付费用户加入。
等等，什么是 RapidAPI？好吧，Mashape 被一家名为 RapidAPI 的初创公司收购了。直到 2018 年年中，他们才将 Mashape 完全更名为 RapidAPI。初创公司通常不会以干净、有条不紊的方式做事，这是完全可以理解的。
然后发生了一些事情。
2018 年 11 月 29 日，RapidAPI 端发生中断。
那时，RapidAPI 进行了一次大规模的后端升级。作为一名工程师，我完全理解停机的发生，尤其是在后端进行重大更改时。但我感到很无助，因为他们的客服没有回复我的电子邮件。电话没有按预期工作。
通常他们的客服响应非常迅速。也许是因为当时是假期，大家都在度假。
所以我使用 hunter.io 查找了 RapidAPI 员工、首席执行官以及首席技术官的工作电子邮件。几个小时后，问题终于解决了。换句话说，我们的 API 在停机期间完全无法使用。我为我们的付费用户感到非常遗憾。
然后在 2019 年 2 月中旬左右，RapidAPI 出现了计费问题，未能向我们支付几千美元。我们的付费用户首先向 RapidAPI 付款。 RapidAPI 抽取了 20% 的费用。然后他们向我们支付了剩余的 80%（减去 PayPal 费用）。
经过几次来回的电子邮件和电话，我们终于收到了付款。这是可以理解的。再说一次，初创公司会犯错。
2019 年 2 月下旬，我决定构建我们自己的 RapidAPI 替代品，原因如下：
- 我们的 API 收入变得不菲。 RapidAPI 的 20% 抽成对我们来说有点太多了。
- 我们希望 API 请求直接到达我们自己的服务器，从而降低用户的延迟。
- 我不想在 RapidAPI 中断时感到无助。总的来说，他们在运行服务方面做得很好。但我想掌控自己的命运。
- 我想直接联系我的 API 用户。使用 RapidAPI，像我这样的 API 提供商无法访问我们用户的电子邮件地址。这是可以理解的。这就像“Uber for X”公司不希望员工和客户绕过他们并私下达成交易。市场不希望用户跳过中间人的佣金。
此外，我发誓要为我们的新 API 系统做好两件事：
- 我们必须为付费用户提供出色的客户服务。
- 我们将为客户提供非常稳定可靠的后端服务。
经过 30 天的艰苦努力，我们于 2019 年 3 月 27 日推出了 Listen API v2。托管在 RapidAPI 上的旧版 API 变成了 Listen API v1，我们不会向该版本添加新功能，但不想关闭它，因为截至 2020 年 12 月，有些应用程序仍在使用它！
我们继续改进我们的新 Listen API v2，添加新的端点、新的数据字段、提高运营效率，以及改进用户仪表板和我们的内部工具。
事情正在逐渐加快速度。从那时起我就很开心。
所以，这就是 Listen API 迄今为止的旅程。
注意：虽然我们决定放弃 RapidAPI，但我仍然认为它是一项很棒的服务。初创公司在早期都会犯错。他们会解决问题并继续改进服务，这很棒！
2、Listen API 背后的技术
开发人员可以使用我们的 API 搜索播客并获取详细的播客剧集元数据。为了使整个过程正常运转，我们需要确保一些核心组件到位。
- 数据存储和搜索引擎
这是与我们的网站共享的组件。因此，在构建我们的 API 基础架构时，我不需要对数据存储和搜索引擎进行任何更改。我们使用 Postgres 作为我们的主要数据存储（例如，用于播客元数据、用户帐户等），并使用 Elasticsearch 作为搜索引擎。我写了一篇旧博客文章，其中包含整个技术栈的详细信息。
- 内部工具和流程
如果你曾在任何网络公司工作过，你可能知道我在这里指的是什么。互联网业务很少实现 100% 自动化。公司总是需要构建大量内部工具并设置手动流程来保持服务正常运行。这就是为什么像 Retool 这样的公司如今估值如此之高的原因。公司正在大笔投资于最终用户不可见的内部工具：
要启动我们的 API 业务，我们需要构建（至少）两种类型的内部工具：
- 对于数据操作：我们需要能够使播客元数据保持最新、修复损坏的元数据，以及审查和批准用户所做的任何更改。此外，我们需要一个框架来处理播客数据损坏的新、罕见的边缘情况。在某种程度上，构建软件产品意味着在很长一段时间内（例如数年）处理大量边缘情况，而不是每天推出新功能。
- 对于用户操作：我们需要能够暂停不良用户的帐户，以及立即查找与因特定问题与我们联系的特定用户相关的所有信息。此外，当用户抱怨时，我们必须能够快速评估“这是我们的错”（服务器端错误）还是“这是他们的错”（客户端错误）。
内部工具由公司内部员工使用。其中一些工具是完全自动化的，例如执行计划任务的 cron 作业。但许多工具应该由人类员工手动使用，例如输入用户的 ID 号并单击按钮时。我们的大多数内部工具都有丑陋的 Web UI，采用默认的 Bootstrap 样式 :)
幸运的是，我们的 API 与网站共享许多内部工具。所以我们不需要在这里构建太多新东西。
- 分析和计费系统
API 的定价模型通常基于使用情况。查看一些真实示例：
- https://www.twilio.com/pricing
- https://sendgrid.com/pricing/
- https://cloud.google.com/maps-platform/pricing/
- https://www.microsoft.com/en-us/bing/apis/pricing
必须实时跟踪用户使用的请求数。我们使用 Redis 来跟踪此类统计数据，并定期转储到 Postgres 进行持久存储。
如果我们的 Redis 发生中断，会发生什么？我们可能会暂时丢失一些跟踪统计数据。在这种情况下，我们有一个内部工具来同步原始 Nginx 日志中的统计数据。
我们必须在不影响现有用户的情况下更改计费计划。例如，如果我们提高价格，现有用户仍应享受旧计划的优惠。如果做得不好，很容易出现全面不一致的状态，愤怒的用户会因为错误的计费计划而受到收费！
付款失败是一种非常常见的情况，必须妥善处理。我们不能立即暂停用户。我们需要能够通知自己“此用户未能付款”并通知用户“您未能付款”。
经过几次重试后，我们会手动暂停用户 - 好吧，我们可以自动执行最后一步。但我们现在不经常暂停用户，所以手动暂停是可以的。没有必要把一切都做得完美（至少现在不需要）。
我们有一个仪表板（上帝视角）来查看每个用户在当前计费周期中使用了多少个请求。而且，我们能够从 Web UI 查看每个用户的原始日志，而无需手动从 S3 中提取日志文件。
Stripe 和 PayPal（通过 Braintree）是我们的支付处理器。我们的大多数国际用户都使用 PayPal。最后，将所有这些因素综合起来，我们可以根据用户的使用情况实时计算出用户应向我们支付的实际金额。我们通过 Celery 运行异步任务来收取到期账单。如果用户在结算周期中途取消订阅会发生什么？我们会根据时间和使用情况按比例向他们收取费用。在这种情况下，用户无需支付整月的费用。
最后，将所有这些因素综合起来，我们可以根据用户的使用情况实时计算出用户应向我们支付的实际金额。我们通过 Celery 运行异步任务来收取到期账单。
如果用户在计费周期中途取消订阅，会发生什么情况？我们会根据时间和使用情况按比例向他们收费。在这种情况下，用户无需支付整月的费用。
- API 服务器
我们运行 Django 应用来处理 API 请求。每个端点都是一个简单的 Django 视图。 Django 中间件会验证请求是否合法，然后生成日志或立即拒绝请求。
我们在 Redis 中缓存每个 API 密钥 + 唯一 URL 的响应数据。总体而言，我们的 API 性能相当不错。
我们使用 Nginx 作为负载均衡器并提供多个 API 服务器。在这里进行滚动部署非常简单，只需进行一系列健全性检查即可确保 API 正常运行。
一般来说，简单而强大的部署过程增强了我经常进行增量代码更改和频繁部署的信心。
API 端点是 RESTful 并返回 JSON 响应，这在当今非常标准。
- 用户仪表板和 API 文档
每个 API 用户都可以访问我们网站上的仪表板，了解他们在当前计费周期中使用的请求数量并查看最近的原始日志。他们还可以更新付款方式、创建或重置新的 API 密钥、设置 webhook 以及将同事添加到同一个 API 帐户。
API Docs 可能是 API 业务最重要的 UI。因此，许多 API 公司雇用了一整支全职工程师团队来构建和维护“仅仅”API Docs 页面。
API Docs 页面不仅仅是一整页的英文单词。它必须显示不同编程语言的代码片段。用户必须能够直接从页面运行你的代码示例。你需要设计一个可重复的过程（无论是自动还是手动）以使文档与你的代码保持同步。有很多细微差别。
我们花费了大量时间和精力来构建和迭代我们的 API Docs 页面的多个版本。以下是最终结果：
最初，我们尝试了一些开源 API 文档解决方案。要充分了解开源项目并对其进行自定义非常耗时。最终，我们决定从头开始构建页面比自定义其他人构建的开源解决方案更快。
我们的 API 文档页面基本上是一个 React JS 单页应用程序。
我们在 OpenAPI 规范中编纂所有端点、响应数据架构和示例响应。 API 文档页面的 React JS 应用程序直接从我们的 OpenAPI 规范中读取。
使用 OpenAPI 的额外好处是我们可以轻松地与 Postman 等工具集成，因为 OpenAPI 是当今 API 文档的（相对）广泛采用的标准。
3、Listen API 为何有效
到目前为止，Listen API 对我来说是一笔不错的生意。但不要指望我会公开分享收入数字 :)
有些公司正在做这种开放式创业，向公众分享每一个业务指标，这很好。但我们不应该责怪大多数公司（包括我的小公司 Listen Notes, Inc.）不愿意公开分享业务指标。不是每个人都愿意在公共场合赤身裸体，无论是字面上还是比喻上。
同样，有很多商业建议（或陈词滥调）你不必遵循：
- 你不必找一个联合创始人——有一个可怕的联合创始人比没有联合创始人要糟糕得多。
- 你不必向公众透露你的收入或做任何“开放式创业”的事情。没有压力。如果你没有做其他酷孩子正在做的事情，不要感到内疚。你经营自己的公司。你做自己的决定。
- 你不必去做 Twitter VC 哲学家在类似幸运饼干的推文中敦促你做的 XYZ 事情。
- 你不必 100% 自力更生，也不必 100% 获得 VC 支持。很多事情并不是非此即彼。通常，都有中间立场。
- ...等等。
底线是，没有绝对错误或绝对正确的。每个人的视野/知识都是有限的。每个人的偏好可能非常不同。
API 业务对世界上大多数人来说可能太晦涩难懂，但我非常喜欢我的 API 业务。来自大公司（如 Apple、Amazon 或 Microsoft）的人可能会审视我的业务并认为它“很可爱”。但我个人认为这是成功的。
成功是相对的。关键是给客户带来快乐（通过为他们节省时间和金钱并帮助他们解决问题）、我自己（职业成就）和我的家人（通过保持冰箱满满的）
那么 Listen API 为何有效？
3.1 需求和 MVP
我构建解决方案并不是为了发现问题。是问题（一个想要添加搜索功能的播客应用）找到了我们——我们一开始就构建了一个非常简单的解决方案。
我们并没有花几个月的时间来发布 API。我们只花了几个小时。在旧金山聘请一名还不错的工程师每小时至少要花费 100 美元，因此发布这个 API MVP 的成本约为 200 美元。即使是 2,000 美元，我仍然认为这是值得的。
我们能够快速发布 MVP 有两个原因：
- 由于我们的播客搜索引擎网站，构建播客数据库、搜索引擎和数据操作工具的繁重工作已经完成。
- Mashape / RapidAPI 的存在是为了为我们提供一种即插即用的解决方案，让我们无需在我们这边编写代码即可管理用户和创建付费计划。
然而，事后看来，商业搜索引擎授权他们的技术（通过 API 或其他方式）实际上非常普遍。以下是一些示例：
- 雅虎搜索在 2000 年左右由 Google 提供支持，而如今则由 Bing 提供支持。
- 早期，百度的唯一商业模式是将网络搜索放在一些中文门户网站上
- 如今，Bing 提供了大量搜索 API。
通过快速发布 MVP，我们能够尽早获得反馈，尤其是在发布后仅一个月左右就获得第一个付费用户之后。
3.2 良好的文档
用户反馈证明我们的 API 文档页面在客户决定使用我们的 API 方面发挥着重要作用。 API 公司雇用一整支工程师团队“只”维护他们的文档页面肯定是有原因的。
优秀的文档可以建立信任。
3.3 稳定的后端服务
稳定性是 API 业务马斯洛需求层次理论的基本基础。如果 API 完全不稳定（例如，它经常中断或运行非常非常慢），则无法使用。
但是，执行工作以提高后端稳定性是一件无聊的事情。大多数稳定后端服务的任务都是预防性的，包括广泛的监控和警报、自信地部署代码的过程、端到端回归测试等等。
没有消息就是好消息。
没有中断就是好消息。
我们使用 Statuspage.io 连接我们的 Datadog 指标以构建状态页面：
希望状态页面能够说服我们的潜在用户尝试我们的 API :)
3.4 卓越的客户服务
我们都是别人产品和服务的客户。在人生的某个阶段，我们都曾因糟糕的客户服务而感到沮丧。显然，优质的客户服务大有裨益——愿 Tony 安息。
很多人可能不知道，要获得更好的客户服务，你必须向 AWS 支付大笔费用！
我们的客户不仅为使用我们的在线服务 API 而付费。他们还为能够从真人那里获得高质量的客户帮助而付费。在我们的情况下，就是我，这个东西的创造者。
我使用 Superhuman 来及时高效地处理电子邮件。我有大量预先编写的电子邮件模板来处理最受欢迎的客户支持单。通常，我可以在 5 秒内回复电子邮件，使用 CMD + K 选择电子邮件模板。
3.5 投资内部工具和流程
对于知识工作，一个人（或一个小团队）可能比一个大团队创造 10 倍、100 倍甚至 1,000 倍的价值。
让我们看一个极端的例子：图书出版。聘请 10,000 名优秀作家共同创作一本书，并希望这本书在凝聚力上比由一位作者撰写的《哈利波特》“更好”是（几乎）不可能的。
JK·罗琳一个人创造的价值（以可衡量的美元金额和不可衡量的幸福、美好时光而言）远远超过世界上大多数拥有数百名员工的公司。
最终，软件业务将以类似的方式增长。
我们已经目睹了拥有 13 名员工的 Instagram 在 2012 年以 10 亿美元的价格被收购。我们什么时候才能看到一家拥有 5 名或更少员工、价值 10 亿美元以上的软件/互联网公司取得同样的成就？
优秀的内部工具和流程提供了杠杆作用，使小团队也能超高效。这很容易理解。我们人类已经制造了很多工具来极大地扩展我们的身体/精神极限，例如自行车和汽车（相对于步行）、计算机（相对于手动计算）等等。
鉴于互联网业务几乎不可能 100% 自动化，我们必须提高手动操作的效率。这是一项提高人类操作员生产力的重大投资。
4、将 Listen API 作为一项业务运营的花絮
以下是我之前不知道的一些事情……
- 任何人都可以注册 => 首先提交你的申请
几年前，我注意到某些 API 要求我先提交申请，描述我的用例，然后再给我 API 密钥。
当时我不明白其中的原理。
在运营自己的 API 业务后，我现在明白了。
互联网是巨大的。世界是巨大的。有好人也有坏人。如果你提供的 API 有用，有些人会试图滥用你的 API。
这就是我们最初允许任何人创建 API 帐户时发生的情况。我们看到用户创建了数十个帐户以绕过免费配额限制。
今天，我们要求人们先提交申请。我们通过 Slack 收到通知。然后我们使用我们的内部工具来审查并批准或拒绝申请。申请人会收到一封自动电子邮件。在我们这边，只需点击两三次即可完成所有这些操作。
为了协助我们的审核流程，我们使用了一系列启发式方法：
此用户之前是否创建了多个帐户？
此 IP 地址是否是可通过 stopforumspam.com 发现的知名垃圾邮件发送者？ （提示：有一个 API 可用）
等等……
同样，我们时不时会看到新的边缘情况。但我们也在学习如何处理这些特殊情况。
- 理想客户和有趣的客户
我们最好的客户大多是创业公司创始人，他们已经经营了相当长一段时间。
他们可以自己做决定。他们了解我们提供的价值。他们有权最终确定购买决定。他们有足够的能力自主阅读我们的文档，很少提问——或者他们根本不和我们说话。
另一方面，来自资金充足的风险投资支持的初创公司或大公司（一些世界上最大的公司）的人经常要求折扣或免费试用，而我们没有。为什么？我在这里没有好的答案。
当然，总会有例外。
- 开发商店和编码训练营
我们的许多用户聘请海外自由职业者或开发商店来构建应用程序和网站。
一般来说，开发商店的开发人员不如内部开发人员。虽然不是 100% 正确，但可能性相当高。
本质上，我的许多客户支持回复都是为了教授计算机科学 101。有时他们会用 PHP（或我不知道的语言）发送代码片段，要求我们通过电子邮件对其进行调试。
我知道一些来自开发商店的开发人员刚刚从编码训练营中毕业（或者开发商店本身就是一个编码训练营）。大多数时候，我会在 Google 上搜索他们，并向他们发送 StackOverflow 链接或类似的东西。但偶尔，如果我心情不好，我不会回复来自不付费的免费用户的“帮我调试我的 PHP 代码”电子邮件。
此外，相当多的编码训练营使用我们的 API 来教学生如何编写代码，这很好。在实际的 Web 项目中，你无法避免使用第三方 REST API。教新程序员如何与 REST API 对话是必要的。
- API 是一种慢生意
通常，用户需要几个月的时间才能开始向我们付款。
他们需要先添加一个重要的产品功能，甚至构建整个应用程序。然后他们需要做一些营销并获得一些关注。最后，他们要么付款，要么放弃并关闭应用程序。
我们绝对应该考虑如何帮助我们的用户快速构建产品功能。
Stripe 在这方面做得很好。他们构建了许多不错的 UI 组件，开发人员可以直接使用而无需编写大量代码，例如 Checkout。
- API 是一项稳定的业务
我们的客户流失率很低。人们花费数月时间使用我们的 API 构建应用程序，因此他们不太可能在一夜之间切换到其他业务。
我对此感到高兴。
同时，我也非常看好其他 API 业务，例如 Stripe、Plaid 和 Twilio。（这不是投资建议，但请关注 TWLO 的股票。）
- 从鲸鱼开始，然后多元化
在早期阶段，可能会有少数用户“鲸鱼”占很大一部分甚至大部分收入。
不要惊慌。
有收入总比没有收入好。
我们在早期阶段没有资格挑剔。我们可以一路多元化。
我喜欢读 S-1。
一些 SaaS 或 API 公司在上市时拥有一些鲸鱼并不罕见。如果他们失去一两个这样的鲸鱼，他们的收入会立即下降 10%，甚至 20% 以上！好吧，他们已经是一家上市公司了。不必担心他们。他们知道下一步该怎么做。
- 定价是一项正在进行的工作
我们一直在尝试新的定价。与一般的软件项目构建类似，定价也始终是一项正在进行的工作。
我们允许老用户坚持他们注册时获得的较低价格。任何未来的价格变动都不会影响现有的付费用户。
我知道精选定价专家会警告我，这种做法会让我损失金钱。但我对长期支持我们的客户表示感谢。我希望他们能享受低价作为一种福利。
顺便说一句，ProfitWell 拥有丰富的定价资源。
- 仇视者/无关的批评
你可能见过这个理论：当你有仇视者时，你做的事情是对的。
曾国藩（19 世纪中国最重要的军事领导人和政治家之一）也有类似的名言：
不招人妒者皆庸才。“如果没有人嫉妒你，那你就无能。”
旁注：你可以在中国的许多机场书店找到曾国藩的智慧。如果他出生在我们这个时代，他会是一个伟大的 Twitter 用户，并击败那些 Twitter VC 哲学家——在幸运饼干游戏中很难打败一个中国历史人物 :)
如果你的项目在互联网上可见并获得了一些关注，有些人会无缘无故地讨厌你。
一旦你提供付费服务，你就永远不会提供足够低的价格来让世界上的每个人都满意。不，1.00 美元在世界上很多地方一点也不便宜。非目标用户会抱怨你的定价。
根据我的经验，忽略大多数批评者、建议者和非用户的建议是安全的。有时人们会试图比较两个名称相似的东西。
例如，如果你在 Google 上搜索“podcast API”，你会发现其他几个名称中带有“podcast API”的 API。但是，如果你花几分钟浏览文档，你会发现明显的差异。这就像比较两个名字和姓氏相同的人，毕竟他们是两个完全不同的人。
我唯一关心的批评或建议大多来自我们的用户。我可以看到他们的 API 使用情况。我知道他们表达的是有意义的事实。所以我听取了他们的意见。
5、那么，你有兴趣建立 API 业务吗？
如今，“激情经济”或“创作者经济”非常火爆。谁是创作者？作家、播客、主播……
别忘了，软件开发人员也是创作者！如果你已经运营一个网站或有一些有趣的数据，你也可以开始 API 业务。
原文链接：How I Accidentally Built an API Business
BimAnt翻译整理，转载请标明出处
