大家好，我是讯享网，很高兴认识大家。



 <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> <blockquote> 

讯享网

原文：Moesif Blog

协议：CC BY-NC-SA 4.0

原文：https://www.moesif.com/blog/api-product-management/api-analytics/Introducing-Profile-Dashboards/

我们很高兴地宣布个人资料仪表盘现已在 Moesif 中上线！我们设计了个人资料仪表盘，让面向客户的团队能够以便捷的方式监控和分析您客户的账户健康状况。这项新功能以简单、一致的方式提供客户特定信息。简档仪表板允许您查看特定用户和公司的个性化仪表板。

个人资料仪表盘是查看特定用户和公司关键指标的最简单方式。让我们了解如何查看和利用 Moesif 中的个人资料仪表板！

Moesif 的个人资料仪表板是一个新添加的功能，可为您的整个客户群提供个性化的账户指标。这是通过提供应用于每个客户的个人资料页面的可定制模板来实现的。

讯享网

Profile Dashboards 为 Moesif 用户提供了客户账户健康状况的直观分析。以前，Moesif 用户可以在每个用户和公司的个人资料下查看实时事件日志，该日志显示用户的活动以便于查看。Profile Dashboards 在此基础上进行了扩展，它允许您使用自己喜欢的图表创建一个控制面板模板，自动筛选和显示特定用户或所选公司的指标。

Profile Dashboards 只需导航到客户的个人资料页面，您就可以查看您想了解的关于客户使用情况和与您平台互动的一切信息。您的所有个人资料仪表板都源自一个模板，可以根据您的特定使用情形进行定制。以前，您需要覆盖现有的控制面板来筛选特定用户或公司，或者为每个唯一的用户或公司手动创建一个全新的控制面板。现在，您可以一次性创建模板，并在查看用户或公司简档时自动过滤和填充简档仪表板。

Profile Dashboards 的灵活性可以帮助您业务的许多领域，包括您的销售和客户成功团队。与手动过滤您需要的数据或操作现有的仪表板过滤器相比，即时访问帐户健康状况可以使某些任务变得更加容易。

一个很好的例子是，当客户向您的团队寻求支持时，他们从 API 接收到了 400 状态代码响应。您的支持代表可能需要几分钟时间来筛选和提取他们的信息。如前所述，他们首先需要复制一个现有的工作区，或者甚至需要从头开始创建一个新的工作区。然后，他们需要为客户遇到的问题设置所需的过滤器，并根据客户 ID 过滤结果。Profile Dashboards 允许客户成功代表转到用户的个人资料，并查看显示 4XX/5XX 错误的仪表板磁贴，从而简化这一过程。然后，销售代表可以轻松查看错误，并快速提供故障排除建议。

一旦设置完毕，个人资料仪表盘将是您团队工具库中的一大补充，有助于查看和维护良好的帐户健康状况。使用 Moesif 构建美观、面向客户的仪表盘。

个人资料仪表板模板位于左侧导航窗格的已保存仪表板标题的底部。在这里，我们可以为每个配置文件定制我们的布局。点击个人资料仪表板下拉菜单，显示两个子类别用户资料和公司资料。

让我们进入用户档案子部分。仪表板预览显示了我们的工作区当前的样子。它还让我们深入了解将在我们的个人用户资料仪表板上显示的内容。

与用户档案类似，公司档案可以通过点击公司档案以同样的方式访问和编辑。

使用左侧导航窗格，我们可以访问用户简介或公司简介下拉列表。我们可以看到所有已配置工作区的列表。单击其中任何一项都会直接进入配置视图，在这里我们可以根据具体的使用情形对每一项进行定制。

有多种方法可以导航到特定用户或公司的简档。您可以通过以下方式做到这一点:

• 进入事件屏幕，点击实时事件日志中的用户 ID 或公司 ID

• 导航至用户或公司屏幕，点击查找中的用户/公司 ID

调出用户或公司资料后，滚动到屏幕底部，查看所选用户或公司的资料仪表板。在此屏幕上，您将看到您创建的 Profile Dashboard 模板(或默认模板，如果您没有接触过它),其中包含为特定用户/公司筛选的指标和图表。不需要额外的工作，这都是为你自动过滤。

如您所见， Profile Dashboards 是一个很好的工具，可以为使用您平台的每个用户和公司提供个性化的图表和指标，从而帮助您业务的许多方面。我们已经为您提供了一组很好的默认仪表板磁贴来帮助您入门，但是您可以根据自己的需要轻松定制您的个人资料仪表板。要开始使用个人资料仪表盘，只需登录 Moesif 或立即注册。如果你对 API 货币化感兴趣，也可以看看我们新的计量计费功能。

原文：https://www.moesif.com/blog/api-product-management/api-analytics/Keep-A-Pulse-on-Your-Account-Health-with-Profile-View/

Moesif 产品团队最近一直很忙！我们一直在倾听我们的合作伙伴并收集反馈，我们听到的是对新工具的大量请求，这些工具可以提供对您的客户帐户健康状况的 360 度优势。因此，我们非常兴奋地宣布，我们已经发布了我们的最新功能:个人资料仪表板视图。

我们的个人资料视图旨在为面向客户的团队提供一个监控和分析客户账户健康状况的中心资源。我们创建了一个迷你仪表板，是 Moesif 的用户和公司部分的一部分，其中有许多与我们最相关的图表。该工具将允许支持团队快速了解您的客户在哪些方面取得了成功，以及他们可能会遇到哪些问题。目标是驱动更多令人愉快的平台体验。

我们开发 Profile View 工具的一个重要原因是，我们的合作伙伴告诉我们以简单统一的方式访问客户指标的重要性。他们不想管理跨平台分布的一组不同的图表。相反，我们的合作伙伴指出了在一个屋檐下拥有关键客户指标的必要性，以便准确地了解每个客户的情况。使用 Moesif 的个人资料视图，您可以使用单个模板进行操作，您的指标可以应用于您的客户群，而无需进行手动调整。

例如，假设你接到一个客户的电话，他们正在为 400/500 错误而努力。支持代表必须敏捷地工作以快速解决问题，而没有时间构建新的报告。为了实现这一点，销售代表现在可以在 Profile 视图中收集必要的产品指标，这样他们就可以诊断问题并让开发人员回到正轨。

此外，支持团队需要从战略层面运作，通过建立趋势来显示客户是否适合扩张或客户是否有流失风险。能够访问多个信号，例如最近的登录、日常使用和以简化方式呈现在 Profile View 中的功能利用，对于未来的收入目标和支持团队的成功至关重要。

虽然支持团队必须管理各种优先级，但成功指标本身可能会有很大差异，这取决于您希望优化的业务成果。这就是为什么我们的个人资料视图能够定制您想要报告的指标。也就是说，Moesif 确实提供了一些图表发件箱供你的团队使用，这为你的支持团队提供了一个很好的起点。仅举几个例子:

• 新帐户登录
• 每日 API 增长率
• 最活跃的用户
• API 错误日志
• MRR 增长

了解更多关于 Moesif 如何围绕您的分析实现协作。

登录您的 Moesif 帐户。在左侧边栏导航中的“Saved Dashboards”下，您现在应该会看到一个标题为“Profile Dashboards”的控制面板。单击该行(或其左侧的“展开”箭头)显示“用户资料”和“公司资料”选项。然后单击其中一个仪表板进行查看。这些模板决定了在每种客户类型的相应配置文件中显示哪些图表，其中“用户”代表个人用户，而“公司”代表整个组织。

在用户视图或公司视图中，您都可以找到 Moesif 的现成仪表板，但是如前所述，您可以根据组织的需求定制图表。我们的 Profile 视图在与我们的工作区相同的框架中运行，您只需点击几下鼠标就可以添加和删除图表。

一旦你完成了个人资料视图的定制，你可以在 Moesif 的客户或用户页面中测试新的个人资料。例如，如果您想要检查某个特定客户的帐户健康状况，您可以搜索该客户，然后单击他们的橙色公司 ID，从那里您可以向下滚动并查看带有您预先建立的图表的公司 dash 视图。

有了 Moesif 的个人资料视图，支持团队现在可以以闪电般的速度工作，以更好地了解他们客户的账户健康状况，因为您只需点击一下鼠标，就可以看到您需要了解的任何客户的所有信息。无论您需要从运营角度还是从战略业务角度开展工作，Moesif Profile View 都能为您的支持团队提供帮助。

原文：https://www.moesif.com/blog/api-product-management/api-metrics/Keeping-Your-API-Product-Team-Happy/

Moesif 有幸向撰写了关于 API 产品管理的书籍的专家请教。在与 Amancio Bouza 博士的广泛讨论中，我们发现作为一名 API 产品经理，你真正应该关心的是什么，而不是你可能认为的那样(提示:见标题)。我们还将讨论 API 的定价，如何成为更好的产品经理，以及床头柜上应该放什么书。

作为 API 产品经理、产品负责人、技术负责人和工程师，Amancio Bouza 拥有近 15 年的经验。除了出版关于 API 产品管理的书籍，他还帮助建立了 API 作为数字经济产品的概念，如 API 作为价值主张的接口:VPI。如今，他通过结合精益创业方法、客户关注和生态系统开发，帮助公司创造商业价值。

以下是我们的问答。为了清晰和长度，对它们进行了编辑。

问:你认为 API 产品公司最重要的 KPI 是什么？

答:要真正看一个提供 API 产品的公司是否成功，应该把重点放在留存上。

通常情况下，顾客会尝试某些东西。他们说他们想去使用你的 API，或者计划以某种方式使用它。但是当他们真正做项目时，将它集成到他们的产品或内部业务流程中，只有这样你才能真正验证他们是在以满足他们用例的方式使用它。然后，如果他们继续使用它，并且你观察到 API 使用的增长，那么你知道它在那个公司是成功的。

如果你看到有更多的吸引力，更多的公司对它感兴趣，那就更好了。但这实际上取决于 API 产品。可能市场规模很小，但对你的 API 产品来说价值巨大。

问:如果绝对数字不重要，你如何量化你的 API 可能给潜在客户带来的价值？

答:为此，您必须真正了解客户的使用情形。

我举个例子来解释一下。我曾与一家保险公司合作，该公司创建了一个新的在线门户网站来吸引用户并销售保险产品。在 onboarding 中，他们看到人们去平台、开始注册过程和注册服务的转化率只有百分之十。

我们深入研究了入职流程，以了解潜在客户必须做什么，我们看到的是大量的验证和确认步骤——发送电子邮件以验证电子邮件地址，发送短信以验证手机号码，甚至向家庭地址发送信件以验证人们的住址。

从那以后，我们看了下电话号码，发现在电话号码阶段你会失去一些人，电子邮件会让你失去更多，但是写信会让你失去更多。不仅如此，除了将信件发送到平台的营销费用之外，信件的准备和发送也要花费 6 个邮资。从那里我们估计，如果能解决这个问题，不仅公司将节省邮寄成本，但提高他们的转换率。所以我们知道，当你提供一项服务，我们可以提高转化率，他真的得到了一个胜利，通过节省邮资，他得到了另一个提升。基于此，我们还对 API 进行了定价。

因此，只有真正理解这个过程，你才能衡量你的 API 的价值。

问:就初始定价而言，如何确定 API 的收费标准？

答:我们使用一种通用的经验法则，即我们需要在一定的时间范围内收回营销成本。

我们通常从最初的估计开始，即你为注册一个新用户而投入到市场营销中的成本大约是 10 到 15 美元。请记住，10%的转化率会让你失去 90%最初被营销项目吸引的人。

然后，对于真正的定价，你不能说，好吧，听着，你作为一个公司或你作为一个潜在的客户，你将为每个呼叫节省 10 美元，所以请继续给我们 9 美元，然后你将节省 1 美元。通常将你提供的价值除以 10，甚至更多，以使它变得如此引人注目，以至于他们无法拒绝。或者像电影《格伦加里·格伦·罗斯》里那样，给他们开出一个他们无法拒绝的条件。所以在 10 倍到 100 倍之间的某个地方，是你应该结束的地方。

问:对于那些考虑提供一个 API 来补充他们现有的有前端等的“完整”产品的公司，产品经理应该对完整产品应用什么折扣？

答:我的合著者 Andrea Zulian 说，这是 API DNA 的一个缺陷，你不能只是购买和使用它，你还必须集成它，这通常不是小事。

将一个 API 集成到一个产品中通常需要公司投入相当多的资金。他们必须打开一个程序，加入一个项目团队，创建任务以将其集成到他们的测试环境中，管理持续集成、持续交付管道、沙盒测试等等。因此，这是客户为了使用 API 而不得不投资的一笔巨大成本，在您确定价格时必须考虑这一点。

但这也是整个 API 产品设计的某种机会。最好的项目经理会尽力让开发人员尽可能容易地以适当的方式集成，通过:提供一个沙箱来测试它，让用 API 进行持续测试变得容易，提供测试数据和良好的文档、SDK 和用例。

API product managers should make data-driven decisions. After specifying the API product, verify whether it brings value to the customer by closing the monitoring log file, or using a tool like Moesif to provide more insight into what is happening to the user

问:一个产品经理应该提供什么最重要的特性来使开发者的旅程尽可能的顺畅？

答:其他人可能不同意，但这是一个沙盒环境。

事实证明，通常只有少量的文档就足够了。使用或集成 API 的开发人员能够使用 API，并了解他们可以从中获得什么样的信息。通常，真正缺乏的是提供某种沙盒或测试环境。一个好的工程师想要做敏捷开发，他们想要做持续开发，或者 CI/CD，并且自动化流水线。如果你不提供某种自动化测试，他们就不能自动化测试。

近年来，开发模式已经发生了变化，真正实现了整个过程的自动化。你总是希望优化渠道，尽快将产品投入生产。如果没有适当的测试，你就不能真正确定你集成的 API 是否仍然工作，即使该 API 仍然可用。

通过排除一个测试环境，工程师将不能发光——他们将不能确定他们实际构建的是不是他们所期望的。他们定义测试用例，他们知道什么应该是正确的答案，他们知道什么应该是错误的答案，他们知道如何使用 API。但是如果没有测试环境，就会缺少一个关键部分。这通常是使用其他供应商 API 的开发人员最失望的地方。

问:API 产品经理通常必须指定测试环境吗？

答:最好的产品经理需要了解开发人员是如何思考的，他们是如何工作的，他们的需求是什么。

API 产品经理应该决定实际交付的内容和实际的 API 产品本身。因此，这是完整平台功能的一部分，就像提供沙盒环境、测试日期等，产品经理必须定义。这应该被视为他的 API 产品的一个重要特性，就像一种 SLA 特性。当然，这取决于 API 产品经理的开发团队来监控 API 的工作情况，改进平台，提供更好的沙盒环境等等。

这是 API 产品经理必须具备的新技能或视角。他现在需要了解开发人员是如何思考的，他们是如何工作的，他们的需求是什么，此外还有他的传统职责，即了解他的客户将如何消费 API。

问:产品经理如何让自己的角色更加有效？

答:充分理解 DevOps 和开发者的心态。

真正读到 DevOps 这个话题。DevOps it 将开发、运营和在生产中运行软件的整个过程自动化结合在一起，或者将软件毫无摩擦地投入生产。产品经理有一个内部开发团队，所以他应该直接问他们是怎么做的。有趣的是，提供 API 的公司也在做 DevOps，但通常 API 是以 DevOps 不友好的形式提供的。

所以我真的建议产品经理去和他们的软件工程师谈谈。他们应该从他们那里听到他们喜欢什么，他们想要什么，他们需要什么，以及他们的痛苦在哪里。有了这种视角，产品经理将对公司外部的开发人员有更好的理解。

问:深入挖掘 API 的有效负载以了解最终客户如何使用它是否有很大用处，或者产品经理的工作范围是否仅仅停留在基础设施监控上？

答:通过研究有效载荷可以获得很多价值。

我认为这两者都为 API 产品本身提供了有用的视角。举个例子，如果你在你的 API 调用中发现很多错误，比如 4xx 响应(某些东西不存在)，可能是某些东西出错了，或者消费者，从他的角度来看，正在做一些正确的事情，错误消息实际上是一个有效的结果。这可能发生在数据库中不存在 person 的搜索 API 中，但是 4xx 错误实际上是有效信息。

API 产品经理很少能够看到有效负载，真正理解 API 消费者需要什么样的信息，然后解释并从中学习。

例如，我与一家支付 API 提供商合作，我们发现所有的交易，或者说大部分交易，都是小额支付。然后我们说，好吧，作为一个供应商，我们需要改进我们的微支付计划——我们需要尽可能降低这些交易的成本。如果你不能支持微交易，因为它们太贵了，也许你应该提供批量微支付。你看，在这个案例中，我们了解了消费者如何使用 API，然后调整 API 产品，这样我们的客户获得了更多的价值，组织也获得了额外的价值。

问:你参与开发的其他 API 产品是否受益于以用户为中心的分析？

答:大型电信运营商的数据治理。

在一家大型运营商处，我们构建了一个身份验证 API 产品，该产品在数据隐私/数据治理方面有非常具体的规则。他们的法律部门说我们不能提供运营商客户的信息，只能提供运营商以外的信息。

在设计阶段，我们实现了一个系统，允许直接调用来进行身份验证，只是规定如果您正在验证运营商的零售、商业或 VIP 客户，则不允许使用 API。当我们查看日志文件时，我们发现客户在不应该使用它的时候使用它。为了指导他们做正确的事情，我们重新设计了 API 产品，以符合我们的内部规则——我们实现了一个密钥，只有在验证他们没有搜索客户后才提供该密钥。

问:成功的 API 产品经理应该遵循的首要标准是什么？

答:这可能不是一个衡量标准，但它是构建您的 API 的团队的快乐。

当他的团队受到鼓舞和激励时，当他们学习新的东西来提高自己时，这对项目经理真的很有帮助。如果你有一个快乐的团队，那么他们真的关心提供好的错误消息，他们关心他们的客户，想让他们真正成功，他们会为 API 产品经理提供支持，帮助创造最好的 API 产品供消费。我不知道如何，或者在多大程度上你可以真正衡量它，但至少你应该和他们谈谈，感受一下他们是否快乐，如果不快乐，你可以做些什么来改变这种情况。

问:你要遵循的另一个最重要的衡量标准是什么？

答:入职时间。

第二个是入职流程，或者说一个公司真正集成一个 API 需要多少时间。这不仅仅是遵循一个很好的指标，如首次 Hello World 的时间，或首次 API 调用的时间，它实际上是关于客户需要多少时间来支持 API:测试它，集成它并将其投入生产。

好的一面是，如果你正在记录 API，或者有这样的工具，比如 Moesif 的，这些将显示真实的情况。你可以问你的客户他们是否在使用你的 API，但是如果你没有看到任何你不知道的流量，好吧，他们没有使用它。我们与一家保险公司合作，他们说他们在使用 API，但是我们从来没有看到任何流量，所以我们知道有问题。我们找到他们，问他们我们如何帮助他们整合，然后我们一起想出了该怎么做。有时项目被推迟或者有依赖性，但是其他时候有集成问题，你真的可以帮助解决。

问:除了你自己的书，你推荐产品经理应该读什么？

答:全面的产品经理知道如何围绕客户旅程创建生态系统。这四本书就如何做提供了全面的描述。

Roman Pichler 的《运筹帷幄:数字时代的产品战略和产品路线图实践》是第一本关于数字产品的书。作者真正理解了如何做利益相关者管理，如何将数字产品定义为服务。他预见了数字产品的趋势。

The Lean Startup:How Today ’ s Entrepreneurs using The Continuous Innovation to Create probably business 作者 Eric Ries 了解基于数字验证你的想法的方法。

Mehdi Medjaoul 等人的《持续 API 管理:在不断发展的环境中做出正确的决策》面向 API 架构师、开发人员和产品经理，从您需要的角色类型到组织主题，从技术角度提供了 API 产品管理的全貌。

詹姆斯·马龙的《竞争之死:商业生态系统时代的领导力和战略》讲述的是如何构建商业生态系统。API 的最终承诺是你成为一个生态系统的一部分，一个让你在特定行业之外有价值的生态系统。行业之间不再有壁垒，相反，你可以通过正确的合作方式，参与围绕客户旅程创建的生态系统。

原文：https://www.moesif.com/blog/announcements/features/Leveraging-User-Behavioral-Analytics-For-API-Analytics-Platforms/

行为分析揭示了用户在你的产品中采取的行动。从一开始，Moesif 就将原始事件数据、特定的 API 调用组织成每个用户行为或旅程的时间线。其中最著名的例子是我们追踪新用户转化的漏斗视图:注册>第一个 API 调用>第一个工作应用。

我们现在已经增强了我们的用户和公司过滤功能，因此您可以超越按客户人口统计和其他传统属性进行的典型分析，而是专注于了解用户如何行动以及他们为什么执行这些行动。相反，用户行为使您能够了解跨多个 API 调用的复杂用户交互事件，或者客户进行这些调用的频率，而不是关注单个值的时间序列指标。

担心上周 API 调用(400 或 401)失败的美国公司？

我们刚刚在用户查找和公司查找下完成了一个相当大的更新。新功能包括:

• 动作:过滤公司或用户，不仅通过人口统计，还通过动作——他们在你的 API 上做了什么
• 数量:在特定的时间范围内有多少行动
• 组合:可以使用 AND 和 OR 函数一起检查多个动作
• 图形化:过滤不仅在 lookup 中受支持，在复合视图中也受支持

查看行为过滤器灵活性的**方式是通过用例的图解:

用例 1:显示在过去 24 小时内进行了至少 9 次 API 调用的所有用户

用例 2:向我展示上一季度美国所有 API 调用失败的用户

用例 3:按营销活动渠道绘制的图表所有购买的美国用户，按 API 的年龄

随着 Moesif 行为过滤器的发布，您现在可以使用简单的下拉菜单和查询框来询问复杂的数据问题:

想要通过活动来源识别在过去 3 天内提出 3 次购买请求的用户？

有了行为过滤器，产品经理现在可以对功能做出更具洞察力的决策，营销人员现在可以在正确的时间向正确的用户群提供正确的产品。

原文：https://www.moesif.com/blog/technical/kong/Load-Balancing-using-Kong-API-Gateway-with-Docker/

为了打破单一应用架构的僵化，开发人员正大量转向微服务。微服务是大型软件中的小型、独立、松散耦合的模块，它们通过 API 相互通信。微服务架构提供容错能力，支持连续交付，并能够跨多个区域扩展以确保高可用性。

在本文中，我们将展示一个例子，说明如何使用最流行的 HTTP 服务器之一 NGINX 作为核心构建的一个流行的开源 API 网关来实现负载平衡。通过 Kong，您可以从一个集中的位置获得更多的控制，以处理身份验证、速率限制、数据转换等事项，即使您拥有多个微服务，而不是典型的负载平衡器。

负载平衡是高可用性基础设施的关键组成部分，用于将用户的请求负载分布在健康主机的多个服务上，以便没有主机过载。

单点故障可以通过引入负载平衡器和服务副本来缓解。每个服务都将返回相同的响应，因此无论调用哪个服务，用户都会收到一致的响应。

Kong 为多种服务提供了不同的负载平衡请求方法——基于 DNS 的方法、循环法和基于哈希的平衡方法。基于 DNS 的方法将以这样的方式在 DNS 中配置域，即用户对域的请求分布在一组服务中。循环法会将负载均匀有序地分配给主机。当使用基于散列的平衡方法时，Kong 将充当服务注册中心，通过一个 HTTP 请求来处理服务的添加和删除。

Kong 可安装在多种操作环境中。根据您当前使用的环境设置 Kong。关于如何安装孔的更多细节

我们将启动两个服务，它们将是两个 NGINX 实例。我们会拉基于 NGINX 和 LuaJIT 的 OpenResty 官方 docker 镜像。

讯享网

让我们启动两个服务，并将其映射到不同的端口

在配置服务之前，我们将安装软件包。

讯享网

现在，我们将使用两个端点和来配置服务，我们将分别验证和监听端口和。我们将更新的配置文件。

我们将重新启动服务，以确保反映最新的配置更改。

讯享网

如果我们根据配置点击它们，我们将很快看到服务的响应。

这个想法是让两个服务成为彼此的副本，这样我们就可以在它们之间负载平衡我们的流量。

我们将从 Kong 开始，将通过 Kong 的流量代理为反向代理，而不是直接访问 NGINX 实例。

为此，我们必须向代理端口和管理端口发出请求。

创建服务

我们将创建一个名为的服务。

讯享网

创建路线

我们将创建一个接受流量的路由，并将从该路由收到的所有流量发送给上面创建的服务。

此时，我们能够通过 Kong 将流量代理到 port 服务。

讯享网

太棒了，我们实际上是通过 Kong 将流量代理到上游，因为 Kong 将在响应中添加几个报头。

我们还可以将流量代理到任何上游端点，这使得 Kong 完全透明，因为它不关心我们发送哪个请求，只要它匹配我们在路由中定义的规则，它就会将该请求代理到上游。在我们的例子中，它是,这基本上意味着通过 Kong 的每个请求都将被代理到端口服务。

现在让我们谈谈我们在上游定义的另一个端点。

如果我们想强制每个请求通过上游被认证，我们可以创建一个路由并在该路由上应用插件。

创建路线

为了尽可能的灵活，Kong 有一个配置参数来定义我们是否剥离请求路径，默认为 true。这意味着被代理为上游的。因此，我们必须通过一个简单的补丁请求来禁用它。

讯享网

现在，如果我们向发出请求，它将正确地向上游的发出请求。

现在让我们将插件应用于路线。

讯享网

我们需要在调用端点时传递 API 键，因为我们必须创建消费者。

为了获得 API 密钥，我们将发出一个 POST 请求

讯享网

我们用 API-key 作为头向发出请求，

我们可以看到,已经过身份验证，并按照上游配置返回响应。

您已经观察到另一个服务处于空闲状态，没有接收任何流量。这里的目标是平衡两个服务之间的流量负载。

我们不打算使用基于 DNS 的负载平衡，而是使用类似于 NGINX 中的模块的手动完成。我们必须给出的唯一参数是，在我们的例子中是。因此，每个主机名为的服务都将通过上游代理，这将做出负载平衡决策。

讯享网

我们将为这两个端口添加目标，并开始在服务之间代理负载平衡流量。

现在，如果我们通过 kong 发出请求，它将在两个服务之间实现负载平衡。

如果我们关闭其中一个服务，Kong 将使用重试机制。但是在某些情况下，如果我们在相同的上游用尽所有的重试，仍然可能有错误。在监控 Kong 日志时，您可以看到 Kong 正在做出的决定。它正试图与第二个上游通信，但未能成功，并重试对第一个上游的请求。我们的负载平衡槽的大小相当大，可能需要一段时间来访问另一个服务。在这种情况下，我们必须继续发送更多的请求。

要了解如何使用您的 API，捕获 API 请求和响应并记录到 Moesif，以便通过 Kong 轻松检查和实时调试您的 API 流量。有关如何安装 Moesif 插件的更多详细信息，请查看此方法。

同时，如果您有任何问题，请联系 Moesif 团队

原文：https://www.moesif.com/blog/technical/logstash/Logstash-Filter-to-run-ElasticSearch-Queries-Dynamically-on-Events-in-Scala/

不要将此过滤器与 Logstash 内置过滤器 ElasticSearch 混淆，后者可用于将 ElasticSearch 中现有事件(或任何其他对象)的字段加载到当前事件中。这里解释的 Logstash filter 用于检查事件是否与给定的 es 查询相匹配，并根据事件是否满足查询来采取行动。这个 logstash 过滤器也是在 Scala 中开发的(除了 java 中的插件链接部分)。

因此，无论是对设计通过在事件上运行 ES 风格的查询来采取某种行动的解决方案感兴趣的人，还是对在 scala 中开发 Logstash filter 感兴趣的人，这篇文章都是相关的。本文首先关注如何在 scala 中开发 Logstash filter，然后关注如何实现 Logstash filter 来通过 es 风格的查询过滤事件

Logstash 7.2.0 包含对 Java 插件(GA)的原生支持。早期的版本(6.6.0) 提供了测试版支持。关于如何编写 java 过滤插件的 Logstash 文档对如何用 Java 编写插件有明确的说明。我将只关注在 scala 中开发插件所需的额外变化。

下面是如何将 scala 源文件链接到 Java 示例过滤器插件的说明

创建 scala 源模块

您需要在项目 src/main 下创建一个 scala 目录，并将其标记为 source 文件夹(这些是针对 IntelliJ 的说明，其他 IDE 可能需要遵循不同的步骤)。确保在 IntelliJ 模块设置中包含 scala 库依赖。在 scala 源代码模块下，可以根据需要创建包和源文件。项目结构可能如下所示

梯度构建配置

Gradle 构建配置文件可用此处需要更改为包括

1. scala 库依赖
2. 首先编译 scala 代码，然后编译 java 代码的配置

对于步骤 1，当构建插件时，确保 scala 库 jar 包含在最终的 jar 中(grad le dependencies . implementation 选项编译代码，但是除非使用 dependencies.compile 选项，否则不会包含所需的 scala 库)，否则您会遇到问题，插件的 scala 部分不会在 Logstash 中执行。这是因为 Logstash 运行时环境不需要 scala 库

讯享网

通过对 gradle.build 文件的上述更改，src/main/scala 中的 scala 源代码应该在 java 和 gem 文件中生成的 fat jar(之后)之前编译。/gradlew gem)应该包含在 Logstash 中运行插件所需的所有库

在 java 源文件中使用 scala 类

在 java 类中使用 scala 类/对象/方法非常简单，这里有几个例子

ElasticSearch 查询支持多种运算符，包括搜索数据的聚合。这里我们只关注测试事件字段的布尔查询。测试事件字段的示例查询

查询 A

查询 B

讯享网

一旦事件匹配给定的 es 查询，应该做什么取决于您正在处理的项目。在这篇博客中，我们解释，假设每个查询都有唯一的标签，如果事件满足给定的查询，如何用查询标签来标记事件。

我们的方法包括两步

使用 and、or 等将 ES 查询优化为简单的平面表达式

上面的示例查询将被转换成如下的平面表达式，并在前面加上查询标记

将 es 查询转换成平面表达式的 Scala 代码可从这里获得ElasticSearchQueryTransformer。ElasticSearchQueryTransformer 不仅转换查询，还通过删除不必要的表达式来优化查询，同时保持逻辑等价

讯享网

上述查询转换成平面表达式

日志隐藏过滤器弹性搜索 _ 查询 _ 过滤器

在 Apache 许可下可用的 elastic search _ query _ filter这里使用简单的平面表达式来评估事件。上面步骤中的平面表达式需要对过滤器可用，这可以通过几种方式实现

1. 将平面表达式存储在 ES 中，并使用内置过滤器 elasticsearch 将平面表达式加载到事件本身中(这是我们所做的，也是 elasticsearch_query_filter 所期望的，不会改变)
2. 平面表达式可以保存到任何其他数据库中，并可以使用特定于该数据库的不同插件加载到事件中
3. 更改 ElasticSearchQueryFilter 类，以便在插件初始化时将平面表达式加载到内存中

ElasticSearchQueryFilter 根据平面表达式评估传入事件，并用匹配的查询标签标记事件

测试 Logstash 过滤器插件

需要首先安装 Logstash 过滤器

讯享网

logstash_test.conf 有测试日志 stash 配置

安装过滤器后，可以使用上面的配置运行 logstash 来测试过滤器插件，输出事件应该包含值为 tag1 和 tag2 的字段 matched_query_tags

讯享网

Java 执行引擎的性能与 Ruby 执行引擎不相上下，甚至更好。现在，如果你像我一样喜欢用 scala 编码，我们可以使用 java 进行更快的插件开发，以及来自其丰富的生态系统或 scala 的其他好处。上面的说明应该可以指导你如何在 scala 中编写插件。如果你的插件项目需要根据事件是否匹配 Elasticsearch 风格的查询对事件采取一些行动，你可以使用代码这里

原文：https://www.moesif.com/blog/technical/timestamp/manage-datetime-timestamp-timezones-in-api/

假设您有一个应用程序(移动或网络)，通常您希望显示终端用户的当地时间。但是，您的数据库仍然需要存储时间。虽然这是一个常见的场景，但经常会出现几个问题:

• 您应该如何在数据库中存储用户的时区？
• 你什么时候把它转换成当地时间？
• 假设您在客户端和后端之间有一个 API，时间戳应该如何表示？
• 日期时间将以什么格式存储在数据库中？

数据库被设计成高效地存储日期，最小化空间，同时尽可能快地进行查询。因为整数比字符串更容易查询、索引，并且空间效率更高，所以日期通常存储为 64 位整数，例如以毫秒为单位的 unix 纪元。作为数据库的用户，您通常不需要关于实现细节的详细信息，因此可以利用数据库提供的或数据类型。应该没有理由将日期存储为原始字符串或 bigint。

数据库会将任何转换成 UTC 纪元以存储在内部。但是，一些数据库可能支持存储时区信息。如果是这种情况，建议在存储之前将所有日期转换为 UTC。

不要使用本地时区。否则，当您的数据库部署在跨多个时区的多个数据中心的高可用性设计中时，您将会非常紧张。

移动应用和单页应用等前端客户端需要通过 API 与后端通信，这些 API 可能有字段。像数据库一样，为了保持 API 的一致性，HTTP 响应的有效负载应该总是使用 UTC。然而，你的 API 应该遵循健壮性原则:*在你做的事情上要保守，在你从别人那里接受的东西上要开明。*因此，您的 API 应该解析 HTTP 请求体或 URL 参数中的任何时区，而不需要 UTC。一些 API 将时区信息的缺失默认为 UTC。

与大多数数据库不同，JSON 中没有本地的数据类型，因此日期必须存储为 JSON 或 JSON 。这两种方法都可行，但是应该遵循标准，这意味着日期字符串应该被格式化为 T4 的 ISO 8601 格式之一。日期数字应该存储为 Unix 纪元时间和指定秒或毫秒的 API 契约。

这两种方法之间存在分歧。Twitter、DropBox、Segement.io APIs 使用 ISO 8601，Chargebee、Pusher 和 Stripe APIs 使用 Unix Epoch Time。

我们 Moesif 更喜欢 ISO 8601 ( )，因为它是人类可读的，并且有特定的时区。如果历元是以秒或毫秒为单位，则没有歧义。ISO 8601 字符串是以一种支持体面的字符串排序和比较的方式编码的。

Epoch 也比 ISO 8601 有优势。如果您正在处理大容量传感器数据或物联网设备的 API，您可能需要 epoch，因为它支持较小的有效载荷，无需考虑压缩，并且更熟悉来自物联网/嵌入式背景的数据。

首先，决定是否需要存储用户的时区。

如果您的需求是在应用程序中只显示用户本地时间的日期时间，您甚至不需要存储用户的时区。浏览器 javascript 和移动 API 可以根据用户设置的时区和地区转换日期时间并打印出来。

但是，您可能会发现，您稍后将执行后端处理来启动与您的用户的通信，例如 Slack 警报或电子邮件。在这种情况下，您可能会在数据库中缓存用户的时区/地区信息。因此，您可以在发送提醒或电子邮件之前转换并漂亮地打印任何日期时间。

避免存储 UTC 偏移量的陷阱，因为偏移量经常会因夏令时等因素而改变。建议存储时区标识符，如。有一个大多数日期时间库本身支持的时区的完整列表。

如果您有一个全球应用程序或 API，管理不同时区一开始看起来很有挑战性。这篇文章基本上概述了保持简单的策略，并且在向用户显示之前一直使用 UTC 时间。

Moesif 是最先进的 API 分析平台，支持 REST、GraphQL、Web3 Json-RPC 等。成千上万的平台公司利用 Moesif 进行调试、监控和发现见解。

了解更多

原文：https://www.moesif.com/blog/developer-marketing/Market-Your-SaaS-Platform-To-Developers/

如何在不确定的时期向开发者推销你的 SaaS 平台

健壮的 API 和开发者平台对不确定性具有弹性

在数字平台上创建一个有凝聚力的营销形象不仅对加强品牌知名度，而且对消费者参与度都至关重要。虽然为最坏的情况做计划从来都不是一件有趣的事情，但是必须有适当的结构来利用长期的解决方案来应对(希望)短期的下降趋势。冠状病毒疾病的溢出效应和随后的就地安置给初创企业带来了严重后果。由于就地安置规则而关闭的小型实体企业不再花钱在脸书或 Yelp 上推广他们的业务，也不会维持他们的 SaaS 订阅。大型企业可以也将会在预期业务下滑的情况下缩减销售和营销支出。虽然不能保证，但这种行为会导致 SaaS 合同的使用或座位数的减少。首席财务官和财务总监将阻止比以前更多的收购，这可能会迫使 SaaS 的交易陷入僵局。…

好消息是，许多开发人员平台和 API 都有一些技巧，可以让他们更好地适应快速变化的环境。然而，如果你今天没有执行这些想法，现在是时候重新考虑，以确保你的产品和/或公司的寿命。

在不确定时期，许多大型企业由于自身的财务限制，不愿投入财力和人力资源来开展有偿试点或签署大型企业合同。你可以通过案例研究和强大的客户标识获得最好的社会证明和量化数据，但副总裁可能已经收到冻结所有非关键任务支出和招聘的指令，让他们别无选择。从积极的一面来看，许多高级工程师和经理都有 SaaS 工具的自由支配支出预算。

虽然预算可能很小，仅允许每月 100 美元到 1000 美元之间的支出，但这些支出通常不需要签核或批准。通过正确的基于使用的定价模式，您将能够随着时间的推移扩展这些帐户，甚至可能接近您通常在小型企业协议中看到的 ACV，即使客户是通过信用卡按月支付。当你的竞争对手眼看着他们的销售渠道枯竭并解雇大量销售人员时，你开始获得自助服务客户，一旦他们的市场开始复苏，他们的使用可能会迅速增加。

自助服务企业有多种定价方式。通常，您希望使用价值指标而不是成本指标来定价。但是，您可以利用多个价值指标。理想情况下，确保您的定价支持自动追加销售，即使在裁员的情况下也是如此。例如，通过 CRM 中的联系人数定价的销售工具或通过 MAU(每月活跃用户)定价的营销工具将比利用每席位定价的工具做得更好。大量裁员会导致公司重新协商降低座位数。然而，很少有公司会经历 MAU 或联系人数的下降。

如果你还没有任何产品分析工具，现在正是时候。尽你所能探测一切。检测您的 API。检测您的 web 应用程序。确保每个广告或外部链接都利用了 UTM 参数。。这使您能够了解哪些获取渠道具有最高的投资回报率，并推动产品增长。漏斗顶端的增长不再理想。你应该只投资直接转化的渠道。对于大多数开发人员平台来说，这意味着客户实际上已经集成并正在积极使用您的 API。如果你只是在衡量页面浏览量和注册量，那就停下来重新评估一下你的真实想法

随着会议线路慢慢恢复生机，现在是时候考虑一下你的在线表现了。创建博客帖子和网络研讨会，既可以发布到您自己的博客上，也可以联合发布到您的空间中的合作伙伴。内容的关键是确保它的真实性和相关性。高质量的内容几乎总是胜过纯粹的数量。通过创建内容，你增加了你在有机搜索中的存在，但你也获得了其他好处。例如，潜在客户将通过社交渠道分享内容，让你免费获得额外的曝光率。您还可以在跟进潜在客户时利用这些内容。你可以通过分享内容让他们按照自己的节奏消费来展示价值，而不仅仅是“让我们安排一个时间来聊天”这样一致的暗示。

在任何不确定时期，识别和最小化客户流失风险变得比漏斗增长顶部更重要。很多时候，我们可以通过重新安排已经注册和/或正在付费的潜在客户的优先顺序来找到额外的增长。您应该有一个机制来跟踪帐户健康状况，并在情况不妙时得到提醒。需要注意的事项:

• API 使用率逐年下降的客户
• 仅访问一个或两个终端的客户
• 查看下降较高的 SDK，这可能表明存在缺陷或缺少文档
• 具有大量错误或延迟(如未经授权的错误)的客户
• 尚未访问您的主要价值创造端点的客户

取决于你的公司，你可能有一个更传统的客户成功部门，或者可能有一个 devrel 组，开发人员支持接管一些更传统的客户成功职责。在任何低迷时期，你当前的客户都是你最大的支持者。让他们用你的 API 和令人敬畏的开发者体验获得成功，他们会告诉他们的同事和朋友。一些小事情包括跟进那些已经集成了你的 API 的开发者，看看他们在构建什么，你能提供什么帮助。如果您发现客户遇到了集成问题，请伸出援手。

当付费营销预算缩减，销售人员减少时，实现同样的增长里程碑可能看起来像是一个梦想。然而，有无数的开发者平台利用合作和集成来实现有机的低成本增长。看看任何一家提供你可以上市的市场的公司，比如 GitHub、Heroku、AWS 等等。因为其中一些可能会减少你的知名度拥挤，你也应该看看其他 SaaS 工具，你的目标买家也在使用。如果你是一个营销工具，也许与 Hubspot 整合是有意义的。如果您是一个 API 监控工具，那么构建与 PagerDuty 和 Slack 的集成可能是有意义的，这样您的客户就可以通过他们现有的设置获得警报。

向开发者推销一个 API 平台是困难的。通常营销和销售预算需要减少，企业更不愿意签订新合同，等等。通过关注你的采用漏斗，寻找廉价的增长渠道，如内容和合作伙伴关系，可以奏效。

原文：https://www.moesif.com/blog/developer-marketing/inbound-content/Marketing-to-Developers-during-a-Recession/

这是德里奇·吉利恩 在 DevRelCon Earth 2020 上的演讲。

https://www.youtube.com/embed/Ph3KeQezQXY?start=17075

下面是附带的幻灯片。

//www.slideshare.net/slideshow/embed_code/key/Ieri5aXOZ31Suj

原文：https://www.moesif.com/blog/technical/api-analytics/Mastering-API-Analytics-for-API-Programs-Chapter-1/

你有一个开发人员正在采用的 API 程序，但是不确定采用了多少。新的集成需要多长时间才能产生收入？如果你有网络或移动产品管理背景，你可能已经熟悉了用于衡量应用参与度和留存率的移动产品分析。成长中的 API 有相似的 KPI 来衡量你的 API 程序的成功。本文将更多地讨论您应该测量什么以及如何利用这些信息。

而传统的客户漏斗将仅由营销和销售漏斗组成。然而，作为一种产品，客户和合作伙伴包括开发人员的 API 拥有所谓的开发人员漏斗或集成漏斗。开发者漏斗在营销漏斗之后，销售漏斗之前，有三个核心阶段:

预整合阶段

开发者进入营销漏斗后的预整合阶段。虽然什么是营销漏斗，什么是开发者漏斗，这是一个模糊的概念，但意图是主要因素。他们只是在考虑通过案例研究、内容和演示账户等明确定义的营销资产来开发解决方案，还是承诺自己测试解决方案。

一旦评估或考虑阶段是积极的，就有测试的意图。这将导致开发人员开始安装，这可以通过创建一个空白工作区、下载一个配置文件或复制一个 API 密钥来看到。

这意味着你的产品是免费增值，有免费试用，或其他。

沙盒阶段

一旦在 API 上采取了一个动作，潜在客户就进入了沙盒阶段，这给了开发人员一种温暖的感觉，他们完成了一些事情，并且能够验证这是一个对他们来说可行的解决方案。从预集成阶段到沙盒阶段的时间通常用到第一个 Hello World (TTFHW)的时间来衡量。这是一个关键的 KPI，每个 API 产品经理都应该尽可能地跟踪和减少它。

开发人员可能不会进入沙盒阶段，原因有很多，包括:

• 集成问题，如 SDK 或实现中的错误和 bugs】

  例如，如果开发人员从您的 API 收到 500 个错误，或者 SDK 没有对您的 API 进行任何调用。后者是最难衡量的，因为开发人员完成了实现，但您没有采取任何行动。

• 没有简单的方法来验证实施是否正确

  如果你的产品在集成后看起来是空的，开发者可能会认为它不起作用。对于安全和分析公司来说，这种情况可能会发生，因为在处理大量数据之前，这些公司不会有有意义的见解。

• 对 API 采取了行动，但不清楚值是什么

  这个行动应该有一个明确的价值，而不仅仅是一个“你被整合了”的信息对于通信 API，该值可能是发送一条 SMS。对于分析公司来说，它可能是捕获和显示单个事件。

当集成成功并且有明确的价值标志时，开发人员就进入了沙盒阶段，从而创造了你的啊哈时刻。这些开发人员开始成为您的解决方案的内部倡导者。

生产阶段

一旦开发人员看到了解决方案的价值，他们就会希望尽快将他们的实现推向生产。然而，由于内部的阻碍，开发者可能无法将你的 API 推向生产，很多阻碍都超出了开发者个人的控制范围。

开发人员可能出于多种原因不进入生产阶段，包括:

• 项目优先级

  客户错误或其他项目特性可能会优先考虑。您的通信 API 集成退居二线，只是因为开发人员被分配了一堆吉拉入场券。

• 法律与合规部

  特别是在金融和卫生等受监管的行业，开发人员可能必须等到法律部门的必要批准。

• 功能和性能测试

  公司可能有测试第三方服务的内部政策，这些服务需要首先完成。

您的目标是让开发人员拥有正确的工具来消除这些异议。一旦开发人员进入生产阶段，就会有大量的流量从该帐户流向您的 API。达到生产级流量所需的时间可以称为到第一个工作 App 的时间 (TTFWA)或到第一个付费 App 的时间 (TTFPA)。

为了对你的 API 业务有一个准确的快照，每个漏斗边界都需要明确的目标。让我们以搜索 API Algolia 为例。

集成前步骤目标

Algolia 的第一步将是开发人员使用 API 密钥复制功能。此时，开发人员已经注册，并且正在经历入职流程。

沙盒步骤目标

Algolia 的 API 有两个核心特性。查询或搜索 API 和索引 API。Algolia 的成功标准是开发者能够通过索引 API 索引至少一个实体。如果开发人员在 Algolia 中没有存储任何数据的情况下调用查询 API，这不被认为是成功的，因为查询将是空的。

为了简化集成，他们可以:

1. 驱动用户通过端点索引新实体
2. 使用示例数据引导开发人员可以查询的示例索引

假设我们使用(1)，那么我们的漏斗转换点将是任何至少执行了一个操作的开发者。Algolia 可能想要一个更严格的转换指标，以便他们可以跟踪任何至少执行了一个 操作和一个 操作的开发者，其中响应内容长度> 0 。这意味着开发人员成功地索引了至少一个实体，并且能够读回它。

生产步骤目标

为被认为是生产级别的流量创建一个指标可能很难，因为它可能依赖于行业或项目。对于 Algolia 来说，电子商务应用程序与拥有大量动态内容的内部企业应用程序相比，具有不同的生产使用级别。对于具有动态内容的企业应用程序，每个实体可以用更新的数据以编程方式在一天内被重新索引数十或数百次。但是，如果数据从来不被查询，那么 Algolia 的值还没有被看到。因此，只寻找拥有超过 1000 个操作的开发人员可能不是跟踪的**价值指标。一个更好的价值衡量标准可能是拥有超过 1000 个 操作的开发者，其中响应内容长度> 0 。

请注意我们如何关注 Algolia 的核心价值，即搜索。我们不太关注辅助功能，如 Algolia 的监控 API、报告 API 等，也不关注高级功能，如同义词或规则 API。

现在我们已经了解了开发者漏斗每个阶段的转化率，重要的是利用 API 分析来了解不同的开发者群体如何通过你的开发者漏斗。没有它，你会有一种虚假的成功感。

例如，从预集成到生产阶段，您可以有很高的转换率，但是如果大多数开发人员在没有购买力的情况下从事辅助项目，那么您可能需要重新评估您的目标。

建立用户和公司的档案

为了进一步细分你的漏斗，你的 API 分析解决方案应该有办法创建用户简介和公司简介。建议在用户配置文件中跟踪的变量包括:

• 电子邮件
• 名字
• 职称
• 参考网站

建议在公司中跟踪的变量包括:

• 公司收入
• 雇员人数
• 工业
• Alexa 等级
• MRR 计划

一旦你有了这些信息，你的开发者漏斗分析就会变得更有价值。您可以看到谁在集成，谁没有，而不仅仅是跟踪高层次的集成之旅。例如，我们可以通过公司收入进行细分，以比较从事副业项目的用户转化率与财富 500 强公司工程师的转化率。

将公司(即客户)与用户分开跟踪，确保您能够创建使用您的解决方案的组织中开发人员或团队数量的指标。

理解 API 设计

就像建立用户和公司的档案一样，你的 API 分析解决方案应该理解你的 API 的业务功能。如果您的 API 是 rest，那么只跟踪和将没有价值。然而，添加与 API 事务相关联的元数据可以为您提供更高级别的使用模式趋势。例如，如果您的 API 是 RESTful 的，那么您的分析解决方案应该将 API 事务存储到一个特定的 REST 资源操作中，比如。这支持更高级别的图表，如下图所示，显示了使用每个 REST API 操作的顶级公司。

定义 API 项目

在我们深入研究获取渠道绩效和 API 增长等关键业务指标之前，我们需要定义什么是 API 参与度。毕竟，一个开发人员仅仅触及你的根端点或者仅仅探查 API 的健康可能不被认为是真正的参与。继续 Algolia 的例子，Algolia 的核心商业价值问题是快速搜索。因此，他们定义 API 参与度的标准是客户在过去 28 天内至少执行一次搜索。

有效的新客户获取可以成就或摧毁一个原料药企业。在衡量不同流量来源的在线营销活动的有效性时，必须考虑开发者漏斗中定义的三个步骤的转化率。API 产品营销领导应该超越注册等基本指标，考虑开发者集成漏斗。这使您能够了解这些注册在整合步骤中进行了多少。

例如，像脸书广告这样的渠道可能会给你的 B2B 解决方案带来很大的影响，但如果这些注册中有很小一部分由于目标不明确而最终通过了整合过程，那么你的渠道的整体有效性就会降低，因为你不太可能从那些只注册而不做任何其他事情的人那里获得太多价值。

如何正确衡量开发者营销渠道

如果我们同步营销数据，例如来自营销自动化和分析工具(如 Hubspot 或 Amplitude)的海胆跟踪模块(UTM)参数，那么我们可以在队列分析中利用这些数据。这使我们能够利用我们早期的开发者漏斗，并通过渠道进行细分。一旦我们做到这一点，我们就能够看到按活动细分的每个步骤的转化率。

什么是 Moesif？ Moesif 是最先进的 API 分析平台，被数以千计的平台用于了解您最忠实的客户正在使用您的 API 做什么，他们如何访问它们，以及从哪里访问。

API MAU 和 API DAU

如果你想跟踪你的 API 程序的增长，那么 API 月活跃用户 (API MAU)和 API 日活跃用户 (API DAU)是每个数据驱动的产品领导者应该跟踪的两个 KPI。

这类似于 web 和移动 MAU，可以提供增长指标和 KPI 的高级概述。然而，API MAU 不是跟踪执行 UI 交互(如在应用程序中点击按钮)的不同用户，而是跟踪执行与 API 的编程交互的不同用户。根据您所在的行业，不同的用户可以是个人用户或开发人员，也可以是不同的公司或帐户。像 Moesif 这样的 API 分析产品可以跟踪哪个对账户级分析至关重要。

为什么是 28 天？

尽管我们说的是 MAU，但我们实际上应该衡量固定的 28 天窗口中的活动，而不是整个月。通过使用 28 天，我们能够忽略由于一个月中的天数不一致而产生的偏差。此外，28 天确保每个时间窗口在同一个工作日开始。这保证了我们在每个时间窗口中总是有相同数量的工作日和周末。许多公司，尤其是 B2B 公司，在周末的使用水平与工作日不同。通过保持这些数字的一致性，我们可以消除这些偏见。

28 天 API 使用量/28 天活跃公司

您还应该跟踪每个活跃公司对同一合约定义的总 API 使用量。API 使用量只是 API 调用子部分的总 API 使用量，而不是计算不同的用户。通过按活跃的公司划分 API 的使用，您可以跟踪每个客户是如何随着 API 的发展而增长的。该指标是收入增长的领先指标。如果 API 使用量/活跃公司数持平(或者更糟的是下降)，您的 API 不会随着客户的增长而增长，并且可能很难推动销售突破计划限制。然而，随着 API 使用/活跃公司的快速增长，API 计划将享有不断增长的平均合同价值和总收入。当然，这假设你的定价是基于一些使用指标，比如 Algolia 的搜索操作或索引操作。

如果你有一个像 GitHub 或 Intuit 的 API 一样有数百个独立功能和实体的 API，那么测量每个应用程序调用多少个独立的函数可以帮助你了解 API 使用的广度。将此绘制成直方图有助于找出完全使用您的 API 的高级用户与可能只使用一两个端点的其他开发人员相比所占的百分比。如何跟踪不同的 API 操作将取决于 API 的架构。例如，如果您的 API 是 REST，那么您可能有 REST 端点，如:

然而，如果您的 API 是 GraphQL，您可能希望跟踪查询和变异操作，如:

讯享网

如果您打算构建一个不断增长的 API 程序，那么您应该跟踪许多更深入的 API 指标。然而，如果您还没有开始采用数据驱动的方法，这些指标是一个很好的起点。随着您的 API 程序的发展，您将跟踪其他 KPI，这些 KPI 可以显示您的 API 程序的健康状况。像 Moesif API Analytics 这样的工具可以帮助您通过快速安装 SDK 来开始测量这些指标。

继续本系列的第 2 部分:掌握 API 分析-群组保持分析

原文：https://www.moesif.com/blog/technical/api-analytics/Mastering-API-Analytics-for-API-Programs-Chapter-2/

对于平台业务来说，很少有指标比留存率更重要。如果你以 25 美元获得客户，但是他们在一个月后停止使用你的 API，那么你就有一艘漏船。在留住人才的问题解决之前，不要在开发人员获取上花更多的钱。这需要准确测量原料药的保留率。

如果你来自网络或移动产品背景，你可能已经熟悉了移动留存来衡量有多少获得的用户保持使用一个移动应用。发展 B2B 平台需要跟踪类似的 KPI 来衡量你的收购和产品策略的成功。本文将深入探讨跟踪和提高 API 保持率的**实践。

保持率衡量的是一群人中再次使用你的产品并保持活跃的用户的百分比。对于您的产品，什么被认为是有效的取决于产品的类型。对于流媒体移动应用程序来说，在某一天活跃可能意味着播放一首歌曲。对于一个支付 API，它可以在一天中处理一次信用卡支付。

为了准确地测量用户保持率，你需要将你的用户分成不同的群体。通常，这是通过注册日期来完成的，但对于 API，建议根据集成日期或第一个 Hello World 的时间来划分。这是用户第一次通过您的 API 集成并进行第一笔交易的日期。然后，每天、每周或每月，我们都会统计返回并执行某项操作的独立用户的数量，您认为这是活跃的有力指标*。*

下图显示了按第一次 API 调用日期划分的新用户。从那里，我们跟踪每天仍然活跃在我们的 API 上的用户的百分比。该图表显示，37.5%的新用户在集成后的第一天仍然在积极地进行 API 调用。整合五天后，只有 24%的初始队列仍然活跃。

虽然只有 24%的群组在集成后 5 天内是活跃的，这看起来并不算高，但根据您的使用情况，此图表可能相当不错。留存不应衡量参与度或粘性水平。相反，您应该使用保留曲线来查看有多少用户被保留。最好的方法是判断曲线有多平坦。

保留曲线持续下降直至达到 0%的产品保留性较差。然而，保留曲线变平或略微上升的产品具有良好的保留。

第一天应该有最大的衰减。大多数平台都有一批注册的开发者，他们在沙盒里摆弄 API，但永远不会回来。一旦客户发现了价值，他们会在第二天、第三天继续使用 API，以此类推。这些用户发现了 API 的价值，并保持整合。另一方面，如果你的 API 或者 SDK 有问题或者不能提供即时的价值，开发者会逐渐移除他们的实现，导致留存率逐渐下降到 0%。

与上图不同，下图显示了糟糕的 API 保留情况。

请注意，在这种情况下，保留率一直下降到 0%。

以前，我们关注的是整个用户群。然而，要更深入地探究为什么保留率下降，重要的是找到驱动这种下降的变量。一种方法是将您的用户分组到桶中。这可以通过用户属性来划分，比如他们来自哪个国家，用户获取渠道，甚至是产品特定的信息，比如开发者使用的 SDK。

在这种情况下，我们可以更清楚地了解是什么推动了长期保留。虽然整体保留曲线相对平坦(即良好的保留)，但我们看到大多数非美国客户下降到 0%。只有美国用户继续利用 API。我们应该进一步调查为什么非美国用户不使用这个 API。是因为高延迟吗？非本地化文档？阻止收养的当地法律和法规？在金融、医疗保健和其他受监管的行业尤其如此。

从商业角度来看，退货行为应该是只有活跃用户才会做的事情，并从你的产品中获取价值。为了正确测量保持力，你需要定义初始动作和返回动作的*。虽然不是必须的，初始动作通常是新用户使用你的产品的第一个动作。*

以前，我们只是跟踪第一次进行 API 调用的新用户，然后进行任何返回 API 调用的*。然而，我们可以更具体地了解那些初始或返回动作是什么。*

例如，我们可以认为只有当用户返回并在 API 上进行支付交易时，用户才是活跃的。

例子

假设您正在构建一个管理信用卡交易的支付 API。API 提供的主要价值是通过信用卡处理支付，因此商家得到支付，因此我们考虑每天通过 API 处理至少一次信用卡支付的活跃用户。

对于 API，我们可以按如下方式跟踪留存率:

首次事件标准:

• 第一次调用 API 的新用户

返回事件标准:

• 回来并至少进行了一笔支付交易

如果您打算构建一个不断增长的 API 程序，那么您应该跟踪许多更深入的 API 指标。然而，如果您还没有开始采用数据驱动的方法，这些指标是一个很好的起点。随着您的 API 程序的发展，您将跟踪其他 KPI，这些 KPI 可以显示您的 API 程序的健康状况。像 Moesif API Analytics 这样的工具可以帮助您通过快速安装 SDK 来开始测量这些指标。

参见本系列第 1 章:掌握 API 分析——开发者漏斗

原文：https://www.moesif.com/blog/developer-platforms/api-analytics/Maximize-your-API-Revenue/

国际货币基金组织(IMF)预计，未来几年全球经济增长将大幅放缓，从 2021 年的 6.1%大幅降至 2022 年和 2023 年的 3.6%。与此同时，路透社的民意调查显示，T2 的全球高通胀还远未结束。

因此，企业需要竭尽全力实现收入最大化——不是通过增加新基础设施的支出，而是通过从现有产品中获得最大商业价值。你已经在构建你的 API 上花费了大量的财富，不要通过低价出售它。

基于使用的计费使您能够实现 API 的真正商业价值。它允许您创建高度独特的过滤器来为特定的端点及其使用方式计费，而不是基于原始的原始计数。在从 API 中的数据推断可操作的见解方面，Moesif 一直处于领先地位。现在，您也可以使用这种密集的粒度审查来货币化您的 API。

底线呢？更好的底线。

Moesif 的基于使用的计费意味着您可以将 API 调用或 API 有效负载中的任何参数货币化——您可以计量特定的端点、交易计数、独立用户、数据量、美元量或平台上任何其他基于使用的指标。通过 Moesif 的计费表，您可以快速试验不同的定价杠杆，看看如何获取最大的收入增长和扩张收入

起床跑步很容易。当实时患者预约平台 NexHealth 实施基于使用的计费时，一个人不到一周就完成了系统的集成、全面测试和部署。

“Moesif 允许我们灵活地采用基于 API 使用、基于呼叫或任何类型的定价模式。我们很快就可以开始向客户收取 API 使用费用，这很快成为我们的收入来源。”NexHealth 总经理 Paul Fung。

Moesif 位于您的应用程序/API 和您首选的计费提供商 Stripe、Recurly、Chargebee 等之间。我们的平台计算并向计费提供商发送数据。这意味着您可以根据客户的使用情况准确地向他们收费，而易于使用的仪表板则允许您直观显示使用情况并跟踪付款情况。

我们还提供了一个嵌入式的非品牌仪表板，您可以与您的客户共享，让他们清楚地了解他们需要的一切。与此同时，行为电子邮件让他们的客户了解和更新他们的使用水平。

无需任何代码，只需在配置设置中点击几下，就可以启动并运行 Moesif 的计费系统。然后，您可以跟踪客户对您的 API 的使用情况，获得非常灵活和可定制的基于使用情况的 API 计费选项。

当涉及到您的 API 和您的客户时，数据安全性是最重要的。这就是 Moesif 提供 SOC 2 合规保证的原因，它对静态和传输中的数据进行加密。公司还可以利用 Moesif 客户端加密功能，使其数据对组织保密或满足监管要求。我们提供您今天需要的安全性，使您能够为明天建立一个利润更高、更具前瞻性的企业。

通过在我们的分析平台上构建基于使用量的计费产品，我们将 Moesif 多年的知识和经验放在您的指尖。我们在分析方面的专业知识为我们基于使用情况的计费产品提供了更精细的细节，这意味着您现在可以最大化每个 API 的商业价值。

它不仅有可能增加你的利润，而且基于使用的计费也能吸引你的客户。过去几年是一个强有力的教训，说明公司需要灵活。借助这种计量计费安排，您的客户可以根据需要灵活地扩大和缩小规模。他们可以这样做，同时坚持与你的业务，减去任何尴尬的谈判，试图缩减固定利率合同，不再适用于他们的变化情况。结果呢？更快乐的客户和更高的忠诚度。双赢。

如果你遵循传统的 API 使用计费方式，那么你就是在浪费钱。鉴于国际货币基金组织对未来几年相当黯淡的全球前景，现在真的是随波逐流、让潜在收入收不回来的时候吗？即使不考虑当前的经济环境，充分利用您已经投资建设的基础设施难道不合理吗？

Moesif 基于使用量的 API 计费使你的 API 产品前所未有的货币化成为可能。快速且易于实现，它可以最大化 API 的商业价值，同时让您的开发人员和产品团队以及您的客户满意。

您可以在此阅读更多关于基于使用的 API 计费的详细信息或联系 Moesif，了解您的需求或安排演示。我们在这里支持你把你的 API 货币化到一个新的水平。

原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-with-AdOps-Manager-Rachael-Kiselev/

你能想象用两只猫在你腿上喵喵叫来解释 API 的可观测性吗？认识一下我们的常驻多任务专家，雷切尔·基舍列夫。她是用不到 300 个单词宣传一种全新的分析 API 的方法的策划者。作为我们 Meeting Moesif 博客系列的一部分，我们向她询问了关于 API 的未来，以及在全球疫情期间从一名新毕业生转变为技术营销人员需要做些什么。

你的职称是什么？你的工作需要什么？

我是一名内容营销经理，但这确实是一个相当不固定的头衔。我负责与内容相关的数字营销。你可能在 Reddit 等网站上看到的很多数字广告都是我的。嗯，它们是营销和设计的共同努力，以创造一个有凝聚力的广告战线。我处理一些 SEO 实践，比如 UTM 给博客文章加标签，或者在 Moesif 其他员工写的文章中加入行动号召。作为一名多面手，我也在业余时间支持营销团队。因此，从转录播客到做竞争对手的研究，等等。我尽量专注于支持销售漏斗。

我们刚刚从改变了一切的全球化疫情中走出来。你的职业生涯和你的余生是如何发展的？

在 COVID 之前，我实际上刚刚从大学毕业。所以真的，我在工作世界中没有任何真正的“工作”经验，更像是之前的亲身实习。当我毕业时，我在一家非营利组织工作，管理他们的谷歌广告词、时事通讯之类的东西。当第一次封锁开始时，我结束了在一家小的精品代理处的工作。在那里的时候，我和很多人一样，完全处于偏远地区，非常怀念面对面的交流。这有点孤独，只能通过聊天或缩放来交流。

当我离开那个职位时，我知道我想去一个允许远程工作的灵活性，但提供面对面协作空间的地方。由于海湾地区的人数下降，Moesif 的员工已经能够根据自己的意愿在办公室工作。在我最初的入职经历后，我成了一名“灵活”的员工，所以我每周至少来一次，但每周不超过两三天。这对我有好处，因为我住在离半岛很远的地方，直到最近，我们的公共交通系统才增加了更好的空气过滤器。简而言之，去办公室的通勤可能会有点拥挤，所以最好不要每天都这样。此外，在家工作意味着我可以实时处理家里出现的问题，而不是对我的猫留给我的礼物(和混乱)感到惊喜。

你认为 Moesif 适合 API 的未来吗？

我想在理想的世界中，API 看起来不会像今天一样，这意味着今天的 API 很可能会与明天的 API 有所不同。我认为 Moesif 是随着 API 环境的发展，公司将进行的变革的一个组成部分。我认为 Moesif 将继续加深客户对其 API 的理解，从而推动细分市场的发展。我认为 Moesif 最大的价值是能够挖掘 API 来理解和货币化 API 的使用。因此，能够站在事物的最前沿，让公司有机会迭代和改进他们的 API，将有助于整体技术的发展。同样，我们已经看到 API 经济已经从 REST APIs 转向 GraphQL，所以 API 格局已经发生了变化。我认为在接下来的几年里，我们将扩大我们的支持能力，并成为 API 优先公司的一部分，以保持迭代和技术的前沿。

你的工作空间是什么样的？

坦白说，很乱。我工作时的桌子看起来没人住，除了我的一个小丙烯酸支架。我的键盘和鼠标还在它们的盒子里。在家里，我的办公桌上有几台显示器，但通常我会把时间分配在办公桌和沙发上。我一气呵成地掌握了高效工作和毁姿的艺术。还有，我的猫跟随着我，所以它们是我的额外同事。

你能告诉我们一些关于你的背景，以及你是如何进入 Moesif 的吗？

我过去的经验是倾向于数字营销。我有一个广告学学位和一个信息科学辅修专业，但最终选择了市场营销。我的很多辅修专业都围绕着数据聚合和可视化(重点是关于信息的道德和政策)。我认为我的分析背景加强了我的营销和广告技能，因为数据驱动一切。Moesif 是一个“分析优先”的产品，这使我们成为一家天生的数据驱动型公司。就这一点而言，它感觉很适合我。

关于会见 Moesif

在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API 平台。

会见 Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。

如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击链接查看其他 会议 Moesif 团队成员访谈。

原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-With-Developer-Advocate-Dylan-Frankcom/

Dylan 是 Moesif 的一名助理开发人员。他最近刚从加拿大安大略毕业，是开发人员宣传的新手。他拥有独立软件开发人员的经验，为许多开源项目做出了贡献，并为 Mac 和 iOS 发布了软件。作为我们 Meeting Moesif 博客系列的一部分，我们询问了他在 Moesif 中的角色，他如何处理在不同国家的远程工作，以及他对 Moesif 适应当今和未来 API 环境的看法。

我是 Moesif 的一名助理开发人员。我本质上是一名开发人员，作为开发人员的拥护者，我有责任向其他开发人员详细介绍我们的产品和平台。这项工作需要通过各种媒体展示我们的产品，并与其他开发人员合作，帮助他们充分利用我们公司的产品和服务。

开发者倡导者可以承担许多不同的角色。有些人在内部支持开发人员，与工程团队合作，帮助他们了解开发人员社区的需求。其他人在外部工作，通过活动、社交媒体和其他渠道与开发人员接触。在 Moesif，我尽力做到这两点。我觉得我在 Moesif 的角色非常明确:帮助 Moesif 为开发者提供最好的服务。

远程工作是一个很好的机会，可以很好地平衡工作和生活。这是我第一份完全远程的工作，最初，我担心如何管理我的时间并保持高效率。然而，我很快意识到远程工作是管理你的时间和保持高效的好方法。

关于远程工作，我学到了一些关键的东西，它们帮助我保持高效，并保持良好的工作/生活平衡。首先，有专门的工作空间是很重要的。这可以是一张桌子，或者是你房子或公寓里专门用来工作的特定区域。一个专用的工作空间有助于在你的工作和个人生活之间建立一个界限。第二，养成日常作息并坚持下去是至关重要的。这种日常生活可以包括休息，为深度工作留出时间，为个人生活活动安排时间。

帮助实现这种平衡的一个方法是利用无限带薪休假(PTO)。这让你有足够的时间充电，并在职业生活之外获得一个身份。Moesif 提供无限制的 PTO，可用于各种目的，如休假、个人时间和病假。

在远程工作时，健康的工作/生活平衡是一个重大障碍，因为如果你总是工作，你会筋疲力尽，这是显而易见的。所以花时间给自己充电是很重要的，这样你在工作的时候就能更有效率。

我了解到在多个工作区之间分配工作有很多好处。例如，当你为特定的任务指定了区域，它可以帮助你保持更加专注和有效，不太可能分心或偏离方向。另一个好处是，它可以帮助你保持条理。不同类型的工作有不同的区域可以帮助你记录你的进度，最有效地利用你的时间。最后，将你的工作分成两个工作区也有助于提高你的工作效率。例如，当你有一个专门的空间来完成每一项任务时，你更有可能迅速完成它。这可以让你腾出时间做其他任务，或者给你一种成就感。

至于工作区本身，它们都是围绕 MacBook Pro 设计的，并考虑到了坞站。这使我的开发环境保持一致，同时能够在多个地点工作。我在办公室的主要工作区由典型的开发者显示器设置组成:一个是横向的，另一个是纵向的。我和我的搭档共用一间办公室，有时我们都远程工作。所以我们创造了我们喜欢称之为“不可知工作站”的东西。“不可知工作站”只有一个外部显示器、外部键盘、触控板和鼠标。根据我们每天的安排，我们会在办公室和工作站之间来回穿梭。我也喜欢在露台上喝咖啡开始我的早晨，同时由于时差的原因，补上一些错过的松散线索和前一天的概念票更新。

是的，肯定的。我喜欢在小公司工作，因为这让我觉得我可以产生巨大的影响。小公司通常更灵活，可以更快地利用新的机会。他们也更乐于接受新思想，更愿意承担风险。这意味着员工通常有更多的机会直接影响公司的成功。我觉得我的工作与众不同，我可以帮助塑造公司的方向。当然，这也带来了更多的责任，但我认为这是值得的。

当你在一家小公司或初创企业工作时，你需要能够身兼数职。这有助于你变得自在，成为人们可以为各种任务而去找的人，无论是回答客户问题、开发概念证明，还是尝试可能不属于你特定领域的事情。

作为一名开发者倡导者，我负责与我们的客户交谈，了解他们的需求，然后在内部为他们辩护。然后，我与我们的工程和营销团队合作，帮助他们了解我们的客户如何使用我们的产品。这也告诉我如何开发内容，以帮助我们的客户充分利用我们的产品。我通过撰写指南和博客文章、制作视频以及帮助开发人员与客户沟通来支持我们公司的目标。到目前为止，这是一次很棒的经历！我也喜欢每个人为了共同的目标一起工作时形成的紧密团结的社区。

目前，在开发 API 产品时，Moesif 可以在几个方面提供帮助。首先，通过了解您的 API 是如何被使用的，您可以做出关于改进它的明智决策。其次，Moesif 可以通过提供哪些功能最常被使用以及被谁使用的见解来帮助制定货币化战略。最后，通过了解哪些功能对用户最有价值，开发人员可以相应地为他们的 API 定价，并确保他们从最受欢迎的功能中获得收入。

我认为 Moesif 在 API 领域具有独特的优势。Moesif 分析套件附带的功能，如计量计费、治理和行为警报提供的不仅仅是统计和日志。能够在一个平台上利用分析提供的见解、行为电子邮件提供的即时客户支持以及计费表产生的收入来开发您的 API 产品，这确实改变了游戏规则。随着我们继续构建和增加这些功能，未来看起来很有希望。

在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API 平台。 Meeting Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。

如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击以下链接查看其他 会议 Moesif 团队成员访谈。

原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-With-Head-Of-Developer-Relations-Matt-Tanner/

Matt 是 Moesif 的开发者关系主管。他目前居住在加拿大安大略省和爱德华王子岛。在进入开发人员关系之前，Matt 曾在多家大型企业担任软件开发人员、团队领导和架构师。作为我们 Meeting Moesif 博客系列的一部分，我们询问了他在 Moesif 中的角色，他如何处理在不同国家的远程工作，以及他对 Moesif 适应当今和未来 API 环境的看法。

我的职位是 Moesif 的开发者关系主管。这个角色相当多样化，因为你帮助公司的所有方面，包括营销、销售、工程和产品。成为这些部门之间的粘合剂和产品的主题专家对我们在开发人员关系中的角色至关重要。我们做任何事情，从写技术博客，与其他公司讨论潜在的合作机会，甚至坐在客户的电话上，从开发人员的角度帮助解释产品。在 Moesif 的开发者关系工作中，我们有一个目标:帮助 Moesif 成为开发者(以及所有 Moesif 用户)的**选择。

远程工作有利也有弊。你有很大的责任来确保你高效地完成工作，但是你也需要成为一个看门人来确保你有足够的时间离开工作。我坚信，当人们喜欢他们所做的工作，得到充分休息，并受到赏识时，他们的工作就做得最好。这是我在自己的工作和生活中为之奋斗的，也是为我们团队的任何人奋斗的。Moesif 在这方面做得很好。尽管如此，我非常喜欢在开发者关系领域与 Moesif 一起工作，以至于大多数时候我真的感觉不像是在工作。

根据我所做的工作，我的工作空间看起来会有所不同。如果我需要对视频或书面内容进行一些深入的工作，我通常会使用带有大型超宽显示器的办公桌。如果我在进行销售拜访或其他会议，我通常会在房子的不同地方进行，以保持一天中我的环境不同。

在设备方面，我使用 17 英寸的 MacBook Pro，如果我不在办公桌前工作，我会使用 Sidecar 将我的 iPad 用作第二个屏幕。当您离开办公桌时，这种能力为您提供了极大的灵活性。

多年来，我为许多小型创业公司工作，这是意料之中的。Moesif 的伟大之处在于，当你开始拓展并与公司的不同部门合作时，协作就发生了。这里确实有一种学习的文化，让每个人都有机会以他们想要的方式学习和领导。

Moesif 是一家鼓励每个人提问并充分理解我们正在构建的公司。甚至我们的销售和营销团队也完全了解我们的产品愿景和我们要解决的问题。如果有人想领导，总是有信任让一个人这样做，并支持确保他们也能成功。

我认为 Moesif 适合所有产品的未来，包括 API。我们的平台允许任何企业分解他们做得好的地方和他们需要改进的地方。此外，我们为这些用户提供工具，让他们开始根据这些见解采取行动，并跟踪以确保他们所做的更改能够为他们的用户带来改善。如果有人正在开发一个产品或者希望改进一个现有的产品，无论是入职还是留任，等等。，那么 Moesif 就可以给他们工具集进行改进。

我真正感到兴奋的最后一件事是我们的计费表功能。过去我一直致力于将 API 货币化，我能体会到有效地实现这一目标有多难。借助计费仪表，我们可以通过一个非常简单的集成(设置大约需要 5 分钟)将使用数据发送到 Stripe、Recurly 和 Chargebee，设置计费标准，并在几分钟内将使用情况报告给提供商。对我来说，这确实是一个有助于巩固 Moesif 对 API 和 API 产品的未来的直接影响的特性。

在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API 平台。 Meeting Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。

如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击以下链接查看其他 会议 Moesif 团队成员访谈。

原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-with-SEO-Manager-Savannah-Whitman/

会见 Moesif - SEO 经理萨凡纳·惠特曼

职业发展既令人害怕又令人兴奋，我们的 SEO 经理 Savannah Whitman 在加入 Moesif 之前就经历了这两种情况。现在，她正在培育搜索排名，将 API 可观察性的最新成果带给需要的技术人员。在本期会见 Moesif 中，我们将与她探讨 API 技术的发展方向，以及如何跟上它的步伐。

你如何描述你在 Moesif 的角色？

理论上？我是内部的 SEO 经理，确保任何对 API 可观察性感兴趣的人都能找到我们的建议。

真相？SaaS 的每个人都对 API 的发展方向有自己的看法。不是每个人都有像 Moesif 的以用户为中心的 API 分析这样的类别创建产品。这足以证明我们的知识库是针对那些在可能性边缘工作的技术专家的。这就是为什么我利用我的(不那么)神奇的力量让我们的内容在 Google、DuckDuckGo 或 API 爱好者搜索答案的任何地方弹出。

像任何初创公司的员工一样，我通常会戴不止一顶帽子。我实际上是从公关和数字营销开始的，所以我经常被 SEO 之外的项目所对待。

由于 Moesif 是一家小公司，你是否觉得有必要以你以前从未有过的方式进行领导？

绝对的。在我过去的角色中，我为大型团队提供幕后支持。在我职业生涯的前五年，我做过公关助理、市场自由撰稿人、代笔人，应有尽有。这些经历让我明白了互利的品牌客户关系是什么样的。与此同时，我开始花时间与我真正感兴趣的品牌——API 优先的公司，如 Auth0 和 Postman 。最终，我意识到我知道我想要什么，以及如何得到它。是时候进入我职业生涯的下一阶段了。

然而，迈出这一步说起来容易做起来难。我认为，对于女性和不同性别的科技工作者来说，有一种感觉是，你需要为自己的位子而战。重要的是要记住，不是每个公司都是这样运作的。

在 Moesif，每个人都有一个座位，无论我们是坐下来吃午餐还是参加规划会议。我很惊讶在这个团队中成长是如此容易。在这里，我可以自由地设计和运行自己的项目，而不仅仅是执行别人的项目。更令人耳目一新的是，我是在整个团队的支持下这样做的，而不是作为一个自由职业者独自这样做。

如今 API 产品面临的最激动人心的挑战是什么？

我渴望看到 API 将他们作为一种新的、未验证的技术的身份转变为一种可靠的、成熟的技术。

API 优先的公司和我差不多同时成熟，在 2000 年代后期。脸书和 Twitter 第一次宣布了他们的 API，建立了一个新的标准。那时候，我还是一名第一机器人公司的学生，第一次交流技术，向赞助商推销消费技术。这可以说是多愁善感，但我希望我的职业生涯能随着那个时代诞生的科技潮流一起成长。

我们现在是在 2020 年，我已经实现了我的愿望。API 为我们全球互联的应用和微服务世界提供动力。就像在任何趋势转变的革命中一样，大规模采用发生在细节被整理出来之前。例如，API 仍然特别容易受到新出现的安全威胁的攻击，并且仍然不确定如何应对监管。

比起看到任何一个问题得到解决，我更兴奋地看到一个完整、可靠的生态系统出现。API 分析只是其中的一部分，但是每一个小的改进都很重要。我期待着传播这样一个信息，“API 会一直存在，并且每次都能完美运行。”

驱动你的价值观是什么？

我是一个终生的技术爱好者，但最重要的是，我重视像对待人类一样对待人类。这不是硅谷众所周知的价值观。这是有正当理由的，但我相信技术有服务于公共利益的潜力。

可以理解的是，大型科技公司的丑陋之处受到了关注。操控软件。“科技兄弟”文化。能源使用失控。即使在科技工作者中，我也听到了对道德的担忧。谁愿意相信他们的工作对世界有害？当我们把不道德的企业框定为“创新”的顶峰时，很容易感觉整个科技行业都是如此。

但是，创新本身是公正的。当我看到关于“邪恶”科技公司的头条新闻时，我看到的是一个社会问题，而不是新工具的问题。这就是为什么我寻找那些为了大多数人而不是少数人的利益而拥抱非传统的公司，并且诚实地承认他们有能力做到这一点。这意味着意识到它们对员工、社区和技术生态系统的影响。我确实认为这个游戏目前倾向于不守信用的演员，但如果说科技领域有什么是不变的，那就是进化——大的变化往往始于小步。

即使足迹很小，每个敢于做得更好的公司都树立了榜样。我喜欢认为我们正在这样做，在 Moesif。我们正在朝着计算的进步而不是寻求短期回报而努力。Moesif 是管理 API 的“缺失部分”。无论产品发生什么，我们正在建立的利基市场将进一步完善 API 技术。我们在这样做的同时，将员工视为真实的人，他们有时会面临挑战或需要额外的支持。成就和责任之间的平衡让我有家的感觉。

关于会议 MoesifT3】

在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API 平台。 Meeting Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。

如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击以下链接查看其他 会议 Moesif 团队成员访谈。

原文：https://www.moesif.com/blog/companies/runscope/Migration-guide-for-Runscope-Traffic-Inspector/

Runscope 是测试 API 的一个很好的产品。他们相信 API 的发展方向，并希望帮助 API 开发者以一种简单的方式测试他们的 API。很遗憾看到他们将关闭他们的流量检查员(网关 URL、网关代理、流量流、请求捕获、共享请求等)。)来关注其他产品特性，比如他们的 API 测试。

如果您正在寻找一个平台来运行复杂的测试序列来测试您的 API，我们仍然推荐 Runscope。事实上，Runscope 测试序列与 Moesif API 分析相结合，为您提供了一个强大的平台来测试任何新的 API 更改，并监控这些更改对您的客户群的影响。

Runscope 主要关注于测试一个 API，按照设定的时间表 ping 它并检查结果。您可以定义更精细的测试序列，也可以从 CI/CD webhooks 等中触发。如果其中一个测试序列失败，也可以配置松弛警报。

Runscope 还有一个交通检查员，可以用来检查这些测试的结果。一些低流量用户甚至使用 Traffic Inspector 对生产流量进行常规 API 监控，但这超出了该功能的设计范围。

Moesif 不关注测试序列，也没有合成 ping的概念。相反，Moesif 的主要关注点是 API 分析，为您的生产应用提供对实时 API 流量的深入了解。这意味着 Moesif 被动地捕获您的 API 数据，以了解使用趋势并检测您的 API 上的异常。

有了 Moesif，您可以看到前 10 大 API 客户调用最多的 API 端点，或者得到提醒，在推出新的 SDK 版本后，欧洲用户在 Java SDK 上遇到了更高的错误率。

Moesif 提供了许多不同的视图来可视化您的 API 数据，包括事件流、热图、分段和时间序列。

对于那些从 Runscope 的流量检查员迁移过来的用户来说，Moesif 的事件流是 Runscope 用户在开始时最熟悉的。

Moesif 支持各种 API 协议/架构，包括 RESTful、GraphQL 和 Web3/JSON-RPC。

集成差异

Runscope 的交通检查员唯一的集成是通过代理。传入的 API 调用将通过 Runscope 的代理路由，然后被中继到您真正的 API。

Runscope 有一个云代理可用于所有计划，还有一个本地代理设备可用于某些企业级计划。

Moesif 主要集成不是云代理。相反，Moesif 的大多数客户使用开源的服务器中间件 SDK，如 moesif-express 或 moesif-servlet。对于像 DApps 这样的客户端应用，也有 moesif-browser-js 可用。

Moesif 还有一个高可用性的云代理服务器，在你不能安装 SDK 的环境中非常有用，比如捕获 T2 网页钩子。

应该选择 SDK 还是云代理？

如果你想要更多的定制和最高的性能，请使用 SDK，如果你想要替换 Runscope 的流量检查器或无法安装 SDK，请使用云代理。

SDK 的一些额外好处

• 而不是另一跳，这意味着对延迟没有影响。数据异步发送到 Moesif。
• Moesif SDK 或 Moesif 服务中的故障不会影响您自己的服务正常运行时间。
• 可以自定义 API 调用如何归属于您的 user_id 和会话/身份验证令牌
• 可以在发送到 Moesif 之前清除任何敏感数据。

云代理的一些额外优势

• 没有软件安装，它只是创建了一个编码的网址。
• 替换 Runscope 交通检查员。
• 可用于 webhooks 或捕获健康探测的结果。

综合

遵循服务器中间件 SDK或云代理各自的集成指南

在成功集成 Moesif 之后，您应该开始看到数据立即出现在 API 事件流中。可能需要几分钟事件才会开始出现。

Runscope 没有用户的概念，所以我们建议查看 moesif 文档中关于创建用户配置文件的内容，以使您的集成更加强大。

原文：https://www.moesif.com/blog/technical/api-analytics/Moesif-and-Datadog-Feature-Similarities-Differences-and-How-They-Can-Work-Together/

Moesif 和 Datadog 都是提供监控和查看指标能力的平台。然而，从本质上讲，这两个平台为您的组织和使用它们的团队做了非常不同的事情。两者可以很好地互补，并包含有助于制造无缝扩展的更好产品的功能。

Datadog 非常适合确保基础设施按预期运行，向您发出错误警报，并监控停机时间和性能下降。这都是良好的应用程序性能监控解决方案的一部分。从本质上讲，如果您拥有对您的运营至关重要的基础设施和资源，Datadog 是查看您的运营状况全貌的绝佳方式。该平台可以帮助确保您的技术操作的所有部分都顺利运行，并在不顺利时提醒您。

另一方面，Moesif 更关心从用户和公司的角度进行监控和分析。Moesif 可以确保用户再次使用你的产品，提供关于他们如何使用它的有价值的见解，授权使用它的团队推动采用，等等。Moesif 让你看到端到端的用户旅程，包括用户如何与你的应用或 API 产品交互，以及他们如何使用它。通过启用公司跟踪，您还可以查看特定公司的一组用户是如何与您的产品进行交互的。

两者都有不同的目的和目标，但它们一起可以创建一个端到端的业务图，包括您的用户和操作。建立一个伟大的企业包括拥有伟大的产品体验和坚实的基础设施监控，以确保**性能。

像 Datadog 这样的工具擅长单维分析，这意味着有一个度量名称和一个随时间变化的值。可能有少量的标签或维度，但通常为数不多。对于产品驱动的团队来说，重要的是不仅要理解交易量，还要理解客户通过 API 发送的不同类型的负载和查询。这可以跨数千个不同的查询参数、HTTP 头和主体键来定义。此外，这些字段中的每一个都可以有大量不同的值(高基数)，包括客户标识符本身。

这就是 Moesif 的优势所在，它使产品所有者能够通过无数种不同的可能性来分割他们的 API 使用数据。例如，在下图中，我们可以在响应有效负载“标签”中跟踪每天经历缺货与可用的独立用户数量。虽然 DevOps 工程师对独立用户和他们是否看到缺货不太感兴趣，但这些见解对于做出良好的业务决策至关重要。

由于两个平台针对不同的目标使用不同的指标和数据，因此一起使用它们是有意义的。将两者结合使用有很多好处，有助于生成整个业务的整体视图。涵盖一切，从客户如何使用您的产品，一直到产品运行的基础设施如何运行。

现在，让我们看看每个平台都包含哪些功能。

这两个平台都提供了多种功能，可以从多个方面帮助您的企业。下面是对每个平台提供的内容、其重要性以及如何补充其他平台的分析。

连接器、插件和集成

这两个平台都支持市场上许多最常见的平台，具有各种集成。由于这两个平台在一个组织中服务于不同的功能，它们的连接器、插件和集成反映了这一点。

Datadog 更支持基础设施，因此有许多连接器，如帮助监控安全性、容器、编排、成本管理和问题跟踪的连接器(仅举几例)。AWS、Google Cloud Platform 和 Azure 上许多最流行的工具和平台都得到了支持，这里仅举几例。

Moesif 支持大多数 API 框架。其中包括 Node.js、Python、Java 等的服务器集成。Moesif 还为流行的 API 网关和 API 管理工具提供插件，包括 Kong、NGINX、Tyk、Envoy 等等。

Moesif 的连接器更侧重于产品用例。一些包括 Slack、Segment、Pendo、HubSpot、Salesforce、Marketo 等。

TL；灾难恢复-两个平台都有许多可用的集成。Datadog 涵盖了大多数平台，在这些平台上，基础设施监控将是有益的。Moesif 集成了构建和管理 API 的最流行的方法，包括直接插入代码的服务器集成 SDK 或与 API 网关集成的插件。T3】

仪表盘

仪表板是汇集数据进行快速浏览的好方法。展示单一领域的关键见解是两个平台都擅长的事情。

Datadog 允许您构建自定义仪表盘来显示基本指标。运营团队可以非常轻松地查看每个系统的运行情况，包括性能、使用情况和其他表明平稳运行的关键值。

Moesif 仪表板可用于为所有可能关注的部门提取关键的客户洞察。例如，营销仪表板可以显示流量来源、网站参与度和客户保持率。产品仪表板可以显示客户激活漏斗、平均 TTFHW(首次 Hello World 的时间)以及显示客户如何使用 API 或平台的其他指标。

TL；Datadog 中的 DR - Dashboards 可让您深入了解您的运营情况，并确保您的关键业务正常运行。这些都是可定制的，易于设置和优化。Moesif 还提供易于使用和设置的仪表板，包括一些开箱即用的仪表板。Moesif 仪表板可以显示许多团队，包括营销和销售，粒度指标，以帮助绩效和采用。T3】

发信号

在监控工具中，关键事件发生时向特定通道发送警报的能力至关重要。当满足特定条件时，警报允许用户在其选择的平台上得到通知。这意味着用户不必手动观察事件，而是可以“设置并忘记”，知道他们将自动和实时收到警报。

Datadog 警报可以围绕您的基础设施内的条件。Datadog 能够创建主动检查指标、集成可用性、网络端点等的监视器。当警报被激活时，Datadog 可以通过电子邮件、吉拉、PagerDuty、Slack 或 WebHooks 发送警报。

当用户遇到某些情况时，Moesif 可以创建警报。这些可能是新用户注册、进行一系列 API 调用、API 流量异常增加或减少，或者用户遇到大量错误或集成问题。这些警报中的许多可以帮助您的团队积极主动，确保良好的用户体验，并快速缩小产品中的问题范围。

TL；DR - Datadog 非常适合提醒您基础设施问题和一般技术操作，确保系统正常运行。Moesif 非常擅长警告特定的用户行为，并主动让开发人员、产品经理和支持团队意识到用户陷入困境或收到错误。T3】

用户和公司跟踪

用户行为分析的一个关键特性是能够分析不同用户所做的事件序列，而不仅仅是孤立地看待事件。为了能够分析复杂的用户行为，Moesif 中的 API 调用和动作可以绑定到用户 id 或公司 id 。从那里，您可以跨多个 API 调用创建报告。例如，使用 Moesif，您可以找到对 GET /widgets/category/:id 进行了至少 10 次 API 调用，但对/purchases 进行了 0 次 API 调用的用户。

借助用户行为分析，以产品为导向的团队可以分析他们的激活漏斗，并执行群组保持分析，以了解他们业务的健康状况。

这些类型的分析对于以产品为主导的组织来说是一个巨大的优势，因为在这些组织中，用户体验是最重要的考虑因素。

漏斗可以让你看到你的产品漏斗中不同步骤之间的转换率，比如注册用户中最终进行第一次 API 调用的用户的百分比。在此基础上，你可以根据用户统计数据(如营销活动)进行细分，以了解在哪里投入更多资源。留存分析可以让你看到用户是否忠诚，是否继续从平台中获取价值。细分让你可以深入了解谁是你的用户和公司，以及他们属于哪个细分市场。

因为 Moesif 可以通过 API 或像 Segment 这样的连接器获取客户数据，所以您可以根据客户的人口统计数据来划分您的 API 使用和 API 指标。例如，为了更好地理解公司规模或职位的使用。这使得按计划或其他客户信息跟踪使用情况变得更加容易。

通过分析 API 有效负载和 UI 事件(通过 Moesif 的 BrowserJS 包或片段)，可以很容易地收集和操作战略性业务洞察。一个例子是优化应用程序中的电子商务交易。通过跟踪未完成的结帐，您可以确定不成功结帐的确切路线，与卖方一起解决问题，并主动通知买方该问题。这些信息也可以在产品团队中使用，以改善结账流程，从而避免将来的交易出现以前没有结账或结账不完整的问题。

Moesif 跟踪每个用户及其公司的能力使得“行为度量”的使用成为可能。这些类型的指标允许我们查看多个事件，而不是允许我们将多个事件联系起来以确定特定的行为模式。这正是 Moesif 能够做上述所有事情的原因。

有了 Datadog，你也可以看到用户正在做的动作，但是没有 Moesif 那么精细。然而，Datadog 支持一些非常基本的用户跟踪，这有助于调试平台上出现的基础设施和安全问题。但是 Datadog 不支持每家公司跟踪。由于 Datadog 应用于其分析模型的模型，因此不支持“行为指标”。

TL；DR - Datadog 支持跟踪用户动作和调用，但更适合显示整体流量、API 调用和性能。Datadog 的用户跟踪功能更符合网络分析。Moesif 允许跟踪用户和公司的使用情况。这一功能使 Moesif 用户能够查看转换漏斗、保留分析和探索用户细分。Moesif 的功能旨在从用户第一次访问您的应用程序到他们最近的转换，增强用户的能力并改进您的产品。T3】

行为邮件

通常，用户在我们的产品中表现出的某些行为或采取的行动可以被跟踪。能够自动发送定制和模板化的电子邮件是通知用户接下来的步骤或他们可能违反的某些条件(如速率限制)的好方法。

借助 Moesif 跟踪个人用户的能力，我们可以监控特定的条件或行为，并根据它们发送电子邮件。Moesif 可以在用户在入职或开始时遇到困难、接近 API 速率限制或任何其他用户可能受益于电子邮件的标准时检测并发送电子邮件，以引导他们回到正确的道路上。

因为 Datadog 更关心的是基础设施和整体性能监控，所以它不支持这个功能。这是 Moesif 可以增强您已有的监控并帮助改善您的产品和用户体验的另一个案例。

TL；DR - Behavioral 电子邮件可用于根据用户显示的行为或采取的行动，在他们的入职和用户旅程中提醒和帮助用户。Datadog 本身不支持行为电子邮件，因为它在指标方面不是以用户为中心的。Moesif 允许根据用户何时符合特定标准来发送定制的电子邮件。T3】

治理规则

治理规则是 Moesif 更加关注基于用户的分析的另一个因素。这些要求包括阻止未经授权的访问或阻止过期发票用户的访问，这只是几个例子。

此功能不仅仅是监控和警报，而且像行为电子邮件一样，允许您自动根据指标采取实际行动。在 Moesif 中，您可以创建阻塞和非阻塞规则。阻止规则可以阻止对 API 的访问，同时通知用户为什么会发生服务中断。非阻塞规则仍然允许请求继续到您的上游服务。Moesif 将只覆盖任何 HTTP 响应头，但不覆盖正文和状态代码。

Moesif 提供这一功能，作为创建和实施治理规则的一种简单方式。由于确定和执行这些规则所需的所有指标都已经存在于平台中，这使得它成为创建它们的绝佳场所。

Datadog 不支持这种方式的治理。Datadog 可以用来探索对组织的治理需求可能很重要的数据，但它不能像 Moesif 那样强制执行规则并通知用户。

TL；Moesif 可以创建和实施灾难恢复治理规则，例如阻止未授权或可能的恶意访问。这些规则可以是阻塞的(停止请求)或非阻塞的(仍然允许请求通过)。Datadog 不能用于这样的功能，但是仍然可以被治理团队用作高级调查的一部分。T3】

基础设施监控

无论服务和产品有多好，只有当它们所依赖的基础设施运行良好时，它们才能成功。基础架构监控是组织确保其运营正常运行的一种重要方式。您可以监控网络速度变慢、流量异常增加、服务器出现问题以及其他影响系统稳定性和用户体验的事件。

Datadog 最初的功能主要集中在这种类型的监控上。可以说，Datadog 是满足这些需求的**和最受欢迎的工具之一。各种基础设施和服务可以轻松连接到 Datadog 并进行监控。由于这是 Datadog 平台的核心用例，难怪世界上许多最大的公司都利用 Datadog 来忽略他们的运营(包括 Moesif！).

Datadog 提供了一些很棒的仪表板，让您可以监督您的整个操作。您的架构中的每个基础设施都可以使用该平台进行监控、查询和优化。

Moesif 不提供基础设施监控，但是 Moesif 中的许多指标——包括那些表示 API 性能问题的指标——也可以通过使用 Datadog 来快速调试。一个很好的例子就是当大量的问题和警报开始涌入 Moesif 时。我们可以检测到用户遇到的问题，然后转向 Datadog，将其缩小到基础设施问题，或者可能是一些问题，如一些坏代码的发布问题。

TL；DR - Datadog 是基础设施监控的**平台之一。几乎所有的系统都可以连接到 Datadog，因为它们提供了大量的集成。查看端到端操作和基础设施状态是 Datadog 真正擅长的地方。Moesif 不提供任何类型的基础设施监控，但是当与 Datadog 一起使用时，可以很容易地帮助诊断和解决影响用户的问题。T3】

Moesif 中的指标可以帮助塑造更好的用户体验，并帮助发现应用程序中的困难。这可能涵盖从前端体验(使用 Moesif 的 BrowserJS 或 Segment)到后端事件(比如与 API 的成功集成)的所有内容。Moesif 还可以通过将指标与生成自动电子邮件、通知甚至治理规则的工作流联系起来，帮助实现以产品为主导的组织。

Datadog 中的指标非常适用于跟踪运营和系统健康状况、整体流量、监控基础设施成本，以及确保您的应用以最高水平运行的多个方面。

如您所见，两个平台都为不同的受众和角色提供了许多有价值的见解。Moesif 专注于帮助您构建更好的产品，而 Datadog 则专注于确保您的基础设施和其他操作变量能够让这些产品发挥应有的性能。平台之间的功能重叠很少，因为它们在如何使您的业务扩展方面有两个非常不同的角色。将 Datadog 和 Moesif 结合使用是构建完整而全面的分析和监控堆栈的**方式之一。

原文：https://www.moesif.com/blog/business/soc2/Moesif-API-Analytics-is-SOC2-Compliant/

Moesif 很高兴地宣布，它已成功完成其 SOC 2 认证。Moesif API 分析平台现已通过独立验证，符合最高安全标准。

通过完成这一全面级别的认证，Moesif 证明了它能够可靠、安全地维护企业关键数据资产的机密性、可用性和完整性。

SOC 2 法规遵从性表明组织可以保持高水平的信息安全。这种负责任地处理敏感信息的承诺在银行、保险和政府部门尤为重要。

事实上，SOC 2 的框架规定，合规组织只能与通过审核的其他组织共享数据。Moesif 现在能够与其他 SOC 2 兼容组织建立业务关系。

SOC 2 审计流程包括五个用于评估和报告信息和系统控制的信托服务标准:安全性、可用性、保密性、处理完整性和隐私性。

由于 Moesif 一直处理客户数据，我们在构建解决方案时考虑了安全性。我们安全、保密地处理数据的强大流程包括:加密所有存储的静态数据、对访问生产数据的内部控制，以及对所有涉及客户数据的软件修改的变更控制流程。

除了从不将客户数据存储在公司基础架构或工作站之外(所有这些都是远程监控的)，我们还为核心服务实施自动安全更新，并在发现安全问题时进行现场更新。

除了服务器端加密和 SOC 2 之外，通过客户端加密实现零知识安全，具有敏感数据的应用程序可以对您的组织保密。获得了内部安装的隐私优势，而没有构建和扩展您自己的数据基础架构的复杂性。

Moesif 致力于客户数据的安全。我们的 SOC 2 合规性是我们平台发展的下一步，以应对更苛刻的市场。

原文：https://www.moesif.com/blog/cors/chrome-extension/Moesif-CORS-Extension-For-Chrome-Milestone/

我们很高兴看到 Chrome 浏览器的 Moesif CORS 扩展达到了一个重要的里程碑:超过 10，000 周活跃用户。

这也是最高评级的 CORS 浏览器插件。

也可以查看我们在 CORS 的流行指南以及如何用 CORS 设置你的 API。

了解更多信息

原文：https://www.moesif.com/blog/meetups/graphql/Moesif-Developer-Meetup-on-GraphQL-and-Serverless/

Moesif 在 GraphQL、Serverless 和 API 上举办了第一次会议。我们与 Box 开发者平台团队的创始人以及 Back4App 和 StdLibs 的首席执行官进行了富有洞察力的谈话。

有大量的免费啤酒和比萨饼，这是与更大的 API 和开发人员社区的成员交流的一段美好时光。以下是会谈中的一些亮点。

首先发言的是 Jeremy Glassenberg，他是 Box 开发平台团队的创始人，现在是 API 策略师。开发者平台是那些可以半途而废，但很难正确吸引开发者的东西之一。Jeremy 讨论了避免激怒开发人员的不同方法，比如 API 版本控制和与开发人员社区交流的力量。

主要采取的方式是把你的 API 当作一个产品，而不仅仅是试图发布内部 API。然而，API 不是网站，因此 API 产品管理不同于一般的 API UI 设计。像 A/B 测试和分析这样的常规 UI 实践更难实现，但同样重要。如果你推出一个突破性的改变，你可能会严重影响一小群非常高收入的顾客。与可以不断更新的网站不同，您的开放 API 可能会被数百家不同的公司用于数千种不同的产品和集成。

https://www.youtube.com/embed/VI-gXpnVCnc

要获得更多资源，我们建议查看我们的 API 开发者体验指南。

Back4App 是一个后端即服务，让开发者无需担心后端就能快速创建应用。

达维·马塞多(Back4App 的首席执行官)一直在 AWS Lambda 上试验 GraphQL，供内部使用，并将其作为 Back4App 产品的一部分。许多为要在 AWS Lambda 上托管的 GraphQL APIs 生成无服务器函数的搭建工具可能会造成某些复杂性，尤其是当您的应用程序很大时。具体来说。达维注意到，支架工具不是在真正的无服务器/FaaS 架构中创建许多小函数，而是生成一个单独的 AWS Lambda 函数来保存整个 GraphQL API 的所有业务逻辑。这可能会导致可伸缩性问题，例如冷启动缓慢，在函数能够响应传入的 GraphQL 请求之前，必须下载许多 javascript 库。

不幸的是，我们没有记录整个会议，下面只是一个简短的片段，但查看Back4App.com了解更多信息。

https://www.youtube.com/embed/FKcVtsCXy1o

Stdlib 帮助开发人员和非开发人员快速创建 API，而无需考虑底层基础设施。

他们的 CEO Keith Horwood 在 StdLib 上给我们演示了如何创建一个快速的 Hello World API。看到您可以如此轻松地启动和运行 API 是非常令人着迷的。如果你所做的只是将 Salesforce 连接到另一个服务，你可能不需要微服务或甚至 AWS Lambda 的全部重量。很高兴看到 Zapier 的易用性和更大的灵活性。下面看。

https://www.youtube.com/embed/dPYZ3JgY9F4

这是 Moesif 主办的第一次开发者聚会，但很高兴将来能主办更多。如果您未能出席，请加入meetup 群组或我们的邮件列表(在左侧栏),以便获得未来活动的通知。如果你真的参加了，我们很乐意通过给我们发邮件来听听你对我们能做的任何改进。

Moesif 是最先进的 API 分析平台。成千上万的平台公司利用 Moesif 进行调试、监控和发现见解。

了解更多

原文：https://www.moesif.com/blog/technical/monitoring/Monitoring-API-Integrations-Stories-From-Fusebit-And-Their-Customers-in-the-Field/

根据 Blissfully 的年度 SaaS 报告，员工人数在 250-500 人之间的公司平均使用 123 个 SaaS 应用程序来支持他们的业务，并将在两年内更换其中令人震惊的 39%。对于较小的公司，这个数字上升到 46%。为了在这种环境中生存，为特定问题提供一流的解决方案正在成为 SaaS 供应商的赌注，并且不再足以确保持续的成功。成功的 SaaS 供应商在其平台中提供了出色的集成和定制功能，以提高转化率和保留率。

构建健壮和有效的集成经常是一个挑战。在 Fusebit ，我们每天都听到客户的声音，他们在可靠性、隔离、安全性和版本控制等问题上苦苦挣扎。然而，监控几乎是每一次谈话中最棘手的问题。开发时的可观察性问题首先出现，但随着生产负载的增加以及 API 的发展和破坏，很快就被确保可靠性的需要所取代。

用我们客户的话说，以下是一些常见的棘手问题和故障模式:

• “我对附加组件/web hook 和现有附加组件的标注没有内聚的可追溯性”~德国跨国公司软件开发高级总监
• “我们的故事很糟糕，合作伙伴在可检查性方面举步维艰。我们经常听到:‘我收不到事件，告诉我你发送给我的是什么’或类似的话”~同一家德国公司的技术产品管理副总裁
• “很难知道我们什么时候被调用，开发者不想‘错过’一个 webhook 调用。(在我们的案例中)这可能会决定订单是否得到支付。”~湾区启动工程经理
• “在提供 API 时，我们必须针对客户和大公司(Skype、Stripe)设定防御性费率限制。”~湾区启动时的首席技术官
• “如果失败，Zendesk 将关闭我们的 webhook……我们这边几分钟的中断将导致 web hook 停用。我们必须建立一个主动监控和通知解决方案来处理这个问题
• “因为集成是机器对机器的，所以很难知道发生了什么。人们给我们带来大量的交通流量，却忘了关掉它。没有人会看到这些消息…我们的客户不擅长记录和监控。”~湾区创业公司的联合创始人兼首席执行官
• “我们的集成最近被关闭，因为我们没有及时响应。有时它会被关掉，不知道为什么。我们开始监控我们合作伙伴的 webhooks 状态页面，我们甚至围绕它建立了自动化，以获得更多的可见性。”~西雅图创业公司工程经理

在这种代表 SaaS 主要参与者对 API 集成监控系统投资不足的背景下，寻求构建强大集成的公司经常只能用自己的监控基础设施来填补空白。这就是像 Moesif 这样的解决方案可以为开发人员节省数周不必要的前期工作的地方，更不用说持续的安心和减少操作痛苦了。

大多数监控解决方案提供商关注客户自己的 API 表面，但是在集成领域，监控集成合作伙伴的基础设施同样重要。在这里，Moesif 的产品以其为监控第三方 API 而定制的特性集脱颖而出:

• 通过实时事件流查明导致 API 调用失败的确切 JSON 或 XML 键。
• 比较数以百万计的成功和失败的 API 调用，并审计发生了什么变化

• 了解进入集成合作伙伴的请求量，衡量表现不佳的第三方 API 如何影响您自己的客户体验。

• 当合作伙伴失败时获得提醒，并确保他们支持该问题
• 查看哪些合作伙伴出现故障的全球状况以及发生故障的频率
• 将多个失败的事务关联在一起，以避免警报风暴

在构建客户要求的集成时，SaaS 供应商通常有一个选择:是在内部构建集成，还是利用集成平台(iPaaS)合作伙伴，如 Fusebit 。如果 SaaS 供应商只开发少量的集成，并计划成为维护这些集成的专家，那么前一种方法是有意义的。如果集成的数量预计会增长，并且供应商选择利用该领域专家合作伙伴的技术和运营知识，后一种方法是更好的选择。Moesif 的解决方案可以与任何一种方法结合使用，同时仍能提供显著的价值。

因此，无论你是自己构建集成还是与合作伙伴合作，都不要像上面引用的 Fusebit 客户那样结束；投资一流的监控和分析！

原文：https://www.moesif.com/blog/technical/graphql/Monitoring-GraphQL-APIs-Built-With-Apollo-and-Express/

当我们想了解最新的功能和性能问题时，监控我们的 API 是必须的。

Keyur Doshi 已经写了一篇关于监控用 Django 和 Graphene 构建的 GraphQL APIs 的文章，所以让我们深入 JavaScript 生态系统，看看需要什么来启动和运行它！

有许多 JavaScript GraphQL 实现，在本文中我们将讨论两个最突出的参与者:Apollo-server&express-graph QL

本文的第一部分是关于如何为每个 GraphQL 实现设置 Moesif API 分析。

第二部分是关于如何使用 Moesif API 分析来保持我们的 API 游戏的领先地位！

Apollo server 提供了一个独立版本和多个框架的集成。我们将在这里讨论独立版本。

首先，我们和 NPM 一起建立了一个项目。

其次，我们安装所需的两个 NPM 软件包。

1. 包括运行 GraphQL 服务器所需的一切
2. 连接到 Moesif API 分析服务

讯享网

接下来，我们创建一个保存所有设置代码的。

代码的关键部分在最后。对象的方法返回一个承诺。

这个承诺让我们可以通过对象访问底层的 HTTP-server。

这个服务器对象是事件的事件发射器。

我们可以在工厂函数的帮助下创建一个中间件函数，并将其用作事件的事件监听器。

Apollo server 也有一个 Express 集成，但是有一个替代的 GraphQL 服务器实现可以与 Express 一起工作，所以让我们看看如何设置它。

首先，我们创建一个项目。

讯享网

其次，我们安装所需的软件包。

• 是底层的 HTTP 服务器框架
• 是 express 中间件，它使用 Node.js 的参考 GraphQL 实现
• 是连接我们和 Moesif API Analytics 的库

这里的过程相当简单。我们使用工厂函数来获得一个可以与 Express 对象一起使用的中间件函数。

就代码而言，这是所有要做的工作。现在，每个到达服务器的请求，无论是 Express 还是 Apollo，都将被转发到 Moesif API 分析服务，并可以进一步检查。

在我们用我们选择的框架建立了我们的 GraphQL 服务器之后，Moesif 中间件将把请求数据发送给 Moesif 服务。就 GraphQL 而言，这意味着 Moesif 服务现在知道我们的查询和变化。

如果我们使用 apollo-server 独立版本，GraphQL API 会在所有路由上应答。Moesif 期望 GraphQL 查询在路线上，所以我们必须使用这条路线。

如果我们用浏览器登录到我们的 Moesif 控制台，我们会在 API 分析部分找到所有记录的事件。这包括但不限于:将 GraphQL 请求发送到路由。

为了只显示 GraphQL 查询请求，而不显示其他 HTTP 请求，比如加载 GraphiQL UI 的 HTML 或获取 GraphQL API 信息的自省查询，我们必须使用左侧的过滤器侧栏。

在 API 过滤器中，我们选择请求- > URI 路由，并将其设置为以去除非 GraphQL 请求。

现在我们只有 GraphQL 请求，我们可以应用 GraphQL 查询过滤器来关注我们想要监控的特定查询。

例如，我们可以通过选择作为 GraphQL 查询过滤器并将其设置为 ≠ IntrospectionQuery 来消除请求。

用 Node.js 框架将 Moesif API Analytics 添加到我们的 GraphQL API 构建中只是几分钟的事情。我们必须通过 NPM 安装,需要中间件，用我们的 Moesif 应用密钥配置它，我们就可以开始了。

设置完成后，我们所有的请求将被发送到 Moesif API 分析服务，并保存以备后用。

稍后，当我们的 API 启动并运行时，我们可以根据 GraphQL 查询的内容进行过滤、排序和分段，以深入了解我们的查询。

哪些是

• 最受欢迎？
• 最慢的？
• 最容易出错？

原文：https://www.moesif.com/blog/technical/graphql/Monitoring-GraphQL-APIs-built-with-Django-and-Graphene/

本教程假设您熟悉使用 Django 和 Graphene 的 GraphQL 和 Python。如果没有，你可以参考本系列之前的文章Python 和 GraphQL 入门

在前面的文章中，我们创建了 API 来查询、变异、搜索和过滤数据。在本教程中，我们将讨论如何使用 Moesif API Analytics 来监控我们构建的 API。

我们将通过在 requirements.txt 或中包含来安装库

讯享网

一旦安装了库，我们需要更新来向应用程序添加中间件。

我们还需要将添加到文件中

讯享网

您的 Moesif 申请 Id 可以在 Moesif 门户 中找到。注册 Moesif 帐户后，您的 Moesif 申请 Id 将在入职步骤中显示。

登录 Moesif 门户 ，点击右上方菜单，然后点击安装，您随时可以找到您的 Moesif 应用 Id。

一旦中间件被集成，所有的 API 调用将被 Moesif 捕获，我们将能够分析它。

现在我们将查询对象并选择、和字段，可以看到 API 调用被捕获。

我们可以通过提供配置选项来添加与 API 调用相关联的定制元数据、用户或公司 id。

关于配置选项的更多细节可在这里找到。

设置配置选项后，捕获的所有 API 调用将包括元数据、用户和公司信息。

要查看 GraphQL 的运行情况，您可以从 GitHub 克隆并运行这个示例应用程序。

在下一个教程中，我们将讨论更多关于分页的内容。同时，如果您有任何问题，请联系 Moesif 团队。

本系列前情提要:

• Python 和 GraphQL 入门第 1 部分
• Python 和 GraphQL 入门第 2 部分

原文：https://www.moesif.com/blog/api-engineering/api-gateways/Open-Source-API-Gateway-Roundup/

API 优先的公司依靠广泛的服务套件来构建他们的 API，并为他们的客户创造价值。多个团队可能使用不同的技术开发 API。通过流程和工具，您希望这些 API 与您的 API 消费者(无论是内部的还是外部的)保持一致。公司用来将多个 API 结合在一起的一个工具是 API 网关。

API 网关是一种简化访问、认证和管理公司众多 API 端点的工具。通常，网关不知道您的架构、数据格式和其他 API 决策。例如，一个成熟的 API 程序可能有不同的 API 类型。类似地，网关可以处理内部和外部服务，这意味着您可以使用一个网关来处理微服务、移动后端，甚至是合作伙伴或公共 API。

在本文中，我们将讨论 API 网关的常见特性。我们将详细介绍一些最通用、最受欢迎的开源 API，它们是如何工作的，以及如何利用它们来监控 API 的使用和性能，从而为 API 消费者创造更多价值。

API 网关在实现上有所不同，但都有一些共同的特性:

• 数据有效性
• 证明
• 版本控制
• 贮藏
• 分析学

如果一个 API 不返回它所声称的，开发者将很难或者不可能使用它。数据验证将确保您的用户向您的端点发送正确的数据类型，您的服务器正确地存储它们，并且您的 API 向您的用户返回正确的数据类型。

您还可以通过 API 网关实现身份验证。例如，您可能需要对 API 中的特定端点和特性进行速率限制或限定，以供经过身份验证的用户使用。API 网关有助于保持跨终端的身份验证的一致性，即使您实现了多个后端服务。

大多数 API 网关还处理每个端点的版本控制，因此您的组织和用户都可以跟踪您的 API 发生了什么变化。这为您的 API 用户带来了很好的开发体验，并且当您知道开发人员正在使用哪个版本时，可以提供更好的客户支持。

网关也可以实现缓存来提高 API 的性能。根据请求的复杂程度，有些调用可能不需要与数据源进行完整的往返。在这些情况下，您可以配置网关来提供缓存和其他节省资源的过程，以保持 API 的性能和响应性。

最后，可以配置网关来收集 API 分析。这使得它成为关于 API 及其使用的数据的单一来源。使用持续监控来收集端点的使用日志，然后分析数据或与强大的分析工具集成，以便您的组织能够获得对您的 API 的重要洞察。

这些 API 网关特性将帮助您构建可靠地随用户伸缩的 API。虽然您会找到许多解决方案，但我们还是收集了一些开源 API 网关供您考虑。这些工具不仅提供了所需的特性，还提供了在社区贡献的帮助下随时间扩展的能力。此外，您的工程团队可以构建满足您需求的功能，并将其回馈给社区。

在接下来的几节中，我们将分解一些流行的开源 API 网关，以便您可以获得一些关于它们如何工作的信息。

Tyk 是一个模块化的开源 API 网关。它是灵活和开源的，因此您可以集成第三方中间件或部署定制插件，使您的 Tyk 实现适应您公司的需求。Tyk 允许您连接系统中的每一个数据源、API 端点和后端服务，使您能够轻松地查看您的 API、控制访问、记录您的 API 以及监控您的 API 路由。您可以将 Tyk 实现为一个自托管解决方案，由您的组织负责管理用于运行 Tyk 的服务器，或者您可以将其用作一个完全托管的解决方案，如果这对您的组织更好的话。

Tyk 开发团队通过与用户交流和构建插件来满足他们的需求，在社区中发挥着积极的作用。通过使核心 Tyk 平台模块化，默认的 Tyk 体验可以保持轻量级和敏捷，同时为具有不常见用例的用户维护一个易于访问和易于实现的插件库。这使得 Tyk 成为可能改变或扩大范围的 API 的**选择，因为随着时间的推移，Tyk 也可以变得更适合您的 API。

虽然 NGINX 主要被认为是一个流行的 web 服务器、反向代理和负载平衡器，但 NGINX 也可以充当 API 网关。如果 NGINX 已经是您的 API 技术栈的一部分，您的团队可以快速地将它部署为 API 网关，这是一个很好的选择。它也非常适合单一服务整体和微服务后端实现。

NGINX 受益于他们为在互联网上提供和开发服务而构建的大型 NetOps 和 DevOps 工具套件。对 NGINX 进行故障排除非常简单，因为它有一个庞大的现有用户群，这些用户共享关于在生产中使用 NGINX API 网关的实用信息。NGINX 被大公司和小公司使用，它适合许多常见的用例，并且很容易上手。

Gravitee 是一个流行的开源 API 网关，它通过一个独特的实现与我们列表中的其他部分共享一组核心特性。它允许您控制谁访问您的 API 以及如何访问，限制他们可以在您的 API 上使用哪些资源，并添加功能来监控您的 API。它旨在为具有 HTTP 服务器经验的开发人员快速实现。Gravitee 被构建得尽可能的轻量级和灵活，因此您的开发人员在构建它的时候会有最小的开销，这样您就可以为您的用户创造价值。

Gravitee 在这个列表中是独一无二的，因为它的所有服务都是开源的，而不仅仅是 API 网关。这包括增强核心 Gravitee API 网关的托管服务。这为他们提供了独特的社区参与度和透明度。用户可以公开报告 Gravitee 的问题，并跟踪他们的问题是如何解决的，或者通过软件更改，或者记录用户自己可以做些什么来解决常见问题。

Kong 基于 NGINX，一个已经出现在我们名单上的 API 网关。Kong 的某些独特之处使其成为各种规模的组织的普遍选择。Kong 专注于实现大规模的微服务 API 架构，并提供了一套大型插件来实现这一目标。不需要安装每一个 Kong 服务就可以上手。它是模块化和灵活的，因此您只需安装您的团队想要使用的服务。

Kong 的插件开发工具包(PDK)也允许你使用 Go 或 Lua(一种基于 C 的脚本语言)构建插件来扩展 Kong 的功能。这导致了大量由 Kong、他们的合作伙伴以及他们的庞大社区构建的插件可供选择。如果核心的 Kong API gateway 不能满足您组织的所有需求，您可以利用现有的插件库，或者专门为您的独特用例构建一个全新的插件。如果您正在寻找一个社区驱动的、开源的 API 网关，Kong 可能是您的正确选择。

我们列出的 API 网关超越了 API 网关最常见的核心特性，具有独特的方面，可能使它们更适合您的组织。在评估 API 网关时，考虑您的长期需求是很重要的，这样您就不会在产品开发周期的后期被迫迁移到不同的解决方案。我们讨论的所有 API 网关都有方法来轻松扩展它们的功能。随着时间的推移，您的 API 需求会发生变化，您将需要能够更改您的 API 网关以满足您的需求，从而继续为您的用户提供**体验。

API 可观察性是一个重要而强大的特性，可以添加到 API 网关中。您可以向 API 网关添加强大的分析和监控功能，以获取产品指标，并构建一个为客户创造价值并推动增长的 API。Moesif 为最流行的 API 网关提供了优秀的本地插件，并且可以很好地适应许多 API 管理栈。Tyk 和 NGINX 有很好的与 Moesif 集成的例子，你可以快速实现或适应另一个 API 网关。

乍一看，为您的组织选择 API 网关似乎是一个挑战。只要您选择的 API 网关具有我们讨论过的核心特性，并且可以扩展到包括像使用 Moesif 的 API 监控这样的强大特性，您就可以随着 API 产品的增长而不断改进您的 API 网关。

原文：https://www.moesif.com/blog/podcasts/api-security/Podcast-API-Security-and-FHIR-Recommendations/

Ep。12:艾丽莎·奈特(Alissa Knight)，康复黑客和 API 安全专家

Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。

加入我们的是 Alissa Knight ，她是 CISO Knight Ink Media 的合伙人，网络安全专家、电影摄影师和出色的内容创作者，擅长大规模讲述品牌故事。

莫里斯国际基金会的 CMO 拉里·埃布林格是今天的主持人。

https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true

Moesif · 12. API Security and FHIR Recommendations

在 SoundCloud 上听这一集，在我们的 YouTube 频道上观看，或者在苹果或谷歌上下载。

目录

• 2:23 免狱黄——成为一个有道德的黑客
• 5:43 认证不等于授权
• 8:14 用瞄准镜防流星雨
• 10:06 不要用 WAFs 来保护你的 API
• 13:08 知道你的 API 有哪些流量
• 14:35 向左移动安全护罩向右移动
• 17:39 PHI 值 1000 倍信用卡信息
• 21:41 原料药是医疗保健领域最薄弱的环节
• 24:27API 有多个攻击面
• 29:40 使用 MobSF 查找 API 密钥
• 30:44API 需要符合 FHIR
• 34:55 正确实现 FHIR】
• 37:11 获得 FHIR 认证
• 38:11 FHIR 认证与 HIPAA 合规性
• 39:59 没有一个合适的 API 安全解决方案
• 42:59 检测您的 API

拉里·埃布林格(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络的第 12 集。我是劳伦斯·埃布林格，今天的主持人，也是 Moesif 的首席营销官，API 可观测性平台。

和我一起的是艾丽莎·奈特，CISO(首席信息安全官)，网络安全专家，电影摄影师和出色的内容创作者，擅长大规模讲述品牌故事。她是一个定期的会议发言人，这也是我第一次在 apidays 界面会议上看到她做主题发言的地方。她正在做一个关于安全和医疗保健应用的精彩演讲，我想我们的观众会很乐意听到她对 API 安全性的看法。

所以我们在这里。欢迎艾丽莎。我们在哪里能找到你？

艾丽莎·奈特(奈特墨媒)😗*所以，首先感谢拉里。这是一个伟大的介绍。我总是为人们不得不提供我的简历和介绍我感到难过，因为这感觉就像可以永远继续下去。所以我要开始让人们介绍我，你知道，那个“安全小妞”，那个“黑客小妞”但是不，谢谢你邀请我参加你的节目。很荣幸来到这里。非常感谢。

所以我在拉斯维加斯。很多人不知道有人住在这里。这不仅仅是为了参加会议，而且人们确实住在这里。我和妻子住在一个叫萨姆林的地方，离加沙大约 20 分钟的路程。

Larry: 很高兴你能参加我们的节目，我们很高兴你能和我们分享你对安全的看法。

顺便提一下，当我向家人提到我在我们的播客上主持你时，我一个 12 岁的女儿问你是白帽子还是黑帽子。科技语言已经变得如此主流，甚至连十几岁的孩子都很熟悉。因此，为什么不与我们分享你从黑帽到白帽的历程，创办两家网络安全公司，然后到今天经营 Knight Inc. Media。

“快进到我 17 岁的时候。我做了一个非常糟糕的决定，黑了一个政府网络。被抓了…最后在网络战中为美国情报部门工作。”即使你一开始是一名黑帽黑客，你也可能成为一名道德黑客。

艾丽莎:所以，令人惊讶的是，即使是 12 岁的孩子也知道黑帽子和白帽子之间的特殊区别。很好的问题，我认为这是一个很好的开场方式。

我大约 13 岁的时候开始从事黑客工作。不幸的是，我很少有指导。但是当时的情况非常不同。你说的是一个不同的时代，那时你还没有今天所有这些可用的资源。你知道，那时还没有 SANS，甚至谷歌。

我通过 IRC 参与了黑客活动。有一个 IRC 服务器，互联网中继聊天，叫做 EFnet，我非常喜欢这些 EFnet IRC 频道。所以，那真的是我的家人。因为，我的意思是我花在网上的时间比和家人互动的时间还多，所以他们几乎把我养大。我是在 IRC 上长大的。

在这些渠道中，我通过其他人学习，也通过自己学习。当时，外面的知识非常少。如今，通过谷歌和所有这些资源，我们可以获得如此多的知识，但那时候真的很难学。你真的需要靠自己去学习。

快进到我 17 岁的时候。我做了一个非常糟糕的决定，黑了一个政府网络。被抓了，他们在学校逮捕了我，信不信由你。在指控被撤销后，他最终在网络战领域为美国情报部门工作。所以我被迫扮演一个白帽子的角色。我穿橙色很难看。监狱不适合我。

我脱离了自己的控制，从黑帽子变成了白帽子，这很好，因为我意识到我是谁，我很清楚，我可以做我最喜欢的事情，赚很多钱，那就是黑客。

因此，渗透测试/道德黑客技术诞生了——实际上是黑客攻击公司网络，并向他们解释我们是如何做的，以便他们能够抵御真正的攻击者。

拉里:我觉得没人穿橙色那么好看。

艾丽莎:橙色不是新的艾丽莎骑士。

Larry: 在你的一个很棒的 YouTube 视频中，顺便说一下，我推荐我们的听众收听，你给黑客下了一个精彩的定义，它是一个想要理解事物如何工作的人，然后发送一个开发者没有预料到或考虑到的刺激。所以，并不像人们想象的那么邪恶。同样，在你的 YouTube 和博客内容上，你真的用大量的经验数据来支持你所有的主张，这真的使它更有价值。

开发人员在开发 API 时最大的系统性问题是，他们会记得对 API 请求进行认证，但却无法授权。理解授权和认证之间的区别:您可能有一个 API 密匙来证明您有发送 API 调用的合法权限，但是您不一定被授权接收您所请求的数据。

Larry: 所以，作为一个坐在桌子两边的人，可以这么说，并且写了大量关于黑客攻击银行&健康技术应用编程接口的文章，现在我刚刚听说了一个政府网络。最近有人向 Gartner 报告了您对 API 安全性的看法，开发人员在 API 安全性方面最常犯的错误是什么？

艾丽莎:好问题。我认为，对我来说，最系统的问题是开发人员会记得认证 API 请求，但他们不会授权它。所以，这是理解授权和认证之间的区别。身份验证是您拥有或知道的东西，而授权是被允许实际查看数据。

我可能有一个 API 令牌或 API 密钥来证明我有一个合法的用户帐户，可以合法地访问 API 来发送 API 调用，但是我无权接收我所请求的数据。这是我所看到的所有 API 都存在的一个问题，就是缺乏授权。特别是围绕所谓的破坏对象级授权(BOLA) 漏洞。

对于那些不完全理解这意味着什么的听众来说，我最喜欢用的比喻是整个衣帽间的事情。如果你和我去参加一个鸡尾酒会，我看到你把你那件昂贵的博柏利外套寄存在衣帽间，我想把它带回家。衣帽间的人给了你 18 号，我得到了 17 号，我拿了一支记号笔，把 7 号换成 8 号，然后把它还给衣帽间，说我想要我的大衣。这是 BOLA 漏洞的一个很好的例子。我通过验证了，我有票，但是我没有权利把你的博柏利外套带回家。授权漏洞基本上就是这样工作的。

当您没有指定您的用户有权访问的内容时，BOLA 漏洞经常发生。如果您使用像 OATH 这样的令牌，那么您可以通过将作用域绑定到令牌来限制访问。

拉里:你实际上抢先问了我最后一个关于博拉的问题。请告诉我们，我们的开发人员如何防范此类 BOLA 攻击。

艾丽莎:所以你可以做不同的事情。我注意到的一件事是许多开发者会实现令牌，但他们不会实现范围。一个非常重要的建议是，如果你要实现 OATH 之类的令牌，你要确保你将范围与这些令牌联系起来，这些令牌定义了访问级别或允许你查看的记录。它基本上围绕您的令牌设置参数，并定义您可以请求什么。举例来说，如果我是一名临床医生，我有一个登录帐户，通过这些示波器，我只能查看这些特定的患者。或者，如果我是一名患者，我的令牌的范围应该只允许我查看我的患者记录，而不是/patient/1，2，3，4，5，所有这些其他患者记录。我应该只能要求我的特定病人记录。

显然也有商业解决方案可以实现这一点。但是我发现的许多漏洞只是基本的授权问题。它们不像 sequel injection，可以由传统的 Web 应用防火墙(WAFs) 来处理。waf 非常适合基于规则/基于逻辑的安全控制，因此无法真正抵御 BOLA 攻击。

分析师已经将 Web 应用防火墙和 API 网关提升为抵御 API 攻击的有效安全控制手段。waf 对于识别有效负载中的 sequel 注入或跨站点脚本很有用，但是它们不能知道我是否被授权查看我所请求的数据。

关于基于规则的 waf，比如 ModSecurity 甚至 API 网关，我注意到在你最近的一篇 YouTube 帖子中，你说它们对保护你的 API 毫无用处。

艾丽莎:我很固执己见！

Larry: 有趣的是，我认为这是来自 Gartner 的 2019 年报告，你需要做什么来保护你的 API，他们在报告中拥护 API 网关和 WAFs 的优点。然后你上了 Gartner，基本上把它否决了。

艾丽莎:我觉得他们不太喜欢我。

Larry: 还有什么可以做的，比如先进的异常检测，可以进一步保护你的 API。

艾丽莎:这是我的立场。我不认为安全性应该成为产品的一个特征。例如，当您有一个 API 网关时，他们会将安全性作为一项功能添加到他们的主要职责中。对我来说，这是一个问题。

Gartner 发布了一份关于 Web 应用程序防火墙的报告，其中他们说 WAFs 是针对企业的有效安全控制。这是我可以整天谈论的事情——关于付费游戏和分析师行业之类的东西。但我不会去那里。事实是，我认为这造成了这种虚假的安全感，因为 CISOs 正在购买 WAFs，他们正在实施 API 网关并打开安全性，这造成了这种虚假的安全感。

我最近入侵的每一个 API 都受到 WAFs 的保护。这些首席信息官正在倾听来自分析师行业的信息，他们不得不发表和谈论这些信息，因为这些是他们的付费客户。但问题是，它们不是抵御 API 攻击的有效安全控制措施。WAF 如何知道我是否应该请求不属于我的数据？它将在有效载荷中寻找 sequel 注入、跨站点脚本攻击之类的东西。但是它不知道我是否被授权查看某些东西，这超出了它的理解范围。我认为这回答了你问题的四分之三，另外四分之一是什么？

保护您的 API 的第一步是了解它实际上要做什么。合法的人流量和合成的流量有很大的不同。你不能保护你不知道自己拥有的东西。

Larry: 如果 WAFs 和 API 网关不摆动它，你怎么保护你的 API？事实上，我认为你提到了一个非常有说服力的观点，我也在你的 YouTube 频道中听到过，那就是许多 CISOs 和开发人员将安全性视为事后的想法或附加条件。你说，不要这样，你应该从一开始就把安全作为重要的考虑因素。

我想以这样一个事实作为这个答案的开头，即任何拥有 API 的组织都需要知道他们的 API 将会得到什么。他们需要知道:这是人流量——合法的人流量，是合成流量，还是使用凭证填充的账户接管(ATO)攻击？寻找高频工具也是一个好主意，这些工具可能会持续攻击您的 API，并从合法用户那里窃取非常昂贵的带宽和资源。每个人都应该知道自己拥有什么——你无法保护你不知道自己拥有的东西。这非常重要。因此，我想以这样一个事实作为开始，即您应该知道流向您的 API 的流量内部是什么。

使用双管齐下的方法在编写代码时实现安全性，让开发人员参加安全代码培训，并使用工具在编写不安全的代码时发出警告。保护权:在你的保护被部署到生产中后保护它。

Alissa: 在了解哪些类型的流量流向您的 API 后，最重要的事情之一是左移安全，但也要屏蔽右移。左移安全的概念是，当你写代码的时候，你应该把你的开发人员送到安全的代码培训，你应该实现一个工具，这个工具会监视他们写不安全的代码，当他们写不安全的代码时，对他们大喊大叫。寻找一个解决方案，你可以用应用程序编译 SDK，如果你有一个基于应用程序的架构，那么，把安全转移到左边:当产品被创建时，当代码被编写时，实现安全。

“保护权利”的理念是，不仅要在编写时保护它，还要在它部署到生产环境后保护它。因为我们知道网络安全是一个非常转瞬即逝的行业。它移动得非常快。就在你我谈话的这段时间，又有几个新的零日漏洞出现了。每隔几分钟就会有新的漏洞和漏洞出现，所以你需要对即将发生的事情保持警惕。

未知的未知。这就是现在让每个人都紧张的原因，也是现在让很多人被攻破的原因——未知的未知。对我来说，已知是传统的安全控制，如网络入侵检测，就像过去的 Snort，当你为这些漏洞编写 Snort 签名时，你基本上是在记录已知的已知。但是未知的未知呢？我不知道什么是我还不知道的，所以这就是神盾局可以带我们去未来了解我们不知道的事情的地方。

拉里:我刚看完妮可·珀尔罗斯的一本书，他们是这样告诉我世界末日的。

艾丽莎:哦，妮可，实际上我刚刚在 MoneyFest，Money2020 上采访了她。所以如果你还没看过，我强烈建议你和你的观众去看一看。这是一本很棒的书。她是纽约时报的一名非常非常出色的记者。

拉里:对。这本书又长又厚。一本厚书。它读起来像一部犯罪惊悚片，涵盖了整个剥削行业，从 2000 年、2002 年的早期开始。左移右护的绝佳视角。我喜欢这个比喻。

你的医疗保健信息是持久的，如果它被发布到黑暗的网络上，它就消失了，无法改变或恢复。相比之下，在 Target 被黑客攻击后，银行只是简单地给你邮寄一张新的信用卡。

拉里:继续前进。由于 Moesif 用于一系列健康技术应用程序，并且我们的一些观众在健康技术部门工作，根据您的经验，ePHI(电子患者医疗保健信息)或个人银行信息在黑暗网络上更有价值，为什么？

艾丽莎:哦，实际上我对此做过研究。这是一个很好的问题。所以很明显，在我的工作中，我经常浏览 Tor 网站，黑色网站，我可以告诉你的一件事是，电子健康记录的价值是美国信用卡号码的 1000 倍。所以当你有一个 PHI 记录，EHR 记录，不管你怎么称呼它，你有很多数据。所以，如果我妥协了，在妥协中，我偷了拉里的信用卡号码，你的银行可以很快发给你一张新卡。银行花了几块钱。他们送你一张新卡，你有一张全新的卡，你很好。

如果我泄露了你的健康史，并把它放在黑网上出售，你有多容易通过邮件获得新的健康史？不可能的。没有这回事。它不见了。一旦公开，就结束了。如果我想知道如何杀死拉里，我找到他的 PHI，我发现他对蜜蜂叮咬过敏。所以我带着大黄蜂去追你。但事情一旦发生就无法挽回了。这也是我认为它价值如此之高的原因之一。另一件事是，已经妥协了这么多的医疗保健 API，我可以告诉你，那里有一个数据宝库。

有一次，我不仅看到了医院的入院记录，还看到了那个人的家庭成员信息。所以，当你去一家医院，他们要求近亲信息和所有这些其他的东西，所有这些其他的数据，他们需要知道，这就形成了一个非常丰富的内容，非常丰富的数据环境。在 PHI 记录中有很多关于个人信息的数据，这就是为什么我们需要如此认真地对待这个问题，这也是我很多医疗保健研究的动力。

当你谈论人们的健康时，这和破坏一个公司网站是完全不同的。在过去的二十年里，发生了太多的变化。我是说，以前我在 IRC 上玩这个的时候，都是关于，地狱世界的大规模毁损。现在是钱。这是一个利润丰厚的行业。当你谈到黑暗面和这些勒索软件集团带来的数千万美元时，这是疯狂的。我的意思是，许多勒索软件集团比一些国家赚得更多，手头的现金比一些大公司还多。所以很恐怖。这是一个巨大的行业，对于你的问题，冗长的答案是 PHI 绝对比财务数据更有价值。

这并不是说，不要误会我的意思，拉里，这并不是说它不重要，它只需要比 PHI 少得多的钱。

最大的问题之一是 PHI 的监管链，数据从一个非常安全的 API 转移到一个不太安全的 API。Cerner 和 Epic 有非常强的安全性，但是一旦 PHI 离开了 API，你就不知道下一个系统有多安全了。黑客瞄准了不太安全的 API——拆东墙补西墙。

Larry: 考虑到 PHI 和 EHR 的患者记录如此宝贵，锁定 healthtech APIs 是否存在独特的挑战，相对于那些来自 fintech 的挑战？

Alissa: 我认为 API 可能是安全方面最薄弱的环节。不同的医疗保健提供商将使用不同的人力资源系统，无论是 Epic 还是 Cerner 或其他系统，请填写此处的空白。这些系统之前，我相信我们会谈到这一点，但在 FHIR 之前，他们不能互相交谈。有一些问题，例如，如果我的目标是像塞尔纳·EHR 系统这样的系统，它可能受到非常非常好的保护，非常安全，但一旦那些 PHI 离开该系统，转而使用不太安全的 API，作为一名黑客，你认为我会以哪里为目标呢？我将针对安全性较低的 API。我要走阻力最小的路。

我认为最大的问题之一是监管链，或最薄弱的环节——PHI 可以从一个非常安全的 API 变成一个不太安全的 API。它不太安全，因为编写它的人只是一些小企业，他们不知道自己在做什么，也不知道任何关于安全的事情。我抢劫了他们。我抢了保罗而不是彼得。

此外，我认为第二件事是普遍性，我甚至敢说，在我观察的许多移动应用程序中，这是非常系统化的，在这种移动健康或移动健康应用程序的新概念中，API 密钥和令牌以明文形式存储在移动应用程序中，或以明文形式硬编码。开发人员只是伸出他们的手臂说，“嘿，如果我不能把它们存储在应用程序中，我应该把它们存储在哪里？”他们不知道该把它们放在哪里。所以这确实是个问题。我认为在应用程序方面存在问题，密钥和凭证被硬编码，然后在 API 所在的后端也存在问题。

由于数据无处不在，城堡和壕沟的安全是不可能的。攻击面很广，从面向合作伙伴的 API(考虑供应链威胁),到 web APIs(没有 SDK 来捆绑额外的安全性),再到中间人攻击(证书安全性影响服务器/客户端 API 安全性)。

拉里:对。您能否详细介绍一下 ePHIs 可能受到攻击的不同攻击面，以及如何加强这些攻击面？我们讨论了一些应用程序本身，但是关键商店、网络、API 端点以及数据泄露又如何呢？

当然可以。显然到处都有数据。城堡和护城河的整个概念在这一点上被完全抹去了。你控制不了。因此，在客户端，密钥和令牌或凭证的硬编码才是真正的问题。您有不同类型的 API，所以让我们来讨论不同的攻击面。

您有面向合作伙伴的 API，其中供应链攻击是当今的真正威胁。我甚至不需要从网上追踪你，我可以找到你和谁做生意，然后追踪他们。因为你们两个之间有联系，通过一个合作伙伴 API，一个 B2B API，它正对着你们两个公司，我加入了。因为不管是谁写的，都觉得这是一个面向 API 的合作伙伴，而不是面向互联网的合作伙伴，所以我们不用太担心安全性。

你有 web APIs，如果你没有移动应用，客户端的安全控制将会大不相同。虽然你可以用移动应用程序编译一个 SDK 来增加额外的安全层，但是当你不能用 SDK 编译 Chrome 浏览器时，你该如何处理 web APIs 呢？让谷歌帮你发布吗？

还有一个关于中间人/中间人/中间人攻击的问题，在这种情况下，许多组织没有实施证书锁定。作为一名攻击者，我可以用很多这样的应用程序将自己插入到客户端和后端 API 之间的通信中。然后我向两个方向提交 SSL 证书，告诉 API 我是客户机，告诉 API 客户机我是 API 端点的 API 服务器。他们都认为他们在和对方说话，但他们实际上是在和我说话。这使我能够解密 SSL 加密的流量并查看它。我可以通过拦截流量并解密，然后将这些 API 请求复制并粘贴到我自己的 API 客户端(如 Postman)来了解 API 的工作原理。然后，我可以用 API 客户机自己手动跟踪 API 端点。

黑客不在乎你的手机应用程序是否能在越狱的手机上运行。下载 APK，或者拦截从手机应用程序到&的 L7 流量，通常足以找出如何访问所有数据。

拉里:明白了。我最近听了你的一个教程，是关于如何真正做到这一点的，而且出乎意料的简单。我也不是超级伟大的程序员。事实上，我根本不是一个程序员。但是有一点令人震惊的是，你可以通过下载到你的 MAC 上的 Postman 和一些软件包，把所有的信息都提取出来。

艾丽莎: 《吃豆人》让事情出奇的简单。这是一个像红帽转速和真正强大的包管理器。这些工具很多都是免费下载的。比如我觉得叫高级休息客户端，那是免费下载的。问题是，当你进行黑客攻击时，这是我不明白的，许多开发人员会实现安全性，并说“哦，别担心，我们希望确保移动应用程序不会在越狱或路由的手机上运行。”我不在乎那个。我不需要在越狱的手机上运行它。面对许多这样的 API 攻击，我只是从我的 android 设备上提取了 APK。然后使用 Apk Extractor 将它加载到我工作站上的工具中，讽刺的是，你可以从谷歌商店下载。我不需要执行它。我不需要在监狱环境中运行它。我可以在笔记本电脑或工作站上完成所有这些工作。

或者，我甚至可以在 android 设备上运行它，并用工具拦截流量。然后再次访问所有数据。信不信由你，我更喜欢这样做，而不是看 API 文档。对于 FHIR，有很多关于它的文档，因为 FHIR 的要点是你已经为它开发了。但我更喜欢实际拦截流量并观察它。我是一只包猴。我倾向于通过查看包和 API 在第三层如何工作来学习，而不仅仅是阅读文档。

要解构一个应用程序，只需将 APK 文件拖放到 MobSF 中，它只需将其拆开，还原到原始源代码，然后用 Grep 找到硬编码的密钥/令牌。

拉里:我注意到你是 Grep 的支持者。

是的，我是一个希腊女孩。哇，你看了我的视频，不是吗？但谢谢你跟踪我，我很感激。爱我的粉丝。

有一个很棒的工具叫做 MobSF ，给那些可能不熟悉它的观众。它被称为移动安全框架，它允许您将数据包 APK 文件拖放到该工具中，然后它会对其进行解构。它只是把它拆开，倒回到原来的源代码。所以我才能找到所有这些硬编码的钥匙和令牌。有趣的是，很符合你的观点。我不喜欢使用图形用户界面，实际上我会用它来返回源代码。然后我进入我的命令外壳，进入终端，使用一串 Grep 字符串。这是我在应用程序中寻找硬编码 API 秘密的首选方式。

最近的《医疗法案》规定医疗技术公司需要向请求者提供患者数据。符合 FHIR 的 API 提供了一种安全的方式来满足这些需求。

拉里:有趣的东西。继续关注 HL7 的工作以及他们即将发布的最新版本 FHIR(快速医疗互操作性资源)标准。这项工作有多重要，开发人员是否应该按照最新的 FHIR 标准进行构建，您认为这对医疗保健领域的 API 安全行业有多重要？

艾丽莎:这一点都不重要——不，只是开玩笑。这是巨大的。在我所有的脆弱性研究中，这可能是我做过的最重要的事情，因为你知道，我接触了很多来自医疗保健行业的人，谈论这项研究有多么重要。

很多人不知道这一点，但他们自然而然地认为我们黑客天生就知道这些东西。我不知道怎么拼写 FHIR，更不知道当我走进这里的时候它到底是什么。我不得不做作业。我不得不研究。我甚至不知道 HL7 是谁。HL7 是组织的名称，也是标准的名称。这就像是整张面巾纸。这些都是我需要研究和理解的。这花了我几个月的时间，我仍然不知道它的全部，我仍然不完全理解它的许多内容。我对这项研究感到非常兴奋。我目前正在研究 FHIR 的 R4，这是该标准的第 4 版。

它是由 HL7 国际组织创建的，健康七级国际组织，就像你提到的，在 FHIR 之前，有所有这些在 FHIR 之前的 HL7 的不同版本。并且 ONC(国家健康信息协调员办公室)已经基本上为医疗保健支付者和医疗保健提供者设定了这些截止日期，并且说“你需要使这些患者数据对请求它的人可用，否则你就违反了这个数据封锁规则，信息封锁规则。”这可能意味着严厉的处罚和罚款。如果你被发现违反了这条信息封锁条例，那可就麻烦了。这有一个截止日期，组织和医疗保健支付者需要实现 FHIR APIs，并使这些医疗保健数据可用。

唯一的事情是，我想展示当这些 API 没有被正确保护时会发生什么。这是这项研究的动力。这是我过去一年一直关注的。这项研究的第一阶段目标是存储医疗数据的移动医疗 API。在第二部分，我们称之为玩 FHIR，我们专注于入侵 FHIR APIs。这就是即将发布的报告将详细介绍的内容，它将给出我们的发现以及我们在那里看到的情况。有很多，我真的很兴奋能够公布这项研究。我知道你们在医疗保健领域也做了很多工作。医疗保健是一个目标非常丰富的环境。那里有如此多的钱，黑客们知道这一点。数据太多了，通过这些易受攻击的 API 很容易获取。

使用 OAuth、认证、授权和其他**实践创建坚如磐石的 FHIR APIs。如果人类实现了它们，它们就会有漏洞。让他们很难被发现。

拉里:在这里戳熊，但如果修订版 4 即将推出，你一直在努力，许多其他聪明人也一直在努力，它发布后会有很多漏洞吗？或者，它将会是安全健康、移动健康和 ePHI 超越 AIPs 的涅槃，继续前进？

Alissa: 我需要向您的观众澄清，当您部署 FHIR 时，您不会真的像购买收缩包装的 FHIR API 一样购买，并确保将安全性包括在内然后它就展开了。这将取决于实施。

一个组织可能实现了一个 FHIR API，但是没有遵循**实践，因此它非常容易受到攻击。但是，另一个组织可能会实现 FHIR APIs 并使之坚如磐石。漏洞在哪里可能并不明显。也许会比其他组织花更长的时间来找到它。我永远不会说任何事情都是不可激活成功教程的。如果人类正在实现它，它会有漏洞，但它们可能更难被发现。这就是他的特点。你和我都可以实现 FHIR APIs 来服务我们的 PHI 记录，但是你的可能比我的更安全，因为我不知道我在做什么，而且我实现得不安全。

所以要看实现。这取决于谁在实施它，以及他们是否知道如何正确地保护它。因此，在 FHIR 上的智能带来了 OAuth 和所有其他事情，如认证和授权。因此，实现 FHIR 当然在很大程度上取决于实现者，以及他们是否正确地实现了它。

作为额外的检查，让你的 FHIR API 获得认证是值得的。

Alissa: 现在，我真的想插一句——组织可以通过一个认证过程来获得 FHIR API 认证。因此，如果你要实现一个 FHIR API，我也要实现一个，我实际上可以让我的 FHIR API 获得认证，证明它是根据标准实现的，并有适当的安全控制。您可以继续运行您的 FHIR APIs，但无需认证。这不是强制性的。你不需要得到你的认证。

在这项研究中，我接触过的 EHR 供应商当然都在追求认证。但是你可以有非认证的和认证的 API。这意味着易受攻击和非易受攻击的 API 将会非常多。我这么说的时候要小心，因为我并不是说一个经过认证的 API 将是安全的和不可激活成功教程的，我只是说你将拥有两者的混合。

与 HIPAA 不同，FHIR 有第三方机构可以认证你的 API。

拉里:这听起来有点像 HIPAA 合规，没有第三方认证机构；有您应该遵循的**实践，也有人会审核您构建的内容，但是 HIPAA 基本上是您应该遵循的一系列指导原则。听起来，HL7 更进了一步，有第三方机构可以检查你是否按照标准实现了 FHIR。

Alissa: 我采访过的一家 EHR 供应商，我不会说出他们的名字，但他们确实说他们正在争取年底前获得认证，这将使他们成为第一家获得 FHIR 的公司。我不知道谁是真正的认证机构，也许是 HL7，我不知道。但是你绝对可以选择去获得认证或者不获得认证，就你的例子来说，你不需要这样做。

有很多很好的 API 安全解决方案。但是实际的**方法是什么，我不知道是否会有答案。

拉里:明白了。好了，我们今天的播客已经涵盖了很多内容。关于如何保护你的 API，特别是你的移动医疗和医疗技术 API，你已经给出了很多精彩的见解。作为倒数第二点，我们还没有看到 API 和安全性的下一步是什么？

艾丽莎:我认为#更多请。这是结束节目和面试的好方法。首先，如果我戴上算命的帽子，这绝对是世界前进的方向:我们正在完全远离整体架构，转向微服务，一切都在转向云，一切都是由 API 驱动的微服务。我认为我们将会看到越来越多的这种情况。

问题是组织将从运行 1 到 2 个 API，发展到运行 1，000 到 2，000 个 API。我现在正在与一个拥有超过 1600 个 API 的组织合作。这么多 API。我认为这将创造一个更大的市场。在向 Gartner 提交的关于 API 状态的演示文稿中，有一点是市场正在经历一场身份危机。

API 安全市场还不知道它是什么。每一家拥有 API 安全威胁管理解决方案的公司都相信他们的做法是正确的。这不一定是错的。每一家公司可能都在用正确的方法处理 API 安全问题，但是我认为陪审团仍然不知道它会落在哪里。它是在线的吗？是被动吗？我们用 SDK 吗？我们使用分布式跟踪吗？我们是否使用…有很多非常棒的方法，其中很多是我的客户，他们都有很好的解决方案。实际的**方法是什么，我不知道是否会有答案。

但我知道什么是错误的方法。我们已经在节目中讨论过这一点，那就是这些传统的基于规则的系统，如 Web 应用程序防火墙。或者，我们已经有了一个 API 管理解决方案，让它来确保安全性。我的研究表明，我可以攻击和破坏这些 API，并通过受 WAFs 和 API 网关保护的 API 窃取所有这些数以千计的患者记录，这证明了没有人应该使用这些来保护他们的 API。他们应该关注像 Moesif 这样的解决方案，关注像 Traceable 和 Approve 这样的其他威胁管理解决方案，以及其他许多优秀的解决方案。

保护您的 API 最重要的一步是了解它们发生了什么。给自己配备一个工具，让你能够深入研究你的 API 的流量。

首先，每个人都需要明白的是，你无法保护你不知道自己拥有的东西。您需要知道您有多少 API，它们提供什么类型的数据，它们是否与互联网隔开(我可以从互联网访问它们吗)或者它们是否面向合作伙伴，我们是否授权和认证(我们给予您对此的认证访问，但是我们是否授权您可以请求什么数据)？所有这些都非常重要。了解您的 API 服务的数据类型。如果我有 1600 个 API，你认为我会知道哪些 API 服务于 PII 或 PHI，哪些服务于 PCI 数据吗？我应该知道这一点，但我不可能记住它，所以我需要一个工具来做这件事。我对你们所有人的建议是知道哪些数据将进入你们的 API，拦截它，查看它，分析它。知道那里发生了什么，知道什么占用了 API 的带宽，以及正在发送什么 API 请求。用工具装备你自己，这将给予你观察它的能力。

拉里:然后采取行动。多么精彩的总结和采访收获。我的最后一个问题:我们的观众在哪里可以找到更多关于艾丽莎的信息，你接下来会在哪里演讲？我知道你是一个非常多产的主题演讲人。艾丽莎会有什么下场？我们的观众还应该关注哪些资源？

作为一名内容创作者和电影制作人，我认为我发布漏洞研究和内容的主要渠道是 YouTube。所以，一定要订阅我的 YouTube 频道，打破通知的铃声图标。但是，也请在 Twitter 上关注我，并在 LinkedIn 上与我联系。总的来说，我喜欢对 API 安全和黑客技术的研究。我有一本关于通过 Wiley 入侵 API 的新书要出版了。我的第二本书。我正在为一部新电视剧写剧本。我的世界里发生了很多事情，我肯定会敦促所有人在 YouTube、LinkedIn 和 Twitter 上关注我，因为这是我的主要去处。除非他们想看我食物的照片，否则我会在 Instagram 上发布我食物的照片。

我感谢你们所有人，作为我的网络的一部分，我的追随者和粉丝们请保持关注，因为这将是非常令人兴奋的一年。我将在 HIMSS 上发表演讲，我想说，这可能是世界上最大的医疗保健会议，我将在那里做主题演讲。除了其他一些令人惊叹的主题演讲人，如 A-Rod 和 Michael Coats。

如果有人想过来打个招呼，我肯定会看看会发生什么，我也会在 DEFCON 上发言，今年我会在 30 多个会议上发言。所以很多激动人心的事情。我还将在即将到来的 Money2020 会议上发表主题演讲。这真的很令人兴奋。实际上，我会在我的网站这里和【KnightInkMedia.com T2】T3】上发布我的活动日程，请留意。再说一次，找我的最好方式是在社交媒体上。

拉里:太好了。非常感谢艾丽莎今天抽出时间。我相信我们的观众会非常喜欢这个播客。

谢谢你。感激不尽。

原文：https://www.moesif.com/blog/podcasts/developer-marketing/Podcast-APIs-for-the-Right-Business-Case/

Ep。14:埃里克·王尔德，阿克斯韦公司的催化剂

Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。

加入我们的是 Axway 的催化剂、作家和标准撰稿人 Erik Wilde。他帮助组织进行数字化转型，确保愿景、战略和技术保持一致，并得到业务和组织计划的补充。

劳伦斯·埃布林格，Moesif 的 CMO，是你今天的主持人。

https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true

Moesif · 14. APIs for the Right Business Case

在 SoundCloud 上听这一集，在我们的 YouTube 频道上观看，或者在苹果或谷歌上下载。

目录

• 1:55 从您的 API 中驱动价值
• 3:53 专注于一项超级有价值的业务能力
• 8:23 大学生关注 API 商业案例
• 11:54API 的互联网——引擎盖下的 API
• 15:17 **的 API 风格是由 API 的用途决定的
• 17:13 为什么安全性对 API 健康很重要
• 23:30 API 可观察性 vs API 监控
• 26:28 通过指标和结论衡量 API 的成功
• 30:15 整个 API 生态系统的未来

拉里:欢迎来到 Moesif 的 APIs over IPAs 播客网络的第 14 集。我是劳伦斯·埃布林格，今天的主持人，也是 Moesif 的首席营销官，API 可观测性平台。

加入我的是 Eric Wilde，多产的 YouTuber，作者，标准贡献者，Axway 的催化剂，最近是加州大学伯克利分校哈斯商学院的客座讲师。

Eric 的大部分职业生涯都在从事 web 技术和 API 方面的工作。虽然他的背景是计算机科学，但他认为技术很少是阻碍组织发展的因素，所以现在他专注于帮助制定战略，以确保公司成功。

欢迎埃里克，我们在世界的什么地方能找到你？

谢谢，谢谢拉里的热情欢迎，也谢谢邀请我。现在，你可以在伯克利找到我，因为我计划在这里参加一个为期四天的校内课程，就像本周的前四天。嗯，像很多事情一样，最后一分钟它变成了一个在线的事情，但我仍然在这里。所以，是的，我在东湾，我想你在半岛的某个地方。

拉里:实际上，我就在旧金山海湾大桥的对面。伯克利和你平常的家完全不同。你一年中大部分时间住在哪里？

埃里克:我现在住在苏黎世。我曾经在伯克利住过一段时间，那时我在伯克利工作，但是几年前我们搬到了苏黎世。我们仍然喜欢回到这里，因为这是一个如此可爱的地方。

如今 API 专业人员应该关注什么？人们不再需要被说服为什么原料药很重要，它们就像蘑菇一样冒出来。更确切地说，重点在于什么是好的 API，我如何让我的团队设计它们，以及我如何用一个平台来支持它们。

拉里:对，的确如此。那是非常真实的。

现在，你和三个火**最近发布了开创性工作持续 API 管理的新版本。除了封面的彩色照片之外，自第一版以来的过去三年中，API 生态系统有什么新的变化以及如何变化？

埃里克:这是个好问题。在某种程度上，新的是，你可以说现在发生的事情是，我们必须越来越少地告诉人们为什么 API 很重要，它们很重要，以及如何设计 API。我们必须更多地讨论如何大规模地做到这一点。

就像我的一个好朋友，Isabelle Mauny，在一个播客上说，“API 就像蘑菇一样到处涌现。”。我认为在某种程度上这是真的。我认为越来越多的组织没有看到这一点，当然，他们正在使用 API，每个人都在使用 API。如今，如果不使用大量的 API，你就无法使用计算机。

但是，管理这些并弄清楚我如何获得为组织驱动价值的 API，而不仅仅是“我们有 API，所以可能会发生好事情”。而且还要了解什么是好的 API？什么可能不是这么好的 API？我如何让我的团队设计出好的 API？我如何用一个平台来支持他们？

所有这些，我认为我们仍然会看到这个行业的发展势头，因为我们知道 API 不是你唯一需要的东西，但它们可能是一个限制因素。因此，重要的是要真正做到这一点，而不仅仅是抱最好的希望。

使用 Moesif 强大的 API 监控功能评估和优化您的 API。T3】

API 实际上只是一个接口。业务价值的交付很重要，但这不是开发 API 产品时要考虑的最重要的事情。

拉里:嗯，很有趣。多棒的 segway 给你的一条 pins tweets，上面写着“为正确的事情构建 API 比为事情构建正确的 API 更重要”。我的意思是，这不仅是一个绕口令，而且有点难以解开。你能为我们打开它并告诉我们你是什么意思吗？

当然，当然。

我认为关于 API 的一件重要的事情是理解它实际上只是一个接口。API 是一种能力的交付机制，有时我认为，我们在 API 领域高估了交付的重要性，而不是交付的内容。我的意思是说，如果你有世界上最好的 API，有很好的文档记录，设计完美，使用所有正确的 http 方法，并正确地做所有这些事情，但它提供了对没有人需要的功能的访问。那个 API 没有任何意义，从审美上看可能是一个美好的东西，但肯定不会带动任何商业价值。

另一方面，如果你有一个超级有价值的业务能力，它可能不是最好的 API，但是人们可以以某种方式忍受，这将更有价值。

最后，我认为更重要的是，至少在第一步，在你直接跳到“我们使用哪种 http 方法”之前，考虑我设计的 API 是为了什么，你知道所有这些事情。我认为，有时我们真的会专注于设计的技术部分，但我们并没有真正足够关注我们实际设计的产品，而不仅仅是产品的交付。

我认为最近的书，我认为我们有一波很好的书出版了，所以迈克尔·阿蒙森刚刚出版了一本。最近有一本是詹姆斯·希金波坦写的，对吧。有一本是 API Handyman 写的，在所有这些书中，我认为现在关注的是整个过程，而不仅仅是“你在技术上做什么？”，而是“我如何设计正确的东西？”。

我认为我们越来越理解这一点，但我认为这仍然是我们必须关注的事情，并确保设计的这一部分是重要的一步。在进入技术细节之前，我们对此非常小心。

拉里:非常有趣，是的。有趣的是，当我们与新客户签约时，传统上，首席执行官是产品人，我们看到，产品、商业案例和制造完整产品所涉及的所有问题都更加重要，然后以正确的方式实际实现 API 平台。因此，你对产品经理在 API 平台中具有非常重要的战略作用的分析也是我们在客户群中看到的。

埃里克:我想，最终，是这样的，对吗？思考我正在创造的价值以及一直在使用的一些例子是很重要的。像 Twilio，Stripe 和所有这些东西，我的意思是我也喜欢这些例子。

但是最后 Stripe 没有他们成功，因为他们的 API 不错。但是 Stripe 是成功的，因为每个人都需要支付服务，他们为此提供了 API，对吗？这是主要原因。

然后，他们在设计产品方面也做得很好，对吗？但是，如果没有最初的想法，即“嗯，实际上每个人都需要支付服务，没有人想自己做”，那么为什么没有一个好的 API 呢？

正是这一点让他们成为了今天的公司，然后他们在同样重要的事情上执行得很好。

了解更多关于谁使用您的 API 以及如何使用 Moesif 的信息。T3】

加州大学伯克利分校哈斯商学院的学生知道，很多业务将流向 API。教授可扩展和可持续的商业模式让学生为不断变化的 API 环境做好准备。

拉里:非常非常真实，非常真实。是的，我的意思是，我认为有很多例子，你可能有一个很好的实现，但你不一定有一个很好的业务案例来证明你的公司，即使我们在 API 领域处于一个非常泡沫的时间点。我认为市场和投资者仍然在市场中寻找收入和牵引力，而不是真正有光泽、设计良好的 API 实现。

埃里克:对，就是这么回事，对吗？同样，这个星期有四天，我基本上在这里度过了商学院，我的意思是他们理解 API 的重要性，因为有很多业务都是面向 API 的。但是，当他们看到 API 时，他们不会对“嗯，他们以正确的方式使用 HTTP Post 吗？”。他们会问类似这样的问题:“嗯，有这样的生意吗？”。比如你的商业模式是什么？你将如何建立一个可持续发展的业务来提供服务？然后也许你也应该在技术层面上做好设计，但那真的不是主要的。这很重要，但不是主要的事情，也不是我们应该关注的唯一事情。

拉里:对，对。最近我们的播客中有一位大型企业软件公司的首席 API 产品人员，她的任务是真正提出通过 API 实现一些功能的整体计划。他们的一些客户要求这样做，但这并不是足够的理由。与她交谈很有趣，她告诉我，做好这件事最重要的一点是，它首先必须是一个收入中心。它必须有能让高管团队说“是的，这是值得投资的”的东西。

Erik: 是的，如果你做得好的话，你还可以使用 API 来了解一些人们或多或少感兴趣的东西。不久前，我与 Tanya Vlahovic 进行了交谈，我想她现在在 Salesforce，她那时曾在易贝工作。她讲述了一个故事，在易贝，有一个 API 是很重要的，但最初他们认为“API 对于人们可能寻找物品和做这类事情很重要”，他们就是这样。

但事实证明，推动更多价值的是，美国石油学会现在推动最大价值的是那些将过剩库存放在易贝的大公司。对吗？他们通过一个 API 来做这件事，他们需要一个 API，因为，当然，他们必须卖出，我不知道，大概 10 万双鞋。你需要一个 API 来确保这个库存从你所在的地方进入易贝。

拥有一套初始的 API，然后理解“嘿，这似乎是真正推动价值的东西”，然后在这方面投入更多的努力，对吗？这是一个很好的方式来理解我们必须找出真正推动业务的是什么，然后我们可以在这个方向上分配我们的资源。

通过 Moesif 了解您的 API 采用情况和规模

API 很复杂，但是理解创建和支持 API 的基本构件对于构建一个优秀的 API 产品是很重要的。

拉里:对。非常非常突出的一点，非常有趣。这是一个小小的不合理的推论，实际上是从商业案例跳到更多的底层技术和对一般技术的理解。我真的很喜欢你在 YouTube 上关于互联网如何工作的 12 分钟讲解，你解释了 IP，TCP，SSL 和 UDP。

和我们分享一下为什么你认为这样的理解对 API 专业人员很重要。

Erik: 所以我认为，至少在一定程度上，理解整个 API 到底是如何工作的是很重要的。

当然，你不需要理解，比如所有的东西都是玻璃纤维，我是说在那种情况下，我也不知道这些东西是如何工作的。但我认为真正理解基本机制很重要，这样你也能理解一些风险，以及一些可能正确发生的事情。

例如，你可以得到延迟，你可以得到，取决于正确的技术，你可以得到事物的重复，当然，总是 API 可以某种程度上正确地删除。

我认为重要的是比仅仅理解 http 和 json 更深入一点，并且理解它是建立在什么之上的。至少给我展示一下它的基础，它的基础就是 TCP/IP。

我认为这也有帮助，例如，你变得更加意识到事情可能会失败，对吗？我认为，我们仍然看到的许多事情是，API 领域的太多设计只是建立在快乐的道路上，假设一切都将永远正确。现在你看到许多应用程序，如果事情不顺利，它们会悲惨地失败。你可以很容易地说“嗯，那没有必要”，对吗？通过更好地理解事情是如何失败的，只要考虑到这一点，您就能够拥有一个更健壮的应用程序。

我认为这对于从事这方面工作的人来说是很重要的，他们将 API 作为工具来组装部件。为了理解事情是如何出错的，我理解它们会继续出错，它们会如何出错，然后我可以更好地为那些情况设计。我认为为失败而设计变得越来越重要。

就在最近，Gartner 的这篇文章预测，到 2025 年，我想他们会说，“组织对 API 的外部依赖性将是现在的三倍。”这意味着你越来越依赖他人，这很好，因为你可以组装东西，这很好。但是你也必须负责任地管理这些依赖，并且可能构建一些东西，这样，如果那个东西失败了，我仍然至少做我的工作的一部分，对吗？

我认为，理解有时仍然是我们需要更多一点的基础来真正理解什么会出错，所以我们只是设计一个更有弹性和更健壮的系统。

借助 Moesif 深入了解您的 API，从采用漏斗分析到端点延迟。T3】

有许多类型的 API 风格可供选择，但是“正确的”风格可以由 API 项目决定。为什么要建立一个 API 对于这个过程来说和如何一样重要。

Larry: 关于这个话题，你有没有列出一系列你会选择或强调的流行 API 风格？

Erik: 在我概述风格时，我会谈到这五种风格，其中有面向资源的风格、超媒体风格、RPC，就像传统的面向函数的函数调用，还有面向查询的风格，比如 GraphQL，甚至基于事件的 API。

最后，我认为 API 只是一个工具，这个工具允许我们从现有的连接到网络的构建模块中构建新的东西。更好地理解什么样的工具是好东西，对于哪种设计，对于哪种目的，我认为这是一件好事。围绕 rest 的这整个原教旨主义总是正确的，或者 GraphQL 总是正确的，或者基于事件总是正确的。我认为我们正在慢慢地远离这一点，这很好。

我最想告诉人们的是，不要那么原教旨主义，更好地理解有不同的风格。他们没有天生的好坏，只是周围有不同的约束。更好地理解它们是如何工作的，也许也更好地理解，在什么情况下，哪种风格，也许是更好的选择。我认为这会让你成为一个更好的设计师，因为最终，设计师不应该总是说“我总是这样做”。作为一名设计师，你应该明白你必须为一个问题设计，为面临这个问题的人设计。你必须给他们一个适合这种环境的解决方案。

通过 Moesif 的定制仪表板，与队友协作监控 KPI。T3】

良好的 API 安全性始于理解您的 API 环境。全面了解当前正在使用的 API 对于构建安全框架至关重要。

拉里:非常有趣，是的。作为我们必须支持的 API 平台提供商，有多种风格和实现过程似乎越来越困难，但我认为这是野兽的本性。

谈到 API 平台和第三方解决方案的重大变化，人们必须意识到这一点。请告诉我们您对 API 安全性的看法，为什么它很重要，我们如何促进安全性的黄金标准，以及您对最近标准化的最新版本 fhir for APIs 的看法。

Erik: 好了，让我们从安全性开始吧。

安全当然是非常重要的。API 总是提供一些与你的系统环境交互的方法，它可能是只读的，但是即使这样，你也可能暴露出某种风险。这种能力总有可能以某种形式被滥用。

对于一个好的 API 安全性来说，最开始的地方就是了解你拥有哪些 API，这让我感到很惊奇，就像我与许多非常大的组织一起工作一样。每当我们与那些组织中的人交谈时，他们都不知道他们有哪些 API。组织中有人构建 API 并发布 API，因为他们只需要完成一些工作。他们可能没有意识到有一个平台可以保护它，或者他们只是说“它足够好了，它只是与我的应用程序对话，所以它能有多坏”。有时，在理解每个 API 都是潜在的安全风险方面，存在所有这些缺失的实践。

你必须考虑可能发生的最糟糕的事情是什么，而最糟糕的事情通常是可以准备好的。安全性并不是一件超级复杂的事情，它只是人们需要了解的一系列实践，他们必须应用这些实践。您可以为他们提供非常好的工具，确保他们自己不必做那么多。

但这仍然是一个组织内部的事情，我认为我们仍然经常看到它没有以足够严格的方式完成。有时候，我看到一些组织在某个时候关闭了防火墙中的某些端口，这真是令人惊讶。基本上说了一小会儿让我们不要通过通过某些端口的流量，然后他们基本上只是等待报告进来，关于“嘿，这个应用程序停止工作”。然后人们就理解成“哦，那里好像有个 API”。没有人告诉任何人，人们只是创造了它，它运行在那里。它可能一点也不安全，甚至没有人知道它在那里。

在黑客之前找到这个应用程序是非常重要的。这就像我们现在看到的正在爆炸的整个可观察空间。我认为这是非常重要的，有时你必须观察事情，只是为了清楚地了解我的网络中正在发生的事情。

有时候，组织越大，越少组织真正知道发生了什么。我认为这是安全性的一个基本方面，在技术层面上，它几乎比“你是如何做到的”更重要。我认为，一旦你知道你有一个 API，如何保护它，如何为它提供工具，我们已经做得很好了。只要知道你有 API，它们是什么，谁应该访问它，以及所有这些事情。我认为有时这几乎是棘手的部分，因为你的网络上有太多未知的东西。

拉里:对，非常正确，非常正确。Alissa Knight 最近参加了我们的播客，她谈到了中间人拦截以及如何使用 API 避免这种情况。她的大外卖，这真的强调了你的问题，只是知道你有哪些 API。她的主要观点是，你可以解决 90%的问题，方法是确保当你对用户进行身份验证时，并不一定意味着他们可以访问所有内容。当她入侵人们的 API 时，她发现我可以被认证，但是然后，通过改变我的一些令牌，仅仅一两个字符，我现在可以获得对一整套其他用户 API 有效载荷材料的访问。她说这太棒了，我是说，她出版了这个。她为医疗应用和银行应用做了这个。她说，令人惊讶的是，很多人认为“哦，这个人已经通过认证，现在他们可以访问任何东西了。”。

是的，我认为这是 owasp 安全列表中的第一项。这是对象级访问，就像人们只是假设你可以访问某些东西，所以这里是一切。浏览一下 owasp 十大应用，你会发现，“是的，你知道，我们实际上并不是所有的应用都做得这么好。”。

借助 Moesif 的 SOC2 兼容客户端加密技术，自信地获得深入的 API 分析。T3】

可观察性和监控似乎是同义词，但它们是同一枚硬币的两面。可观察性是关于将机制放在适当的位置以支持主动迭代。监控可以被看作是一个技术层面的观察。

拉里:对，非常正确，非常正确。回到你提到的一些事情，那就是现在有一个关于 API 可观察性的大运动。

你为什么不告诉我你对 API 可观察性和 API 监控的区别的定义。为什么可观测性，更重要的是停留和仅仅是纯粹的监测。

Erik: 我不会给你下定义，因为我需要再考虑一下。但我认为，至少在我使用它的方式上，我认为大多数人都会使用它，就是说如果你有一个 API，监控通常是你应该做的事情。这是一个相当技术性和具体的组成部分，你把它放在那里，说“让我们数一下访问次数”或其他什么。这是一种非常具体的观察层次，是这样的，但我想，它更具体，我们需要看一些我们知道的东西。

我认为可观察性更加根深蒂固，随着我们看到的工具的出现，它更加根深蒂固于我们知道有事情在发生。但我们并不确切知道它是什么，它的行为如何，甚至可能不知道我们有什么。所以我们观察环境，观察正在发生的事情，并从中学习。与其说只是通过数东西来学习，不如说是监控。我们了解到我们有一些我们并不真正了解的 API，我们了解到这些 API 有一些我们认为不会被使用的使用方式。

我要说的是，它的内部要深得多，其中还涉及到许多更先进的技术，这些技术不仅试图计算字节数，还试图真正了解正在发生的事情。为了帮助你更好地了解发生了什么，然后你可以做所有这些事情，你也可以像 Phil Sturgeon 一样进行逆向工程，他最近发表了一篇文章，内容是关于从监控流量基础或观察流量来推断开放 API 信息。我要说的是，这类事情比我们现有的相当简单的监控更能洞察流量。

拉里:对，非常正确。我的意思是有点自私，但我为一家 API observability 公司工作。我们总是强调这样一个事实:是的，您可以计算服务器正常运行时间、延迟和地理位置问题。但实际上，通过深入研究有效负载中的细微差别，以及客户实际上是如何使用它的，您会获得更多的商业价值。这似乎有更大的价值。

通过 Moesif 获得关于您的 API 和用户的深入、细致的分析和指标。T3】

评估原料药的功效并不总是像选择一个指标来衡量那样简单。因为 API 只是一个工具，衡量成功应该从 API 的业务目标以及在 API 使用过程中发现的任何见解开始。

非常有趣的 segway 来衡量 API 的价值。你如何衡量你的 API 是否成功，如果不成功又如何，你认为哪些指标是重要的，或者你可以从你所监控的事物中得出什么结论，然后观察并把它变成一个性能 API。

Erik: 让我大胆地说，API 不可能成功。能够成功的是一种能力，一种产品，或者你通过 API 实际交付的东西。我有这个视频，我必须指出来，因为这是我最喜欢的视频之一，我在这里谈论啤酒。我给出的类比是，API，传递机制，所以它就像一个瓶子或一个罐子，它是你获得啤酒的方式。最终真正重要的是啤酒，但啤酒不是交付机制，这是有区别的，我认为真正理解 API 仍然很重要…不要太关注 API，API 只是让事情运转的机制。

最后，你必须考虑我想用这个做什么生意。我正在工作的实际能力是什么，这更像是做好产品管理的人？谁真正负责设计该产品，交付该产品，确保它被使用，监控它如何被使用，计算出它产生的收入多于我们运行它的成本。

在这种程度上，我认为纯 API 指标只是其中相对较小的一部分。您可以看到这是没问题的，这可能是我们提供访问此功能的另一种方式。最终，真正重要的是“我们推动业务了吗？”所以我认为 API 有价值的整个想法可能很有趣，但主要是关于我是否在正确的方向上推动了正确的事情。

拉里:非常有趣，是的。是的，重要的是再次回到 SaS 的 Jeannie Hawrysz，她对在现有企业软件公司中创建 API 的观点，你的 API 必须是一个中心收入意识，不能只是一个好东西，或者因为产品经理想把它放在那里。业务案例和业务指标是你必须做好的最重要的事情。

Erik: 很抱歉，因为它对我来说非常重要，我的意思是我见过一些公司，他们做的事情之一基本上就是统计 API 访问次数，这不是很有趣，而且几乎产生了不好的激励，因为不是创建更好的 API，而是更细粒度的 API，这样你就可以用一个 API 做更多的事情。他们受到激励，基本上有“不，我们有这 25 个 API，如果你想做任何事情，你必须调用所有 25 个 API”。然后说，这很好，这里有 25 个 API 调用，所以这可能不好，但我知道为什么会这样，应该有人阻止这种情况发生。

将您的 API 分析与您更大的业务目标联系起来，并通过 Moesif 加速采用。T3】

随着技术和非技术方面之间的桥梁越来越好，API 的前景将继续发展，从而实现商业成功。

拉里:对，没错。查看正确的指标，不要为了指标而统计指标，绝对要。所以我的最后一个问题，水晶球凝视，整个 APIs 生态系统的未来是什么样子的？

Erik: 所以我认为在 API 领域将会发生的是，我们将会看到在 API 的技术方面和非技术方面之间将会有更好的桥梁。我认为，现在，我们仍然没有足够的重叠和更具商业头脑的事物之间的平稳过渡，真正理解什么是我们应该拥有的能力，什么是我们应该提供的能力。

现在想想，我们是否有这样的 API，比如我们是否应该投资建造这些东西，然后说好吧，应该有人来设计这些东西，但我们也需要有人来思考应该设计哪些东西。回到建造正确的东西和建造正确的东西。我认为，几乎在某个时候，我们对开发人员、开发人员、开发人员有点过头了，因为开发人员当然非常重要。但他们也必须开发正确的东西，我认为建立更好的桥梁，以确保每个人都理解正在建立的东西。我认为这很重要，而且在某种程度上，我本周发现这非常有趣，当你与湾区的公司交谈时，他们当然非常注重技术，在那里你不必解释太多 API 是什么等等。但另一方面，如果我回到瑞士的家，与德国和瑞士的组织交谈，他们并不是天生数字化的。对于 IT 部门来说，业务部门和数字部门之间的差距仍然很大。

我认为跨越这一鸿沟，确保每个人都明白正在发生什么，每个人都明白需要发生什么，我认为这是我们仍然需要开发更好的工具，做更多的教育。这样到最后，每个人都真正明白，我们都应该做什么，我能做些什么。不仅仅是开发者在做贡献，所有人都在做贡献，我认为这是我们有望看到巨大变化的地方。

拉里:太好了，太好了。是的，我完全同意需要团队合作。让你的产品上市并在市场上取得成功，不仅仅是关注优秀的开发者体验。

因此，我们的听众在哪里可以听到更多你的声音，显然，请给我们一个你最新的优秀出版物的纯正插头。

当然可以。遗憾的是，我不能拿起我们的书，因为我没有带在身边，但是当然每个人都应该看看我们最新的书“连续 API 管理”第二版，这是一个月前出版的，现在是两个月前了。我希望每个人都觉得这很有趣，特别是关于 API 和一个会议案例，因为我们认为当我们围绕它开始整个计划时，这确实是世界的发展方向，我认为继续这样下去对我们有好处。

至于你能在哪里找到我，当然，你总能在谷歌上找到我。但是这些天我的主要渠道是我的 YouTube 频道，所以只要把我的名字输入 YouTube，你就会找到我的频道。这叫做“让 API 工作”。

我在那里有很多有趣的客人，他们谈论他们的 API 实践，他们在 API 领域的经验，所以去看看，除此之外，你会在我经常去的地方找到，比如 Twitter 和 LinkedIn。

拉里:太好了。埃里克，今天很高兴和你谈话。非常感谢你的真知灼见，我相信我们的听众会发现它们很有教育意义，非常有用。

拉里，非常感谢你邀请我，我希望这不是我们最后一次这么做。我总是喜欢谈论 API 的事情和空间的走向。

拉里:当然可以。下次再见，非常感谢 Eric。

原文：https://www.moesif.com/blog/podcasts/developer-marketing/Podcast-Developer-Marketing-Essentials/

Ep。10:亚当·迪万德，EveryDeveloper 的负责人

Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。

加入我们的是亚当·迪万德，他是 T2 EveryDeveloper 的负责人，也是一名开发者营销专家。在我们的播客中，他探讨了如何让开发者使用并喜爱你的 API 产品。

莫西夫的首席执行官德里克·吉林是今天的主持人。

https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/&color=%23ff4f00&auto_play=false&hide_related=true&show_comments=true&show_user=true&show_reposts=false&show_teaser=true

Moesif · 10. Developer Marketing Essentials

在 SoundCloud 上听这一集，在 YouTube 上看，或者在苹果或谷歌上下载。

目录

• 0:41 讲故事搞事
• 3:38 帮助开发人员更好地完成工作
• 5:33 让你明白开发者的问题
• 7:18 使用非开发消息
• 13:23 超越 Hello World
• 16:41 衡量成功
• 18:19 找出你的解决方案
• 20:20 与你的用户交谈
• 22:16 允许开发者在你的文档中提供反馈
• 25:05 单据只有一张 DevEx
• 28:48 进行大开发重点入门项目
• 32:00 通过所有渠道沟通
• 35:14 在提出异议之前确定用法
• 38:33 精简你的指南
• 41:15 通过用例激发开发创造力

德里奇·吉林(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络第 10 集。我是德里克·吉林，今天的主持人，API 分析平台 Moesif 的首席执行官。

和我一起的是亚当·迪万德。在成为《连线》的技术记者和可编程网站的编辑后，他给提供商带来了一个非常有趣的视角。他在 Sendgrid 和 Zapier 负责开发人员沟通和营销。有趣的是，Moesif 本身就是 Zapier 的客户，所以喜欢使用该产品。他还帮助许多不同的公司和创业公司从事开发者营销和所有开发者平台的工作。很高兴你今天能来，亚当。

亚当·迪万德:是的。谢谢你邀请我。

作为一名偶然的营销人员，我发现在你的 API 中吸引技术受众的**方式是讲述一个故事，说明你所拥有的为什么重要

德里奇:好吧，那么就开始吧，我想听听你的故事，从为可编程网络写作开始，到你如何进入开发者优先的行业。

亚当:首先，我是一名开发人员。我有一个计算机科学学位，并且是一名专业的开发人员，所以我有这样的背景。但实际上，我一直对教学感兴趣，对当某人真的有所收获时的那种“啊哈”时刻感兴趣。我一直都是这么做的。《连线》的写作始于 Webmonkey 的技术教程。我是一名开发人员，心想“嘿，应该有更多的开发人员知道我正在使用的这项很酷的新技术或工具”。然后在某个时候，我意识到这是我想做的一点。

我又为 Wired 和 Webmonkey 写了一些，实际上我的最后一篇文章是“混搭已死，网络活着”。这应该是在 2000 年代末，所有的东西都是混合在一起的，我说，未来所有这些 API 都是网络的未来。当然，移动电话还处于萌芽状态。我很确定可编程网络从那篇文章中找到了我，这是一个完美的时机。我正在埋头写我的第一本关于映射 API 的书，所以这就是我开始为可编程 Web 写作的方式，然后最终作为第一个编辑全职加入。

我建立了一个团队，发现新的 API 并报告 API。我们追随了所有这些趋势。事实上，对我来说，开发者营销的一部分故事是，我会收到所有这些公司的公关宣传，他们对他们的 API 非常兴奋，但并没有真正讲述他们为什么重要。所以当我离开可编程网络的时候，我意识到这是一个帮助讲述这些故事的机会。所以我称自己是一个偶然的营销人员，因为我真的回到了我以前作为开发者为了好玩而做的那种教学和讲故事的部分，因为我意识到这实际上是公司吸引技术观众的最好方式。这就是我如何完成从开发人员到记者再到技术营销人员的转变。

Dev 对传统营销持怀疑态度——这将他们引向另一个方向，浪费了他们的时间。相反，给他们一些能帮助他们更好地工作和像开发人员一样交流的东西。

德里奇:哦肯定。我喜欢听这个故事，尤其是因为与技术型观众交流非常困难。是什么让它如此艰难？为什么比传统营销难那么多？

亚当:你知道，你可以说开发者以前被狡猾的销售策略弄得焦头烂额。我想那可能是真的。他们浪费了时间。但最重要的是，这是开发人员在做他们的工作，他们工作的一部分是持怀疑态度，思考你可能遇到的所有边缘情况。因此，许多传统营销被他们视为阻碍他们实现目标的陷阱，他们的目标是构建一些伟大的软件，而不是浪费他们的时间，将他们拉向其他方向。

所以我认为，很多时候，不面向开发者的营销可能会让人产生怀疑，感觉就像“哦，这是以前浪费我时间的东西，它把我带到了其他方向”。所以他们不会被它吸引。

相比之下，有些东西会帮助他们更好地完成工作，而且确实来自这样一个地方，在那里他们可以看出发送信息的人要么有相似的背景，要么知道他们在哪里。这对于建立信任至关重要。

通过展示你熟悉开发人员的问题，与他们建立信任:“我们了解自己的情况，这是我们看到的成功案例”

德里奇:这是一个很好的观点，关于信任，把开发者，怀疑论者变成更像福音传播者的东西。一家公司可以做些什么来建立这种信任，不管是围绕产品、营销还是信息传递。

Adam: 所以我认为为开发人员开发工具的公司通常是由开发人员创办的，他们当然了解那些问题，那些他们正在解决的真正的开发人员问题。所以我认为你越能分享你对这一点的理解，就越能建立信任，因为你能说“看，我们在那里。我们明白了。这就是它存在的原因。”我的意思是，公司开始于那些观点，那些信念，认为事情比应该的要难，或者其他公司做这件事的方式不是他们认为应该做的方式。所以你越能分享这些观点，你就能让开发者参与进来。

因此，分享你理解这些问题是一部分，但也能够表明你知道如何解决这些问题是另一个关键部分。这就是我不断回到教育的原因，因为一个开发人员不可能尽可能地了解所有事情，所以，如果你能够向他们展示“我们知道我们的东西，这就是我们所看到的成功”，你将获得很多信任和潜在的客户。

你的产品可能会被非开发人员使用:产品、营销、支持或客户成功，所以使用非技术营销并提供非编码人员也可以使用的工具，比如可视化构建器

德里奇:这是一个很好的教育市场的想法，而且展示比告诉更好，开发者希望看到一些东西是如何工作的，是什么让他们做得更好。也就是说，有很多公司，包括 Zapier，有两种不同的受众:开发人员受众和业务人员，他们正在试图弄清楚什么是 API，或者如何称之为 API。你能给我讲讲那里的一些挑战吗？你实际上是如何同时对两种听众说话的？

Adam: 如果你考虑到 Zapier 的用户方面，Zapier 的受众可能会比这更多。所以，那些真正为你自己的工具建立自动化的人，那些为 Zapier 付费的人，就是那些观众。这些观众肯定有开发者，我仍然有一个付费的 Zapier 帐户，我经常使用，我可以编写一些我在 Zaps 中做的东西，但大多数观众不是技术人员，不知道如何在他们的工具之间建立联系。他们甚至可能不知道是 API 让这一切发生的。

然后你有平台方面，这是我在扎皮尔做的大部分工作。因此，在平台方面，你有一个 SaaS 工具，它有一个 API，你想把它连接到 Zapier，集成到那里，使你的所有用户都能够进行这些自动化。我的标题在 Zapier 有开发者营销，但花了一点时间才意识到，即使是那些观众也没有我们想象的那么发达。肯定有开发人员在构建与 Zapier 平台的一些集成，但其中许多人来自产品部门，或者在某些情况下来自营销部门、支持部门、客户成功部门，公司中任何关心能够对更多客户说“是”的人，“是的，我们就是这样做的。是的，我们整合了这一点”，我们希望 Zapier 能够提供平台方面的支持，并以这种方式支持他们的客户。因此，可以肯定的是，开发者的信息要少得多。

当然，我尝试分享了一些 API **实践，这些实践更多地面向技术受众。有时他们确实在业务和开发人员之间游走，但很多信息实际上是想让更多的用户看到你的产品，并扩展你的产品的能力，以做用户希望它做的事情。所以，我实际上做了一个关于这个的演讲，我有一个关于它的帖子，那就是“你的门户网站的无形观众”，我真的相信比你意识到的更多的 API 拥有的观众不是你和我可能称之为开发人员的人，不是整天写代码的人。我想通过各种方式让他们举手，让他们发现他们就在那里。

在那篇文章中，我举了一个例子，说明我们如何在 Zapier 为平台推出 CLI，这是基于一些顶级集成商的研究，他们希望获得更像开发者的体验。但是，经过几个月的时间和对开发者平台的改变，我们意识到他们在那些刚起步的人中是少数。人们真的想要一个视觉建筑者。所以我们能够根据观察他们关心的事物来确定。并慢慢做出改变，以便能够证明“哦，我们已经投资了这个真正以开发人员为主的平台，这不会消失，但我们需要另一个界面来与这里的更大群体交流”。

尽管我很喜欢开发者观众，但我认为在任何 API 中都有这样的空间，特别是在开发者优先的基础设施类型的 API 中，这种 API 可能不支持 SaaS 工具。我在这里提出的区别是，开发人员支持通常是 SaaS，在那里你需要一个开发人员来帮助你使用 API，而不是像 Twilio 或 Stripe 这样的东西，它需要你的堆栈的一部分，这成为一个更加以开发人员为先，以开发人员为中心的公司。但我认为，对于所有这些人来说，如果你能够找到那些不太懂技术的观众，他们肯定会有一席之地。但是在某种程度上，你也需要拥有开发者所寻求的所有东西。所以这确实让你走上了寻找两个地方的道路，所以如果你足够早，你可能会寻找那些准备更充分地融入的人。

通过监控您的 API 是否正被用于进行调用来确定您的 API 是否成功

derrick:听起来你做了很多测量来弄清楚他们在多大程度上被 Zapier 激活，他们在这个平台上做了什么。他们得到的入职或其他类型的沟通有任何类型的反馈吗？根据他们是开发人员还是非开发人员受众，反馈有何不同？

Adam: 大部分工作都是平台产品团队完成的，我和他们合作得非常紧密，但这部分是他们推动的。这绝对是在看“他们是否创建了一个应用程序”(一个集成到 Zapier 平台的应用程序)，然后他们在这方面做了多少？在这种情况下，有触发器和动作，所以您可以查看他们是否创建了一些触发器和动作来启用他们自己的用户。然后，那些用过吗？有真正的呼声反对吗？这些都可以在日志数据中找到，至少在这一点上，我敢肯定他们仍然收集了相当多的数据，但这都是在一个系统中，我们作为员工，可以真正挖掘并整理出我们或多或少成功的原因。同样，这很大程度上取决于产品团队。

然后，当然，你可能会想象在用户端也有很多关于激活的东西。我认为，尽管这是用户方面，但肯定有一个 API 的教训，因为 Zapier，当它工作时，你不必回来。API 也是类似的东西，对吗？如果有人每天都回到你的开发者门户，那可能真的有问题，他们还没有达到完全集成。对 Zapier 的用户来说也是如此。因此，它在日志中寻找证据，扎皮尔甚至以这种方式收费。那么，有人成功运行过他们建立的这种集成和自动化吗？他们已经成功运行了多少次？随着时间的推移，他们还会继续运行吗？这也是你可以做的事情，就像你看到的“有人在使用我的 API 吗？”再次寻找那些已经超越“Hello World”的迹象，他们已经取得了初步的成功，他们已经将代码转移到他们的机器或服务器上，并且有足够频繁的呼叫，至少你知道他们仍在测试。

德里奇:这是一个非常好的观点，尤其是因为你不是每天都登录门户网站。如果您正在集成 Stripe，我为什么要集成呢？但是，这也带来了一个不同的挑战，即当您不希望人们登录您的门户时，您如何实际衡量和创建 KPI？这是否意味着 KPI 不同？你如何利用你之前在 Zapier 提到的 API 数据？"

亚当:我认为能够识别出成功人士的标志，然后确保你能够衡量这些标志。我的意思是这对于 Moesif 来说很棒，API 日志中有很多内容可以肯定地讲述这个故事。所以我认为寻找最近的调用，然后调用某个阈值，调用特定的端点，有希望成功。因此，如果您看到许多 401/403，那么有人仍然停留在身份认证上，当然从我作为一个内容丰富的人的角度来看，我会立即想到“入门指南中有什么”，我们是否充分讨论了获得身份认证需要什么，或者我们只是简单地浏览一下。因此，如果您看到这种类型的错误，这将是我需要查看的标志。

你的平台用例越具体，你就越能成功地集成合适的开发人员

我认为你可以看到类似的事情，将是特定于你的 API，你知道它看起来像有人成功连接。即使你是全新的，你至少可以弄清楚那会是什么样子——让 API 调用通过，然后确保你看到它，并在每个用户的基础上查看它。不同的 API 会有所不同。我是一个数据库 API 的开发者关系，很多人进来踢了一次轮胎，然后继续前进，因为在一个数据库中，你不会拆掉你的整个数据库并替换它，你必须在正确的地方，在正确的时刻。我们是一个早期的创业公司，所以我们撒的网可能比他们走得更远时撒的网要宽一点，因为他们知道一些人会使用他们的 API 的用例。但是，我认为任何数据库类型的 API 成功的人都比更精确的解决方案要少。我真的认为 Twilio 和 Stripe 的一些优势在于它们有非常具体的使用案例。

要真正了解你的平台，用户可以打个电话或发个邮件，以获得关于某人可能在哪里挣扎的定性数据

Derric: 当然，业务线基本上，你提供的是非常明确的交易或业务功能。当您发现可能存在一些问题时，您谈到了围绕身份认证的工作原理创建更多内容。有没有其他方法可以让你改变你的营销策略，不仅仅是看激活情况，或者看人们是如何采用你的平台的？

亚当:有一件事我没提到，其实就是和人说话。我知道我们已经进入了分析领域，但另一个问题是人们何时会注册，这是在 Zapier，也是在 Orchestrate，这是一种数据库即服务。那就是:如果某人刚刚开始，我们如何才能通过一个电话或一封电子邮件来获得更多关于某人可能正在努力的定性数据。当然，这在很大程度上与数据库即服务有关，我们如何让他们进入“Hello World”，但在 Zapier，更多的是了解受众是什么。很多都是内部交流。这里的许多听众可能使用公司内部存在的 API，因此必须进行大量的内部对话，并帮助其他人了解您所学到的东西。这也是这个项目的一个重要部分，了解 Zapier 平台的用户，将他们与愿意写代码的开发人员联系起来，并能够证明有更多的人没有这样的背景，也没有准备好在他们的终端上运行 CLI。

用户在你的文档中建议编辑的能力提供了另一种与你的开发者交流的重要方式。当他们提出建议时，一定要回复并解决问题。

德里奇:关于定性和定量反馈的思考，这无疑是一个很好的观点。我知道，不与开发人员交流，很容易陷入分析中，毕竟他们也是人。但有时他们不回邮件，或者他们想一个人呆着。你有没有发现一些**实践，可以分享给开发者，让对话进行下去？

亚当:是的，我认为接受多种沟通方式很重要。所以我们在这里已经提到了两个例子，这是对电子邮件的回复:在开发者持怀疑态度的事情列表中有一个是“我只是想占用你几分钟的时间进行视频通话”。有些人已经准备好了，但不是所有人，所以愿意把电子邮件作为另一个选择。然后，我认为每个人都可以做的事情是在文档中放置反馈的机会。我知道的 Algolia 在每个页面的几个地方都有一个感叹号，当你点击它时，你至少有机会填写“这不起作用”之类的东西。在 Zapier，我们在每一页的底部都有一个盒子。现在很多都有“编辑这个”的功能，你可以去 GitHub 里把它叉出来，然后把你认为应该放在这里的编辑内容放进去。所有这些不同的级别都是获得某种反馈的一种方式。我认为最重要的一点是，你必须真正看到它，然后采取行动。在 Zapier，我们不会感到惊讶，我们已经有了一个 Zap，它将管道到所有平台团队都在的特定松弛通道中。如果这个问题与某个特定的用户有关，有某种方法能够回复，但至少能够采取行动，特别是当有人注意到一个问题时，因为这是“我们都在文档中出现了错误的地方”,这只是一个又一个开发人员让你心烦。我的意思是，这是远离那些开发人员的捷径，就是在你的文档中继续有不准确之处。

DevEx 包括某人与你的公司和产品(包括文档)的所有互动，所以要想方设法积极地展现出来，给开发者体验带来好处

我笑得很厉害，因为我知道让这些文档保持最新总是一个挑战。事实上，在 Moesif，我们利用了 GutHub 按钮上的编辑功能，我们的文档都是开源的。我们使用 Jekyll 和一个开源的静态生成器，一个很棒的产品。但是，在这种情况下，谁真正拥有文档呢？是不是说明是产品团队，是营销？有没有什么好的过程来保持这些更新，因为我们总是把这看作是对开发者平台的挑战？

Adam: 至于谁拥有它，我经常与营销团队交谈，提醒他们确实需要关心文档。许多营销团队都这样做，但我认为很少有人拥有它。我认为最常见的可能是产品本身，但我们也知道，并不是每个产品团队都将它视为产品的核心部分。较大的团队会有专门的文档团队，但是当然也不总是这样。

我认为，如果你正在听这个，那么你可能是在你自己的公司里支持它的一个很好的人，至少认识到文档在可能关心它的多个团队之间传播，并且在最起码的程度上，组成一个关心它的特设小组。我们确实这样做了，在此期间，来自支持、产品、工程和营销部门的人员多次致电 Zapier，他们有理由希望更多的人在文档方面取得成功。

文档也只是整个开发人员体验的一部分，当然入职的产品方面也是其中的一部分。我也看到了很多与开发者体验相关的开发者内容。因为即使这是他们第一次接触到某个内容，他们也能找到你，因为你写的是他们遇到的开发者问题。最初的体验是一种体验，是整个旅程的一部分，希望有人会继续使用你的 API。它肯定是从那之前开始的，从开发人员在不和谐的房间里聊天开始，关于哪个 API 更容易或者在那一刻让他们沮丧。这种口口相传的情况也在发生。如果你对开发人员体验的定义非常宽泛，我倾向于对所有人与你的公司和你的产品的交互进行相当宽泛的定义，当他们实际上开始使用你的 API 时，我正在寻找积极地展示对开发人员体验有益的方式。

为了确保开发者有良好的体验，专注于提供优秀的入门类型的东西，例如流行语言的 SDK 和最新的完整参考资料

德里奇:我很高兴你刚刚定义了这一点。我正要问什么是开发者体验，你如何定义它。尽管如此，这是一个如此抽象的事情，是否有一个开发人员体验团队，或者更多的是一种思维模式？你实际上如何确保你有一个好的开发者体验，有没有一种方法来衡量它或者它是否真的不可衡量？

Adam: 所以，就团队而言，我认为这取决于 API 对公司有多重要。因此，如果 API 是一家公司的主要产品，并且我们越来越多地看到很多这样的产品，在这种情况下，开发人员的经验可能在某种程度上对整个公司很重要。在这种情况下，我不确定团队是否有意义。我绝对见过开发者体验团队。我认为大多数情况下，这些团队要么是负责 onboarding/dashboard 体验的产品团队，要么是名称不同的文档团队。我见过那两个人。我敢肯定，一些公司甚至会把这两者混为一谈，尽管我认为我更经常在单独的小组中看到这种情况。因此，我不知道是否需要有一个以这个名字命名的团队，但肯定需要有一个或多个团队想要改善开发人员的体验，不管这个名字是否在这个团队中。

因此，当然能够衡量一些东西，我们谈了一点你想要看到的一些东西，以便能够说这是开发人员的成功。从高层次来说，我有 13 个标准来判断一个人是否在一个能给开发者带来良好体验的地方。当然还有更多，不管他们是否真的成功。但要寻找的东西包括:你有流行语言的 SDK 吗，你有最新的完整参考吗，然后是我在那里寻找的许多入门类型的东西。所以我确实测量了它，但它真的意味着高水平，我认为更细粒度的测量真正涉及到我们已经谈论过的用法，因为这真的是它回答是否是一个好的开发者体验的地方——“开发者成功了吗？”。他们是否从找到你到不仅仅是“你好世界”，而是一些实际上有用的东西，推动他们解决他们的问题。

更改 API 时，使用所有渠道传达更改，包括:电子邮件、仪表板通知、日落标题，甚至开关灯

德里奇:然后，他们完全启动并运行后的下一步是什么？听起来他们不再踢轮胎了。在开发人员沟通方面有什么好的做法吗？

Adam: 当然，如果事情在变化，你所有的文档都应该是最新的，对开发人员的成功来说是极好的。但是如果你的 API 改变了很多东西，破坏了开发者的东西，即使你每次都在更新你的文档，每次你做了改变，它总是最新的，但是他们以前建立的东西，如果那被破坏了，那肯定会创造一个更差的开发者体验。因此，这种产品变化是必须不断发生的事情，但这意味着你需要有那些开放的沟通渠道。当一个持怀疑态度的开发人员可能用一个他们不经常查看的不同的电子邮件地址注册时，这是很困难的，诸如此类的事情。但是电子邮件可能只是获得这些信息的众多方式之一。当然，如果有人登录仪表板，你可以通过这种方式找到他们。我们，甚至在 Zapier，作为 API 大师的 Ben Peter，总是负责计算出现在 3000 个 API 中何时出现了弃用或问题。我真的希望本现在能得到一些帮助，而不仅仅是本在努力。但是他写了一些关于弃用的**实践，甚至在标题中加入了一些东西。

我知道埃里克·王尔德有一个日落头球。经历尝试沟通的步骤，然后将东西放入标题，甚至做一种开关灯的测试，让他们有机会捕捉到它实际上正在下降，可能会打破一些东西，但然后将它放回原处，这样他们就不会完全交火。本写了几篇关于这些**实践的帖子。但是当然，如果你可以开始与开发者交流，并设定期望，你将通过电子邮件和在你的博客上发布有用的东西，那么他们将更有可能希望有一个持续的交流渠道。这意味着当你不得不做出那样的改变时，你更有可能接触到他们。

如果您不得不弃用，那么使用 Moesif 分析使用情况和成功情况，以了解什么会受到影响，甚至到每个呼叫的基础上

德里奇:是的，有趣的是，我们只是偶然看到了一些博客帖子。我们实际上在 Moesif 本身实现了很多功能，开关灯或一个弃用标题。你实际上如何确定什么是不赞成的，这是你写的东西吗，或者你实际上是如何决定的？

所以从完全理想的开发者的角度来看，你永远不会反对任何东西。我认为，如果你看看那里，Twilio 可能从来没有反对任何东西。我想他们是根据日期来进行版本控制的，至少我上次是这么看的。因此，如果您在某个特定时间进行集成，您就有了这个端点，您可以随时升级到最新版本，但他们会让它继续运行。这无疑对开发者非常友好，但你我都知道这并不总是可能的。可能有一个系统，你想采取了昂贵的，在某种程度上，在维护或实际服务器成本，所以有很多原因，你可能会想作出这样的选择。但是绝对不更新是好的。我认为这是典型的产品决策，比如“这个用了多少？”。如果您真的可以访问您的日志，了解谁会受到影响，甚至了解每个呼叫谁会受到影响实际上是可能的。你知道人们在呼叫什么端点。你知道他们在接收什么数据。因此，如果你要改变数据的形状，如果你已经设置好可以访问的东西，你确实有办法可以做到。

德里奇:你只需要确保提前安排好就行了。

我认为 OpenAPIs 作为 API 的一种数据格式是一种方式，我们现在必须至少对 API 中的内容有一些期望，以某种方式谈论它，甚至以编程方式测试它。有一家名为 Optic 的公司，它实际上会查看您的实时调用，并做一些我提到的事情，类似于“嘿，这个 API 调用的形式发生了变化，或者在您的下一个版本中会发生变化，这是受影响的用户”。当然，能够有一个像 Moesif 这样的平台，能够查看人们呼叫的端点，能够获得这种关于使用和成功的分析，将是另一件有帮助的事情。

只有一份入门指南，并使之简化，以便清楚地显示如何打电话

德里奇:肯定。我的最后一个话题是关于那些刚刚开始考虑开发者平台的创业公司。你能为刚刚进入开发者营销领域的人分享一些**实践吗？

亚当:如果你刚刚开始，一定要进行我们之前谈过的那些对话。我们可以假设有人正在做这些事情:和开发人员谈论他们真正想要的东西。然后，我想去寻找一些基本的东西，让人们进入“你好世界”，因为尽管之后发生的事情很重要，但如果他们没有进入“你好世界”，他们永远也不会到达那里。那么，有没有一本入门指南，可以确保你真正专注于这一点。我在入门指南中看到的一些问题是，经常有人想要分享所有你需要知道的关于使用你的产品的背景知识，而这是错误的地方。如果你必须在开始之前研究概念，这对大多数开发人员来说是不可能的。大多数开发人员会跳过这一部分，直接进入我实际打电话的部分。因此，帮助人们能够到达他们想去的地方，所以在入门指南中简化这个过程。你总是可以在需要的时候加入一点点概念，然后你总是可以链接到其他更深入的地方。因此，这绝对是我看到的一个问题，更大的问题是根本没有那种内容可以开始。

有时会有多个入门指南，所以这也是令人困惑的。能够在一个地方发送它们。当然，还要想办法确保你的文档是最新的。我提到了 OpenAPI。你能从你的 OpenAPI 中至少生成你的 API 引用吗，这样你就知道它是最新的了。它还要求您保持 OpenAPI 文档最新，但是必须有某种方法能够做到这一点。这样，你就至少具备了某人所期望的文档基础知识。

通过用例向开发人员展示你能做什么通常会激发他们的创造力

然后从创业的角度来看，你会想尽可能快地了解别人想如何使用你的产品。希望你已经有了一些想法，并以用例及示例应用的形式展示出来。确认那些是某人想要解决的问题。我看到这种情况越来越少，但在上周，我就此进行了一次谈话，内容是“我们是这个平台，可以做任何事情，我们不想通过告诉他们我们做什么来抑制开发人员的创造力”，我认为告诉他们你可以做什么是启动创造力的火花。因此，能够给出一些用例会让一些人意识到“哦，这有点像他们没有想到的另一件事”，然后他们就会有创造力。但是仅仅提供一些东西并说“用这个做点什么”，并不能像人们认为的那样激发创造力。

derrick:这真是一个很好的教训，展示比讲述更好——展示不同的使用案例，并提供非常简洁和具体的入门或入门指南。但是不要有 10 个，只要一个。很好，非常感谢你邀请我们来，亚当。很高兴谈论开发营销和开发者体验。

亚当:谢谢你邀请我。