Moesif-博客中文翻译-一-

Moesif 博客中文翻译（一）

原文：Moesif Blog

协议：CC BY-NC-SA 4.0

首次构建 API 时的 10 个错误状态代码以及如何修复它们

原文：https://www.moesif.com/blog/technical/monitoring/10-Error-Status-Codes-When-Building-APIs-For-The-First-Time-And-How-To-Fix-Them/

当您第一次调用 API 时，事情并不总是顺利的，尤其是如果您是初学者，并且是第一次将 API 集成到另一个系统中。通常缺乏 api 错误状态代码方面的文档，因为预测事情变好比预测事情变坏更容易。

HTTP 状态代码可以让您了解进行 API 调用时发生了什么。标准化的状态代码从 100 到 511，并且都具有不同的含义，但是只有从 400 到 511 的状态代码反映了错误响应。如果您正在使用 Moesif，使用这个方便的表格查看最可能的 API 错误状态的摘要。

让我们看看 10 个最常见的 HTTP 状态代码，它们表示客户端或服务器端的错误响应。

客户端状态代码

4XX 组状态代码通常与客户端错误有关，但是对 API 的更改也会导致这些错误。以下是 5 种最常见的客户端状态错误代码以及解决方法:

404 未找到

这是迄今为止您能得到的最常见的 HTTP 状态代码。这表明您在请求中使用的 URL 在 API 服务器或原始服务器上不存在。虽然这是一个 4XX 错误，通常意味着客户端有问题，但这也可能表示服务器有问题。有时 API URL 路径会在版本更新后改变，但有时它们会因为服务器上的某些地方出错而改变。

最好的做法是在检查 API 是否有问题之前，先检查您的客户机代码中是否有拼写错误。

401 未经授权

这个状态代码意味着您还没有通过 API 的认证。API 不知道你是谁，也不会为你服务。

对于大多数 API，你需要注册并获得一个 API 密钥。然后，当您发送请求时，在 HTTP 头字段中使用这个键，告诉 API 您是谁。

这个 http 状态代码类似于不太常见的407 Proxy authentic ation Required，这意味着您还没有通过代理进行身份验证。

403 禁止

“禁止”状态表示您无权请求该 URL。您通过了身份验证，但是您通过身份验证的用户或角色不允许发出 API 请求。

当您遇到身份验证问题时也会发生这种情况，例如使用错误的 API 密钥或试图访问您的订阅计划不允许的功能。

400 错误请求

400 错误请求错误消息是最常见的 HTTP 状态代码之一。这意味着您没有正确格式化您的 API 请求。如果响应正文中没有给出额外的错误信息，您必须检查文档。您可能缺少一个查询、请求正文中的一个字段，或者标题字段可能是错误的。也可能是某些请求数据的语法不正确。

这与 422 不可处理的实体错误消息不同，后者在您的请求被正确格式化但无法处理时出现。

429 请求太多

大多数 API 订阅计划都有限制——计划越便宜，每秒允许的 API 键请求就越少。

如果您在短时间内发送了太多的请求，请考虑在您的客户端中限制它们。这种反应也可能表明您的帐户达到了每日、每周或每月的限额。如果不实施 API 分析，就有可能在没有收到推送通知或电子邮件提醒的情况下达到这些限制。

有时候，一个 API 听起来很合适，直到你看到它的局限性，突然它不再适合你的用例。在集成之前检查你的 API 订阅的一部分，否则你可能在集成 API 几周或几个月后遇到问题。

服务器端状态代码

5XX 组状态代码通常在响应服务器错误时返回，但是如果在服务器上没有被正确捕获，应该响应 4XX 的无效 API 调用也可能返回 5XX 错误。以下是 5 个最常见的错误以及解决方法:

500 内部服务器错误

这个 HTTP 状态代码可能意味着任何事情，但是它通常表示 API 服务器崩溃了。这可能是由与您的 API 调用相关的某些事情引起的。

仔细检查文档，确保你做的一切都是正确的:查询字段、正文字段、标题和格式。

如果这不能解决问题，也可能与 API 更新引入了错误代码或 API 从上游服务加载的数据有关。在这种情况下，您唯一的行动是联系 API 的支持。

502 错误网关

这个响应告诉您，您调用的服务器不是实际的 API 服务器，而是一个网关或代理。代理服务器试图以您的名义调用 API 服务器。这个错误响应也表明 API 服务器没有响应。这可能与网络问题有关，或者只是因为 API 服务器崩溃，或者因为维护而停机。

“坏网关”错误通常是暂时的，应该由 API 提供者解决，但是如果它仍然存在，您必须联系支持人员。

503 服务不可用

503 服务不可用状态表示服务器出错。发送了太多 API 请求，现在 API 无法处理更多请求。当客户端发送更少的未来请求时，这个问题会自行解决，但这也可能意味着 API 提供者没有为其所有客户规划足够的资源。

如果它符合您的用例，您可以通过等待发送另一个请求来使您的客户端对这个错误更有弹性。但是如果错误代码继续出现，您必须联系 API 提供者。

504 网关超时

像 502 错误网关状态一样，这个响应代码告诉您您正在调用的服务器是真实 API 服务器的代理。这一次，问题是 API 服务器的响应速度太慢。

这可能与代理和 API 服务器之间的高网络延迟有关。这也可能意味着 API 服务器处理请求的时间太长。

要解决这个问题，请检查您的请求内容是否与超时相关。如果您请求的数据太多或者计算时间太长，您应该尝试减少请求。

如果您认为您的请求是合理的，并且状态没有消失，请联系支持人员。

501 未执行

501 未实现状态代码与您用于请求 URL 的 HTTP 方法有关。您可以尝试不同的 HTTP 方法来发出请求。

通常，使用不适当方法的 HTTP 请求只会导致 404 not found 状态。未实现状态意味着该方法“还没有”实现 API 创建者可以使用这个状态来告诉客户端，这个方法将在将来的请求中对他们可用。

使用 Moesif 监控 HTTP 状态代码

Moesif 提供了一组丰富的监控和通知功能，因此您可以自动了解任何 HTTP 状态代码错误，并从您的错误响应趋势中获得深刻的见解。

API 调用总是用用户身份来跟踪，所以很容易定位错误并快速解决它们。

摘要

毫无疑问，在使用 API 时，您会看到许多错误代码，但大多数都有合理的修复。有些与服务器错误有关，有些与客户端错误有关，通常一个错误会导致另一个错误。

总是试着通读文档和 API 注释，这样你就不会在集成时忘记一些东西。如果事情只是简单的中断，请联系 API 提供者。

在某些情况下，API 提供者永远不会为 API 消费者解决问题。如果你正在使用一个流行的 API，你也可以在网上搜索答案，特别是 StackOverflow ，找到错误响应的修复。保持决心，你很快就会看到你的 200 个 ok 状态码。

构建 RESTful APIs 的 10 个最流行的框架

原文：https://www.moesif.com/blog/api-product-management/api-analytics/10-Most-Popular-Frameworks-For-Building-RESTful-APIs/

T2】

正如许多工程问题一样，有许多方法可以构建 RESTful APIs。大多数时候，在构建 RESTful APIs 时，工程师更喜欢使用框架。API 框架为构建 API 提供了一个极好的平台，其中大部分组件都是现成的。在本帖中，我们将探讨构建 web APIs 的 10 个最流行的 REST API 框架。这些框架跨越多种语言和不同级别的复杂性和定制。首先，让我们深入了解决定从哪个框架开始构建的一些关键因素。

如何选择一个 API 框架

选择 API 框架的第一个因素通常是决定您希望使用哪种语言。对于许多项目，根据您工作的组织或您的经验，选择可能是有限的。通常的建议是使用您已经熟悉的语言，因为学习一门新的语言和一个新的框架可能会导致不太理想的实现。如果你已经熟悉这种语言，你的主要精力可以放在理解框架和高效构建上。

一旦决定了语言，您可能有多种支持您选择的语言的框架可供选择。在这一点上，您需要根据您需要的 API 的功能类型来决定。一些框架会有插件和依赖项，允许与其他平台轻松集成，一些可能更精确地支持您的用例，而另一些可能在您需要的功能方面受到限制，自动取消它们的资格。确保框架支持你的用例及功能是关键。

最后但同样重要的是，你还应该考虑学习曲线和可用的教育材料和文档。作为一名开发人员，良好文档和示例的可用性是您和您的团队如何快速扩展 API 的重要因素。在决定一个框架之前，浏览文档，并进行快速搜索，以确保您可以找到可以指导您的示例，并告诉您在您选择的框架中构建 API 需要付出多少努力。

现在我们有一些因素要考虑，让我们看看一些流行的框架选项。

Spring Boot

Spring Boot 是一个开源框架，帮助开发者构建网络和移动应用。由 Pivotal Software 开发的 Spring Boot 是一个旨在使最初的 Spring 框架更加用户友好的框架。您可以轻松地开始使用 Spring Boot 开箱即用，无需花费时间配置它的任何库。

编程语言: Java

优点:

• 由于增强的内存分配，加载速度更快
• 可以很容易地用 XML 配置和注释进行配置
• 易于运行，因为它包括一个内置服务器

缺点:

• 不能向后兼容以前的 Spring 项目，也没有工具来帮助迁移
• 二进制文件的大小可能会因默认的依赖关系而膨胀

轨道

Ruby on Rails 最初是作为 MVC 框架开发的，这使得它在开发者中被称为“启动技术”。该框架的主要目的是交付高性能的应用程序。Ruby on Rails 的高性能标准让使用 Python 和 PHP 的开发人员兴奋不已，它的许多概念在流行的 Python 和 PHP 框架中得到了复制。

编程语言: Ruby

优点:

• 以最小的错误进行快速开发的伟大框架
• 开源，有许多可用的工具和库
• 高效包装管理系统的模块化设计

缺点:

• 与 Django 和 Express 等其他框架相比，可能难以扩展
• 对某些库的有限多线程支持
• 文档可能有些稀疏，尤其是对于第三方库

瓶

烧瓶是由阿明·罗纳彻开发的 Python 框架。Flask 的框架比 Django 更清晰，也更容易学习。Flask 基于 Web 服务器网关接口工具包和 Jinja2 模板引擎。

编程语言: Python

优点:

• 内置开发服务器和快速调试器
• 对单元测试的集成支持
• RESTful 请求分派
• 符合 WSGI 1.0
• Unicode 基本码

缺点:

• 缺少包含的工具和扩展，通常需要定制代码
• 安全风险
• 较大的实现维护起来更复杂

姜戈休息

Django REST 框架是一个可定制的工具包，可以轻松构建 API。它基于 Danjgo 基于类的观点，所以如果你熟悉 Django，它会是一个很好的选择。

编程语言: Python

优点:

• web 可浏览 API 对 web 开发者来说是一个巨大的胜利
• 开发者可以在他们的 web 应用上使用 OAuth2 认证用户。
• 提供 ORM 和非 ORM 序列化。
• 大量文档
• 易于部署

缺点:

• 学习曲线
• 不包括异步
• 对于 JSON 验证来说，序列化程序既慢又不实用

快递 Js

快递。Js 是 Node.js 的开源框架，它通过提供一组有用的工具、特性和插件来简化开发过程。

编程语言: Javascript

优点:

• 有据可查
• 快速扩展应用
• 广泛使用和良好的社区支持

缺点:

• 缺乏安全感
• 回调中的问题
• 中间件系统遇到的请求问题

Fastify

于 2016 年首次创建的 Fastify 是一个高度致力于提供最佳开发者体验的 web 框架。强大的插件架构和最小的开销也使这个框架成为开发者的一个很好的选择。

编程语言: Javascript

优点:

• 容易开发
• 高性能和高可扩展性
• 支撑该系统的低开销 web 框架最小化了整个应用程序的运行成本。

缺点:

• 缺乏文档和社区支持
• 在工业中不容易使用

游戏框架

Play 是一个 web 应用程序框架，用于使用 Scala 和 Java 创建现代、健壮的应用程序。Play 基于动态类型，集成了现代 web 应用开发所需的组件和 API。

编程语言: Java，Scala

优点:

• 直观的用户界面
• 简化的应用程序测试
• 多个项目的快速开发

缺点:

• 陡峭的学习曲线
• 太多不稳定的插件
• 也许它没有提供任何向后兼容的特性。

杜松子酒

Gin 是一个用编程语言 Go 构建 web 应用和微服务的快速框架。它提供了一个类似 martini 的 API，使用户能够用 Go 构建功能多样、功能强大的应用程序。它包含了 web 开发框架中常用的功能，如路由、中间件支持、渲染等。

编程语言: Golang

优点:

• 表演
• 易于跟踪的 HTTP 方法状态代码
• 简单的 JSON 验证
• 无碰撞

缺点:

• 缺少文件
• 语法不简洁

凤凰

Phoenix 是用 Elixir 编写的，它实现了 MVC 模式。它看起来类似于 Ruby on Rails 和 Django 这样的框架。关于 Phoenix 的一个有趣的事情是，它有用于预编译模板的实时特性的通道。这些模板工作迅速，使网站流畅，易于滚动浏览。

编程语言:仙丹

优点:

• 过滤安全有效的数据
• Elixir 在 Erland VM 上运行，以提高 web 应用程序的性能。
• 并发

缺点:

• 昂贵的
• 加工速率
• 需要事先掌握 Erlang 知识

快速 API

Fast API 是一个用 Python 开发 RESTful APIs 的 web 框架。它完全支持异步编程，因此可以与 Uvicorn 和 Hypercorn 等产品服务器一起运行。它支持流行 ide 中的快速 API，比如 Jetbrains PyCharm。

编程语言: Python

优点:

• 高性能
• 易于编码，几乎没有错误
• 开发时间短
• 支持异步编程

缺点:

• 请求验证不佳
• 不支持单一实例
• 主文件很拥挤

添加 API 分析和货币化

构建 API 只是开始。一旦构建了 API，您将需要确保您正在监控和分析传入的流量。通过这样做，您可以识别潜在的问题和安全缺陷，并确定您的 API 是如何被使用的。这些都是开发和支持 API 的关键方面。

随着 API 平台的发展，您可能会专注于 API 产品。这是从简单地构建 API 到将 API 作为商业工具使用的转变。很像一个更正式的产品，API 产品需要被管理，并且可能会被货币化。从你的 API 中获得收入是扩大你的业务底线的好方法。

有了 Moesif，你可以实现以上所有。Moesif 可以通过 SDK 或插件轻松集成，并在几分钟内启动和运行。一旦 Moesif 与您的 API 集成，您将能够探索图表和报告，以查看:

• 实时 API 流量
• 用于检查使用情况的时间序列报告
• 转换漏斗
• 卷紧报告等等…

Moesif 还通过允许您跟踪使用情况并将其同步到 Stripe、Recurly 或 Chargebee 等计费提供商来实现 API 货币化。几分钟内，集成您的 API 并开始向客户收取使用费。Moesif 允许您精确调整您想要的账单，并且高度可定制以满足您的确切需求。

包扎

在本文中，我们介绍了开发 RESTful APIs 的 10 个最流行的框架。我们查看了每一项的高级概述，并列出了一些注意事项。我们还讨论了如何决定使用哪个 API 框架的一些关键因素。最后，我们研究了 Moesif 如何通过实现分析和货币化来帮助您将 API 开发提升到一个新的水平。

在 Moesif 中利用用户指标的 4 种方法

原文：https://www.moesif.com/blog/technical/api-analytics/4-Ways-To-Leverage-User-Metrics-In-Moesif/

没有用户，产品毫无意义。那么为什么这么多组织事后才分析 API 和用户行为指标呢？我的理论是，他们只是没有合适的工具来实际收集、分析和使用这些使用指标。

有如此多的产品旨在改善用户体验和客户满意度，像 Moesif 这样的工具正是我们所需要的。有了 Moesif，我们可以收集有意义的用户数据，发现数据中的价值，甚至在平台内对一些数据采取行动。令人印象深刻的是它是多么容易做到。

这篇文章将着眼于 Moesif 中的 4 个核心功能，它们可以帮助您、您的组织和您的用户获得更好的结果。唯一需要的先决条件是你已经将你的 API 与 Moesif 集成，并且已经设置了用户跟踪。

设置用户跟踪后，导航至用户屏幕将为您提供 4 个选项，您可以使用这些选项来利用基于用户的指标:

• 用户查找(和群组)
• 用户漏斗
• 用户保持率
• 用户构成

这些都可以让你深入了解你的产品做得怎么样，如何让你的产品更好，谁在使用你的产品，等等。

让我们一个接一个地看看这些关键特性。

用户查找(和群组)

能够识别和探索使用您系统的用户是非常重要的。了解谁在使用你的系统，他们是如何使用的，以及他们的个人趋势会带来巨大的价值。

使用 Moesif，您可以使用用户查找屏幕过滤掉特定用户，并在更精细的层次上进行深入探索。当您第一次来到屏幕时，您会看到一个未过滤的用户列表:

从该列表中，您可以创建按单个用户标准进行过滤的过滤器，如“GeoIP”或“上次查看时间”，或者过滤满足特定事件标准的用户，如在过去 24 小时内遇到 HTTP 4XX 错误的用户。

为了实现第一个示例，我们可以查找“最后一次看到时间”在一周之前的用户。看起来会像这样:

创建过滤器后，页面底部显示的用户将自动更新。我们还可以在“谁执行了”过滤器下添加第二个标准，以便为查询添加更多的过滤。为此，我们将额外添加一个过滤器，仅包括居住在美国的用户(通过使用他们请求的 GeoIP)。国家代码。现在我们的过滤器看起来像这样:

现在，我们将只显示美国地区中“最后一次看到时间”在一周之前的用户。

如果我们发现这些标准可能对其他功能有用，或者是我们想要关注的东西，我们可以将其保存为群组。

保存的群组是符合某些特定标准的用户(或公司)的动态列表。这些标准可以是特定的用户/公司属性，或者基于用户/公司在 API 调用和用户操作方面的表现。因为这些列表是动态的，所以 Moesif 会在后台不断更新它们。

我们还可以查看特定的用户。为此，我们只需在列表中找到一个用户，单击他们的 user_id ，然后查看显示一些关键指标和详细信息的概述页面。在这里，您可以看到诸如“首次显示时间”、“上次显示时间”、用户元数据和其他重要信息。

用户查找功能和群组允许您轻松过滤和浏览您的用户。如果您想了解更多信息，请查看我们的文档。

用户漏斗

当用户在应用程序漏斗的不同阶段导航时，能够跟踪用户是一种很好的方式，可以看到什么是有效的，什么是无效的，以及用户在漏斗中的位置。

使用 Moesif，您将设置漏斗的不同阶段，可能是某些 API 调用，以跟踪用户的进度。这方面的一个例子可以是用户执行 3 个步骤的流程:

• Login

  The user logs in to the system

  by calling /logging in to the endpoint.

• Purchase

  Users decide to purchase products by calling the /purchases endpoint.

• Subsent Purchases

  The user decides to conduct two additional purchase transactions through the /purchases endpoint.

这些步骤中的每一步都代表了漏斗的关键部分。通过跟踪用户从漏斗的一个阶段到下一个阶段的移动，您可以更准确地确定痛点或问题，战略性地对流量进行更改以增加转化率，并通过查看指标变化来准确地测试流量的更改。

在 Moesif 中设置这个非常简单。一旦进入应用程序的用户仪表盘，我们将点击用户漏斗。

在这里，我们将定义决定漏斗每个步骤的 3 个步骤/标准。

具体来说，我将确保每次对 purchases 的调用都返回一个 HTTP 200 OK 响应，这样我们就知道购买成功了。我们不想将不成功的电话计入我们的漏斗指标。

由此，你可以看到用户完成的漏斗的每一步，以及进入下一步平均需要多长时间。

我们可以从这个漏斗中看到，用户完成整个漏斗平均需要将近 33 天。我们还发现，只有大约 9.21%的用户通过了我们的整个漏斗。

为了更深入地挖掘用户渠道，深入我们的文档。

用户保持率

利用用户指标的另一种方法是深入挖掘用户保持度。这些指标让你可以跟踪你留住用户的情况，但不仅仅是检查他们是否仍然注册了这项服务。

活跃用户倾向于逗留、升级和推广你的产品。确保你的产品能够促进这种类型的互动，这是留住客户的关键。

使用 Moesif，您首先需要确定显示活跃用户和回头客的标准。例如，你可以说的第一个动作是当用户第一次登录应用程序时，随后的每次登录都是他们的返回动作。随着时间的推移，你将能够看到每天有多少用户返回。

您还可以进一步挖掘，尤其是如果您的应用程序或业务是基于事务的。在这样的场景中，您可以让用户第一次调用 /purchases 端点作为他们的第一个动作。当他们执行另一个对/购买的调用时，这将是他们的返回动作。这意味着用户正在获得价值，因为他们继续积极购买你的产品。

因为你最了解你的业务，你将是确定用户何时第一次感受到价值，以及之后什么事件可以被视为他们继续获得价值的最佳人选。

要在 Moesif 中设置保留分析，您需要导航到用户屏幕，并选择用户保留选项卡。

在这里，您将定义您的第一个事件。在这个例子中，我们将使用第一个事件作为用户第一次购买。这被定义为对/购买端点的调用。我们的返回事件将是用户执行额外购买的时候。

我们还将按 user_agent.name 对结果进行分组，以便我们可以看到哪些平台的保留率最好和最差。

最后，我们希望包括过去 12 周的指标，并每天查看保留情况。为此，我们将图表右上角的下拉列表中的以下值设置为“每日”和“过去 12 周”。

从上面的输出中，我们可以看到基于用于访问平台的用户代理的每日保留率。

准确的保留分析有助于跟踪您的组织在尝试和改进时保留率的变化。在分析您的业务健康状况时，跟踪留存率是一个要考虑的关键指标。

有关如何在 Moesif 中创建保留分析的更多信息，请查看我们的文档。

用户构成

一旦你探索了你的个人用户，你的漏斗指标，你的留存率，你可能想弄清楚你的用户构成。

用户构成可以让你深入了解你的用户群。您可以保持很高的级别，将大的细分市场组合在一起，也可以通过非常特殊的指标和标准过滤您的用户，从而降低级别。

可以按特定的用户属性(如公司或位置)或执行特定事件的用户来筛选用户组合。

这里有一个例子，我正在过滤来自加拿大的用户，他们已经成功地从一个 API 接收到一个 HTTP 200 OK 响应:

一旦您设置了过滤标准，您可以通过按特定标准对结果进行分组以及通过按标准设置分组来进一步挖掘。这方面的一个例子可以是按用户代理(流量来自哪个平台)、按国家、按公司或任何其他可能的分组进行分组。您可以选择是显示分组的顶部还是底部，以及要包含多少条目。例如，您可能只想显示分析中排名前 10 的公司的用户构成。

如果您根据包含时间度量的标准选择一个分组，那么您可以根据包含 1 天、7 天、1 周和 1 个月时间间隔的 date_histogram 对数据进行分组。

为了补充上面的例子，我添加了一个按分组的，它将按用户的公司域名对结果进行分组，并显示前 5 名的结果。

最后，这个查询的结果将根据您选择的任何指标显示。Moesif 有一些预定义的方法以及创建自定义方法的能力。这将是在结果可视化或图表中显示的指标。预定义的指标包括:

• 唯一用户
• 唯一会话/API 密钥
• 独特的公司
• 平均 TTFHW
• 最大 TTFHW

除了上面的例子，我们将确保选择的是唯一用户指标。

选择所有过滤器后，结果将是加拿大的用户收到了一个 HTTP 200 OK 状态代码。该结果集将按用户公司域名分组，并显示前 5 个结果。最后，显示的结果将显示这些公司拥有的符合过滤器的唯一用户。

结果看起来会像这样:

在此图表中，我们可以看到基于样本数据集的上述标准的结果。

通过使用 Moesif 中的用户构成功能，您可以获得有价值的见解，显示您当前的用户统计数据，并可以操作过滤器来查找您的用户群中不同细分市场的非常精确的详细信息。

将这一切结合在一起

有了 Moesif 中的这 4 个工具，您将能够看到支持您的业务所需的一切。你将很容易获得对你的用户以及他们与你的产品的互动的深刻见解。概括来说，我们涵盖了:

• User Lookups/Cohorts

  Find users quickly and easily and find their details according to what they have done on your platform. Very similar to CRM-style solutions, but with the ability to search based on what they do, instead of just creating filters and saving the result list based on their attributes, also known as saved user groups

• User funnels

  Define the steps of creating user funnels in the application and track the conversion rate of each step.

• User retention

  Create an analysis that tracks user retention to ensure that users actively use the product. This is not just to track subscriptions or similar metrics, but actually allows you to define criteria to ensure that your users get value from products, which is the main factor of retention.

• User Composition

  It is easy to explore the composition of user groups by setting standards, filtering and sorting results. Create excellent visuals and diagrams to show who is using your product and how they are using it.

想开始吗？只需登录 Moesif，尝试这些伟大的功能。还没有账户？注册免费试用,点击几下鼠标，开始探索您的用户分析。

GraphQL API 的 5 个安全提示

原文：https://www.moesif.com/blog/technical/security/5-Security-Tips-for-Your-GraphQL-API/

2015 年，GraphQL 由脸书创建，作为 REST APIs 的替代方案，通过使 API 调用更加灵活，为前端开发人员提供更多功能。GraphQL 通过为其 API 消费者提供一种查询语言来实现这一目标，这种语言允许他们只查询自己需要的数据。

虽然 GraphQL 可以改善前端开发人员的体验，但它的规范在安全性方面没有意见。GraphQL API 需要将查询转换为数据获取，这给 API 架构增加了另一层复杂性。

我们已经写了一篇关于十大 API 安全线程的文章，它们都适用于 GraphQL APIs。在本文中，您将了解提高 GraphQL API 安全性的其他增强功能。

美国和欧盟的新隐私法使得每个安全漏洞对 API 公司来说都是巨大的财务威胁。

1.综合查询授权

尽管小型 API 通常提供 HTTP 可访问的方式来访问数据库，但 GraphQL 通常是数据源不可知的。这意味着 GraphQL 不关心数据来自哪里。数据可以来自数据库，也可以从另一个 API 获取。这也意味着，GraphQL 不是一个数据存储库，所以它必须对实际的数据源进行认证，并检查用户是否被授权访问来自这些数据源的特定数据。

假设一个服务于许多不同客户端的 GraphQL 服务器被认证为上游服务或数据库中的一个用户。在这种情况下，graph QL 服务器必须自己在解析器内部进行授权检查。否则，这可能会导致 CCPA 法律规定的私人或更糟的医疗数据的泄露，并使您承担法律责任。

如果需要，您可以在每个解析程序中检查权限:

const resolvers = {
  Query: {
    adminResolver: async (parent, args, context) => {
      if(!context.user || !context.roles.includes("admin")) throw new Error("Permission denied!");

      ...

      return data;
    },
  },
}; 

2.输入验证和规范化

过去，开发人员会在前端生成 SQL 查询，并将它们发送给 API，以便从 SQL 数据库中获取数据；于是，SQL 注入诞生了。攻击者可以编写 SQL 并将其发送给 API，API 会执行它而不会询问更多问题。

虽然没有人阻止 GraphQL API 开发人员创建一个接受 SQL 字符串的类型，但这种情况很少发生。

但是接受来自客户的数据总是有风险的。这就是为什么在任何数据获取发生之前，所有的输入都应该被验证和规范化。特别是自定义标量容易受到这种威胁，因为它们不做默认验证。

3.自省限制

GraphQL 为其 API 消费者提供了一个方便的自省特性，它允许 GraphQL 客户端询问 API 它提供了什么类型的数据。这很好，因为现在客户端开发人员不必查看文档，而是可以直接询问 API 服务器有哪些数据可用。

但是如果没有严格控制，内省也会被滥用。例如，当提供管理功能的 GraphQL 类型可以被普通用户发现和使用时。

GraphQL API 创建者不得不使用严格的授权方案进行自省以使攻击者更难发现 API 漏洞。如果外部开发者不使用你的 API，那么在生产环境中禁用自省特性也是一个好主意。

例如，Apollo server 允许使用一个简单的配置标志来禁用自检:

const IS_PRODUCTION = process.env.ENVIRONMENT === "production";

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: !IS_PRODUCTION,
});

server.listen(); 

4.查询限制

GraphQL 查询为 API 消费者提供了很大的灵活性，只需一个请求就可以准确地获取他们想要的数据，但是这个特性也可能被以多种方式滥用。

出于各种原因，恶意客户端可以创建非常深入、复杂或通常需要长时间运行的查询。如果这些攻击者发现了导致大量计算的边缘情况，或者利用了 N+1 查询问题，他们可以使 API 过载，并大幅降低其他客户端的性能。

这就是为什么 GraphQL API 应该将查询执行时间限制在一个合理的最大值。更好的是，实现这一目标的另一种方式是限制查询深度或复杂性，这样就更难执行常见的 GraphQL DDoS 攻击，这些攻击往往使用递归和深度查询，只是为了中断服务。

5.上游错误隐藏

如前所述，GraphQL API 不是一种数据存储机制；这意味着它使用上游服务，如数据库或其他 API 来获取实际数据。这些服务也可能有错误。如果您将上游服务的错误传递给客户端，攻击者就可以利用它们来了解您的架构。

为了减轻这种威胁，您应该总是在将上游错误提交给客户端之前处理它们。这样，你可以隐藏你获取数据的服务，并阻止攻击者利用这些服务可能存在的漏洞或安全漏洞。

让我们看看下面的代码示例:

const resolvers = {
  Query: {
    myResolver: async (parent, args, context) => {
      try {
        const data = await fetchFromRemoteDataSource();
        return process(data);
      } catch (upstreamError) {
        const cleanError = analyzeUpstreamError(upstreamError);
        throw cleanError;
      }
    },
  },
}; 

解析程序尝试从远程数据源获取一些数据，但这可能会失败。我们捕获的错误来自远程数据源，因此它可能包含关于数据源的信息。

我们需要分析错误，并在将它交付给客户端之前清除任何上游信息。

保证 GraphQL APIs 的安全

GraphQL APIs 是为前端团队改善开发人员体验的一个很好的方式。它为客户提供了一种指定他们需要什么的方法，从而有助于优化数据获取。但这是以 API 架构的更高复杂性为代价的，这增加了 API 的攻击面。

随着规定处以数百万美元罚款的 GDPR 和 CCPA 法律的兴起，对于 API 开发者来说，在开发 API 时牢记常见的 API 威胁以及寻找可能出现的 GraphQL 特定弱点比以往任何时候都更加重要。

利用 API 收回收入的 5 个技巧

原文：https://www.moesif.com/blog/best-practices/api-product-management/5-Tips-For-Recovering-Revenue-With-APIs/

在现代 API 经济中，回收收入是经营成功企业的重要组成部分。使用 API 产品很容易低估你的服务，最终低估你的业务。这就是为什么许多 API 提供商转向对客户的使用进行计费，但是哪种 API 货币化方法最适合您的产品堆栈？Moesif 使您能够围绕您的客户做出明智、明智的决策，并最大限度地实现您的商业模式的货币化。以下是如何接近你的 API 货币化结构，以尽量减少流失风险，并最大限度地提高 API 收入和客户满意度。

1.监控客户行为和使用情况，以制定指导方针

理解你的 API 的商业价值以及如何构建货币化和使用指南从数据开始。了解您的用户通常做什么，以及他们通常通过您的 API 接听多少电话。利用通过 API 收集和存储的数据，对您的用户群进行分析，从而对用户行为进行基准测试。需要注意的是，用户的行为会因 API 的用途而有所不同，但是理解用户的基本需求将有助于开发人员建立有意义的内部协议来处理客户问题。

设置知情的内部协议和标记异常值的警报，使您能够围绕可能的使用或计费问题更快地联系客户，或者在客户意识到可能的问题之前管理支持需求。

2.基于使用计费的直接货币化

决定一个计价策略不是一件容易的事，但是将你的 API 货币化是在不扩展产品线的情况下收回资金的一种方式。Moesif 可以通过轻松集成的 API 货币化支持来满足您的业务需求。通过检查你当前的用户来决定你的产品合适的 API 货币化策略——他们最依赖什么特性？他们的业务基于什么标准？了解用户的首要需求将使您能够实现创收。

基于使用的计费使您能够实现 API 的真正商业价值。如果你遵循传统的 API 使用计费方式(分层订阅模式)，那么你就是在浪费钱。无论您实施预付费还是后付费模式，货币化都允许您选择最相关的指标(API 调用计数、活跃用户、发送的千兆字节数等。)来利用，为您的客户带来价值，同时允许您对他们的 API 访问收费。定价您的费率计划结构从查看您的 API 平台或产品提供的所有功能开始。看看最必要的工具和企业成本，为他们提供建立您的定价选项，导致直接收入。

3.对开发者的吸引力

API 是由开发人员使用的，因此对文档和消息传递采取开发人员优先的方法是有意义的。创造收入机会始于快乐的用户，这将启动有针对性的 API 资源。您的 API 可能是解决给定问题的最快、最聪明的方法，但是如果集成它太复杂，用户会转向下一个选项。文档应该清晰明了，直截了当，以避免实施过程中的混乱。你的初始文档越简单，开发者就越有可能成功地使用你的 API——开发者看重易用性。当考虑如何吸引用户时，考虑为那些将认真使用你的 API 的人专门发送消息。毕竟，吸引利益相关者始于开发者的倡导。

一定要利用愿意测试你的产品的 API 用户，因为当开发者有机会测试和倡导实现你的 API 时，销售会更容易。围绕特性探索提供试验和灵活性是推动公司围绕增加 API 使用做出明智决策并创造额外盈利机会的一种方式。

4.针对不同的用户进行个性化设置

不同的用户会有不同的行为，因为他们使用 API 产品的目的不同。例如，金融科技领域的开发人员的行为和使用方式与医疗保健领域的开发人员截然不同。了解你的 API 是如何被使用的是一回事，但是谁在使用它呢？数据可以洞察消费者模式、理想的跟进频率，甚至是重试支付方式的频率。利用您的应用程序，针对不同的公司和业务部门个性化这些见解。随着越来越多的企业经历数字化转型，请确保您的信息符合不同客户的 API 需求。

全面了解你的用户并不容易，但 Moesif 通过实时数据和高级用户使用分析让这变得更简单。了解您的用户旅程直至个人用户，并围绕您的 API 货币化模式做出更明智的数据驱动型决策。

5.在合理的范围内给顾客留有余地

没有什么比耐心和轻推更能打动用户了。当付款失败时，不要害怕联系你的客户。对于客户付款方式无法完成交易的订阅，您可以选择:

1. 保持订阅有效，
2. 终止订阅，或
3. 暂停或暂时停用它

对于 API 公司的生态系统来说，客户是有价值的，也是重要的，但信任和收入也是如此。这就是为什么最好暂停订阅，暂停未来的服务，同时假定客户可以纠正失败的支付方式。为了恢复 API 消费，数字企业将在收到问题警报后纠正他们的支付问题。除非出现滥用，否则 air 会提醒用户可能出现的问题，而不是直接取消订阅。

对于您的客户成功团队来说，通过围绕客户状态保持定期沟通来平衡您的业务需求和客户期望是非常重要的。这可能很简单，比如[通过 Moesif 的行为电子邮件设置外部警报，让客户知道他们的使用量超过了配额，以避免意外收费，或者通过电子邮件提醒支付失败和订阅停用的时间表。

总结想法

为你的产品建立一个成功的商业策略始于使用数据围绕 API 货币化和客户沟通做出明智的决策。进一步了解Moesif 如何帮助您的 API 创造更多收入，并支持您的客户解决方案进行扩展。

Moesif API 警报可以帮助您的工程、客户成功和销售团队的 6 种方式

原文：https://www.moesif.com/blog/customer-success/monitoring/6-ways-moesif-API-alerts-can-help-your-engineering-customer-success-and-sales-teams/

对于任何由 API 驱动的业务来说，监控 API 的能力都是一项重要的功能。除了 API 监控和可观察性之外，还有针对特定情况主动创建警报的能力。Moesif 是一个利用警报的绝佳平台。有了我们的平台，您所有的 API 和用户数据都可以编译到一个地方。这是为 REST、GraphQL 和其他 API 轻松配置各种有用警报的好方法。

有了 Moesif ，当一个警报被触发时，它可以被发送到许多不同的通道，包括 email 、 SMS 、 Slack 、page duty，甚至是自定义 Webhook 。通过拥有多个可用的通道，用户可以确保正确的警报通知被传送到正确的通道或多个通道。这种灵活性是 Moesif 使您能够为您的业务定制的一个关键因素。

然而，并非所有的警告都是相同的。在 Moesif 中，我们有两种类型的预警规则可以配置: 静态 和 动态 。了解这两者之间的区别以及在哪里使用它们有助于建立一个可靠的警报策略。

静态警报相当简单。您可能希望用静态阈值来跟踪一些指标。例如，您可能希望创建一个警报，当客户端从 API 接收到一定数量的 401 -未授权响应时触发该警报。您的过滤器可能类似于:

• 如果在 15 分钟内 REST API 响应中返回超过 20 个 HTTP“401-未授权”状态代码，则发出警报

对于动态警报，标准通常超出静态警报的能力。动态警报利用 Moesif 的异常检测。该机制与历史数据的趋势线进行比较，并在指标看起来异常时发出警报。灵敏度是可配置的，因此可以根据警报发生前可接受的变化量来定制警报。动态警报过滤器的一个示例可能如下:

• 如果用户的 API 使用率在上周异常下降，则发出警报

这两种类型的警报都可以极大地增强您的支持和警报策略。当统一使用时，它们可以帮助改善组织的多个方面，并让客户满意。让我们看几个具体的场景，在这些场景中，实施警报可以帮助您改进！

跟踪 API 中出现的错误

跟踪和通知团队 API 中发生的错误的能力可能是警报的主要用例。错误是唾手可得的事情，可能会很快使您的业务停滞不前，并使您的支持团队陷入困境。

最简单的方法是通过静态警报。当已知端点在 5 分钟内返回超过 10 次 HTTP 404 Not Found 状态代码时，可以发送警报通知。这可能是由于最新 API 代码版本中的一些代码配置问题，或者是工程团队想要立即了解的另一个错误。

还可以设置动态 API 警报，以检测与历史数据相比，API 中何时出现异常数量的错误。

让您的团队实时收到意外事件发生的警报是非常重要的。立即了解意味着团队可以诊断、警告客户任何暗示，并提前预防任何负面影响。这一点尤其重要，因为支持 SLA 时间持续减少，并成为用户选择采用平台的重要因素。有了 Moesif，您甚至可以使用该平台更容易地调试和重现问题。知道事件发生的时刻，并更快更容易地解决它。

跟踪潜在的安全问题或 API 滥用

使用警报来警告支持和安全团队潜在的安全问题是很容易做到的。这将有助于保护您免受攻击和故意滥用的基础。以静态警报的形式，如果被阻止的用户向特定端点发送请求或仍然以某种方式登录，您可以发送警报。通过动态警报，您可以通知您的支持团队 API 流量出现意外的高峰，这可能类似于拒绝服务攻击。

这是安全之战中的又一道防线。第一道防线当然是首先阻止这些事件的发生。这可以通过确保你有适当的 API 安全机制来实现。这可能包括只允许经过完全身份验证和授权的用户访问 API，或者对每个 API 调用实施适当的速率限制和配额。API 网关将拥有创建这种第一道防线的所有功能。

如果这种防御被突破或者由于某种原因被绕过，Moesif 的警报是一种很好的方式，可以确保您的团队仍然被告知您的 API 的任何不当或破坏性使用。当然，更深入的挖掘也可能带来使用 Moesif 增强 API 安全性和限制滥用的其他好方法。

向陷入困境或苦苦挣扎的新用户伸出援手

发现问题并主动帮助有困难的用户是很难的。当一个新用户加入时，我们喜欢跟踪的一个指标是 TTFHW ，或者“第一个 Hello World 的时间”。这个指标通常从用户第一次注册开始跟踪用户，直到他们第一次成功地“Hello World”为止。对于大多数技术产品来说，这个过程包括注册、初始配置，直到第一次成功的 API 调用。

这个指标非常重要，因为它极大地定义了我们产品的易用性。产品越容易使用，用户继续使用该产品的可能性就越大。对产品的初次体验至关重要。

正如我们所知，这个旅程需要时间来完善，它总是会有障碍。很少有公司完善了他们的用户之旅，但是好的公司会努力接近。如果我们可以在新用户陷入困境时得到提醒，那会怎么样？然后，我们的客户成功团队就可以提高警惕，主动联系该用户。有了 Moesif，我们就能做到这一点。一个很好的例子是，如果用户在发送他们的 API 请求时收到一个 HTTP 400 错误请求响应代码。这显然会非常令人沮丧，并且会成为用户的主要障碍。

例如，我们可以设置一个静态警报，当用户遇到困难时触发。当任何新用户遇到超过 5 个 HTTP 400 且其 TTFHW > 5 分钟时，可能会触发此警报。然后，我们可以将此警报发送给客户成功团队，并对他们进行个性化联系，以解除他们的封锁。这减轻了客户成功团队主动监控这些细节的需要。这也意味着客户成功团队可以在用户放弃并可能永远不再使用该系统或应用程序之前更有效地联系他们。

从动态警报的角度来看，如果新用户 TTFHW 与我们的历史数据相比变得异常长，我们可以设置一个警报来触发。这可能有助于通知产品和工程团队，最新的 onboarding 调整正在影响用户。

通过新增和更新的功能改善用户体验

如果用户在使用我们产品的新功能时遇到困难，我们可以得到提醒，那会怎么样？这可以让我们开展外联活动，询问困难所在。它还可以让我们干预用户，在他们遇到错误时减轻他们的挫折感，帮助他们正确使用该功能，并可能改进用户界面或文档，使使用更加简化。我们可以识别属于特定用户流的 API 调用，如果我们知道完成它的可接受时间阈值，就在它们周围放置一个静态警报。相反，我们可能会创建一个动态警报，对照历史数据进行检查，以确保用户流在我们的最新版本中不会变得更加难以使用。

当功能出错时，客户成功、产品和工程团队能够得到提醒，这是一个救命稻草。我们不需要等待通过渠道获得反馈，也不需要看到用户因困难而流失，当他们走错方向时，我们可以得到这些指标的提醒。

通知客户成功团队主动外展的使用率下降

如果用户的使用率下降，可能有很多原因。他们可能正在缩减运营规模，在平台上遇到了障碍，或者可能在配置中出现了一些他们没有意识到的问题。不管原因是什么，它都应该是客户成功团队关注的问题。

通过使用动态警报，当关键客户或所有客户(取决于您如何设置警报规则)减少了平台上的使用量时，客户成功团队会收到通知。动态警报可以寻找显示使用量显著下降的异常或趋势。客户成功团队可以进行调查，甚至主动联系用户，看他们是否能提供帮助。

这种类型的主动方法是客户成功团队展示他们投资于优先考虑用户业务的一种很好的方式。主动拓展有助于留住客户、提高客户流失率和客户满意度。当然，其中一些可以自动化，但是让客户成功团队意识到问题仍然是一种资产。

告知销售团队追加销售机会的使用增加

无论是合同中期还是用户的续订日期，使用量的增加都会带来收入的增加。提醒可以让您的销售团队主动带来升级机会，而不是等待销售团队做出反应。

在 Moesif 中，您可以使用静态或动态警报以多种方式实现这一点。使用静态警报，您可以在任何新用户在特定时间段内的 API 调用超过特定配额时向销售团队发出警报。这可能向销售团队发出信号，表明新用户可能是一个非常大的客户。不要浏览使用数据来判断应该联系谁，让警报来完成工作。

您还可以使用静态警报来响应“百分比变化”指标。例如，当客户在过去 7 天内的涨幅超过 20%时，会发送警报。这种方法会给销售团队一个提示，某家公司正在快速扩张。这可以帮助销售团队尽早获得升级信息，或者帮助通知即将到来的销售电话。

以上两个用例还可以帮助销售团队避免客户的“贴纸休克”，尤其是新客户。在这种情况下,“标签休克”是指客户因使用而收到一份意外账单。有时这可能会导致失去客户的信任。然后，客户可能会寻找更多成本更低的平台或应用。在这种情况下，可能将客户升级到下一层或产品包会有所帮助。跟踪指标，如配额和增长百分比，可以为客户保留提供优势，并与“价格休克”作斗争。

一旦建立了历史记录，您还可以设置动态警报规则。该警报将查看历史数据，并查看用户的 API 是否正在经历持续的使用增长。如果是这样的话，销售团队可以提前制定一份建议书，并在用户知道他们需要之前将追加销售机会带给他们。

有些产品还会有相关功能。如果使用“X”特征，那么“Y”特征将是有益的。可以设置警报来检测何时使用特定的 API。这将让销售团队精心策划他们的信息和推广活动，以迎合这一信息，并提出一个涉及其他补充功能的包。

这也表明你的公司投资于客户的业务，并帮助他们扩大规模。这些类型的提醒可以帮助销售团队主动培养新客户和现有客户。

设置您的第一个提醒

现在你已经知道了所有的好处，是时候尝试一下了！我们有一些很棒的指南可以告诉你如何创建你的第一个静态或动态提醒。为了进一步挖掘，你可能还想看看我们的广泛的文件。它就像创建您的警报定义、配置您的频道和激活警报一样简单。Moesif 仪表板使配置警报变得无缝和简单。Moesif 甚至在警报面板中默认设置了一些常见的警报。如果您没有 Moesif 帐户，今天就注册！一旦登录，您将能够创建自定义警报，以增强您的 API 监控游戏。无论您使用的是 REST API 还是 GraphQL API，Moesif 警报都是提高所有部门意识的好方法。

正确实施现收现付定价的行动手册

原文：https://www.moesif.com/blog/developer-platforms/self-service/A-Playbook-To-Properly-Implement-Pay-As-You-Go-Pricing/

基于使用量的定价、基于使用量的定价和 PAYG(随用随付)是相对较新的 SaaS 定价模式，与更传统的订阅定价模式(如基于许可或基于座位的定价)相比，这些模式使您能够在推动收入增长的同时增加净收入。使用“随用随付”模式，客户只需为他们消耗的资源付费，如虚拟机小时数或发送的消息数。API 自然是基于交易的，这使得它们适合于新的基于消费的定价。事实上，所有三家云提供商(AWS、Google 和 Azure)都利用基于消费的计费，因此他们的客户可以优化他们的基础设施。

预付费与后付费计费

首先，你需要决定是预付费还是后付费。预付费计费要求客户提前购买信用额度或预先协商好的配额，产生一个正余额，然后“烧掉”。如果是信用点数，客户需要在用完之前定期购买额外的信用点数来充值。一旦余额低于规定的阈值，一些系统会启用“自动加满”。这可以改善您的业务现金流，因为您甚至可以在交付服务产生任何成本之前利用已用资本。不考虑现收现付，大多数企业公司都要求预付企业合同的期限，因为预付可以实现更多的支付选项，如银行电汇或 ACH。客户也会受益，因为他们可以为您的服务设定硬性预算，并禁用任何“自动充值”功能。

预付费计费的缺点是，当使用量不可预测时，特别是当它不是捆绑金额时，购买计划时会增加额外的摩擦。预付费计费要求客户甚至在使用服务之前就估算出要购买多少，如果他们最终没有使用信用额度，这也可能会导致更多的退款请求。除非卡已存档，否则因超龄或违反条款收取额外费用可能更难。由于资金紧张，客户可能会反对预付账单。对于以增长为导向的支出，比如点击付费广告或信用卡处理，情况尤其如此。在这种情况下，客户可能愿意支付更高的价格，因为他们已经从用户那里获得了收入。

第三种选择是利用两者的混合。例如，捆绑的金额可以在信用卡上预付，但超额费用是事后支付的。

计费频率

您还需要决定向客户收费的频率，这与您是否利用预付费与后付费计费有关。一种选择是定期开发票，例如每月的第 n 天。这使得你的客户的账单部门更容易，因为你的服务更可预测，同时最大限度地减少支付发票的额外工作。这也更容易理解，因为大多数 SaaS 订阅已经按年或按月计费。

建议不要像月初或月末那样为所有客户设定一个共同的记账日，因为这可能会导致您的支持团队在当天处理大量的记账请求。

第二种选择是基于阈值的。如果是预付费计费，客户需要购买信用额度，一旦余额低于阈值，则需要充值信用额度。许多系统都允许自动充值，比如当余额低于 10 美元时，增加价值 100 美元的信用点数。如果您实现后付费计费，阈值正好相反，当负余额超过阈值(如 500 美元)时，将生成发票并从信用卡中扣除费用。这在自助广告中越来越常见。缺点是缺乏可预测性，因为某些月份的费用可能比其他月份多得多。如果不小心，这可能会产生不必要数量的小额费用发票。同样，这会给你的会计团队带来一场噩梦，也更难预测未来的收入。

计费测量

根据您的计费时间和频率，您需要实施一个系统，该系统可以准确测量和报告每个客户帐户的交易量。这通常意味着拥有一个关于 API 调用或事务的分析系统。因为每个客户可能有不同的账单周期，所以您的分析解决方案应该有办法处理这种情况。如果您利用定期计费，那么您可以在向客户开具发票时查询他们的使用情况，通常是在预定义的计费日。

对于阈值计费来说，衡量可能要稍微复杂一些，因为发票可以在任何时候生成，而不仅仅是在客户的计费日。这意味着一旦达到阈值，您需要跟踪并触发发票。与定制的内部计费相比，利用像 Moesif 这样的现成 API 分析工具可以大大减少您的开发和维护时间。

配额电子邮件

谈到定价，客户不想要惊喜。然而，对于基于消费的计费，发票金额可能会根据其使用情况而有所不同。通过发送自动配额和使用电子邮件，您的客户可以在成本增加或接近配额限制时获得通知。

如果您利用捆绑费用和超额费用等混合模式，您可能希望在客户使用了大部分配额或超出配额时提醒他们。像 Moesif 这样的行为电子邮件平台可以配置为在一段时间内(如 10 天)让通知静音，这样客户就会收到提醒，以避免向客户的收件箱发送垃圾邮件。10 天后，如果客户仍然超出限额，您可以发送第二封电子邮件。

自助计费仪表板

因为您是根据使用情况计费，所以必须以自助方式让您的客户了解这些使用情况和成功指标。您可以使用像 Moesif 的嵌入式图表这样的工具，将指标嵌入到您的开发人员门户中，而不是强迫您的客户请求支持来了解他们使用了多少配额。您的客户会希望分割这些数据，以便他们能够了解这些数据的使用情况，以及他们可以在哪些方面节省资金。

对使用情况报告的要求包括:

• 能够看到使用不同的时间间隔，如每小时，每天或每月。
• 显示业务交易的数量，即使您的 API 可以批量处理请求
• 一种按用户统计或客户细分使用情况的方法。

除了使用报告，您还可以嵌入其他指标，如 SLA、API 日志等，以改善您的开发人员体验，减少采用您的 API 平台的障碍。

结论

如果实施得当，现收现付定价可以为您的企业增加收入和留住客户。然而，与更传统的订阅定价相比，基于消费的计费实施起来也更具挑战性。您需要对使用情况和工作流程进行准确的衡量，以确保您的客户在收到发票后不会感到惊讶。像嵌入式图表和配额电子邮件这样的工具可以让你的客户了解更多信息。

无服务器计算入门:AWS Lambda vs Google Cloud Functions vs Azure Functions

原文：https://www.moesif.com/blog/engineering/serverless/A-Primer-On-Serverless-Computing-AWS-Lambda-vs-Google-Cloud-Functions-vs-Azure-Functions/

什么是无服务器计算？

无服务器计算是一种新形式的基于云的计算，类似于在云提供商上运行的虚拟机和容器。虽然这并不意味着没有服务器，但服务器的管理、扩展和容量规划由底层云提供商负责。应用程序开发人员只需要关注功能和业务逻辑。

越来越多的开发人员正在为下一代应用程序和 API 采用无服务器技术。无服务器已经比 Docker 和 containers 快 10 倍。本文将提供一些关于无服务器生态系统的信息，以及不同提供商和框架之间的差异。

微服务底漆

在无服务器计算之前，许多企业采用微服务，这是一种面向服务的架构(SOA)形式。微服务使应用程序能够被组织为通过 API 连接在一起的松散耦合服务的集合。每个服务在它自己的进程/容器/VM 中都是一个完全独立的迷你应用程序。主要的好处是我们在计算机科学 101:模块化和关注点分离中学到的。微服务可以让复杂的应用在大公司更容易开发和扩展。应用程序可以很容易地在职能团队之间划分，每个团队负责一个或一组微服务。代码库可以保持很小，并且为了快速迭代开发而构建得很短。应用程序的各个部分可以独立于其他微服务进行扩展。

然而，随着微服务的出现，基础设施和运营工作大大增加。突然出现了许多需要跟踪的持续集成/持续交付管道。需要考虑服务的每个版本或变体的互操作性，以及它所依赖的其他服务。有复杂的编排来管理更多的移动部分。日志记录上下文现在分散在许多单独的进程中。集成测试的负担更重了。事实上，像 Basecamp 这样的公司认为为什么 monolothic 架构对某些像初创公司这样的小公司有意义。

走向无服务器

无服务器计算将微服务推向了极致。基础设施、编排层和部署都被取消了。仍然有服务器和虚拟机，但它们完全由云提供商管理。作为应用开发者，你只需要写业务逻辑和功能，剩下的交给 AWS 或者 Azure。

无服务器计算还可以降低您的计算成本。虽然大多数云提供商将按小时收取保留虚拟机的费用，但无服务器计算可以使用基于消耗的定价模式。如果应用程序没有主动使用计算或内存资源，则无需付费。

无服务器计算提供商

云计算供应商正在推动这一领域的大量创新。下面的比较集中在三个方面:构建(支持的语言)、部署(易于设置和管理)和触发器(触发功能)。

自动气象站λ

AWS lambda 是 2014 年推出的首批无服务器计算产品之一。

AWS Lambda 原生支持多种语言，包括 Node.js、Python、Java 和 C#(。网芯)。通过从 AWS Lambda 沙箱中允许的受支持语言之一生成子进程，可以支持其他语言。AWS 沙箱隔离不依赖于任何允许这种灵活性的语言结构。

开发可以使用 AWS 的嵌入式编辑器在线完成。然而，一旦您需要添加依赖项以使您的代码运行，您需要在您的本地机器上进行开发，并上传一个由您的代码以及任何依赖项组成的包。如果你开发一个节点函数，AWS Lambda 将不会运行npm install。部署需要创建并上传一个部署包，将代码和依赖项捆绑在一起。

AWS 将 AWS Lambda 定位在 AWS 的前端和中心，而不仅仅是一个额外的产品，它提供大量的 AWS 服务，可以作为一键触发器，在使用 Lambda 方面提供很大的灵活性。如果您正在开发一个 API，可以使用非常流行的 AWS API 网关触发器。API Gateway 使您能够将针对 RESTful API 端点(如GET /items/{id})的 HTTP 请求映射到 AWS lambda 函数getItem(event, context, callback) { }。在 REST APIs 之外，AWS 提供了各种触发器，从 Amazon Kinesis(类似于 Kafka)的事件流到 DynamoDB 或 S3 的更新，甚至可以从 Alexa 技能应用程序触发。事实上，AWS 正在推动将 AWS Lambda 作为开发 Alexa 新技能的主要方式。

Azure 函数

随着 Azure 功能在 2016 年年中推出，Azure 在 AWS 之后不久进入了无服务器领域。与 AWS 相比，Azure 支持更多种类的语言。除了 Node.js、C#和 Python，Azure 还支持 F#、PHP、Bash 和 PowerShell。2017 年 10 月 4 日，Azure 宣布他们将在旧金山 JavaOne 大会期间支持 Java。此外，他们的逻辑应用和流程使非开发者能够为业务流程建立自己的逻辑，就像 Zapier 如何连接多个业务工具一样。

Azure 提供了类似 AWS 的在线编辑器。然而，Azure 的编辑器是基于 Visual Studio Online 构建的。与 AWS 和 Google 不同，Azure 围绕部署提供了更多的基础设施。您可以从 Visual Studio Team Services、Bitbucket 和 Github 中的源设置连续构建和部署部署。

在架构上，Azure Functions 与 AWS Lambda 截然不同，因为 Azure Functions 的大部分基础设施都来自 Azure 应用服务和应用服务计划。Azure 功能被逻辑地分组到一个名为应用服务的应用容器或环境中。应用服务中的所有 Azure 功能共享相同的资源，如计算或内存。这也使得能够部署应用程序而不是单个功能。你可以把 Azure 函数看作是 AWS Lambda 和更传统的 Azure Web Apps/AWS Elastic Beanstalk 类环境的混合体。

与 AWS 不同，更多的 HTTP 触发器功能是在 Azure 函数中本地构建的，不需要设置单独的 API 网关。这很大程度上与 Azure 在应用服务容器下对功能的逻辑分组有关。Azure 支持各种其他的触发器。这样的触发器可以包括 Azure Blob 存储、Azure 事件中心和队列。

谷歌云功能

相对于 Azure 和 AWS，Google Cloud functions 在语言方面是最受限制的，因为它们只支持 Node.js。不幸的是，Google Cloud Functions 相对于 AWS 和 Azure 似乎是最不发达的。这部分不是因为谷歌的云功能，而是谷歌在谷歌云中提供的可以作为触发器的服务最少。AWS 有 Kinesis，Azure 有 EventHubs，但谷歌没有类似的服务。与 AWS 不同，谷歌没有将云功能推到前台和中心。谷歌的内部开发更多地依赖于像 Kubernetes 这样的工具，而不是云功能。

从积极的一面来看，Google 允许在进程被终止之前执行长达 9 分钟的时间。谷歌还为 Firebase 提供了一个独立的产品云功能，如果你是一个已经依赖 Firebase 的移动应用初创公司，这可能会很有用。Firebase 使您能够从 Firebase Db 的更新中产生一个新的云函数。与 AWS 不同，Google 将 HTTP 功能直接集成到云功能中，不需要设置单独的 API 网关。

对于部署，您可以上传一个 zip 文件或从 Google 仓库进行部署。

独立的无服务器框架

因为无服务器计算是由云提供商高度管理的服务，所以有很大的局限性。触发器的实现是特定于每个提供商的，因此你不会在 Google 或 Azure 上找到相同的 AWS Kinesis 触发器。除了不同的触发器之外，根据使用 AWS Lambda vs Google Cloud Functions vs Azure Functions，传入的上下文和顶级函数签名也是不同的。

虽然锁定的可能性很高，但是您可以通过利用能够翻译各种服务的供应商中立垫片来减轻这种情况。这种供应商中立的垫片允许您以类似于 Azure EventHubs 的方式使用 AWS Kinesis。此外，HTTP APIs(无服务器的一种非常常见的用法)可以完全开放和透明。

有独立的开源框架可以做到这一点。此外，它们使部署标准化，并使您可以访问的特定于供应商的上下文对象标准化。

有相当多的框架根据您的需求而变化。一些受欢迎的包括:

• 无服务器
• kub less
• 裂变
• 功能

监测挑战

无服务器计算日益增长的挑战之一是监控和调试所有这些功能。与微服务架构相比，日志记录上下文现在分散在更多的组件中。许多日志都是特定于供应商的，不像标准的 NGINX 或 HaProxy 日志。

此外，在相同的环境中，很难在本地镜像和运行用于调试的函数。至关重要的是通过故障场景尽可能多地包含调试上下文，而不仅仅是在本地重现问题。有时，您无法在云供应商的环境中重现该问题。

在 Moesif，我们正在努力提供对这种无服务器功能调用的可见性，并且已经有了带有不同触发器的 AWS Lambda 的 SDK，如 Moesif 的用于 API 网关的 Lambda 中间件和 Moesif 的用于 Alexa 技能工具包的 Lambda 中间件。

实现基于使用的 API 计费的简单方法终于出现了

原文：https://www.moesif.com/blog/developer-platforms/self-service/A-simple-way-to-implement-usage-based-API-billing-is-finally-here/

计量计费终于在 Moesif 中实现了，我们非常兴奋能够推出这一最新功能。我们一直在努力提供一种平稳而简单的方法，通过允许在 Moesif 中跟踪的使用情况由您最喜欢的计费提供商进行计量和计费，来将您的 API 货币化。Moesif 可以计算使用数据并将其发送给计费提供商，以便您的客户可以根据其使用情况准确计费。

Moesif 中的计量计费是跟踪客户使用您的 API 和应用程序并收取费用的最简单方式。该解决方案需要无代码，只需几行配置，您就可以开始运行了。让我们进一步了解我们的最新功能，以及您为什么想要使用它！

什么是计量计费？

计量计费是一项允许 Moesif 用户计量其 API 或 web 使用情况并根据使用情况向用户收费的功能。一个例子可以是现收现付的方法，在这种方法中，每个 API 调用向用户收取特定的费用。用户还可以选择实施分层计费方法，这种方法允许特定的使用层级，并允许根据用户的使用层级向用户收费。

您还可以实现自定义操作来跟踪任何任意指标，如“接收的千兆字节”或“处理的分钟”。

在计费期结束时，使用量被累加并发送给计费提供商，以便用户可以为其使用付费。计量计费是公司以后付费方式将其 API 货币化的方式。任何被 Moesif 跟踪的 API 都可以使用计量计费轻松实现货币化。

Moesif 实际上每小时向计费提供商发送使用数据。然后，计费提供商将汇总使用数据并为其计费。

为什么在 Moesif 中使用计量计费？

计量计费并不是一个新概念，使用相当广泛。然而，创建计量计费解决方案通常非常复杂，需要精确的分析、数据管道以及与计费提供商的集成。整个设置可能需要相当多的应用程序、数据馈送、基础架构，更不用说工程和支持时间了。

幸运的是，Moesif 包含了计量计费系统所需的所有数据，并支持与计费提供商的直接集成。这为您的所有计量计费需求提供了无缝的“一站式”服务。Moesif 收集你所有的 API 使用数据，并按用户和公司进行跟踪。有了它，Moesif 就可以轻松地计算给定时间间隔内的使用量，并将数据传递给支持的计费提供商，以计算使用量并收取费用。

Moesif 还允许用户创建高度独特的过滤器，以便用户可以针对特定的端点及其使用方式进行计费，例如基于正文或标题内容、路由或 Moesif 支持的任何其他过滤标准进行计费。Moesif 提供了一种高度可定制和灵活的方法来为用户的 API 使用计费。

在 Moesif 哪里可以找到？

moes if 中的计量计费可通过计费仪表选项卡下的左侧导航菜单访问。单击该菜单项会将用户带到一个屏幕，您可以在其中添加您的第一个计费计数器或显示当前创建的计数器。

您可以通过使用创建新按钮并选择计费表来创建新的计费表。这将带您进入新计费计数器创建屏幕。

它是如何工作的？

在 Moesif 中启动并运行计量计费只需几分钟。下面是让它工作所需的步骤的高级概述:

配置账单提供商

您的第一步将是配置您的账单提供商。您需要在您的帐户中设置好您的计划和附加服务。这些信息将被导入 Moesif，这样当您将帐户连接到 Moesif 时，您就可以将它们分配到计费表中。

其中一部分还要求您设置任何 webhooks 或其他连接，这是计费提供商和 Moesif 所要求的，以确保系统准备好处理平台之间的通信。当您将账单提供商添加到 Moesif 时，将会概述这一点。

创建新的计费计数器

如上所述，创建计费指示器有几种方式(包括使用左侧导航菜单中的 Create New 按钮)。您需要命名您的计费表，然后继续添加您的计费提供商详细信息。

如果您已经将您的计费提供商添加到 Moesif 中，它将显示在创建新计费计数器屏幕上的计费提供商详细信息部分。如果没有，系统会提示您从同一屏幕上的付费提供商下拉列表中添加您的提供商。

在本例中，我已经设置了一个计费计数器，并为该用途应链接到的计划添加了计费提供商详细信息。

配置要计费的过滤器和指标

接下来，您将配置哪些使用将计入您的计费计数器。第一步是创建您的过滤器，就像您在 Moesif 中创建图表一样。例如，您可能希望只对发送到特定 API 路由的 API 调用计数进行过滤。

最后一步是指定您想要跟踪的指标。这是您向客户收取费用的指标。一般来说，事件计数是常见的选择，但也存在其他选项，包括独特的用户，独特的公司。您还可以使用自定义元数据字段制定自己的指标，例如跟踪消耗的带宽或其他指标。

下面我设置了一个过滤器和指标来跟踪对 /purchase API 端点的调用的事件计数。

保存您的计费表

设置好计费表后，我们现在可以将基于过滤器的使用情况与我们指定的计费计划关联起来。在计费周期结束时，Moesif 将对使用情况进行统计，并将这些数据传递给计费提供商，以便他们进行计费。

我们的最后一步是保存计费指示器，使其处于活动状态。保存后，使用数据将从 Moesif 中收集的使用指标中自动传递到计费系统。

试一试！

要试用它，只需登录 Moesif 并导航到计费表选项卡来设置您的第一个计费表。随着我们功能的扩展，希望所有您喜欢的计费提供商都加入到 Moesif 中，这样您就可以快速轻松地将您的 API 货币化。还没有账户？只需注册即可在几分钟内开始。有关计量计费和可能配置的更多信息，您也可以查看我们的文档页面！

向您的 GraphQL API 服务器添加分析，并使用 VSCode 调试它

原文：https://www.moesif.com/blog/technical/debug/Add-Analytics-to-your-GraphQL-API-Server-and-Debug-it-With-VSCode/

GraphQL 后端现在是 API 行业的必备工具。

GraphQL 让前端可以更好地控制后端通过网络发送的数据。仅这一功能就可以减少流量，从而节省资金并有助于慢速移动连接。

由于 GraphQL 比 REST 更好地指定，不同的 GraphQL 实现比 REST APIs 更能相互匹配，这使得它们更容易被前端开发人员所接受。

在本文中，我们将使用 Apollo-Server 构建一个 GraphQL 后端，并使用 Apollo-Servers 的实验性扩展系统创建一个自定义分析扩展。

为什么

GraphQL 在请求和响应之间添加了更多的库代码，所以如果能更深入地了解当有人从我们的 GraphQL 后端请求数据时会发生什么情况，岂不是更好？

自定义扩展可以挂钩到 GraphQL 请求的生命周期，并允许我们在分析工具和服务中使用这些信息。

我们还可以通过类似 VSCode 中包含的调试器来利用自定义扩展代码。

什么

GraphQL 是 REST 的替代品。它是一种查询语言的规范，也是这种语言的实现。它让我们定义类型化的 API 端点，并允许客户端只请求他们需要的数据。

Apollo Server 是在 Node.js 运行时上用 JavaScript 实现的 GraphQL 服务器规范。

Visual Studio Code ，简称 VSCode，是一个用 JavaScript 编写的可扩展代码编辑器。它附带了一个用于 Node.js 应用程序的集成调试器。

怎么

为了让所有这些工作，我们需要安装 Node.js 和 VSCode 。

GraphQL 服务器安装程序

要启动并运行一个简单的 GraphQL 服务器，我们必须创建一个新的 Node.js 项目。

$ mkdir api-server
$ cd api-server
$ npm init -y 

我们还需要 NPM 的apollo-server和graphql包。

$ npm i apollo-server graphql 

现在，让我们用 VSCode 打开api-server项目，这样我们就可以实现我们的服务器。

$ code . 

我们需要一个新的index.js文件，代码如下:

const { ApolloServer, gql } = require("apollo-server");

const typeDefs = gql`
  type Task {
    text: String
  }
  type Query {
    tasks: [Task]
  }
`;

const resolvers = {
  Query: {
    tasks: () => [
      { text: "Buy chocolate!" },
      { text: "Pay rent." },
      { text: "Wash dishes." }
    ]
  }
};

const server = new ApolloServer({ typeDefs, resolvers });

server
  .listen({ port: 9999 })
  .then(({ url }) => console.log(`Server running! ${url}`)); 

让我们一步一步来。

首先，我们需要 GraphQL 包，apollo-server配置并运行我们的 GraphQL 服务器，graphql解析我们将提供给apollo-server的模式定义。

然后我们定义了一个简单的模式，它只允许从我们的服务器查询任务列表，我们实现了一个解析器用于将任务数组发送回客户机的查询。

当我们使用以下命令启动服务器时:

$ node . 

它将允许我们通过 GraphQL Playground 发送 GraphQL 查询，这是脸书 GraphQL 服务器参考实现的默认graph QLUI 的可选 UI。

要访问这个 UI，我们需要在浏览器中打开http://localhost:9999/graphql。

在 GraphQL Playground 的帮助下，我们现在可以查询任务，看看是否一切正常，服务器是否配置和设置正确。

{  tasks  {  text  }  } 

如果一切正常，我们应该会收到以下响应:

{  "data":  {  "tasks":  [  {  "text":  "Buy chocolate!"  },  {  "text":  "Pay rent."  },  {  "text":  "Wash dishes."  }  ]  }  } 

下一步是我们的分析扩展。

添加分析扩展

apollo-server包附带了一个 实验性的扩展系统，它可以与他们的 GraphQL 服务器实现的不同生命周期事件挂钩。

我们可以利用它来构建一个定制的扩展，从apollo-server接收数据并以某种方式使用它。为了使本文简单，我们将使用我们的扩展记录请求的每个生命周期阶段。

为此，我们创建一个新文件analyticsExtension.js,其内容如下:

class AnalyticsExtension {
  requestDidStart({ queryString, operationName, variables }) {
    console.time("requestDidStart");

    if (!!operationName) {
      console.log("OPERATION");
      console.log(operationName);
    }

    console.log("QUERY");
    console.log(queryString.trim());

    console.log("VARIABLES");
    console.log(variables);

    return (...errors) => {
      if (errors.length) {
        console.log("ERRORS");
        console.log(JSON.stringify(errors, null, 2));
      }
      console.timeEnd("requestDidStart");
    };
  }

  parsingDidStart() {
    console.time("parsingDidStart");
    return () => console.timeEnd("parsingDidStart");
  }

  validationDidStart() {
    console.time("validationDidStart");
    return () => console.timeEnd("validationDidStart");
  }

  executionDidStart() {
    console.time("executionDidStart");
    return () => console.timeEnd("executionDidStart");
  }

  willSendResponse(options) {
    console.log("willSendResponse");
    console.log(JSON.stringify(options.graphqlResponse, null, 2));
  }
}

module.exports = AnalyticsExtension; 

扩展是实现以下部分或全部方法的类:

• requestDidStart
• parsingDidStart
• validationDidStart
• executionDidStart
• willSendResponse

所有这些方法，除了willSendResponse可以返回一个回调函数，当它们的生命周期阶段结束时，apollo-server将调用这个函数。它使用回调，因为这些阶段是异步的。

这样，我们可以在每个生命周期阶段定义两次回调。

在requestDidStart中，我们记录从客户端收到的查询数据，还设置了一些计时器，这样我们就可以检查如何记录服务器处理请求的时间。

在parsingDidStart、validationDidStart和executionDidStart中，我们只设置计时器来检查每个生命周期阶段执行了多长时间。

在willSendResponse中，我们记录了 GraphQL 服务器产生的响应。

现在，所有这些数据都将被记录在本地，但我们也可以将其发送到分析和监控服务，如 Moesif 。

既然我们已经定义了我们的自定义分析扩展，我们必须将它连接到我们的 GraphQL 服务器。

为此，我们在index.js中扩展了require，并将一个新实例传递给ApolloServer构造函数的extension数组。

const AnalyticsExtension = require("./analyticsExtension");

...

const server = new ApolloServer({
  typeDefs,
  resolvers,
  extensions: [() => new AnalyticsExtension()]
});

... 

当我们重启服务器并发送查询时，我们现在应该会看到我们的分析输出:

QUERY
{
  tasks {
    text
  }
}
VARIABLES
{}
executionDidStart: 0.252ms
willSendResponse
{
  "http": {
    "headers": {}
  },
  "data": {
    "tasks": [
      {
        "text": "Buy chocolate!"
      },
      {
        "text": "Pay rent."
      },
      {
        "text": "Wash dishes."
      }
    ]
  }
}
requestDidStart: 1.558ms 

每个生命周期方法都记录它的时间，有些还记录在它的阶段中接收或产生的数据。

有了我们的定制分析扩展，我们现在可以去调试我们的系统。

使用 VSCode 调试

为了设置 VSCode 调试器，我们需要创建一个.vscode/launch.json来告诉 VSCode 如何启动我们的服务器。

{  "version":  "0.2.0",  "configurations":  [  {  "type":  "node",  "request":  "launch",  "name":  "Debug Server",  "program":  "${workspaceFolder}/index.js"  }  ]  } 

如果我们在 VSCode 中打开 debug 视图，我们现在可以在左上角的下拉菜单中看到我们的“Debug Server”launch-configuration。

如果一切都设置正确，我们现在可以在index.js中加入我们的resolvers函数，在analyticsExtenion.js中加入AnalyticsExtension生命周期方法并设置断点。

如果我们遇到这些断点之一，我们可以使用 VSCode 的调试控件来导航我们的代码。例如，我们可以跳出我们自己的扩展代码，进入调用我们的生命周期方法的函数。

有了这个设置，我们现在可以在本地对我们的系统进行更多的控制，甚至当它运行在云中的某个地方时。

结论

Apollo 的 GraphQL 服务器实现为我们提供了一种非常方便的方法来集成我们选择的监控服务。扩展系统为我们提供了对请求生命周期阶段的粒度访问，因此我们可以测量我们的后端发生了什么。

与 VSCode 的调试器协同工作，我们可以使用自定义扩展代码来更好地理解我们的服务器在运行时采用的代码路径。

总而言之，这让我们更好地了解了我们的 GraphQL 服务器中正在发生的事情，以及我们未来可以改进它们的地方。

推动 API 集成的电子邮件营销活动

原文：https://www.moesif.com/blog/developer-marketing/behavioral-emails/An-Email-Marketing-Campaign-that-Drives-API-Integration/

最有效的营销策略之一是根据收件人的行为发送电子邮件。通过触发你的客户如何与你的产品互动，你能够分享与他们正在做的事情实际一致的内容，从而更有可能引起共鸣。

通过使用自动化的电子邮件工作流程，有可能与大批客户大规模共享超级相关的内容。通过基于行为标准的细分，而不是人口统计/公司地理标准，你可以摆脱一成不变的静态滴水活动，将基于客户的营销提升到一个新的水平。

在我们自己的客户群中，我们使用复杂的电子邮件工作流已经有一段时间了。我们发现，那些通过整合漏斗从沙盒阶段进入生产阶段的人与目标电子邮件内容的互动是那些没有进步的人的两倍。此外，通过优化内容，我们能够将的参与度提升 3 倍，从而提高了采用漏斗。

漏斗中部优化

在一篇配套的博客文章中，如何加速 API 与行为电子邮件和开发者细分的集成我们研究了行为电子邮件如何在集成漏斗的每个阶段驱动客户。在这篇博文中，我们专门关注漏斗(MOF)阶段的中期——在这个阶段，客户已经注册并提出了他们的第一个 API 请求，但有些事情阻碍了他们将应用程序投入生产。他们仍然处于沙盒阶段。

从最初注册到推广到生产的时间有时被称为第一个工作应用程序的时间或第一个付费应用程序的时间。API 平台提供商希望优化这一指标，并最大限度地增加投入生产的客户数量。

关注行为细分

在 MOF 阶段，在完成企业销售之前，通常需要争取许多不同的利益相关方。现在是时候展示你的产品带来的价值，并帮助消除任何可能阻碍决策者的障碍。

行为邮件应该在正确的时间向正确的受众提供正确的内容，这样才最有效。主要受众成员包括产品经理(项目经理在确定功能、路线图、跨学科管理、文档等方面发挥关键作用)、总委员会(GCs 关注法律合规性)、CSO(安全审查)、CFO(财务分析)和 CEO(战略契合度)。此外，开发人员需要辅助材料和工具来帮助他们解决集成问题，以及功能和性能测试支持。

真实世界的结果:将应用从沙盒迁移到生产环境

Moesif 已经为数以千计的客户部署了 MOF 电子邮件工作流。通过跟踪用户与行为电子邮件的互动，并将其与我们自己的分析平台的数据相关联，我们能够准确地确定我们营销工作的有效性，如下表所示。

电子邮件区	主题	观众	开放率	协助皈依
特色亮点	仪表盘	首相	——+	——+
援助	设计评论	偏差	——+	——+
个案研究	推动采用	首相	+——	——+
特色亮点	可量测性	首相	——+	—+—
特色亮点	客户沟通	首相	——+	—+—
ROI 计算	构建与购买	首席财务官(Chief Finance Officer)	—+—	+——
个案研究	公司洞察	首席执行官	+——	+——
安全性*	数据完整性	计算机服务机构(Computing Services Office)	——+	+——
合规*	开发人员采用	车底距地高(Ground Clearance)	—+—	+——

^{*估计由于没有足够的数据}

我们发现，展示我们 API 产品价值并推动转化的最佳方式是通过案例研究和特色 亮点。通过展示我们的 API 平台如何满足其他客户的需求，以及提供了哪些高级功能，那些处于集成漏斗中的人看到了他们可以通过我们的产品实现什么，以及我们如何解决他们的痛点。

如果我们观察所有经历过该工作流程的客户，我们会发现，那些将应用投入生产的人打开电子邮件并与之互动的次数是那些停留在沙盒阶段的人的两倍。开发生产应用程序的客户的电子邮件打开率为 59%，大约是那些留在沙盒中的客户的两倍。参与度与转化率成正比。

通过行为电子邮件提高漏斗转化率

行为电子邮件工作流的功效已经在现实世界的例子中展示出来。通过在点滴序列中使用有针对性的电子邮件，我们已经能够提高我们的转化率，并减少我们的客户的时间到第一个工作应用。

开发者旅程中的 API 分析

原文：https://www.moesif.com/blog/api-product-management/developer-experience/API-Analytics-Across-the-Developer-Journey/

每个 API 产品经理都希望尽可能多的开发人员采用和使用他们的 API。他们希望他们能够快速到达 Hello World，并在此过程中拥有出色的开发人员体验(DX)。当然，更大的目标是能够将 API 的成功与公司更大的目标联系起来。对于许多人来说，尽管他们的初衷是好的，但他们的衡量标准过于简单、狭隘，并且基于过时的参与模式。

借助完整的 API 分析，您可以在整个旅程中指导 API 用户——从注册和教育到 Hello World 和应用部署。通常，仅仅有人开始使用你的 API 是不够的。相反，你希望他们完全利用它。API 的原始用法并不能说明您的整体客户体验的全部。您可以使用分析来仔细规划每个 API 的设计，改善每个开发人员的体验，并最大化您产品的成果。

推动更多开发者从 API 注册走向成功

开发人员通常可以选择要集成的 API，或者是否要集成。当你成功吸引了一个注册你的 API 的用户时，你需要做的是让开发者进入下一步。你需要同时记住这种微观上的成功，同时也要在整个 API 旅程中着眼于宏观上的成功。

作为 API 提供者，您希望确保每个创建帐户的开发人员成功地将您的 API 集成到他们的应用程序中。API 分析可以让您:

• 改进 API Onboarding
• 帮助开发者更快到达 Hello World
• 鼓励使用更多的 API 特性和端点

其中一些你可能很熟悉。你可能在没有太多数据的情况下尝试它们。深度集成的最终成功是大多数 API 产品经理没有跟踪的——可能是因为它是不可见的。

改进 API Onboarding

从用户生成 API 密匙到他们将您的 API 集成到他们的应用程序中，会发生很多事情。借助 API 分析和用户界面数据(例如通过 Moesif 的 Pendo integration )，您可以在开发人员入职时跟踪他们，从旅程的不同点收集数据，例如:

• 当用户注册一个 API 账户时
• 当用户生成 API 密钥时
• 入职流程中包含的每个步骤或页面
• 当用户第一次调用 API 时

您应该仔细查看 API 和用户数据，以确定哪种入职流程最适合大多数开发人员。用户在入职时需要做的决定越少越好。尝试先提供有限的入职选项，然后根据提供的数据扩展入职路径。

通过分析 API 和用户数据来个性化入职，然后发送适时的定制电子邮件——这很容易通过像 HubSpot 或 SendGrid 和 Moesif 的行为电子邮件这样的应用程序来完成。

最初的入职培训可能会让开发人员无所适从。API 分析的下一步应该是获得洞察力，以帮助那些开发人员更快地进入 Hello World。

帮助开发者更快到达 Hello World

查看您的 API 数据，您可能会发现一些开发人员在从预集成阶段过渡到沙盒阶段(第一个 Hello World (TTFHW)时遇到了困难。TTFHW 是您需要跟踪的最重要的 API 指标之一，减少这个时间应该是优先考虑的事情。一系列问题可能会增加开发人员到达他们的第一个 Hello World 的时间。

这些潜在问题包括:

• API 错误
• 您的 SDK 中的错误
• 用户实现 API 的方式存在缺陷

通过 API 分析，您可以跟踪 API 的使用情况，并观察开发人员在使用您的 API 时的行为。您可以找到用户犯错的地方，并帮助他们克服任何障碍。例如，一些开发人员在使用特定的 API 端点后是否会访问您的文档页面？使用这些数据来改进您的文档，使其与他们更相关。你可能需要帮助一些开发者进入第一个 Hello World，所以通过相关的内容和帮助向他们提供大量关于你的 API 的信息。

有些用户可能永远也到不了第一个 Hello World。这是 TTFHW 如此重要的另一个原因，因为它可以预示最终的开发人员流失。你需要了解你的 API 用户在哪些方面挣扎，然后帮助他们保持在正确的轨道上。用你的 API 分析创建一个漏斗，并标记动作，不仅指示一个成功的 Hello World，还指示不止一个呼叫的迹象。

很多 API 产品经理止步于 Hello World，不去探索更多更深层次的成功。或者，有时这些后续信号更加手动，如销售对话。通过探索跨多个端点的使用，您可以鼓励开发人员采用额外的 API 特性。

鼓励使用更多的 API 特性和端点

开发人员通常从几个核心端点开始，通常不知道 API 必须提供的一切。一个应用程序的长期成功通常需要超越 API 单一领域的集成。使用 API 分析来跟踪哪些端点没有得到开发人员的重视。然后使用触发式电子邮件和内容营销向开发者介绍你的整个 API。

例如，您可以向一些用户发送一封电子邮件，其中包含产品页面、文档或视频短片的链接，解释未使用的特定终端的优势。提供额外内容，解释应用程序将从该端点功能中获得的价值。定期通过自动邮件向开发人员介绍新的和未使用的端点，鼓励他们使用更多的 API 特性。

识别更深层次集成的另一种方法是通过 SDK。您可以提取 API 头来确定每个头的使用量。进一步划分第一次 API 调用日期，以确定您的产品是否已经被集成到一个活动项目中。

一旦你有了可用的 API 分析数据，有很多方法可以解释它。除了跟随开发人员的旅程，您还可以依靠数据来做出更好的 API 产品决策。

利用数据做出更好的 API 产品决策

当您能够看到整个开发过程时，您就可以根据实际的 API 使用情况来做出产品决策。您可以了解 API 的“热点”和较少使用的部分，然后相应地计划未来的更新。随着 API 产品管理成为一个更新的领域，你需要一个能够理解你想要回答的独特问题的工具。例如，您可能想知道:

• 按 API 使用情况列出的顶级客户
• 每个客户使用的终端
• 端点弃用的含义
• 哪些营销渠道推动了 API 的实际使用

有了这些数据(您可能会寻找其他数据)，您可以探索当前的结果并满怀信心地进行产品更新。当您考虑整个开发人员之旅时，您将重新审视指标，以帮助更多的开发人员不仅迈出重要的第一步，而且更全面地将您的 API 集成到他们的系统中。

使用 Moesif API Analytics 开始构建优秀的 API。了解更多。

特性弃用的 API 最佳实践

原文：https://www.moesif.com/blog/best-practices/api-analytics/API-Best-Practices-For-Feature-Deprecation/

TL；DR 与您的用户交流！

大多数以写软件为生的人都有一个共同点；他们不想永远支持他们曾经实现的所有东西。

软件业的一小部分人试图利用这种做法为自己谋利，并试图走一条不同的路——操作系统尽可能长时间地与旧软件兼容。“Linux 不会打破用户空间”，Windows 带有兼容的运行模式，macOS 甚至有 Rosetta，一个允许你运行在他们转换到 Intel CPUs 之前创建的软件的软件。

甚至一些云提供商试图将反对意见降到最低，这样他们就可以随时说“我们不会让你失望的。”

停止提供 API 特性可能是个好主意，这有多种原因，但不是像微软或亚马逊这样规模的公司就足以成为在某个时间点停止提供部分 API 的理由。

什么是弃用？

贬低一个功能意味着我们告诉用户他们不应该再使用这个功能，因为它将在未来的某个时候消失。

我们应该问自己什么问题？

说到弃用，技术人员通常会考虑实现细节。

“如何在 GraphQL 中将我的字段标记为不推荐使用？”

“我的 REST 端点是否有一个弃用标头？”

虽然这些问题的答案带来了很好的沟通工具，使我们能够防止 API 的新用户使用这些不推荐的功能，但更大的问题是现有用户会发生什么。

他们甚至会检查 API 中的弃用消息吗？

问题往往是这样的措施会导致沟通不足。_“我们宣布了一个新的主要版本，并将一些端点标记为不推荐使用，每个人都知道会发生这种情况，所以这应该足够了。”

所以这些是更重要的问题:

• 谁在使用该功能？
• 我们保持特色有多难？
• 我们的客户愿意花多少钱来保存它？
• 如果我们保留它，而不是扔掉它，对我们的影响有多大？
• 我们希望以多快的速度移除该特征？
• 我们的客户需要多少时间来适应这些变化？

谁会受到贬值的影响？

对贬值的影响有个感觉是很重要的。实现这一目标的一个方法是尽快把消息传出去。

写电子邮件、博客文章、GitHub 问题和推文，看看我们的用户怎么想。我们应该与我们的用户保持持续的对话，但是当它可能导致沮丧时，它就特别重要。

另一种方法是使用像 Moesif 这样的 API 分析服务来找出这些特性的使用量。

我们来看下面这个 Moesif API Analytics 的截图:

这里我们看到了 API 端点的堆叠条形图。每种颜色代表一家使用我们 API 的公司，其大小显示了该公司在过去 28 天内向该端点发送的请求数。我们一眼就能看出哪些是关键的 API 端点，谁在使用它们。

如果我们想弃用/reviews/reviews端点，我们会发现只有一家公司使用它，我们可以直接与他们讨论我们的弃用想法。

通常不赞成某个功能的主要原因之一是没有人使用它，所以这甚至可以是询问用户想法的第一步。

在贬低之前先和受影响的人谈谈

接下来，我们应该向受影响的人伸出援手。我们有分析数据，可以直接与使用这些功能的人交谈，如果我们在社交媒体上宣布了一项弃用计划，那么目前没有使用该功能的人可能会说出来，因为他们计划在未来使用它。

也可能是潜在客户说这个特性对于他们首先考虑我们的 API 是必不可少的。

收集了用户的输入后，可以结合公司内部需求来计划折旧。

宣布反对

下一步是通知用户弃用正在发生。

对于许多公司来说，这是第一步，他们写了一篇博客文章，希望每个受影响的人都会阅读，但这还不够！

如果我们使用 Moesif API analytics ，我们可以检查谁在使用我们想要弃用的特性。通常，我们有与我们的用户或公司帐户相关联的电子邮件地址，所以我们可以直接向功能用户发送邮件，这可能是最直接的方式。

写博客文章，发微博，制造 GitHub 问题，给所有用户发邮件都没有错，因为这向你的用户表明了你的关心。

然后，我们可以使用我们的 API 类型给出的技术来最终将这些特性标记为不推荐使用。

还有:别忘了更新文档！

用限电唤醒其他人

传达反对意见的最后一种方式是限制用电。

我们写了电子邮件，在社交媒体上宣布，并最终将我们的端点和字段标记为不推荐使用。

但是，如果我们有几千个用户，总会有一些用户将我们过滤为垃圾邮件，不会在社交媒体上关注我们，也不会检查 API 是否会返回反对警告。

为了唤醒他们，我们可以使用一种叫做断电的技术。它的工作原理如下:

我们检查不推荐使用的特性使用率低的时段。在此期间，我们会根据使用频率禁用这些功能几个小时或几分钟，然后再重新打开。

这可以在最终关闭该功能之前的一两个月完成，并导致对用户的监控出现峰值。

让阅读我们电子邮件和社交媒体的用户了解这一点也很重要，这样我们就不会被他们关心的信息所淹没。

结论

始终保持对话畅通无阻！

如果我们与人交谈，他们也会把我们看作人，而不仅仅是不知名的公司，即使他们的观点与我们不同。

对我们周围发生的事情和我们的 API 有一种感觉是很重要的。

API 第一产品经理的流行 API 工具和 API 指标

原文：https://www.moesif.com/blog/api-product-management/api-metrics/API-First-Product-Managers-Popular-API-Tools-and-API-Metrics/

我们采访了位于旧金山的一些较大的 API 优先公司的产品经理。这些公司都是上市公司，在 TTM 的收入超过 1 亿美元，涉及计费、安全、通信和工作流程自动化等领域。

项目经理被问及他们最喜欢的工具和最关心的 T2 API 标准。在可能的情况下，我们确定了所有细分市场通用的工具和指标，排除了当您的客户数量达到 1，000 时您可能会遇到的(许多)边缘情况。

毫不奇怪，我们的答案被很好地分成了三个经典领域:采用、参与和保留。在深入这些领域之前，我们需要将数据纳入我们的分析生态系统。

开始是艰难的——大量的数据

最一致的一点是，分析数十亿个 API 调用所需的存储和数据处理是巨大的。数据湖通常会变得非常大，以至于追溯分析不得不局限于几天，甚至是最后几个小时。

在许多情况下，公司采取的第一步是将非结构化 API 数据，或其 syslog 的整个原始转储，转储到亚马逊红移或 T2 Splunk 的数据湖中。从那里，数据基础设施团队取出 PM 感兴趣的 syslog 事件，并将它们传递到数据仓库，通常在雪花中，在那里更容易查询。在这里，度量标准的实际处理和汇总通常在商业智能团队、项目经理甚至工程师的主持下进行。

采用:工具和指标

对于我们采访的大多数 api 优先的公司来说，PMs 追踪的第一个，也可以说是最重要的指标之一，是开发者激活。一般来说，产品采用的步骤很简单:

• 注册一个账户
• 第一次 API 调用
• 部署有效的 API

我们的 API 优先公司使用一个 Tableau 或 Looker 仪表盘，显示有多少人注册，有多少人注册，有多少人登录，有多少人登录，有多少人创建了一个应用，以及这些应用中有多少新的 API 令牌。

主要是 pm 的 okr 致力于提高开发者激活率并确保激活的时间减少。由于开发人员可能会在单个漏斗阶段停留数天或更长时间，因此跟踪每一步的转化率以及到达下一步所需的时间非常重要。

如果正常的销售周期是 90 天，项目经理喜欢查看四分位数:第 50 个四分位数在做什么，第 75 个四分位数在做什么，然后他们使用这个作为代理来确定他们的 SDK 和文档有多有用。

一旦 API 被采用，项目经理希望看到使用量的增加导致付费计划，突出流行的端点和识别缺失功能的能力。在这一阶段，客户的购买行为根据其公司规模分为两类:大型企业或中小型企业/初创企业。

项目:企业客户工具和指标

在很大程度上，大多数开发人员被他们的领导要求评估 API 产品的可能性。他们创建了一个开发者组织，尝试所有的功能。然后，当他们的公司决定在虚线上签名时，他们实际上最终提供了一个单独的帐户。开发人员组织到付费人员的映射，以及在 Salesforce 中绑定收入帐户，并不总是非常清晰。因此，项目经理有时并不试图解决映射问题，而是关注更多的采用，因为采用是客户是否会使用产品的一个很好的代理。

按采集通道划分的 API 令牌

大多数公司认为在面向用户的控制台中跟踪活动有助于提高使用率和参与度。当客户注册、配置帐户、管理可用的 API 或打开和关闭功能时，他们需要通过管理 web 界面。如果您的 API 监控工具不是以用户为中心的(即，它没有能力深入到 API 调用并识别它属于哪个用户和公司)，那么项目经理必须部署分析工具，如 Heap 或 Google Analytics 360 。然后，这些工具被配置为将 web 界面上的用户与其组织中的其他人可能正在进行的 API 调用相关联。

然后项目经理可以跟踪营销渠道归属到各自的谷歌或脸书广告。他们可以跟踪从账户创建，到客户何时转换为付费计划，以及他们何时开始进行 API 调用。

在像 Moesif 这样以用户为中心的工具中，UTM 参数的监控方式与 HTTP 状态响应代码一样有效。这使得可以按 UTM 来源或 UTM 营销活动对 API 令牌进行分组，从而更好地了解哪些营销渠道有助于参与。

每周活动 API 令牌

给定一周内访问 API 的不同令牌的数量，即周活跃令牌 (WAT)，是 pm 用来跟踪其产品的最佳北极星指标之一。与正常运行时间、SLO 或每分钟请求数等与工程目标相一致的基础设施指标不同，WAT 直接与推动采用和增加参与的业务目标相一致。为了计算 WAT，数据基础架构团队需要从 Redshift 中提取相关的系统日志事件，并将其传递给 Snowflake。到了那里，BI 团队编写 SQL 查询并在 Tableau 中可视化。

由于一个开发者账户可以创建多个 API 令牌，比如针对沙盒和生产环境，所以更准确的衡量标准应该是周活跃用户或周活跃公司。但是，这需要能够将 API 令牌链接到相应用户或公司帐户的分析基础架构。

用户数量

“让邀请他人变得容易”

一些项目经理发现账户转换和用户数量之间有直接的关系。更多的用户通常意味着客户对项目更加认真。因此，PMs 努力邀请其他人加入注册流程，比如说“邀请其他人参与这个项目来帮助你完成工作。”通常，一个额外的好处是，这是另一个从用户那里获得公司电子邮件的机会，因为邀请者可能不知道被邀请者的 Gmail，但会知道他们的工作电子邮件。

项目:中小型企业/初创企业自助服务客户

在自助购买活动中，客户是一名独立的开发人员，在一家 5 人或 10 人的初创企业或中小型企业中，他只需放入 CTOs 信用卡，就可以立即开始使用付费服务。

除了项目经理为企业客户所做的工作之外，很难从这个群体中获得更多的见解，因为大多数开发人员都非常喜欢自助服务路线。

“这不是一个绝对的说法，但在大多数情况下，开发人员不想与你交谈，他们不愿意与销售人员交谈，他们也不想回复电子邮件。事实上，他们经常用私人邮件注册，试图隐藏他们在为谁工作。

然而，通过查看开发人员在产品中使用了什么，他们点击了什么，他们进行了哪些 API 调用，以及他们在 GitHub 中的 API SDK 中的使用统计数据，可以在一定程度上收集到开发人员情绪的代理。

保留

一旦项目经理对采用和参与有了很好的理解，他们就会关注 API 产品保留，以找到需要改进的地方。产品留存是一个源自收入留存的概念，需要通过注册日期等方式将用户群分成不同的群组。项目经理会跟踪每个团队返回并参与您的平台的百分比。在下面的示例中，API 保留按用户的 SDK 分组。您可以看到 PHP 的保留百分比远低于其他 SDK，这意味着 PHP 有问题，或者它有需要修复的性能问题。

另一种确定增加或减少哪些产品功能的方法是查看计费 SKU。许多 API 被划分为一组 SKU，每个不同的活动类型都分配有自己的单个 SKU。通过查看谁为什么付费，就有可能识别出哪些正在被使用，哪些没有被使用。

设置指标跟踪是一项艰巨的任务

从项目经理的角度来看，监控商业智能的速度肯定是个问题。

一位不满的总理说:“在提出新指标的请求后，从另一端得到统计数据需要太长的时间。”

设置指标跟踪需要五个步骤。它包括向独立的 BI 团队提出请求，然后他们必须对请求进行筛选，然后将请求提交进来，这通常涉及谈判和政治。代表性的步骤包括:1)所讨论的数据有事件吗？2)如果答案是肯定的，那么它在数据仓库中吗？如果答案是否定的，那么数据基础架构团队中的某个人需要创建一个新的 syslog 事件，然后将其引入。3)创建如何在 Tableau 中显示指标的要求或更改报告。4)BI 数据团队必须执行请求。5)如果 BI 因为太忙或超出他们的能力而无法将其可视化，则 PM 将不得不要求工程部门对数据库本身进行自定义 SQL 查询。

Moesif 以用户为中心的敏捷报告

“项目经理永远不会拒绝更具可操作性或更灵活的报告工具集，”项目经理在一家安全领域的领先公司说道。

在我们采访的许多公司中，他们从零开始组建 DevEx 团队，只是采用 BI 团队正在使用的任何工具。构建数据仓库的定制查询是因为没有现成的选项。但是从那以后，工具已经有了很大的进步。

如今，像 Moesif 这样的 API 分析工具帮助 API 驱动的组织中的每个人从他们的 API 数据中学习，并做出更明智的决策来推动增长。

我们正处于这样一个阶段，API 优先公司的产品经理认识到，好的工具可以让他们对开发人员的成功有独特的见解，并且对公司的成功来说，与可靠的 SDK 或完整的文档一样重要。

API 管理 vs API 网关，API 分析和监控适合哪里？

原文：https://www.moesif.com/blog/technical/api-tools/API-Management-vs-API-Gateway-and-where-does-API-Analytics-and-Monitoring-fit/

在过去的几年里，API 驱动的业务出现了爆炸式增长。有创收的 API，开发者平台，合作伙伴市场，甚至内部 API 支持单页应用。

随着这种爆炸，API 工具也有了很大的增长，以帮助这些公司尽快将其 API 平台推向市场，并在任何竞争中胜出。工具的增加很大程度上反映了我们在移动时代看到的情况。然而，随着这种爆炸式增长，现在有越来越多的工具和解决方案来构建和发展 API 和平台。

此外，像 API 网关这样的工具既可以用作面向公众的 API 的代理，也可以表现得像在各种内部服务之间编排的服务网格。本指南旨在提供各种 API 工具的概述。

api 网关

API 网关是位于 API 前面的 HTTP 服务器/代理服务器，它提供了管理、路由和保护 API 和服务的中心位置。API 网关应该部署在集群中，这样您就可以通过添加更多的机器来水平扩展系统，并确保高可用性。API 网关通常是内部设备，但现代的网关通常基于开源或开放核心模型。比如 Kong 基于 NGINX，Express Gateway 基于 Node.js Express。

还有来自云供应商的专有的基于云的解决方案，如 AWS API Gateway 和 Azure API Management。通常，API 网关会执行以下操作:

认证和速率限制

部署 API 网关的主要目的是提供一种安全的方法来访问您的 API 并防止恶意活动。如果您的 API 需要认证，API 网关提供了一种简单的方法来为每个消费者生成和管理 API 密钥。没有正确凭证访问您的 API 的客户端将获得一个401 Unauthorized。为了确保公平性，可以实施诸如速率限制之类的安全策略，例如每个 API 密钥每分钟 100 个请求的限制。可以基于 API 密钥、通过 IP 地址(如果没有添加身份验证层)或其他自定义策略来实施速率限制。您甚至可以包括额外的安全策略，如 bot 检测，并防止 HTTP 负载过大。

缓存和 CORS 策略

缓存使您的 API 平台能够处理更多的客户端并吸收高峰流量。某些类型的内容(如电子商务和旅游)可以从缓存中受益匪浅。银行和金融服务等其他行业可能无法从缓存中受益，因此您需要进行成本效益分析，看缓存对您的应用程序是否有意义。可以实施诸如 CORS(跨源资源共享)之类的其他策略，以允许从 web 浏览器访问 API。

数据验证和转换

API 网关提供了一种向 API 添加数据转换规则的中央机制。数据转换可以是简单的 URL 重写，如从 api.example.com/search 到 search.example.com，也可以是更复杂的转换规则，如从 XML 到 JSON 的转换。如果您已经有了许多想要作为 API 公开的遗留内部服务，即使遗留服务使用的是更老的内容格式，比如 XML 而不是 JSON，这也是很方便的。

除了数据转换，一些 API 网关还可以结合 end 来避免 API 链接。这使您的客户能够利用像GET /user/me这样的单一公共端点，即使它必须从各种内部服务中获取，如您的身份验证服务、用户服务和计费服务。来自这些内部服务的响应被组合成一个响应返回给客户端。这使得客户更容易使用您的 API，因为他们不必执行 API 链接。一个极端的例子是 Apollo GraphQL，它可以从许多服务中获取许多实体，并将它们组合成一个端点POST /graphql

API Canary 发布/版本控制

与数据转换类似，使用 API 网关，您可以利用 API 网关将用户路由到您的服务的特定版本。这可以通过头字段、路径段如/v1或/v2来完成，甚至可以处理复杂的 canary 发布，其中一定比例的用户流量被路由到新版本。随着您对该版本信心的增加，用户点击更新 API 版本的比率会慢慢增加。通过执行逐步过渡，您可以最小化新的 API 版本由于功能或性能问题而成为系统范围中断的风险。

API 分析

一旦你投资了你的 API 平台，你会希望通过构建一个客户实际采用的、没有 bug 的 API 平台来确保你的投资得到回报。像 Moesif 这样的 API 分析解决方案通过为您提供创造产品销售线索增长所需的必要可见性和报告来补充您的 API 网关。这包括你的客户如何使用你的 API，他们是谁，以及哪些营销渠道引导他们进行整合。除了报告之外，API analytics 通常还包括实时监控功能，因此当问题发生时，您可以保持警惕。

虽然 API 管理和 API 网关解决方案是为基础设施和站点可靠性工程而设计的，但 API 分析通常面向更广泛的技术和非技术用户，包括产品、工程和支持。正因为如此，像 Moesif 这样的 API 分析供应商更有可能采用 SaaS 管理解决方案，而不是本地解决方案，但也可以是本土解决方案。查看我们的指南，了解何时构建和购买 API 分析解决方案。

API 产品分析

产品分析使您能够跟踪和了解关键 API 指标，如您的 API DAU(每日活跃用户数)、您的顶级客户正在使用的终端以及关键终端的 90%延迟。一些 API 分析工具提供了更复杂的分析，如群组保持分析和漏斗分析，因此您可以跟踪 KPI，如首次 Hello World 的平均时间(TTF HW)和转换率，从而了解您的产品的吸引力和粘性。

TTFHW 测量从第一次访问您的登录页面到通过您的 API 平台进行第一笔交易的 MVP 集成需要多长时间。这是一个跨职能的指标，跟踪市场营销、文档和教程，直到 API 本身。

API 日志记录/调试

除了衡量产品指标，如保留和参与度，API 分析还提供了一种简单的方法来加快调查和调试 API 功能和性能 API 问题。高基数日志分析使您能够使用热图、时间序列、瀑布图和其他图表绘制趋势。一些 API 分析还实时记录完整的 API 调用，因此您可以检查请求和响应头和主体，进行比较，甚至重放失败的事务并生成测试。

API 监控

许多 API 分析工具还提供 API 监控和警报功能，因此当 API 关闭或运行不正常时，您可以得到通知。与简单运行状况探测的综合监控不同， API 真实用户监控根据历史趋势，从您的客户的实际 API 流量中检测异常行为。API 问题可能与业务相关，如关键客户的 API 活动意外减少，也可能与工程相关，如功能或性能问题。具体来说，API 分析侧重于几个关键支柱:

团队仪表板

一些 API 分析解决方案提供了一种与技术和非技术团队成员共享和协作仪表板的方式，或者自动沙箱化使用数据，以便您可以以安全的方式直接与外部合作伙伴共享仪表板。通过在面向客户的门户中嵌入 API 调试日志和计划使用信息，客户可以解决问题，而不会让已经不堪重负的支持团队不堪重负。

用户和/或公司角色

API 分析工具从您的 CRM、BI 和支持工具中提取数据。这使您的客户成功和支持团队能够通过客户的电子邮件或名称来查找客户的 API 活动，从而快速解决集成问题。用户和公司级别的信息也使您的公司能够集中跟踪各种潜在客户和客户如何集成和坚持使用您的 API。

API 管理

虽然 API 网关和 API 管理可以互换使用，但严格来说，API 网关指的是单独的代理服务器，而 API 管理指的是在生产中管理 API 的整体解决方案，其中包括一组在集群中运行的 API 网关、一个管理 UI，甚至可能包括其他项目，如供客户注册和生成新 API 密钥的开发人员门户。

管理面板支持几件事情:

1. 能够添加和删除插件，如安全
2. 一种编辑和可视化数据转换(如 XML 到 JSON)的方法
3. 上传和管理 SSL 证书

结束语

由于最近新的商业模型和 API 策略的增长，API 领域发生了很多工具改进。更多信息可以在我们的构建 API 指南和API 分析指南中找到。

每个平台团队都应该跟踪的 13 个 API 指标

原文：https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/

识别关键 API 指标

当涉及到 API 时，每个团队都需要跟踪不同的 KPI。对基础设施团队来说重要的 API 度量将不同于对 API 产品或 API 平台团队来说重要的 API 度量。度量标准也可以依赖于 API 在产品生命周期中的位置。最近发布的一个 API 将更加关注改进设计和使用，同时牺牲可靠性和向后兼容性。维护已被企业团队广泛采用的 API 的团队可能会更关注推动每个客户采用额外的功能，并优先考虑可靠性和向后兼容性，而不是设计。

一般来说，有三到四个团队关心 API 度量

基础设施/开发运营

确保服务器正在运行，有限的资源得到正确分配，可能需要多个工程团队。

应用工程/平台

API 开发人员负责向 API 添加新功能，同时调试 API 业务逻辑中的应用程序特定问题。这些产品可以是 API 即服务、面向合作伙伴的插件和集成、集成到更大产品中的 API，或者其他东西。

产品管理

API 产品经理负责规划 API 特性，确保构建正确的 API 端点，并利用工程时间和个人限制平衡客户(无论是内部还是外部)的需求。

业务/增长

面向业务的团队(如营销和销售)不会考虑 API 端点，相反，他们最感兴趣的是客户采用，确保他们成功地使用 API，他们来自哪里，以及看到哪些用户可能是新的销售机会。

基础设施 API 指标

这些指标中有许多是应用性能监控(APM)工具和基础设施监控公司(如 Datadog)关注的焦点。

1:正常运行时间

虽然最基本的指标之一，正常运行时间或可用性是衡量服务可用性的黄金标准。许多企业协议包括 SLA(服务水平协议)，正常运行时间通常包含在其中。很多时候，你会听到“三个 9”或“四个 9”这样的术语，这是一种衡量每年正常运行时间与停机时间的方法。

可用性%	每年停机时间
99%(“两个九”)	3.65 天
99.9%(“三个九”)	8.77 小时
99.99%(“四个九”)	52.60 分钟
99.999%(“五个九”)	5.26 分钟

当然，从四个 9 到五个 9 远比从两个 9 到三个 9 难，这就是为什么除了最关键的(也是最昂贵的)服务之外，你不会看到五个 9。也就是说，某些服务实际上可以有更短的正常运行时间，同时确保在不影响您的服务的情况下优雅地处理中断。例如，Moesif 的设计使得它可以继续从我们的 SDK 收集数据，即使在网站和仪表板完全中断的情况下。即使在我们的收集网络崩溃的最坏情况下，SDK 也会在本地排队，不会导致应用程序中断。

正常运行时间通常通过 ping 服务或综合测试来衡量，如通过 Pingdom 或 UptimeRobot 。您可以将探测器配置为以固定的时间间隔(如每分钟)运行，以探测特定的端点，如/health或/status。此端点应该具有基本的连接性测试，例如到任何后备数据存储或其他服务的连接性测试。

这些指标可以使用像 Statuspage.io 这样的工具发布在你的网站上。事实上，Moesif 使用了一个基于 Lambda 的开源状态页面。

还有更复杂的 ping 服务，称为合成测试，可以执行更复杂的测试设置，如运行特定序列并断言响应有效负载具有某个值。请记住，虽然合成测试可能不代表真实世界的客户流量。您可以在保持高正常运行时间的同时拥有一个有缺陷的 API。

什么是合成监听？顾名思义，它是一组预定义的 API 调用，服务器(通常由监控服务的提供者之一)触发这些调用来调用您的服务。虽然这并不能反映用户的真实体验，但是按照预期查看这些 API 的顺序是很有用的。

2: CPU 使用率

CPU 使用率是最经典的性能指标之一，可以代表应用程序的响应能力。高服务器 CPU 使用率可能意味着服务器或虚拟机超额订阅和过载，也可能意味着您的应用程序中存在性能缺陷，如太多自旋锁。基础设施工程师使用 CPU 使用率(以及它的姐妹指标，内存百分比)来进行资源规划和衡量整体运行状况。某些类型的应用，如高带宽代理服务和 API 网关，自然比其他指标具有更高的 CPU 使用率，以及涉及大量浮点数学的工作负载，如视频编码和机器学习工作负载。

当您在本地调试 API 时，您可以通过 Windows 上的任务管理器(或 Mac 上的活动监视器)轻松查看系统和进程的 CPU 使用情况。但是在服务器上，你可能不希望运行top命令。这就是各种 APM 提供商可以发挥作用的地方。APM 包括一个代理，您可以将它嵌入到您的应用程序中或服务器上，该代理可以捕获 CPU 和内存使用等指标。它还可以执行其他特定于应用程序的监控，如线程分析。

在查看 CPU 使用率时，重要的是查看每个虚拟 CPU(即物理线程)的使用率。不平衡的使用可能意味着应用程序没有正确线程化或者线程池大小不正确。

许多 APM 提供程序允许您用多个名称标记应用程序，以便您可以执行汇总。例如，您可能希望对每个虚拟机指标进行细分，如 my-api-westus-vm0 、 my-api-westus-vm1 、 my-api-eastus-vm0 等，同时将这些指标汇总到一个名为 my-api 的应用中。

3:内存使用

与 CPU 使用率一样，内存使用率也是衡量资源利用率的一个很好的指标，因为 CPU 和内存容量是物理资源，不像指标那样更依赖于配置。内存使用率极低的虚拟机可以缩小规模，或者为其分配额外的服务来消耗额外的内存。另一方面，高内存使用率可能表明服务器超载。传统上，大数据查询/流处理和生产数据库比 CPU 消耗更多内存。事实上，每个虚拟机的内存大小是一个很好的指标，可以用来衡量批量查询需要多长时间，因为更多的可用内存可以减少检查点、网络同步和磁盘分页。在查看内存使用情况时，您还应该查看页面错误和 I/O 操作的数量。一个容易犯的错误是，应用程序被配置为最多只分配一小部分可用物理内存，这可能导致人为的高页面虚拟内存抖动。

应用程序 API 指标

4:每分钟请求数(RPM)

RPM(每分钟请求数)是比较 HTTP 或数据库服务器时经常使用的性能指标。通常，您的端到端 RPM 会比宣传的 RPM 低得多，这更像是一个简单的“Hello World”API 的上限。因为服务器不会考虑对数据库、第三方服务等进行 I/O 操作所产生的延迟。虽然有些人喜欢吹嘘他们的高 RPM，但工程团队的目标应该是效率，并试图降低这一点。某些需要许多 API 调用的业务功能可以合并到较少数量的 API 调用中，以减少这个数量。像在一个请求中批量处理多个请求这样的常见模式非常有用，可以确保您拥有灵活的分页模式。

您的 RPM 可能会根据一周中的某一天甚至每天的某个小时而有所不同，尤其是如果您的 API 适用于其他在夜间和周末使用率较低的业务。RPM 还有其他相关术语，如 RPS(每秒请求数)和 QPS(每秒查询数)。

5:平均和最大延迟

跟踪客户体验的最重要的指标之一是 API 延迟或运行时间。虽然基础设施级别指标(如 CPU 使用率)的增加可能实际上并不对应于用户感知的响应速度的下降，但 API 延迟肯定会。跟踪延迟本身可能无法让您完全了解延迟增加的原因。重要的是跟踪 API 的任何变化，比如发布新的 API 版本、添加新的端点、模式变化等等，以找到延迟增加的根本原因。

因为当只查看总延迟时，有问题的慢速端点可能会被隐藏，所以按路线、地理位置和其他领域查看延迟细分非常重要。例如，您可能有一个POST /checkout端点，其延迟随着时间的推移而缓慢增加，这可能是由于没有正确索引的 SQL 表大小不断增加。然而，由于对POST /checkout的调用量很低，这个问题被您的GET /items端点掩盖了，它被调用的次数远远多于结账端点。类似地，如果您有一个 GraphQL API，您会希望查看每个 GraphQL 操作的平均延迟。

我们将延迟归入应用程序/工程，尽管许多开发人员/基础架构团队也会考虑延迟。通常，基础架构人员会查看一组虚拟机的总延迟，以确保虚拟机不会过载，但他们不会深入了解特定于应用程序的指标，如每条路由。

6:每分钟错误数

与 RPM 类似，Errors per Minute(或 error rate)是每分钟调用非 200 系列状态代码的 API 的次数，对于衡量 API 的错误和易错程度至关重要。为了跟踪每分钟的错误，了解发生了什么类型的错误很重要。500 个错误可能意味着您的代码发生了不好的事情，而许多 400 个错误可能意味着来自设计或记录不良的 API 的用户错误。这意味着在设计你的 API 时，使用合适的 HTTP 状态码是很重要的。

您可以进一步深入查看这些错误的来源。来自一个特定地理区域的许多 401 未授权错误可能意味着僵尸程序正试图入侵您的 API。

API 产品指标

API 不再仅仅是一个与微服务和 SOA 相关联的工程术语。API 作为一种产品正变得越来越普遍，尤其是在那些希望在与新合作伙伴和收入渠道的竞争中胜出的 B2B 公司中。API 驱动的公司需要看到的不仅仅是错误和延迟等工程指标，以了解他们的 API 是如何使用的(或者为什么他们没有像计划的那样快被采用)。确保构建正确功能的角色在于 API 产品经理，这是许多 B2B 公司争相填补的新角色。

7: API 使用增长

对于许多产品经理来说，API 使用(以及独特的消费者)是衡量 API 采用的黄金标准。一个 API 不应该只是没有错误，而是应该逐月增长。与每分钟的请求不同，API 使用应该以更长的时间间隔(如几天或几个月)来衡量，以了解真实的趋势。如果衡量月环比 API 增长，我们建议选择 28 天，因为这可以消除周末与工作日使用量以及每月天数差异造成的任何偏差。例如，二月可能只有 28 天，而前一个月有整整 31 天，导致二月看起来使用率较低。

8:独特的 API 消费者

因为一个月的 API 使用量的增加可能只归因于一个客户账户，所以衡量 API DAU (每月活跃用户)或API的唯一消费者是很重要的。这一指标可以为您提供新客户获取和增长的总体状况。许多 API 平台团队将 API MAU 与他们的 web MAU 相关联，以获得完整的产品健康状况。如果 web MAU 的增长速度远远超过 API MAU，那么这可能意味着在新解决方案的集成或实施过程中存在漏洞。当公司的核心产品是 API 时尤其如此，比如许多 B2B/SaaS 公司。另一方面，API MAU 可以与 API 使用相关联，以了解增加的 API 使用来自哪里(新客户与现有客户)。

像 Moesif 这样的工具可以跟踪个人用户和 API，还可以将他们与 T2 公司或 T4 组织联系起来。

9:按 API 使用情况列出的顶级客户

对于任何专注于 B2B 的公司来说，跟踪顶级 API 消费者可以给你带来巨大的优势，让你了解你的 API 是如何使用的，以及哪里有追加销售的机会。许多有经验的产品领导者都知道，许多产品表现出幂律动力学，少数超级用户的使用量与其他人相比不成比例。毫不奇怪，这些超级用户通常会给你的公司带来最多的收入和有机推荐。

这意味着跟踪你的前 10 个客户实际上在用你的 API 做什么是很重要的。您可以根据他们呼叫的端点以及呼叫方式进一步细分。他们是否比非高级用户更多地使用特定的端点？也许他们在你的 API 中找到了他们的啊哈时刻。

10:原料药保留

你应该在你的产品和工程上花更多的钱，还是应该在增长上投入更多的钱？留存和流失(留存的反义词)可以告诉你走哪条路。与存在流失问题的产品相比，具有高产品保留率的产品更接近产品市场契合度。与订阅保留不同，产品保留跟踪产品(如 API)的实际使用情况。虽然这两者是相关的，但它们并不相同。一般来说，产品流失是订阅流失的主要指标，因为没有发现 API 价值的客户可能会被年度合同所困，而不会积极使用 API。API 留存率应该高于 web 留存率，因为 web 留存率将包括已经登录但还没有必要集成平台的客户。而 API 保留着眼于集成后的客户。

11:第一个 Hello World 时间(TTFHW)

TTFHW 是一个重要的 KPI，不仅用于跟踪您的 API 产品健康状况，还用于跟踪您的整体开发者体验，也称为 DX 。特别是如果你的 API 是一个吸引第三方开发者和合作伙伴的开放平台，你要确保他们能够尽快启动并运行他们的第一个啊哈时刻。TTFHW 测量从第一次访问您的登录页面到通过您的 API 平台进行第一笔交易的 MVP 集成需要多长时间。这是一个跨职能的指标，跟踪市场营销、文档和教程，直到 API 本身。

12:每个业务事务的 API 调用

虽然对于许多产品和业务指标来说，越多越好，但保持每次业务交易的通话次数尽可能低是很重要的。这个指标直接反映了 API 的设计。如果一个新客户必须进行 3 次不同的调用并将数据拼凑在一起，这可能意味着 API 没有正确的端点可用。当设计一个 API 时，重要的是要从业务交易或者客户想要达到的目标的角度来考虑，而不仅仅是特性和端点。这也可能意味着当涉及到过滤和分页时，你的 API 不够灵活。。

13: SDK 和版本采用

许多 API 平台团队可能也有一堆他们维护的 SDK 和集成。与只有 iOS 和 Android 作为核心移动操作系统的移动设备不同，你可能有 10 个甚至数百个 SDK。在推出新功能时，这可能会成为维护的噩梦。您可以有选择地向最受欢迎的 SDK 推出关键功能，而向不太受欢迎的 SDK 推出不太重要的功能。当涉及到贬低某些端点和特性时，测量 API 或 SDK 版本也很重要。在没有咨询他们为什么要使用的情况下，您不会想要贬低您的最高付费客户正在使用的终端。

业务/增长

业务/增长指标可以类似于产品指标，但侧重于收入、采用和客户成功。例如，您可能不想按 API 使用情况查看前 10 名客户，而是想按收入查看前 10 名客户，然后按他们的端点使用情况查看。为了跟踪业务增长，像 Moesif 这样的分析工具支持使用来自 CRM 或其他分析服务的客户数据来丰富用户资料，以便更好地了解谁是 API 用户。

结论:

对于任何构建和使用 API 的人来说，跟踪正确的 API 度量标准是至关重要的。如果没有正确的工程和产品工具，大多数公司不会推出新的网络或移动产品。类似地，如果没有检测和跟踪正确的 API 指标的方法，您也不会想要启动一个新的 API。有时一个团队的 KPI 可以融入到另一个团队中，就像我们在 API 使用度量中看到的那样。对于同一个基本指标，可以有不同的看法。然而，团队应该专注于为他们的团队寻找正确的度量标准。例如，产品经理不应该担心 CPU 的使用，就像基础设施团队不应该担心 API 的保留一样。像 Moesif API Analytics 这样的工具可以帮助您通过快速安装 SDK 来开始测量这些指标。

要了解更多 API 分析，请参阅本系列的第 1 章:掌握 API 分析——开发者漏斗

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

API 代理 vs API 网关:有什么区别，应该用哪个？

原文：https://www.moesif.com/blog/technical/api-gateways/API-Proxy-Vs-API-Gateway-What-Are-The-Differences-And-Which-Should-You-Use/

在本文中，我们将从较高的层面来看 API 代理和 API 网关之间的区别。当开发人员发布一个公共 API 时，该 API 有必要拥有安全策略和对 API 消费者隐藏后端逻辑的方法。

将 API 从后端服务中分离出来，可以让你的应用免受后端代码更改的影响，并允许用户调用你的 API 而不用担心可用性。如果对某个端点进行了更改，或者发布了新版本，用户可以继续工作而不会中断。此外，API 代理或 API 网关可以帮助您轻松、统一地保护 API 端点。这可以增加另一层防御，防止攻击者渗透到您的系统中。

尽管 API 代理和网关有一些相似之处，但它们的不同之处正是它们的不同之处。让我们来看看这两种解决方案之间的区别，并确定哪一种最适合您的用例。

API 代理

API 代理是位于前端和后端服务之间的接口。这种抽象有助于进一步将前端与后端的实现细节分离开来。代理将公开一个 URL，您的前端将使用它来访问 API。当请求到达代理时，代理将这个请求路由到配置好的 API 端点，响应返回给代理，然后代理将响应返回给调用者。

API 代理的工作方式类似于 API 网关，它可以处理数据转换、安全性和路由。当您定义代理时，您可以向代理下的不同 API 添加传输安全性、监控(SLA、性能)、配额和访问级别。

许多企业拥有由多个应用程序公开的现有服务，并且这些应用程序可能是全球分布的，这使得 API 管理和可靠性变得困难。对于构建一个基本 API 并希望对其应用一些基本安全策略的人来说，API 代理可能是一个很好的解决方案。然而，在规模上，为了满足真正的企业 API 需求，您将需要一个 API 网关。

API 网关

API 网关可以为开发人员提供比 API 代理更多的定制，比如为您的有效负载增加端到端的安全性。API 网关处理认证、授权、拒绝服务攻击、SQL 注入检查、负载平衡、缓存、请求整形、编排、中介和传输安全。一些 API 网关甚至允许用户从现有服务创建全新的端点，或者创建仅在网关上运行的虚拟端点，而没有任何后端。如您所见，API 网关提供了 API 代理的所有特性，甚至更多。

作为开发人员，API 网关可以节省您的开发时间，因为您可以专注于构建应用程序逻辑。这为开发人员提供了一个优势，使他们不必担心通过 API 网关直接在 API 代码中构建特性，如安全性和缓存。能够利用 API gateway 的核心基础设施允许您快速创新和快速原型化。

API 网关提供了比 API 代理丰富得多的功能。您可以使用 API 网关通过将多个现有服务组合在一起来构建 API，这是 API 代理无法做到的。一个设计良好的网关将根据其使用方式自动优化其配置；它应该是轻量级的，并提供卓越的性能。要了解更多关于可靠的 API 网关的信息，以及 API 网关的好处，查看我们的文章。

API 监控

无论您决定使用 API 网关还是 API 代理，API 监控都是一个重要的工具，开发人员需要使用它来确保他们的 API 的可靠性。API 监控允许开发人员查看实时数据，包括错误、异常和其他关键事件。此外，开发人员可以配置 API 事务性数据的日志记录，并分析 API 使用情况以获得见解和趋势。此外，API 监控可以自动生成报告，并帮助您的企业为产品经理和销售人员创建整体的 KPI 和指标数据。

使用 Moesif ，您可以监控端到端的用户体验，包括您的所有 API 和前端事件。您可以自动获得关于 API 性能问题的实时警报，或者根据用户的行为自动发送电子邮件。Moesif 已经作为一个插件与开发人员可用的大多数 API 网关集成在一起，这就是为什么您应该考虑将 Moesif 用于定制 API 监控解决方案。如果你正在使用 Kong，Moesif 已经是一个顶级的社区插件，你可以通过访问此链接了解更多信息并与之集成。你也可以通过使用我们的 SDK之一将 Moesif 直接插入你的 API 代码。

应该选择 API 代理还是 API 网关？

一个设计良好的 API 网关将充当一个代理，允许您打开或关闭某些与应用程序需求无关的功能。每个企业都是不同的，因此需要一个可定制的 API 网关来定制您的 API 体验，以适应您想要的用例。一旦你选择了你的 API 平台，你将希望确保你的 API 按照预期的方式运行。实施一个轻量级的分析解决方案，如 Moesif 通过为您提供可见性和报告来补充您的 API 网关。我们建议开发人员使用 API 网关，这样他们可以从解耦、减少往返、安全性和横切关注点中受益。此外，从 API 网关开始您的开发之旅将减少技术债务，因为当他们的应用程序或客户群扩展时，您的开发人员将不再需要实现 API 网关。

提升分析和监控水平

无论您选择使用 API 代理还是 API 网关，都必须将您的解决方案与分析解决方案相结合。Moesif 为您的 API 提供端到端的可见性，以帮助您构建令人惊叹的 API 产品。在 Moesif 中可以很容易地发现对使用、趋势、错误和采用的深刻见解。使用 API 网关或代理向您的用户交付可靠和安全的 API，同时使用 Moesif 确保您交付无与伦比的价值。由于我们支持许多最流行的框架和 API 管理平台，与 Moesif 的集成变得简单而容易。立即注册moe SIF，升级您的 API，并使用分析和监控来增强您的网关或代理解决方案。

每个 API 团队都应该知道的 10 大 API 安全威胁

原文：https://www.moesif.com/blog/technical/api-security/API-Security-Threats-Every-API-Team-Should-Know/

随着越来越多的数据通过 API 公开，无论是作为 API 第一公司，还是作为单页应用/JAMStack 的爆发，API 安全性不再是事后的想法。API 的难点在于它提供了对大量数据的直接访问，同时绕过了浏览器的防范措施。你不应该担心 SQL 注入和 XSS 的问题，你应该担心的是那个能够对你所有的客户记录和数据进行分页的坏人。

像验证码和浏览器指纹这样的典型预防机制将不起作用，因为 API 的设计需要处理非常大量的 API 访问，即使是单个客户。那么你从哪里开始呢？第一件事是把你自己放在黑客的位置上，然后装备你的 API 来检测和阻止常见的攻击以及未知的零日攻击。其中一些在 OWASP 安全 API 列表中，但不是全部。

不安全的分页和资源限制

大多数 API 提供对资源的访问，这些资源是实体的列表，如/users或/widgets。客户端(如浏览器)通常会对该列表进行过滤和分页，以限制返回给客户端的项目数量，如下所示:

First Call: GET /items?skip=0&take=10

Second Call: GET /items?skip=10&take=10 

但是，如果该实体有任何 PII 或其他信息，那么黑客可以抓取该端点来获得数据库中所有实体的转储。如果这些实体意外暴露了 PII 或其他敏感信息，这可能是最危险的，但在向竞争对手或其他人提供您企业的采用和使用统计数据或向骗子提供获取大量电子邮件列表的方法时，这也是很危险的。查看 Venmo 数据如何报废

一种简单的保护机制是检查获取计数，如果大于 100 或 1000 就抛出一个错误。这个问题有两个方面:

1. 对于数据 API，合法客户可能需要获取和同步大量记录，比如通过 cron 作业。人为的小分页限制会迫使您的 API 变得非常繁琐，从而降低整体吞吐量。最大限制是为了确保满足内存和可扩展性要求(并防止某些 DDoS 攻击)，而不是为了保证安全性。
2. 这对于编写简单脚本、在重复访问之间随机延迟休眠的黑客来说没有任何保护。

skip = 0
while True:
    response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip),
                      headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})
    print("Fetched 10 items")
    sleep(randint(100,1000))
    skip += 10 

如何防范分页攻击

为了防止分页攻击，您应该跟踪在特定时间段内每个用户或 API 键访问了单个资源的多少项，而不仅仅是在请求级别。通过在用户级别跟踪 API 资源访问，您可以在用户或 API 键达到某个阈值(如“一小时内接触了 1，000，000 个项目”)时阻止它们。这取决于您的 API 用例，甚至可能取决于他们对您的订阅。就像验证码一样，这可以减缓黑客利用您的 API 的速度，就像验证码一样，如果他们必须手动创建新的用户帐户来创建新的 API 密钥。

不安全的 API 密钥生成

大多数 API 都受到某种 API 密钥或 JWT (JSON Web Token)的保护。这提供了一种自然的方法来跟踪和保护您的 API，因为 API 安全工具可以检测异常的 API 行为，并自动阻止对 API 密钥的访问。然而，黑客想要通过从大量用户生成和使用大量 API 密钥来胜过这些机制，就像网络黑客会使用大量 IP 地址来规避 DDoS 保护一样。

如何保护 API 密钥池

防范这些类型攻击的最简单方法是要求用户注册您的服务并生成 API 密钥。Bot 流量可以通过验证码和双因素身份验证来阻止。除非有合法的商业案例，否则注册您的服务的新用户不应该有以编程方式生成 API 密钥的能力。相反，只有受信任的客户应该能够以编程方式生成 API 密钥。更进一步，确保针对异常行为的任何异常检测都是在用户和帐户级别完成的，而不仅仅是针对每个 API 键。

意外钥匙暴露

API 的使用方式增加了凭据泄露的可能性:

1. API 预计会被无限期地访问，这增加了黑客获得未过期的有效 API 密钥的可能性。您将 API 键保存在一个服务器环境变量中，然后忘记它。这与用户登录交互式网站形成了鲜明的对比，在交互式网站上，会话在短时间内就会过期。
2. API 的消费者可以直接访问凭证，比如在通过 Postman 或 CURL 进行调试时。只需要一个开发人员不小心将包含 API 密钥的 CURL 命令复制/粘贴到一个公共论坛，就像 GitHub 问题或堆栈溢出一样。
3. API 密钥通常是不需要任何其他标识信息的不记名令牌。API 不能利用诸如一次性令牌或双因素身份验证之类的东西。

如果一个密钥由于用户错误而暴露，人们可能会认为你作为 API 提供者有任何责任。然而，安全性就是减少表面积和风险。像对待自己的数据一样对待您的客户数据，并通过添加防护措施来防止意外的密钥泄露来帮助他们。

如何防止意外的按键暴露

防止密钥泄露的最简单方法是利用两个令牌，而不是一个。一个刷新令牌被存储为一个环境变量，并且只能用于生成短期访问令牌。与刷新令牌不同，这些短期令牌可以访问资源，但有时间限制，如几小时或几天。

客户将与其他 API 密钥一起存储刷新令牌。然后，您的 SDK 将在 SDK init 上或在最后一个访问令牌过期时生成访问令牌。如果一个 CURL 命令被粘贴到 GitHub 问题中，那么黑客需要在几个小时内使用它来减少攻击媒介(除非它是实际的刷新令牌，这种可能性很低)

暴露于 DDoS 攻击

API 开启了全新的业务模型，客户可以通过编程访问您的 API 平台。然而，这可能会使 DDoS 保护变得棘手。大多数 DDoS 保护被设计为在 DDoS 攻击期间吸收和拒绝来自不良参与者的大量请求，但是仍然需要让好的参与者通过。这需要对 HTTP 请求进行指纹识别，以检查看起来像 bot 流量的内容。对于 API 产品来说，这要困难得多，因为所有的流量看起来都像是僵尸流量，而不是来自存在 cookies 之类东西的浏览器。

阻止 DDoS 攻击

API 的神奇之处在于，几乎每次访问都需要一个 API 密钥。如果一个请求没有 API 键，您可以自动拒绝它，这在您的服务器上是轻量级的(确保在稍后的中间件(如请求 JSON 解析)之前很早就将身份验证短路)。那么，如何处理经过身份验证的请求呢？最简单的是利用每个 API 键的速率限制计数器，例如每分钟处理 X 个请求，并使用429 HTTP response.拒绝那些高于阈值的请求。有多种算法可以做到这一点，例如漏桶和固定窗口计数器。

不正确的服务器安全性

就良好的服务器卫生而言，API 与 web 服务器没有什么不同。由于 SSL 证书配置错误或允许非 HTTPS 流量，数据可能会泄露。对于现代应用程序，几乎没有理由接受非 HTTPS 请求，但是客户可能会错误地从他们的应用程序发出非 HTTP 请求，或者暴露 API 密钥的 CURL。API 没有浏览器的保护，所以像 HSTS 或重定向到 HTTPS 这样的东西不提供保护。

如何确保正确的 SSL

在 Qualys SSL Test 或类似工具上测试您的 SSL 实现。您还应该阻止所有可以在负载平衡器中完成的非 HTTP 请求。您还应该删除任何 HTTP 头，清除任何泄露实现细节的错误消息。如果您的 API 仅由您自己的应用程序使用，或者只能在服务器端访问，那么查看【REST APIs 跨源资源共享权威指南

不正确的缓存头

API 提供对每个 API 键范围内的动态数据的访问。任何缓存实现都应该能够限制 API 键的范围，以防止交叉污染。即使您没有在基础架构中缓存任何东西，您也可能会让您的客户暴露于安全漏洞之下。如果拥有代理服务器的客户使用多个 API 键，比如一个用于开发，一个用于生产，那么他们可以看到交叉混合的数据。

这有多严重？见数据安全事件后推特披露账单信息泄露

如何确保没有缓存

您应该确保正确配置了缓存控制头。

API 的一个大问题是许多 API 不使用标准的Authorization头，而是使用像X-Api-Key这样的自定义头。缓存服务器不知道这个请求正在被认证，因此选择缓存该请求。

app.use((req, res, next) => {
  res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');
  res.setHeader('Pragma', 'no-cache');
  // ...
}); 

记录和监控不足

这是 OWASP 十大 API 安全项目。大多数违规研究表明，检测数据违规的时间超过 200 天。如果您没有适当的 API 日志和监控，攻击者可以继续使用相同的漏洞，甚至探测更多的漏洞。

如何正确添加 API 日志记录

您应该确保您的 API 日志记录不仅跟踪 API 请求本身，还与用户相关联，用于用户行为分析，并至少保存一年。这些系统应受到保护，以确保数据不会被意外删除或提前停用。出于安全目的，GDPR 和 CCPA 为 API 审计日志提供了例外。像 Moesif API Security 这样的解决方案为 API 产品提供了一整套 API 监控和分析，只需几分钟就可以开始使用。

不保护内部端点

同一个 API 服务可能有外部使用和外部使用的端点。仅仅因为端点没有被记录并不意味着黑客不能调用它。除了使用身份验证和授权方案进行保护之外，您还应该确保这些端点根本不会暴露给公共互联网，这可以在您的负载平衡器或 API 网关中完成。这有助于提供多种安全级别，这是一种常见的预防策略。

不处理授权

虽然大多数 API 开发者会添加一个全局的认证方案，比如 API keys 或 OAuth 来验证这个人是谁，但是实现授权就更难了，授权也是必需的，并且与认证分开。授权包括检查这个人(已经确定)是否可以访问特定的资源。这可以通过 API 作用域来完成，检查租户 id 或用户 id，等等。

因为它特定于您的应用程序逻辑，并且不总是交叉的，所以授权可能是开发人员忘记的一个领域。除非您的对象标识符有足够的熵，否则黑客可以很容易地通过迭代测试不同的 id。对于在插入时增加 id 的 SQL 数据库来说尤其如此。

如何修复授权

确保经过身份验证的用户有权访问生成 API 响应所需的所有资源。这可能涉及到检查链接到相关对象的用户 id 或访问控制列表(ACL)。关于如何处理授权的更多信息，请查看我们的帖子为 RESTful APIs 构建认证和授权的步骤

API 生命周期每个阶段的 API 工具

原文：https://www.moesif.com/blog/technical/api-tools/API-Tools-for-Every-Phase-of-the-API-Lifecycle/

当你开始构建你的第一个 API 的时候，你很可能会不知所措或者忘记要点。API 工具的生态系统非常庞大，为项目的每个阶段选择合适的工具至关重要。

在本文中，我们将经历一个 API 项目通常会经历的不同阶段。对于每个阶段，我都会列出有帮助的要点和工具。

构建阶段

第一阶段是构建阶段。它是由我们在开始实现之前必须做出的重大决策以及随后 API 的实际实现来定义的。我们不得不问我们想要构建什么类型的 API。是 RPC 还是 REST？我们必须实时向用户推送更新吗，或者我们可以用基于拉取的方法来获得更新吗？

根据我们用例的需求，我们必须选择合适的技术。另一方面，我们还必须关注开发人员的技能组合；如果我们选择没人能掌握的技术，我们就造不出好东西。

设计

设计工具可以帮助我们规划我们的 API，甚至生成它的公共部分。它们迫使我们遵循最佳实践，因此即使技能较低的人员也可以构建安全且高性能的 API。

常用的 API 设计工具包括:

• OpenAPI
• 养蜂场. io
• IBM API 连接
• 云 API 设计者
• 红绿灯工作室

另外，在使用这些工具之前，理解 API 设计模式是很重要的。了解更多。

实体模型

原型库是工具带的另一部分。它们可以用于测试，并帮助客户实现者在实际的 API 准备好之前开始构建。

常见的 API 模型库有:

• JsonStub
• 诺克
• MockServer
• b 接受器
• 摩卡
• 莫奇. io
• 邮递员模拟 API

语言/运行时

虽然一些编程语言，如 Go，是为了构建 API 而创建的，而像 Elixir 这样的语言非常适合并行编程，但它们通常是根据员工的可用技能来选择的。

同样重要的是要注意，语言通常规定了框架。但是 API 框架的一些方法，比如 Sinatra-like，在大多数语言中都有对等的用法。

一些常用于构建 API 的语言有:

• 出发
• Python
• C#
• Java
• JavaScript
• 红宝石
• 仙丹
• 生锈

Moesif 在 API 指南中也有一个按语言分类的 API 资源列表

结构

就像编程语言一样，框架是复杂的结构，所以选择一个框架通常还是取决于你的员工的技能。有些更小；有的功能更全。有些语言提供了更多现成的东西，根本不需要太多框架工具。

以下是一些在互联网上支持 API 的框架:

• 快递
• 姜戈
• Ruby on Rails
• 游戏框架
• 春天
• 火箭
• 狂欢
• 凤凰

测试和部署阶段

测试和部署阶段是让整个项目生产就绪，保持一致，并托管在您选择的数据中心。同样，一些工具会限制其他决策。例如，亚马逊 API 网关只能从云提供商 AWS 获得。

云提供商

云提供商的产品略有不同，他们有不同的优势。Heroku 使用起来很简单。AWS 最早拥有最新的技术，Azure 与微软生态系统整合得非常好，Google Cloud 处于机器学习技术的前沿。

最大的云提供商有:

• Heroku
• 亚马逊网络服务
• 微软 Azure
• 谷歌云
• IBM 云

门

API 网关有助于管理系统的不同部分，并提供一个中心入口点。有些是开源的，有些不是。有些是托管的，有些是自托管的。有各种各样的网关可供选择。

最常用的网关有:

• 孔
• 【T0 厚，io】t1
• 顶点
• 亚马逊 API 网关
• Azure Gateway
• 快递网关

测试

API 的自动化测试有助于防止开发速度变慢。在开始时把事情做好是一回事，但是在一个 API 项目的整个生命周期中把事情做好是另一回事。

可以帮助完成这项任务的测试服务和框架有:

• 运行范围
• 邮递员
• 放心
• 肥皂泡
• JMeter
• 空手道
• 柑橘框架
• 金牛座

监视

当你在一个遥远的数据中心将一个 API 部署到互联网上时，知道它在做什么是至关重要的。您不能让错误被忽视，您也不想过度或不足配置您的系统。有两种不同类型的监控。综合监控如 Runscope，它按照设定的时间表 pings 您的 API；真实用户监控，如 Moesif，它监控来自客户的 API 流量。

优秀的托管监控服务包括:

• 莫西
• 运行范围

发布和共享阶段

当你准备好你的 API，你想与世界分享，但你也想让世界使用它，看看它是如何做到的。文档和分析对此至关重要。

证明文件

正确的文档决定了 API 业务的成败。毕竟，如果没有人知道如何使用你的系统，那么它的超级创新也于事无补。

幸运的是，有许多文档工具可以提供帮助:

• OpenAPI
• ReDoc
• 哲基尔
• 石板

分析学

与监控一样，分析也是一种跟踪 API 健康指标的方法，但分析更进一步，将监控与业务价值和客户统计数据结合起来。这为基础设施之外的团队(如产品、销售和营销团队)提供了对客户 API 使用情况的可见性，以了解客户是如何采用和使用您的 API 的。

像 Moesif 这样的工具也可以跟踪用户行为和网络活动，这使得复杂的产品分析成为可能，比如跟踪从最初注册到第一次 API 调用的漏斗。

API analytics 可以回答商业问题，例如:通过一个渠道进入的客户与通过其他渠道进入的客户行为是否不同？或者更具体一点，我通过 Twitter 获得的客户比我通过谷歌广告获得的客户流失更多吗？

API 现在处于数字化转型的中心

原文：https://www.moesif.com/blog/business/api-observability/APIs-are-Now-at-the-Center-of-Digital-Transformation/

当我们评估新冠肺炎如何影响我们的经营方式时，没有什么比向数字技术的转变更明显的了。尽管我们中的许多人已经从水冷却器健谈者转变为不情愿的 zoom 居住者，但对业务流程本身的影响实际上可能更深远。

据麦肯锡称，冠状病毒对提供数字产品和服务的公司起到了催化剂的作用。在所有业务领域，数字化的采用已经加速到相当于快进 6 年的程度，因此我们现在正在 2027 年运营，美国 60%的企业采用数字化流程。

McKinsey: How coronavirus has transformed business forever

企业在采用简化、自动化和现代化现有系统的数字流程时所经历的演变被称为数字转型。通过为客户、合作伙伴和员工创造数字化体验，企业可以通过提高客户参与度、降低运营成本和开拓新的市场&机会来获得巨大的投资回报。

在疫情期间，旧金山最有发言权的人之一是该市主要教学医院——加州大学旧金山分校(UCSF)的内科主任。鲍勃·沃希特博士管理着一个 3000 人的组织，其中包括 800 名医生，他站在疫情当地应对措施和向数字化转变的第一线，因为他的医院和许多其他医院一样，专注于新冠肺炎的面对面治疗，并将其他大部分工作外包给远程医疗。随着疫情的衰落，沃希特注意到向数字化的转移变得更加持久，在很多方面超出了人们的想象:

Perspective on Digital Transformation after COVID-19 from UCSF Chair of Medicine

在冠状病毒所代表的地震转变中最成功的公司是那些已经接受数字化转型并将其业务战略集中在 API、应用和数据分析上的公司。通过明智的规划和设计，他们成功地简化了工程开发，提供了卓越的客户体验，并提供了与合作伙伴低摩擦的集成方式。

API 加速开发

传统上，数字化转型需要时间来实施。现有系统的现代化就是通过尝试、学习和前进来建立技能和信心——类似于游戏中每一步的升级。

但是疫情已经强制规定了“一切照旧”和“T2 变革”的明确优先顺序。组织不得不应对变化，为新的优先事项提供资金，并快速建立能力。

使用基于微服务的应用在云中运行，敏捷团队能够构建更小的功能组件，并通过 API 将它们连接在一起。此外，由特定领域专家创建的第三方服务可以通过 API 集成到应用程序中，从而解放企业的开发团队，让他们转而开发更多增值功能。

Symbl.ai uses services from Moesif to refine product strategy and enhance DevEx

像许多工程资源有限的公司一样，当 Symbl.ai 面临在其报告仪表板中构建新功能或添加客户要求的新产品功能的选择时，他们会优先考虑产品路线。尽管报告和仪表板对于产品驱动的公司来说是次要的，但它仍然是至关重要的。

Symbl.ai 能够轻松地将 Moesif 的分析和仪表板功能添加到他们的产品中，从而加快了上市时间:

Surbhi Rathore, CEO and co-founder of Symbl.ai, said: "When you are a small company, it is difficult to concentrate 20% of the continuous engineering work on building a dashboard for yourself

API 显示应用程序的解锁版本

API 使对组织提供的能力的访问民主化。无论你是在寻找一个运输服务来帮助管理你的包裹，还是寻找地理围栏功能来获得位置感知体验，都有一个 API 可以满足你。

Shipengine speeds developer adoption with Moesif

API 变得越来越容易使用。越来越多的人参与到对话中来，因为 web APIs 或 RESTful APIs 的技术性要低得多——它们最简单的形式只是一个带有一堆查询参数的 URL，几乎任何人都可以使用。

API 支持一致的用户体验

客户期望的变化日益推动着数字化转型。现在，人们更喜欢持续的 360 度客户体验，包括电脑、电话和实物资产。

API 不仅隐藏了后端的复杂性，而且通过设计，它们还支持单一和一致的用户界面。即使您的企业产品可能使用通过 API 交付的10 到 100个内部和外部服务，您仍然可以完全控制前端以及您的客户如何体验您的产品并与之交互。API 避免了水平分割问题，即使在使用多个服务时，也没有单一的参考点。

分析性能的最佳地方是 API

API 为组成应用程序的服务提供了自然的分界点。对于收集分析数据来说，没有比数据进出服务更好的地方了。

Moesif's Advanced API Analytics drives growth

为了确保你的用户从你的产品中获得最大收益，Moesif 提供了关于客户如何使用你的 API 的深刻见解。我们构建了一个高级的 API 分析平台，帮助 API 驱动型组织中的每个人从他们的 API 数据中学习，并做出更明智的决策来推动增长。

成千上万的客户驱动团队使用 Moesif 来真正了解他们的客户和合作伙伴如何使用他们的 API，并自动调试客户问题。

摘要

新冠肺炎推动许多公司跨越了数字鸿沟。一些组织在疫情之前就已经经历了数字化转型的阵痛，而另一些组织尚未开始。但是，作为一个生存问题，大多数美国企业在过去的 18 个月里已经转向了数字化。

API 曾经是系统间变化的代理，但现在它们真正驱动着业务关键用例。尽管我们可能还没有意识到这一点，但我们已经进入了 API 的黄金时代。

"API is everywhere. They are under everything we touch in our personal and business life, "said Kin Lane, an API preacher.

REST APIs(跨来源资源共享)权威指南

原文：https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/

REST APIs 跨源资源共享(CORS)的深度指南，介绍了 CORS 的工作方式，以及常见的陷阱，尤其是在安全性方面。

什么是 CORS？

CORS 是一种安全机制，它允许来自一个域或来自的网页访问不同域的资源(跨域请求)。CORS 是对现代浏览器中执行的同源策略的放松。如果没有像 CORS 这样的功能，网站只能通过同源策略访问同源资源。

*#### 同源为什么存在？

像许多网站一样，您可能会使用 cookies 来跟踪身份验证或会话信息。这些 cookies 在创建时被绑定到某个域。每次对该域进行 HTTP 调用时，浏览器都会附加为该域创建的 cookies。这是在每个 HTTP 调用上的，可能是静态图像、HTML 页面，甚至是 AJAX 调用。

这意味着当你登录https://examplebank.com时，会为https://examplebank.com存储一个 cookie。如果银行是一个单页面的 React 应用程序，他们可能已经在 https://examplebank.com/api 的 T4 为 SPA 创建了一个 REST API 来通过 AJAX 进行通信。

跨域漏洞

假设你在登录https://examplebank.com时浏览到一个恶意网站https://evilunicorns.com。如果没有同源策略，黑客网站可以对https://examplebank.com/api到POST /withdraw进行经过验证的恶意 AJAX 调用，即使黑客网站不能直接访问银行的 cookies。

这是由于浏览器行为自动附加任何绑定到https://examplebank.com的 cookies，用于对该域的任何 HTTP 调用，包括从【https://evilunicorns.com】T2 到【https://examplebank.com】T4 的 AJAX 调用。通过将 HTTP 调用仅限于相同来源(即浏览器标签的域)，同源策略关闭了一些黑客后门，例如大约跨站点请求伪造(CSRF) (尽管不是全部。像 CSRF 令牌这样的机制仍然是必要的)。

原产地是怎么定义的？

来源包括协议、域、和端口的组合。这意味着https://API. my domain . com和https://mydomain.com实际上是不同的起源，因此受到同源政策的影响。同理，http://localhost:9000和http://localhost:8080也是不同的来历。当考虑原点时，路径或查询参数被忽略。

Origin 指的是发起请求的内容，通常是打开的浏览器标签，但也可能是 iFrame 窗口的来源。

为什么创造了 CORS？

网站发出跨来源的 HTTP 请求是有正当理由的。也许在 https://mydomain.com 的一个单页应用需要对 https://api.mydomain.com 的 T2 进行 AJAX 调用；或者，https://mydomain.com整合了一些第三方字体或分析提供商，如谷歌分析或 MixPanel。跨源资源共享 (CORS)支持这些跨域请求。

CORS 是如何运作的？

---

CORS 请求有两种类型， 简单请求 和 预先请求。 关于请求是否被预先发送的规则将在后面讨论。

一.简单的请求

简单请求是一种 CORS 请求，在启动前不需要飞行前请求(初步检查)。

1. 一个打开到https://www.mydomain.com 的浏览器标签发起 AJAX 请求GET https://api.mydomain.com/widgets

2. 除了添加像Host这样的头之外，浏览器还自动为跨源请求添加Origin请求头:

GET /widgets/ HTTP/1.1
Host: api.mydomain.com
Origin: https://www.mydomain.com
[Rest of request...] 

3. 服务器检查Origin请求头。如果允许原始值，它将把Access-Control-Allow-Origin设置为请求头Origin中的值。

HTTP/1.1 200 OK 
Access-Control-Allow-Origin: https://www.mydomain.com 
Content-Type: application/json
[Rest of response...] 

4. 当浏览器收到响应时，浏览器会检查Access-Control-Allow-Origin标题，看它是否与选项卡的原点匹配。否则，响应将被阻止。如果Access-Control-Allow-Origin与单个原点完全匹配，或者包含通配符 ***** ，则检查通过，如本例所示。

**响应Access-Control-Allow-Origin: * 的服务器允许所有可能成为大安全风险的来源。

只有在你的应用绝对需要的情况下才使用*，比如创建一个开放/公共 API。**

目的

如您所见，服务器可以根据请求的来源控制是否允许请求。浏览器保证Origin请求头的设置可靠而准确。

二、议案预先发出的请求

预先请求是另一种类型的 CORS 请求。预检请求是一种 CORS 请求，要求浏览器在发送被预检的请求之前发送一个预检请求(即初步探测)，以询问服务器是否允许原始 CORS 请求继续进行。该预检请求本身是对同一 URL 的OPTIONS请求。

由于最初的 CORS 请求之前有一个飞行前请求，我们称最初的 CORS 请求为飞行前请求。

在以下情况下，任何 CORS 申请都必须预先审核:

• 它使用 GET、HEAD 或 POST 之外的方法。此外，如果 POST 用于发送具有不同于 application/x-www-form-urlencoded、multipart/form-data 或 text/plain 的内容类型的请求数据，例如，如果 POST 请求使用 application/xml 或 text/xml 向服务器发送 XML 有效负载，则该请求将被预触发。
• 它在请求中设置自定义头(例如，请求使用 X-PINGOTHER 之类的头)

来源: Mozilla

需要预检请求的典型案例:

1. 一个网站调用 AJAX 将 JSON 数据发送到 REST API，这意味着Content-Type头是application/json

2. 一个网站对一个 API 进行 AJAX 调用，该 API 使用一个令牌来验证请求头中的 API，如Authorization

这意味着支持单页面应用程序的 REST API 让大多数 AJAX 请求被预触发是很常见的。

示例流程

1. 一个打开到https://www.mydomain.com 的浏览器标签启动一个带有 JSON 有效负载的认证 AJAX 请求POST https://api.mydomain.com/widgets。浏览器首先发送OPTIONS请求(也称为飞行前请求),其中包含建议的请求方法和主请求的请求头:

OPTIONS /widgets/ HTTP/1.1
Host: api.mydomain.com
Origin: https://www.mydomain.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization, Content-Type
[Rest of request...] 

2. 服务器返回指定允许的 HTTP 方法和头。如果最初的 CORS 请求打算发送列表中没有的头或 HTTP 方法，浏览器将不尝试 CORS 请求而失败。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.mydomain.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Content-Type: application/json
[Rest of response...] 

3. 由于头和方法通过了检查，浏览器发送原始的 CORS 请求。注意Origin头也在这个请求上。

POST /widgets/ HTTP/1.1
Host: api.mydomain.com
Authorization: 1234567
Content-Type: application/json
Origin: https://www.mydomain.com
[Rest of request...] 

4. 响应在Access-Control-Allow-Origin标题中有正确的来源，因此检查通过，控制权交还给浏览器选项卡。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.mydomain.com
Content-Type: application/json
[Rest of response...] 

高级配置

---

您已经在前面的示例中看到了一些用于 CORS 的标题，如Access-Control-Allow-Origin和Access-Control-Allow-Methods，但是还有更多标题用于更好的控制。下面是控制 CORS 的标题的完整列表。

请求标题

标题名称	示例值	描述	用于飞行前请求	用于 CORS 请求
起源	https://www.mydomain.com	浏览器页签的协议、和端口的组合打开	是	是
访问控制请求方法	邮政	对于预检请求，指定原始 CORS 请求将使用的方法	是	不
访问控制请求报头	授权，X-PING	对于预检请求，用逗号分隔的列表指定原始 CORS 请求将发送的标题	是	不

响应标题

标题名称	示例值	描述	用于飞行前请求	用于 CORS 请求
访问控制允许来源	https://www.mydomain.com	服务器指定的该请求的允许来源。如果它不匹配Origin头并且不是*，浏览器将拒绝请求。如果指定了域，则协议组件是必需的，并且只能是一个域	是	是
访问控制允许凭证	真实的	CORS 请求通常不包括防止 CSRF 攻击的 cookies。当设置为true时，请求可以使用/将包括 Cookies 等凭证。标题应该省略，以暗示false，这意味着 CORS 请求将不会返回到打开的选项卡。不能与通配符一起使用	是	是
访问控制公开标题	日期，X 设备 Id	除了默认标题之外，向浏览器选项卡公开的附加响应标题的白名单	不	是
访问控制最大年龄	Six hundred	缓存飞行前请求结果的值(秒)(即Access-Control-Allow-Headers和Access-Control-Allow-Methods标题中的数据)。Firefox 最长 24 小时，Chromium 最长 10 分钟。再高就没有效果了。	是	不
访问控制允许方法	获取、发布、上传、删除	可以是*来允许所有方法。可用于 CORS 请求的允许方法的逗号分隔白名单。	是	不
访问控制允许标题	授权，X-PING	可以是*以允许任何标题。可用于 CORS 请求的允许标头的逗号分隔白名单。	是	不

在当前的浏览器中，Access-Control-Allowed-Headers、Access-Control-Allow-Methods 和 Access-Control-Expose-Headers上的通配符(*)尚未完全实现。
最好列出头或者方法。见铬虫

什么是 Moesif？ Moesif 是最先进的 API 分析和调试平台，被数以千计的平台用于快速调试 CORS 问题，并了解您的客户如何访问您的 API。Moesif 为您喜爱的语言提供了开源中间件和 SDK。

常见陷阱

---

1.对 Access-Control-Allow-Origin 使用*运算符。

CORS 是在试图保持安全的同时放松同源政策。使用*会禁用 CORS 的大多数安全规则。有些情况下通配符是可以的，例如集成到许多第三方网站的开放 API。

您可以通过将 API 放在不同的域中来提高安全性。
T3 例如，你的开放 API【https://api.mydomain.com】T4 可以用Access-Control-Allow-Origin: * 来响应，但是你的主网站的 APIhttps://www.mydomain.com/api仍然用Access-Control-Allow-Origin: https://www.mydomain.com来响应

2.为访问控制允许来源返回多个域。

可惜规范不允许Access-Control-Allow-Origin: https://mydomain.com, https://www.mydomain.com。服务器只能用一个域或*来响应，但是您可以利用Origin请求头。

3.使用通配符选择，如 *.mydomain.com 。

这不是 CORS 规范的一部分，通配符只能用于暗示允许所有域。

4.不包括协议或非标准端口。

Access-Control-Allow-Origin: mydomain.com无效，因为未包含协议。

同样，除非服务器实际上运行在像:80这样的标准 HTTP 端口上，否则Access-Control-Allow-Origin: http://localhost会有问题。

5.在变化响应标头中不包括来源

大多数 CORS 框架都是自动完成的，您必须向客户端指定服务器响应会根据请求来源而有所不同。

6.未指定访问控制公开标题

如果不包含必需的标头，CORS 请求仍会通过，但未列入白名单的响应标头将从浏览器选项卡中隐藏。对于 CORS 请求，始终公开的默认响应头是:

• 缓存控制
• 内容语言
• 内容类型
• 期满
• 最后修改的
• 杂注

7.当访问控制允许凭证设置为真时使用通配符

这是一个棘手的案件，抓住了许多人。如果响应有Access-Control-Allow-Credentials: true，那么通配符不能用在任何响应头上，比如 Access-Control-Allow-Origin。

表演

---

一篇关于减轻 CORS 绩效处罚的文章将很快发布。*

为 RESTful APIs 构建身份验证和授权的步骤

原文：https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/

认证和授权

构建任何 RESTful API 的挑战之一是拥有一个经过深思熟虑的认证和授权策略。像身份验证、安全性和日志记录这样的横切关注点总是具有挑战性，并且涉及许多利益相关者。

为了明确定义，通常将两个独立的操作放在一起讨论:

认证:

包括核实这个人所说的他/她是谁。这可能涉及检查用户名/密码或检查令牌是否已签名且未过期。认证并没有说这个人可以访问特定的资源。

授权:

包括检查用户通过定义的角色或声明有权访问或修改的资源。例如，经过身份验证的用户有权读取数据库，但不允许修改它。这同样适用于您的 API。也许大多数用户可以访问某些资源或端点，但特殊的管理员用户有特权访问。

当然，这些定义通常是一起实现的，并且相互依赖，所以当我们提到 auth 时，我们指的是整个系统。

定义实际的令牌

创建身份验证策略时，首先要考虑的事情之一是您将使用什么类型的令牌。有多种方法，但最常用的有两种:

1.JWT 令牌(JSON Web 令牌)

JWT 令牌实际上是一个完整的 JSON 对象，已经过 base64 编码，然后使用对称共享密钥或使用公钥/私钥对进行签名。不同之处在于，如果您有一个消费者需要验证令牌是否已签名，但该消费者不应被允许创建令牌，则您可以向该消费者提供公钥，该公钥不能创建令牌，但仍然可以验证它们。我将把细节留到另一篇文章中，但是如果你还记得你的密码学课程，非对称加密和签名算法创建了一对在数学上相关的密钥。

JWT 可以包含这样的信息，包括主题或 user_id、令牌何时发出以及何时到期。通过使用秘密进行签名，您可以确保只有您可以生成令牌，因此不会被篡改(例如修改 user_id 或当它过期时)。但是要记住一点，当 JWT 被签名时，jwt 通常是不加密的(尽管你可以选择加密它)。这意味着任何有权访问令牌的人都可以读取令牌中的任何数据。将标识符(如 user_id)放在令牌中是一种好的做法，但不要将个人身份信息(如电子邮件或社会保险号)放在令牌中。您可以使用类似于 JWT.io 的工具轻松地对 JSON 数据进行 base64 解码和查看。

jwt 为什么这么伟大？

jwt 的一个好处是它们可以在没有后台存储的情况下使用。对用户进行身份验证所需的所有信息都包含在令牌本身中。在分布式微服务世界中，不依赖集中式认证服务器和数据库很容易。单个微服务只需要一些中间件来处理验证令牌(从 Express 到 JVM MVC 框架的任何东西都可以公开使用 JWT 库)以及验证所需的密钥。验证包括检查签名和一些参数，如声明和令牌何时过期。jwt 通常是具有有效期的令牌，有效期可以从几周到更长

验证令牌是否正确签名只需要 CPU 周期，不需要 IO 或网络访问，并且非常容易在现代 web 服务器硬件上扩展。

如果 jwt 这么棒，为什么大家都不用呢？

JWTs 的一个缺点是，如果您需要立即采取行动，禁止用户或添加/删除角色会有点困难。请记住，JWT 有一个预定义的到期日期，可以设置为未来一周。因为令牌存储在客户端，所以即使您在数据库中将用户标记为禁用，也没有办法直接使令牌无效。相反，您必须等到它过期。这可能会影响您的架构，尤其是在设计一个可能会被一个超级用户饿死的公共 API 或一个需要禁止欺诈用户的电子商务应用程序时。有一些变通办法，例如，如果您只关心禁止受损的令牌或用户，您可以有一个令牌或 user _ ids 的黑名单，但这可能会将数据库重新引入您的 auth 框架。黑名单的一个推荐方法是确保每个令牌都有一个 jti 声明(或者一个可以存储在数据库中的 JWT Id)。假设您想要使其无效的令牌的数量比您的应用程序中的用户数量少得多，这可能很容易扩展。您甚至可以在与 API 代码相同的进程中本地缓存它，从而消除对具有多个 9 的可靠性的数据库服务器的依赖。

另一方面，如果你有一个企业应用程序，有许多角色，如管理员、项目负责人、服务客户经理，并且你想让它立即生效，那么开发可能会很棘手。特别是，考虑一下管理员正在修改其他人的授权角色的情况，比如他/她的直接下属。因此，在没有刷新 JWT 的情况下，被修改的用户甚至不知道他/她的角色已经改变。

第二个缺点是，随着更多字段的添加，令牌可能会增长。在无状态应用中，几乎每个请求都要发送令牌，因此会影响数据流量大小。例如，我们前面提到的企业应用程序可能有许多角色，这可能会增加令牌中存储内容的膨胀和复杂性。想想设计支持 AWS 或 Azure 门户网站的 API。每个用户对每个资源都有目标权限。例如，允许一个用户查看 S3 帐户，但不能修改 EC2 实例。这件事的复杂性可能超出了 JWT 的能力。

在智能手机用户担心客户端延迟和数据使用的移动应用程序中，jwt 可能会给每个请求增加过多的负载。

2.不透明代币

既然我们已经讨论了 jwt 的优点和缺点，那么让我们来探索第二个选项，不透明令牌。不透明令牌顾名思义就是它们听起来的样子。不透明令牌只是引用包含数据的数据库条目的主键，而不是在令牌中存储用户身份和声明。像 Redis 这样的快速键值存储非常适合利用内存哈希表进行有效负载的 O(1)查找。因为角色是直接从数据库中读取的，所以角色可以更改，一旦更改通过后端传播，用户就会看到新的角色。

当然，维护 K/V 存储和 auth 服务器增加了复杂性。根据您的架构，每个服务都必须与认证服务器握手以获得声明或角色。

3.混合物

有一件事还没有谈及，那就是这两种选择的混合。您可以通过 JWT 处理身份验证，例如检查用户是否是他们所说的那个人。另一方面，对特定资源的授权不是 JWT 的一部分。换句话说，JWT 只处理认证端，而不处理授权端。

Cookies 与标题和 URL 参数

URL 参数

首先，我们从不建议在 URL 中放置令牌。网址被加入书签，与朋友分享，在线发布等。对于用户来说，复制他们喜欢的页面的 URL 并转发给朋友太容易了。现在，这位朋友具备了代表该用户登录所需的所有身份验证要求。此外，还有各种其他问题，例如大多数日志记录程序至少会以纯文本格式记录 URL。有人在 Chrome 中打开开发者工具并复制他们的 cookie 或 HTTP 头的可能性要小得多；)

所以这就把我们的范围缩小到只有 Cookies 和 HTTP 头。如果您专注于创建 RESTful APIs，那么 Cookie 实际上只是另一个头，就像授权头一样。事实上，您可以将通过授权头发送的同一个 JWT 封装在 cookie 中。事实上，许多为其他人使用而设计的纯 RESTful APIs 只是使用标准或定制的授权头，因为它更显而易见。也可以混合使用，例如一个 web 应用程序可以使用 Cookies 与代理背后的 RESTful API 对话。代理将提取 Cookie，并在转发请求时添加适当的头。真正的原因在下一节:

真正的争论:Cookie 与本地存储:

虽然 cookie 可能实际上只是包装了 JWT 或不透明令牌，但是客户端 web 应用程序仍然必须将令牌存储在某个地方。大多数人想到的两个选择是 Cookies 和 HTML5 本地存储。因此，有时当人们提到 Cookie 与 HTTP 头时，他们实际上是在问“Cookie 与本地存储？”两者都有好处和安全风险。

饼干

Cookies 很好，因为它们有一些标志，可以设置这些标志来执行安全检查，比如 HTTP Only 和 Secure。通过设置 HTTP Only 和安全标志，任何 Javascript 代码都无法读取 cookie，也无法通过 HTTP 以纯文本形式发送 cookie。因此，如本地存储部分所述，Cookie 可以免受 XSS 攻击。Cookies 很容易受到一种不同类型的攻击，称为跨站点请求伪造(XSRF 或 CSRF) 。XSRF 意味着不同站点上的黑客可以复制您自己站点上的一些输入表单，并将表单数据发布到我们自己的站点。虽然黑客无法访问 cookie 本身，但是 cookie 会随着每个 HTTP 请求传输到 cookie 有效的真实域。因此，黑客不需要读取 cookie，只需要成功地将表单数据发送到您的真实站点。这是饼干的危险之一。它们是为每个请求发送的，静态的，AJAX 等等。有一些方法可以解决这个问题，但是最基本的原则是你的 web 服务器需要识别这个请求是来自于你的运行在浏览器中的真实网站还是其他人。一种方法是使用隐藏的防伪令牌。一种方法是在 cookie 中生成并存储一个特殊的随机密钥，该密钥也需要与提交的表单数据一起发送。记住，只有你的真实网站可以访问cookie，但是黑客网站由于同源策略不能。然后，您的服务器可以验证 cookie 的令牌是否与表单数据中的令牌相匹配。XSRF 上还有其他保护选项。

局部存储器

本地存储的一个安全风险是 Javascript 可能会受到交叉脚本攻击(XSS)。在早期，XSS 是不逃避用户输入的结果，但现在你的现代 web 应用程序可能会从分析和属性跟踪到广告和小 UI 元素引入大量 JS 库。本地存储对您的网站域是全局的。因此，你网站上的任何 javascript，不管是不是第三方库，都可以访问相同的本地存储。你的应用中没有沙盒。例如，您的分析库从与您自己的应用程序代码相同的本地存储中读取和写入。虽然 GA 可能很好，但是您审计过您添加快速 UI 元素吗？在过去，人们还担心 javascript 是否以纯文本方式调用 AJAX，尽管网站本身是通过 HTTPS 保护的。由于浏览器开始对混合内容进行检查，这种担心比以前少了。一些仍然需要注意的事情，以防浏览器太旧或者启动时没有强制执行。

本地存储的第二个缺点是你不能跨多个子域访问它。如果您有单独的博客子域或电子邮件子域，这些站点无法读取本地存储。如果你不打算跨多个域登录，这可能没问题(想想 mail.google.com 和 google.com)。

谢谢

我们感谢我们的精选测试版客户，他们一直在试用 Moesif，为我们提供了宝贵的反馈，使调试变得更加容易。

配额和计费问题的自动通知

原文：https://www.moesif.com/blog/developer-marketing/behavioral-emails/Automatic-Notification-of-Quota-and-Billing-Issues/

让你的顾客满意是最重要的。没有什么比在他们犯了一个无辜的错误后停止他们的服务更疏远他们了。本行动手册将引导您完成在配额或计费问题出现时让您的客户了解情况所需的步骤。

用例

我们都有过无意中未付的发票，或者莫名其妙地开始失控的实现。与其严厉打击并阻止你客户的服务，为什么不放他们一马，如果他们接近他们的 API 费率限制或付款到期日，就给他们发个警告。

有了 Moesif 的行为电子邮件解决方案,自动让您的客户保持知情是一个简单的过程；让他们有机会修改他们的实现或更改他们的订阅计划，同时确保您的 API 性能 SLA 不会失败。

在哪些情况下，您应该通知您的客户有关订购或费率限制的问题？

以下事件可能会导致超出配额:

• 有缺陷的客户实施
• 单个客户的流量突然增加，达到极限时，可能导致所有用户的服务中断
• 对您的 API 进行 DDoS 攻击，这会破坏您的服务器
• 当你的服务越来越受欢迎时，流量会出现意想不到的峰值

同样，如果出现以下情况，您的套餐可能不会续订:

• 信用卡账单有变化
• 财务部内部的联系人被调换
• USPS 弄丢了支票

与 Moesif 建立更好的客户关系

客户成功管理可以通过提醒客户他们的 API 正在接近其计划的速率限制来改善客户关系。然后，在发送太多的请求错误响应之前，客户有机会调整他们的计划，或者修改 API 的参数。

大多数 API 网关如 Kong 和 NGINX 会在每个 API 调用上添加速率限制插件 HTTP 响应头，这样速率限制就可以被开发者观察和设置。通过将 API 分析与 Moesif 的行为电子邮件相结合，通过一个简单的用户界面，扩展客户沟通的复杂功能浮出水面。

Moesif 的集成与 Kong Gateway 的完整功能在一篇配套的文章中有详尽的解释。

自动通知配额和计费问题的行动手册

自动化重复过程是整个产品设计的一个关键属性。通过将有效载荷的可观察性与行为电子邮件相结合，Moesif 能够让您在许多功能、性能和产品问题的复杂工作流程中更加高效。

本演示行动手册重点关注您的客户可能会遇到的性能和订阅问题，通过向您展示如何处理接近其费率限制的用户或由于发票过期而可能被暂停帐户的用户，来具体说明 Moesif 的功能。

其他行动手册关注如何保护您的 API 免受攻击和故意误用以及如何指导客户将 API 自动与 Moesif 集成。这三部行动手册仅仅触及了我们平台的皮毛；一旦你掌握了创建自己的群组、指定触发事件和设计行为邮件的诀窍，你就会想知道在 Moesif 之前你都做了些什么。

配料清单

我们将使用 Moesif 的分析工具来构建这个应用程序。如果你还没有创建账户，你可以免费注册。

行动手册创建的步骤

行动手册包括工作流、sop 和文化价值观，它们共同形成了一个一致的反应—行动。不管你想达到什么目的，Moesif 行动手册包含两个关键要素:团队规范和电子邮件创建。

群组规范

Moesif 将用户和公司定义为不同的实体，这些实体可以被分组到共享相似标准的群组中。不同的群组包括共享类似领域的群组，例如:订阅计划、端点使用、请求代码等。正如之前的教程中所解释的那样，通过对用户/公司人口统计数据和行为进行过滤，可以创建群组。

要创建新的用户群组，请转到 Moesif 工具的用户>用户查找部分，并从下拉菜单中选择与和执行事件匹配的用户字段。事件过滤器和用户/公司字段的完整列表可以在我们的用户分析面板中找到。

接近速率极限时的警告

要创建一组接近其速率限制的用户，请转到用户>用户查找部分:

• 从执行的事件设置过滤器:
  • response.headers.Ratelimit-Remaining < 100
  • 时间段为At Least 1 times in Last 24 hours，我们还将跳过企业计划中的用户，因为他们将获得更个性化的跟进:
• 从匹配的用户设置过滤器:
  • metadata.plan is not enterprise(1)这显示在下面的屏幕截图中:

账户逾期

要创建一个订阅过期的群组，请转到用户>用户查找，从用户中选择符合过滤器的用户:metadata.outstanding_invoices > 1、&、metadata.due_since is before 1 Month Ago，如下所示。

一旦设置了过滤器，Moesif 将查看当前和历史数据，并将所有符合过滤器标准的用户/公司分组在一起。我们还将监控用户/公司是否继续属于该群体，而无需任何人工干预。

然后，该群组可用于填充行为电子邮件中的收件人列表。

电子邮件创建

你可以使用拖放式所见即所得编辑器在 Moesif 中设计 HTML 邮件。要创建行为电子邮件，请转到 Moesif 工具的警报和治理>行为电子邮件部分。

第一步是添加一个新的+模板，其中模板包括电子邮件设计以及其他相关信息，例如哪些群组应该接收电子邮件。关于创建电子邮件模板的完整文档在可用，但可以说，电子邮件创建非常简单，一旦完成，可以使用测试按钮来验证电子邮件。

接近速率极限时的警告

只需将预定义的群组添加到收件人的行为电子邮件列表中，警告其接近速率限制。为避免不断向客户发送垃圾邮件，请将重新注册标准设置为 24 小时:

现在，每当客户接近他们的利率限制，他们将自动被添加到队列中，并发出警告电子邮件。

账户逾期

同样，只需将您之前定义的一群客户添加到一封行为电子邮件中，提醒他们其订阅已过期:

每当订阅过期时，过期用户将被自动添加到群组中，并发送警告电子邮件。

外卖食品

借助我们的 SaaS 平台，我们努力让我们的客户尽可能高效。通过有效载荷可观察性和行为电子邮件的结合，我们为集成问题创建了自动化警告流程，为您节省了时间和资源。

API 程序的好处

原文：https://www.moesif.com/blog/developer-platforms/api-analytics/Benefits-of-an-API-Program/

API 可以帮助您更快地完成任务、节省资金并增强您的业务决策。如果你正在考虑使用 API 程序来帮助扩展你的业务，请继续阅读。

增加价值

研究表明，在四年的时间里，与不使用 API 的公司相比，使用 API 的公司市值增长了 12.7%。在 16 年的时间里，这一增长率达到了 38% 。

API 可以帮助广泛的商业运作。如果你有一个产品或服务，并且正在考虑采用 API，那么有很多可以考虑的。我们在下面详细介绍了一些好处，以及一些挑战，以帮助您确定采用 API 程序是否具有合理的商业意义。

API 程序的好处？

无论您的用户是内部用户还是外部用户，API 都支持新的用例及定制。正如上述统计数据所表明的那样，在支持业务增长的同时，它们也是一个很好的收入来源。

其中一个原因是 API 很容易赚钱并获得报酬。你可以根据客户调用你的 API 的次数或者一系列其他的更精细的因素来给他们开账单。在早期阶段将货币化融入到你的思维中可以帮助你塑造你的 API 程序，并确保你创建一个防弹策略。

“我们很快就可以开始向我们的客户收取 API 使用费，这很快成为我们的收入来源。”NexHealth 的 API 总经理 Paul Fung，来自他们的案例研究。

API 的另一个好处是你的客户是开发者，而不是最终用户。这意味着他们从架构的角度来做决策。您的 API 可以迅速深入到客户的运营中，使您能够快速扩展。一旦你的 API 被集成，这种架构很难被解开的事实意味着你的客户应该长期坚持——前提是你提供一个很好的开发者体验。

API 有助于加速产品的上市，这也是事实。部分原因是因为你不需要在用户界面(UI)上花费任何精力，因为通常没有用户界面。API 往往是无头产品，嵌入到客户的后端，而不需要 UI。

这意味着您可以将您的工程工作集中在构建差异化的业务逻辑上。通过您的 API，您为开发人员提供了一个构建块，使他们能够采用同类最佳的业务逻辑来实现某些功能。通过不花费资源为您的客户提供一个用户界面来使用您的产品，您将更经济地使用您的工程资源来提供最大的价值。

挑战

每个新的商业冒险或方法都有它的挑战。引入一个 API 程序也不例外。

虽然您不需要花费精力将 UI 作为 API 的一部分，但是您需要投入时间和精力来制作文档。你需要记录标准、指南、模式、建议等等，所有这些都要以一种用户友好的方式进行。这需要一个能写出吸引人的内容的技术资源。

这都是交付卓越客户体验的一部分，它与卓越的客户服务一起，对于确保您的 API 程序不会有坏名声至关重要。

你需要的另一个资源是一个布道者——可以向内部利益相关者推销 API 采用的概念和 API 项目的价值的人。让每个人跟上速度并获得他们的认同需要时间，所以你越早开始传道越好。

“构建 API 程序时要有耐心。对那些和你想法不同的人感同身受——试着搭建桥梁帮助他们理解。要有愿景，并朝着这个愿景努力。”Jeannie Hawrysz，首席 API 架构师，来自我们的播客的 SAS。

安全问题

API 非常通用，适合各种垂直行业和商业模式。尤其是金融科技和健康科技行业已经迅速抓住了它们的潜力。这意味着安全性至关重要，HIPAA/SOC2/ISO27001 合规性是这些行业企业的首要任务。这也意味着有大量的 API 产品和工具可以提供这种级别的合规性和认证，因此当涉及到安全问题时，您可以高枕无忧。

利用 API 的力量

一个经过深思熟虑和实施的 API 程序可以实现新的应用程序和走向市场的策略。用强大的 API 分析和工具补充您的 API，可以确保您充分激活、理解和利用客户。

如果你准备探索一个 API 程序能为你的业务做什么，以及如何从中获得最大价值，现在是时候与 Moesif 谈一谈了。

为您的 API 使用 OpenAPI (Swagger)规范的好处是什么？

原文：https://www.moesif.com/blog/technical/api-design/Benefits-of-using-the-OpenAPI-Swagger-specification-for-your-API/

随着软件产品越来越仅仅是一堆微服务和第三方 API 的融合，让它们的结构井然有序变得更加重要。

GraphQL 从一开始就已经做到了这一点，它提供了一个完整的规范来描述该类型的 API 应该如何工作。在 RESTful API 领域，事情变得更加狂野。然而，即使不是所有的后端开发人员都知道，REST APIs 也有各种各样的规范！

其中最著名的是 OpenAPI 规范或简称 OAS。

输入 OpenAPI

在 2017 年发布 3.0 版本之前， OpenAPI 规范被称为 Swagger，并被重命名为 OpenAPI。这是一种描述 RESTful API 的与语言无关的方式，可以用来生成代码存根和文档。

它的想法是用一个 YAML 文档指定一个 REST API。这个文档可以用来为 API 端点生成文档和方法。虽然 API 通常用于分离软件，但 OpenAPI 规范也允许我们将 API 的公共接口与实现细节分离。

业务和设计团队可以定义他们需要的特性，工程团队可以创建一个 OpenAPI YAML 文档，用技术术语定义所有这些特性。

然后前端和后端团队可以使用这个文档作为他们实现的基础。双方都可以选择他们认为合适的技术。

OpenAPI 生态系统甚至提供了创建模拟 API 的工具，因此前端开发人员有了更实际的工作。

为什么要用？

在前端和后端之间添加一个 OpenAPI 规范是有价值的，原因有很多。

设计第一

在开始实现之前，我们可以为每个端点定义带有类型和示例的整个 API。使用生成模拟 API 的工具，我们可以验证一切看起来都如我们所愿。我们可以通过简单地迭代规范文档来改进我们的 API 设计。

代码生成器

OpenAPI 是 REST 规范，其代码生成器支持大多数语言。它以我们选择的语言生成服务器存根，我们必须将它与我们的后端服务和数据库连接起来。

工具作业

Swagger 规范被捐赠给了 OpenAPI 基金会，并被重新命名为 OpenAPI 规范。然而，在 Swagger 品牌下有一个巨大的工具生态系统，可以用来加速 API 开发过程。

它们可用于自动生成:

• 证明文件
• 试验
• 模拟服务器

庞大的用户群

OpenAPI 被许多大公司使用和支持，可以被视为他们多年来构建数千个 API 的浓缩知识。如果我们开始构建我们的第一个 API，这一知识本身就是无价的，但是如果有什么不太好的地方，知道有很多人在那里提供帮助也是很好的。

稳定实施

正如已经提到的，OpenAPI 规范在 2017 年之前被称为 Swagger 规范，所以它不是该规范的第一个版本也就不足为奇了。从 Swagger 到 OpenAPI 的更名发生在 3.0 版本。

该规范现在并不经常改变，在这一点上可以认为是成熟的。

为什么我们不应该使用它？

OpenAPI 规范并不是能够解决构建 API 时出现的所有问题的灵丹妙药。

没有 RESTful API

如果我们使用 GraphQL ，就不需要 OpenAPI 了。然而，有时这并不明显。有时我们得到构建一个 API 的任务，认为它是 RESTful 的，但是当了解到需要的特性时，我们最好使用非 RESTful 的。

例如，如果我们构建一个基于事件的系统，类似于 gRPC 或 AsyncAPI 的东西可能更适合它。

增加了复杂性

与我们添加到项目中的所有工具一样，存在增加复杂性的风险，但不会带来任何好处。过去，许多人被 SOAP 烧伤，即使 OpenAPI 规范并不庞大，但如果使用不当，也会导致问题。

我们需要为我们选择的框架找到一些集成，或者我们需要切换到支持 OpenAPI 规范的框架。然后我们可能会发现另一个框架的性能不够好，或者不再被维护。

此外，我们编写的每一行代码都是潜在的错误来源，即使它是 YAML。

构建 API 的开发人员也必须掌握使用 OpenAPI 及其工具的技能。

替代缺失的技能

当我们已经有了熟悉他们行业的高级 API 开发人员时，OpenAPI 可能是多余的，但它可以作为经验不足的开发人员的指南。问题是，我们需要培训这些人，而不仅仅是希望 OpenAPI 将我们从糟糕的 API 设计选择中拯救出来。

它应该是帮助人们的工具，而不是教育他们的替代品。

工具

有大量的工具可以让 OpenAPI 的工作变得更加简单。转换器、数据验证器、文档、编辑器、模拟服务器以及测试和 SDK 的生成器。

大部分可以在这里找到:https://openapi.tools/.

替代品？

当然，OpenAPI 规范有许多替代方案，虽然它们的采用率较低，但可能是它们为我们的开发人员提供了正确的选择，并且更容易理解和使用。

• RAML-RESTful API 建模语言 RAML 比 OpenAPI 更轻量级，但仍然基于 YAML。
• API 蓝图。用于 web APIs 的强大的高级 API 描述语言。 API Blueprint 使用自己的(非 YAML)语法。

结论

OpenAPI 是将几十年的 API 构建技巧融入规范的众多尝试之一。看起来甚至是最有想法和财力的人。

OpenAPI 倡议是 Linux 基金会的一部分，这使得它更值得信赖，至少看起来不会很快消失。

它不是灵丹妙药，可能也不适合所有人，但是如果使用得当，增加的复杂性可以在以后的文档编写和测试创建中节省相当多的时间。

moe SIF API 速率限制和配额的最佳实践，以避免愤怒的客户

原文：https://www.moesif.com/blog/technical/rate-limiting/Best-Practices-for-API-Rate-Limits-and-Quotas-With-Moesif-to-Avoid-Angry-Customers/

像任何在线服务一样，您的 API 用户期望高可用性和良好的性能。这也意味着一个客户不应该剥夺另一个客户访问您的 API 的权利。添加速率限制是一种防御措施，可以保护您的 API 不被请求淹没，并提高总体可用性。类似地，添加配额管理还可以确保客户遵守他们的合同条款和义务，从而确保您能够将 API 货币化。如果没有配额管理，客户可以很容易地使用远远超过其计划允许的资源，即使他们保持在您的整体服务器速率限制内。然而，不正确的实现可能会导致客户因为他们的请求没有按预期工作而生气。最坏的情况是，一个糟糕的速率限制实现可能会失败，导致所有请求被拒绝。本指南介绍了不同类型的速率限制和配额。然后，它介绍了设置速率限制的方法，既保护了您的 API，又不会让客户生气。

速率限制和配额是如何工作的

配额和速率限制都是通过跟踪每个 API 用户在定义的时间间隔内发出的请求数量来工作的，然后在用户超出限制时采取一些措施，这些措施可能是各种各样的事情，例如使用429 Too Many Requests状态代码拒绝请求、发送警告电子邮件、添加附加费等等。就像衡量不同的目标需要不同的指标一样，不同的速率限制用于实现不同的目标。

费率限制与配额管理

有两种不同类型的速率限制，每种都有不同的使用案例。短期速率限制侧重于保护服务器和基础设施不被淹没。然而，长期配额侧重于管理 API 资源的成本和货币化。

费率限制

短期速率限制关注每秒或每分钟的请求数量，帮助“平衡”峰值和突发流量模式，以提供后端保护。因为短期利率限额是实时计算的，通常很少有客户特定的背景。相反，可以使用每个 IP 地址或 API 密钥的简单计数器来测量这些速率限制。

费率限制的使用案例示例:

• 保护下游服务不会因流量高峰而过载
• 提高可用性，防止某些 DDoS 攻击使您的 API 停机
• 提供时间缓冲来处理容量扩展操作
• 确保为客户提供一致的性能，并均衡数据库和其他相关服务的负载
• 由于下游计算和存储容量利用率不均衡，降低了成本。

标识符

由于其时间敏感性，短期利率限额需要一种机制来识别不同的客户，而不严重依赖外部环境。一些速率限制机制将使用 IP 地址，但这可能是不准确的。例如，一些客户可能从许多不同的服务器调用您的 API。更健壮的解决方案可以使用 API 密钥或客户的 user_id。

范围

短期速率限制的范围可以是服务器，也可以是使用 Redis 等缓存系统的分布式实例集群。您还可以使用请求中的信息，例如用于附加范围的 API 端点。这有助于根据不同服务的容量为它们提供不同的速率限制。例如，某些服务的维护成本可能非常高，并且很容易被淹没，例如启动批处理作业或在数据库上运行复杂的查询。鉴于其实时性，短期费率限制可能并不完美，这使其在计费和财务方面表现不佳，但在后端保护方面表现出色。

配额管理

与短期费率限制不同，长期配额衡量客户在更长时间内对 API 的利用率，例如每小时、每天或每月。配额并不是为了防止 API 出现高峰。相反，配额通过确保客户遵守他们同意的合同条款来管理 API 的资源。因为您可能有各种不同的 API 服务层，所以对于每个客户来说，配额通常是动态的，这使得它们比短期速率限制更难处理。除了配额义务，客户行为的历史趋势可以用于垃圾邮件检测，并自动阻止可能违反 API 服务条款的用户(ToS)。

配额限制的使用案例示例:

• 阻止故意滥用，如发送垃圾邮件、刮擦或创建虚假评论
• 减少无意滥用，同时允许客户在需要时爆发使用
• 通过计量和基于使用的计费来适当地利用您的 API
• 确保客户不会消耗太多资源或增加您的云账单。
• 执行合同服务条款，防止“白吃白喝”

标识符

长期配额几乎总是按租户或客户级别计算的。IP 地址在这些情况下不起作用，因为 IP 地址可能会改变，或者单个客户可能会从多个服务器调用您的 API，从而绕过实施。

范围

因为配额通常强制执行合同的财务和法律条款，所以应该在所有服务器上统一，并且应该准确。在配额问题上，不能有任何“猜测”。

如何实现速率限制

通常像 NGINX 或 Kong 这样的网关服务器是集成速率限制的理想场所，因为大多数外部请求将通过网关层路由。对于短期速率限制违规，通用标准是用429 Too Many Requests拒绝请求。可以在响应头或主体中添加附加信息，指示客户端何时清除限制或何时可以重试请求。

对于长期配额违规，可以采取多种不同的措施。你可以拒绝类似于短期利率限制的请求，但你也可以处理其他方式，如增加超龄费。

阻止超过配额的用户

管理配额的一个简单方法是使用 Moesif 的 API 治理特性。这使您只需简单的 SDK 和用户界面中的几次点击，就可以添加管理 API 的规则。如何做到这一点的说明如下:

1. 在 Moesif 中，在用户查找选项卡下创建一个用户群组。当用户被认为超出其配额时，添加您的标准。在这个例子中，当用户在一个小时内做了超过 1000 个/purchases或/purchases/:id/decline时。

1. 现在我们已经创建了群组，转到警报&治理选项卡下的 API 治理。从这里，创建一个新的治理规则，如下所示。在这种情况下，我们用状态代码429 Too Many Requests短路请求。我们还会提供一条信息性消息，说明请求被拒绝的原因。

通知客户违反费率限制和配额

像任何故障或错误情况一样，您应该进行主动监控和警报，以了解客户何时接近或超过其限制/配额。您的客户成功团队应该主动接触遇到这些问题的客户，并帮助他们优化集成。因为手动扩展可能很慢且不可扩展，所以您应该准备一个系统，当客户的交易被拒绝而导致他们的应用程序出现问题时，该系统会自动通知他们遇到了费率限制。

让客户了解此类问题的一个简单方法是通过 Moesif 的行为电子邮件功能。如何做到这一点的说明如下:

1. 在 Moesif 中，在用户查找选项卡下创建一个用户群组。添加何时提醒客户的标准，例如查看 API 调用的数量，或者当速率限制标题达到某个阈值时。在本例中，我们添加了一个过滤器response.headers.Ratelimit-Remaining < 10

1. 现在我们已经创建了群组，请转到警报&治理选项卡下的行为电子邮件。从这里，创建一个新的电子邮件模板，并按照您的要求进行设计，如下所示。

剩余标头的速率限制

除了发送电子邮件，使用 HTTP 响应头通知客户任何剩余的速率限制也很有帮助。有一个互联网草稿指定了头RateLimit-Limit、RateLimit-Remaining和RateLimit-Reset。

通过添加这些头，开发人员可以很容易地设置他们的 HTTP 客户端，以便在正确的时间过后重试。否则，你可能会有不必要的流量，因为开发者不会确切地知道何时重试被拒绝的请求。这可能会造成糟糕的客户体验。

速率限制实施错误

甚至像速率限制这样的保护机制本身也可能有错误。例如，与 Redis 的不良网络连接可能导致读取速率限制计数器失败。在这种情况下，即使 Redis 集群不可访问，也不要人为地拒绝所有请求或锁定用户，这一点很重要。您的速率限制实现应该失效开放而不是失效关闭，这意味着所有请求都被允许，即使速率限制实现出错。

这也意味着速率限制不是容量规划不佳的解决办法，因为您仍然应该有足够的容量来处理这些请求，甚至设计您的系统来相应地扩展以处理大量涌入的新请求。这可以通过自动伸缩、超时和自动跳闸来实现，使您的 API 仍然能够工作。

结论

配额和速率限制是使您能够更好地管理和保护 API 资源的两个工具。然而，就业务用例而言，速率限制不同于配额。理解每种方法的差异和局限性是非常重要的。此外，提供工具也很重要，这样客户就可以随时了解速率限制问题以及审计 4xx 错误(包括 429)的方法。

为 API 构建 SDK 的最佳实践

原文：https://www.moesif.com/blog/technical/sdks/Best-Practices-for-Building-SDKs-for-APIs/

2019 年，没有 API 程序，你是做不了 B2B 公司的。无论你是 API 还是 API，产品或 API 都被用来为你的 web 应用提供额外的集成和功能。

尽管 SDK 在代码行方面看起来很简单，但 SDK 需要可靠并易于扩展。设计不佳的 SDK 可能会削弱客户的基础设施，降低客户对您服务的信任度。在 Moesif，我们投入了大量精力来创建 SDK，这些 SDK 既具有高性能，又添加了故障保险，以防发生不好的事情。本文将介绍其中的一些实践。鉴于 Moesif 是一个 API 分析服务，其中一些实践是特定于大容量数据收集的。但是，不管您的 SDK 目的是什么，其他功能都是适用的。

安全异步地初始化 SDK

对于大多数带有 SDK 的 SaaS 解决方案，您的用户需要初始化 SDK 并传入 API 密钥。您可能需要从您的服务器获取某些帐户信息或获取某些设备信息，如操作系统版本。这项工作应该在后台线程上执行，或者利用异步调用。通过利用后台线程，主线程可以继续响应而无需处理。根据您的 SDK 是用于前端还是后端，主线程可能是主 UI 线程，也可能是响应传入 HTTP 请求的线程。

除了卸载初始化工作之外，您的 API 密钥不应该假设 SDK 运行在一个安全可信的环境中。许多 SDK 包含在移动应用程序包中或通过浏览器 javascript 实现，所有这些都可以很容易地被分解，从而向任何可以下载或访问该应用程序的人透露 API 密钥。降低这种风险的一种方法是将 API 键的范围缩小到特定的 API 资源和动作。例如，如果您正在构建一个 analytics SDK 来收集和记录信息，那么 API 键可以是只写的，并且仅用于与您的数据接收 API 进行通信，但是对数据导出 API 的访问被阻止。

批量繁重的网络流量

对于与另一个服务器创建的任何 HTTP 连接，在传输任何数据之前都会有一些开销。这包括客户机和服务器之间创建 TCP 连接的 SYN 和 ACK 数据包的相互交换、建立 SSL/TLS 的握手等。您可以通过 Keep-Alive 重用连接，而不是为每个 HTTP 请求重复这些操作。

除了保持活动状态，您还可以将多个事件或命令批处理到同一个出站 HTTP 请求中。回到我们的 analytics SDK 示例，为每个需要记录的客户端事件发出 HTTP 请求是低效的。TCP 本身有开销，而且你还为每个请求发送许多 HTTP 头来处理认证、缓存等。批处理减少了这种开销，减少了系统调用的次数，同时将所有数据保存在同一个内存缓冲区中。

批处理是通过发送一组事件或命令来完成的，而不是每个 HTTP 请求发送一个事件或命令。它通常在与本地排队结合使用时效果最好。

利用本地排队

为了正确地实现上面的一些特性，比如批处理，您可以利用本地队列。本地队列将捕获或处理数据的逻辑与批处理数据并将其发送到服务器所需的逻辑分离开来。如果有断电的风险，事件可以存储在内存中的内存队列中，或者刷新到磁盘以保持持久性。更精细的排队架构可以利用分布式数据存储，如 Redis，尽管这增加了设置 SDK 的复杂性，所以除非绝对需要，否则不推荐使用。

当 API 关闭时，排队还可以增加 SDK 的可靠性。当 API 关闭时，本地事件可以继续被推入队列。一旦启动，就可以大批量清空队列。如果 API 长时间关闭，建议实现防止队列消耗过多内存或磁盘空间的逻辑。做到这一点的一种方法是通过实现一个固定大小的队列，该队列在新值出现时自动丢弃旧值。虽然一些事件可能会被丢弃(如果事件仅用于分析目的，这可能是可以的)，但这可能是一个很好的权衡，可以保证您的 SDK 不会崩溃或使您客户的基础架构过载。

刷新队列

正确的排队将需要某些触发器来将事件或命令刷新到您的服务器。推荐方法是同时利用基于时间和基于计数的触发器。例如，从上次刷新起 10 秒后，一旦缓冲区达到 50 个事件 OP，您就可以刷新事件。这确保了您的 SDK 可以在高峰流量期间批处理许多事件，同时仍然保持较低的端到端延迟。

如果没有基于时间的刷新，如果没有其他事件被推入队列，单个事件可能会无限期地停留在队列中。

压缩

压缩非常容易利用，但也很容易被遗忘。默认情况下，并非所有 HTTP 客户端库都压缩有效负载，您的后端需要支持您首选的压缩编码。通过使用 zlib 或类似工具将有效负载压缩为 gzip，您可以将有效负载的大小从纯文本减少 10 倍以上。你也可以研究像 Brotli 这样的新格式，它可以比 gzip 进一步减少 10%到 20%的开销。

设置User-Agent

您应该在User-Agent HTTP 头中包含 SDK 名称和版本。这使您能够了解 SDK 的采用情况，并将问题与特定版本关联起来。例如，我们 Moesif 在我们的 SDK 中采用了标准格式libraryname/semvar,因此:

 const request = require('request');
  const  pjson = require('../package.json')

  request({
  headers: {
    'User-Agent': 'nodejs/' + pjson.version
  },
  uri: 'https://api.example.com',
  method: 'POST'
}, function (err, res, body) {
  //it works!
}); 

利用 API 分析

一旦您构建并发布了这些 SDK，关键是您要有正确的 API 分析来衡量您的 API 的性能和利用率，并查看您可以在 SDK 或 API 方面做出哪些改进，例如调整批量大小或添加更高效的端点。正确实现的分析可以让您深入了解在分页或查找不正确使用的端点方面可以做出哪些改进。

文档更改

利用 GitHub 的发布流程或创建一个 CHANGELOG.md 来彻底记录变更，即使是很小的变更。当 SDK 的用户遇到错误或问题时，他或她可以检查的第一件事是 changelog 和任何类似问题的标签。有时小的变化会在你不知道的情况下在旧的或特定的环境中发生。

重大变更应该有更全面的文档来描述什么是重大变更以及如何迁移。您可能有一些 SDK 用户试图从版本 1 迁移。X.X 到 3。而其他人可能会从 2。X.X 到 3.X.X。记录完成迁移所需的内容会非常有帮助。

衡量 API 平台成功的开发者关系项目的最佳实践

原文：https://www.moesif.com/blog/developer-relations/measure-success/Best-practices-for-Developer-Relations-Programs-to-measure-success-of-an-API-platform/

每一个开发者关系项目都有一个不同的观点，即应该用什么样的北极星标准来衡量他们平台的成功。一些指标是有效的，而其他指标可能是所谓的虚荣指标。这篇文章讨论了你应该或者不应该跟踪哪些指标。

衡量什么

开发者关系的目标是确保第三方开发者能够利用你的平台创造有价值的东西。价值可能是主观的，但一些例子包括发布一个新的集成或插件来提高您产品的可用性，或者将您的 API 和 SDK 集成到他们的 web 或移动应用程序中，为他们的客户提供更好的体验。

假北极星度量

因为这很难量化，一些开发者关系项目天真地依赖于营销指标，比如页面浏览量和注册人数。这些指标的问题在于，注册你平台的新用户实际上并没有创造任何价值。你可以通过运行一个大型的 Google AdWords 或脸书活动来推动随机注册的涌入，从而轻松破解这些指标。然而，这些用户永远不会集成和利用这个平台。

要真正衡量一个平台的成功，您应该看看两个北极星指标:

1. 每周活跃令牌(或每周活跃用户)
2. 第一个你好世界的时间到了

1.每周活动代币(WAT)

为了衡量一个平台的成功，我们应该看它的使用情况。这可能来自您为第三方开发者发布的各种 API 和 SDK，以便与您的平台进行交互。仅仅是生成 API 密钥的行为并不能衡量使用情况，因为即使非开发人员也可以查看 API 密钥，而不会真正使用它们。因此，我们转向每周活跃的 API 令牌。由于大多数 API 都将访问权限限制在经过身份验证的用户，因此我们能够跟踪在给定的一周内有多少不同的令牌正在访问我们的 API 平台。

由于单个客户可以创建多个具有不同范围和到期日期的 API 密钥，我们可以进一步将范围缩小到每周活跃的集成公司。当决定在哪里投入更多时间时，开发人员关系团队中的每个人都应该看看这个指标。为了做到这一点，您应该准备好工具，将令牌之类的指标与开发人员的人口统计信息联系起来，例如将开发人员带到您的站点的任何营销渠道、公司关系和规模，甚至是 GitHub stars 之类的社交信息。有了这些信息，你就可以分解 WAT，找出对你的北极星指标贡献最大的是什么。阅读更多平台团队应该了解的其他指标

2.第一个 Hello World (TTFHW)的时间到了

其次是每周活跃代币，第一次你好世界的时间，是你的平台整体成功的一个很好的代理。它不仅包括像 WAT 这样的采用和使用，还包括 DevRel 之外的其他功能领域，如营销和支持。

开发者开始使用你的平台的时间越长，他们成功的可能性就越小。难以理解的文档，不清楚的入职后续步骤，或者需要六个小时讲座才能理解基础知识的 API 和 SDK，这些都可能导致 TTFHW 高于预期。阅读更多关于 TTFHW 和开发者漏斗的内容。

一个有效的 DevRel 程序应该致力于增加每周活动令牌(WAT ),同时减少首次 Hello World (TTFHW)的时间。

开发者关系在哪里

由于开发人员关系的目标是确保开发人员能够利用您的平台创造有价值的东西，因此必须格外小心，以确保 DevRel 的目标与更大的部门保持一致。作为一个相对较新的领域，每个公司都有自己的想法，DevRel 应该位于哪里，预算应该来自哪里。

营销

在一些公司，开发者关系是营销的延伸。由于这个原因，这些 DevRel 团队拥有大量的广告预算，可以在任何地方推广平台，从脸书广告到大型会议。营销团队的关键指标包括页面浏览量、注册人数和营销合格线索(MQLs)。然而，这些指标在帮助开发人员参与和发现平台的价值方面与开发人员关系团队不一致。因此，这些团队实际上是技术或开发者营销团队，没有太多的关系部分。

工程

在其他公司，开发人员关系是工程团队的延伸。这些团队负责最新的 API 文档，可能还有 SDK 本身。他们还能够调试和修复开发人员可能遇到的问题，或者创建额外的指南和示例来帮助他们的开发人员社区。不幸的是，由于持续不断的 SDK 变更、文档更新、调试等，这些团队将大部分时间花在了与公司其他队友的交流上，而不是更大的社区。

产品

产品的使命是构建一个客户(或开发者)实际采用和使用的产品。他们不断测试各种假设，并根据产品分析数据和客户的定性反馈构建功能路线图。开发人员关系团队不断地收集来自开发人员的反馈以影响路线图，同时他们是第一个知道他们的社区对产品变更是否有任何不满的人。在这种情况下，开发人员关系是产品的延伸，更多的是“在社区中”，而不是集中在构建方面和与内部利益相关者合作。虽然这是与多个平台公司和开发者关系团队合作的偏见，但我们已经看到 DevRel 在与产品而不是其他领域如营销和工程保持一致时表现最佳。毕竟，产品还受到参与度指标的约束，类似于每周活动令牌和首次 Hello World 的时间(产品信息和入职体验可能会对其产生很大影响)。

结束语

任何新的计划都需要有正确的指标来指导计划的任务和目标。开发者关系团队也不能幸免于责任。然而，开发人员关系团队有限的运营历史已经创建了一个基于 DevRel 预算来源的从其他部门借用指标的特别系统。创建产品指标，如每周活动令牌，确保 DevRel 能够帮助开发人员参与新的 API 或平台并从中发现价值。

如何用付费营销向开发者营销

原文：https://www.moesif.com/blog/developer-marketing/paid-ads/Best-Practices-for-Paid-Marketing-To-Developers/

在 Moesif，我们主要面向开发人员和其他技术受众，如产品经理和开发人员关系团队，他们希望自己的开发人员平台取得成功。让开发人员采用你的 API 或工具是很困难的，并且需要在实验和测量上的大量投资，以达到你想要的结果。与此同时，你听到的很多关于 B2C 或 B2B 营销的网上建议在对开发者进行营销时根本不起作用。这篇文章概述了我们在 Moesif 从 0 发展到现在超过 5，000 家公司(包括德勤、UPS 和 Radar)的过程中所看到的许多发现。

是什么让开发者营销变得艰难

在开始你应该尝试的事情之前，让我们回顾一下对开发者来说营销有什么特别和困难的。大多数以开发人员为中心的公司都是由开发人员自己创建和领导的，所以你会认为搞清楚像产品营销这样的事情应该很容易，对吗？毕竟，你们只是在向自己推销。就像任何观众一样，没有单一的开发者角色。

精确测量是困难的

快速反复的实验对于收回付费广告的投资至关重要。如果你没有努力跟踪你的指标，你很容易就会增加你的每次收购成本(CPA)。然而，对于一个开发工具公司来说，你实际上衡量的是什么？准确的归因可能是复杂的，因为对于许多开发者工具来说，你的产品创造的大部分价值和魔力是通过 API 或集成，而不是通过移动或 web 应用程序。这意味着注册并点击你的网站的用户不一定是转换用户。然而，有一些意图是基于用户正在查看的产品的内容或区域的。对于大多数开发者优先的公司，我们建议查看一个指标，比如开发人员第一次调用 API 的次数。随后，您可以定义额外的漏斗阶段，比如通过您的 API 进行超过 X 次交易的开发人员，或者使用 Y 个不同特性的开发人员。额外的复杂性来自于归因于营销渠道，因为现在你必须在你的网站上安装仪器来跟踪开发者通过的获取渠道，然后将它与开发者对你的 API 所做的事情联系起来。

锁定目标很难

大多数社交广告网络都是基于个人人口统计数据来针对普通消费者，而不是开发者。你可以通过简单的是或否过滤来锁定这些网络的消费者。比如这个人住在三藩市吗或者是年龄在 18 到 24 岁之间的人。这意味着，如果你是旧金山的一家披萨店，那么针对住在旧金山或附近的 18 至 24 岁的大学生投放脸书广告就相对容易了。这些人可能是理想的深夜披萨顾客。

对于开发者来说，没有一个简单的是或否的问题就能回答“是开发者”的问题。你可以尝试类似“他们的大学学位是计算机科学吗”这样的问题，但是软件工程是一个有多种教育途径的职业，并不总是需要计算机科学学位。即使你能匹配一个人的头衔，软件工程也是一个有着不同职责的模糊角色。一些工程师为汽车和无人机开发嵌入式系统，一些软件工程师专注于构建内部数据分析基础设施，其他人则在集成计费 API。

许多开发者工具都是针对各种市场的横向市场，而不是针对某个特定的行业，但是它们解决了一个特定的问题。像企业销售一样，这意味着你需要瞄准合适的开发人员，他们将使用你的 devtool 并在内部支持它。

• 如果你正在构建一个计费 API，你需要瞄准负责计费基础设施的专家
• 如果你正在构建分析工具，你需要瞄准产品经理或工程经理，他们是事实上的分析专家
• 如果你正在为 docker 构建一个新的工具，你需要把 devops master 作为目标，他碰巧也是一个 Linux master。

许多利益相关者

向开发人员销售的艺术类似于最复杂的企业销售过程，其中涉及大量的利益相关者。对于 devtools，涉众的数量可能比传统的 SaaS 还要多，因为您可能要进行架构评审、安全签核、实现等等。这是因为很多时候开发者是为公司而不是为他们自己检验你的工具或产品。处理这些复杂问题可以融入您的营销计划，而不是等到最后一刻才处理异议。

开发者对此表示怀疑

技术受众天生多疑。他们喜欢建造东西，而不是购买服务。这就产生了固有的偏见，因为他们暴露于第三方解决方案。由于内部政治斗争，一些开发人员可能对销售和营销团队有怨恨或偏见。这降低了直接外联的有效性。虽然它确实适用于某些自上而下的销售策略，例如向 CISOs 销售安全软件，但许多 devtools 都试图让个人开发者首先采用该工具，然后在此基础上发展壮大。

付费集客营销

吸引开发者到你的平台(而不是填满他们的邮箱)的最有效的方法之一是集客营销。集客营销是吸引或吸引开发者采用你的平台，而不是强行向他们推销你的平台的艺术。从 SEO 到推荐，集客营销有多种技巧，但本文的重点是付费广告。

为什么集客对开发者很重要

如前所述，开发者通常对传统的营销活动持怀疑态度。无论这是一封来自特别提款权的电子邮件，有两段太长，还是一个巨大的横幅，上面写着“立即注册”。由于受数字驱动，他们宁愿不去理会那些废话，自己探索某样东西是如何工作的，也不愿被一个非技术人员告知某样东西是如何工作的。开发者也喜欢修补和发现。这种发现的感觉是一种强烈的情感。想想你最近一次发现一些新的生活帮或网站成为你的最爱，并告诉你的朋友。这就是集客营销所利用的。

有效的集客营销让开发者看起来像是自己发现了一个新的工具或平台，而实际上他们是被营销给了这个工具或平台。

付费广告如何做集客营销

如果做得好，付费广告可以以较低的收购成本推动采用，但它需要更多的规划和支持，而不是简单地在脸书广告上投入一大笔钱。如果做得不正确，你仍然会推销你的产品。关键是要自然。

首先，您应该确定这些计划的目标，例如:

• 品牌曝光和驱动流量
• 创建新的销售线索和开发人员注册
• 推动现有销售线索整合您的 API
• 让开发者付费或进行更大规模的部署

一旦你有了你的核心目标，你就可以像创建一个 SEO 策略和关键词规划器一样，设计一个用于社交广告的内容策略。内容是让你的广告出现的首要因素。内容应该是真实的，对开发者来说是有趣的，但是仍然与你的工具解决的具体问题相关。

你想变得多具体是一条细线。如果你走得太远，那么你就没有真正吸引到合适的开发人员来采用你的解决方案。你不能在开发者还没有意识到他们有问题的时候就推出告诉他们注册的内容。解决这一问题的方法是将上述目标映射到针对购买漏斗各阶段的内容:

意识/曝光度

• 应该是信息，足智多谋，像如何 XXX 的东西，和 YYY 的最佳做法
• 例子包括:Moesif 的 apiguide.io，Launch Darkly 的 featureflags.io，Hubspot 的 website.grader.com
• 不是销售，只是将开发者暴露在问题空间中

创建合格的销售线索

• 思想领导力内容/让自己成为领域专家
• 为什么要接受你正在解决的论题/想法/产品。仍然不是关于你的公司，而是关于问题/解决方案

考虑您的产品

• 使用您的解决方案的结果和基准，技术白皮书
• 案例研究和比较图表

确保您能够捕捉到销售线索

对于大多数开发公司来说，比其他任何活动都更多的营销资金用于引导客户。然而，这需要额外的基础设施来处理。最简单的方法之一是将一些非门控内容与门控内容混合在一起。门控内容是指需要通过电子邮件来下载或查看内容。这通常最适合电子书和白皮书，因为作者通常会花更多的时间来起草它，使它对读者更有价值，而不是简单的博客帖子来克服留下电子邮件的障碍。要使封闭内容有效，您需要:

• 内容应该是高质量和思想领导水平(一些公司可以从几个 pdf 文件中产生许多线索)
• 一个专门的登录页面，消除大多数干扰。专注于下载 PDF 文件，而不是点击你的登陆页面。
• 一个表明隧道尽头的目标是接收报告的表单

不是所有的内容都需要被限制，但是如果目标是通过网站流量最大化潜在客户，拥有限制内容是一个简单的方法。门控内容可以采取其他形式，如网络研讨会和会议。

明确你的目标

对于开发者来说，明智地选择你的社交渠道和目标标准。正如开始提到的，瞄准开发者很难，因为角色相对模糊。规避这一点的一个方法是在能够锁定开发者的渠道上花费最多的时间和金钱。Moesif 在 LinkedIn 广告上运气不错，因为你可以缩小到特定的头衔、资历和公司行业。我们在 Reddit 上也很幸运，因为你可以针对与我们的分析平台相关的特定子编辑组。我们根本不使用脸书广告进行初步推广。相反，我们只使用它来重新定位已经注册了 Moesif 的现有开发人员，这带来了另一个问题:

你的广告应该以他们的行为为导向

当然，在 Moesif，我们吃自己的狗粮，并使用 Moesif 自己根据用户的 API 使用数据创建用户群组，以进行重新定位:

这些被同步到 Hubspot 和各种广告平台，这样我们可以根据开发者是否发送了他们的第一个 API 调用以及他们是否超过了他们的免费限制等来插入不同的广告。这使得广告信息更具体地针对开发者在你的开发者漏斗中的位置。

结束语

2020 年，随着领导力从不惜一切代价的增长转变为由产品优化驱动的高效增长，准确跟踪使用和留存至关重要。你不能再仅仅衡量浏览量和注册量这样的虚荣指标。相反，你应该衡量整个漏斗，并了解影响每个阶段的输入。价格和包装的变化如何改变你从活跃开发者到转变为付费用户的转化率。

基于使用计费的 API 货币化的最佳实践

原文：https://www.moesif.com/blog/developer-platforms/self-service/Best-Practices-For-Usage-Based-Billing-To-Monetize-APIs/

为什么要将 API 货币化？

对于许多 API 程序来说，API 是一种为了直接收入而出售的产品。这需要一个走向市场的策略来有效地将 API 货币化。如果你没有直接将你的 API 货币化，你可能会把钱留在桌子上。如果您没有任何配额限制来确保客户遵守合同条款，这种情况尤其明显。

然而，可能有许多利益相关者可以权衡或否决购买 API 产品的决定。即使你提议的 API 解决方案的经济购买者不是工程设计的一部分，API 本质上是非常技术性的，需要来自不同工程团队的大量输入，这可能会创建一个销售 API 的复杂过程。

销售原料药的挑战

谈到货币化，有两个挑战需要注意。既有工程挑战，也有商业挑战。本指南将涉及这两个方面，但本文主要讨论的是围绕走向市场(GTM)战略和财务的业务挑战。

销售 API 的业务挑战

向开发者销售很难，这使得 API 的盈利策略变得复杂。即使你提议的 API 解决方案的经济购买者不是工程的一部分，API 本质上是非常技术性的，需要来自不同工程团队的大量输入。作为任何采购过程的一部分，你需要求助于软件架构师、安全工程师、法律团队和产品经理，他们每个人都可以参与或否决购买 API 产品的决定。

首先是土地开发商

不要试图通过复杂的、自上而下的销售流程来吸引每一个利益相关者，而是首先让开发人员获得自助式入职体验。这并不意味着你放弃销售团队，但是你正在做的是让开发者开始看到 API 的价值，并在他们与你的销售团队合作之前向他们的领导团队宣传。这个过程通常被称为开发者优先采用或者产品导向的增长。你的目标是让开发者用信用卡支付象征性的金额，比如每月 50 美元。他们应该能够以自助方式快速完成这项工作。此阶段不涉及采购，因此订阅可以简单地放在经理的信用卡上。

通过开发商销售

一旦您的客户已经购买了自助服务计划并满足了某些使用标准，您的销售团队就可以参与进来。因为客户已经在 API 中获得了初始值，所以销售团队采取了咨询的方式，这样讨论就变成了更多的“追加销售”讨论。销售人员指导客户如何从 API 中获得更多的价值，或者浏览客户可能有的某些业务需求。由于使用量增加、新的使用情形或有更高的要求，客户可能会考虑升级。

这意味着您的销售团队应该了解客户的使用情况，以确定何时让客户参与销售流程。为了做到这一点，您应该设置一个 API 分析工具，它可以通过一个基于帐户的仪表板跟踪每个客户的 API 使用情况。这为每个客户和试运行的销售和客户成功提供了单一窗口。当客户的使用趋势发生变化时，建议设置自动通知，如通过 Slack。例如，当某个客户的 API 使用量周环比增长超过 10%时，他们可能已经准备好进行销售讨论。其他指标包括邀请其他团队成员加入他们的订阅，或者使用他们以前没有使用的其他 API。

确保 API 创造业务

即使你能够让开发者使用 API，这也不一定意味着 API 创造了商业价值。开发人员可能采用 API 只是为了试验一项新技术、创建一个业余项目、学习新技能等等。然而，企业并不关心一个简单的“Hello World”API。相反，企业购买 API 是因为他们看到它为组织增加了价值。就商业价值而言，这三种类型包括:

• 降低成本或时间(相对于自行开发的解决方案)。
• 为组织释放额外收入。
• 降低组织的风险。

定价和包装

如果你正在销售你的 API，根据你的商业目标，有很多方法可以打包它。由于其交易性质，许多 API 享受基于使用的计费模式(也称为按需付费或基于消费的计费)来实现收入增长，但您可以采取许多不同的方法。您应该在定价策略中考虑的领域包括:

1. 演员表
2. 包装
3. 货品计价

1.计费策略

计费策略对采用和客户激活影响最大，通常由产品部门驱动。预付费计费是指客户在消费服务之前提前支付服务费用。另一方面，后付费是指客户在服务被消费后付费。

预付账单

预付费是传统 SaaS 和企业软件公司最常见的模式。因为 API 提供者在提供任何服务之前先获得现金，所以预付费模式可以成为企业的救命稻草，从而增加现金流。如果您的收购或安装成本很高，这一点尤其重要，因为这允许您进一步投资于产品和增长。预付费也有利于客户，因为它提供了支出的可预测性，并减少了采购过程。因为在付款之前使用量是未知的，所以您可以通过承诺支出来处理基于使用量的计费。这可能包括数量折扣。然而，预付费可能会迫使客户在获得真实数据之前进行数学估算。

后付费账单

另一方面，后付费是当你的客户使用你的平台时，你向他们提供信用，直到他们付款。后付费可以简化基于消费的商业模式，因为客户不需要“猜测”他们将消费多少。相反，他们可以只输入他们的信用卡，然后处理账单，看看损失有多大(比如在餐馆或酒吧用餐)。后付费计费已经通过基于消费的模式得到普及，如数字广告业，以及最近的云行业。后付费的一个好处是，在看到任何价值之前，客户不需要提前承诺。

然而，这也有不好的一面。因为您提供了信用，所以根据您提供的服务，它可能会被客户滥用(就像用餐和冲刺场景)。拥有良好的安全措施和限额对于确保客户在购买前不会积累“过多的信用”非常重要。后付费也可以有更高的取消率。客户可能会使用比预期更多的昂贵服务，然后后悔。

	预付账单	后付费账单
描述	客户提前购买信用/配额，随后消费	客户仅在消费后为其使用付费
赞成的意见

• Better cash flow
• Familiar with traditional enterprises.

|

• Less entry friction
• Make PAYG easier.

|
| 骗局 |

• Friction in employment
• -好的

|

• Additional credit risk
• Can be abused

|

2.包装策略

包装策略对合同价值和扩张收入的影响最大。因为不是每个顾客都会得到相同的价值和支付相同的金额，所以包装指的是如何向顾客展示不同的 SKU 和产品。您可以使用不同的功能或使用组件来实现客户细分。

分级定价是 SaaS 常用的一种包装技术，用于创建“好”、“更好”和“最佳”计划，每个计划都有一组预定义的功能和配额。现收现付(PAYG)是另一种打包技术，也称为基于使用的定价或基于消费的定价，其中客户购买一定数量或体积，如 API 交易数。PAYG 是开发者优先或产品优先组织的催化剂。当客户的使用率非常低时，这一点也很重要。

分级定价

经典的分层定价使客户很容易了解他们的成本，并使定价更可预测，这对于购买软件的大公司来说是一个优势。这在 SaaS 行业很常见，也很容易理解，因为这降低了计费的复杂性。另外，实现起来超级简单。您不需要任何计量或分析来跟踪使用情况。你可以只实现一个订阅计费软件。

分层定价的问题在于价格和感知价值之间的脱节。当客户接近其计划的极限时，他们自然应该升级他们的计划。但是，下一个计划的价格跳跃可能会很大，这可能会导致客户对下一层“没有准备好”的情况。如果分层利用太多变量，这可能会被夸大。客户超出计划的所有限额而仅超出一个配额限额的情况并不常见。但是，下一个计划有“太多客户不需要的额外项目”(如附加功能)。同样，你不希望超过三层或四层。如果你有太多，它会造成分析瘫痪

现收现付(PAYG)定价

由于分层定价的这些问题，一种更现代的方法正在被使用，即客户为他们的使用付费。消费者在相当长的一段时间内使用了物理计量方案，如燃气和电力设施。计量的概念可以应用于具有基于使用的组件的数字产品。常见的衡量指标包括交易量、发送的千兆字节数或独立用户数。

基于使用情况的定价的一个好处是价格与感知价值的差距显著减小，因为客户只为他们需要的东西付费。PAYG 是产品导向型增长或开发者至上型企业的绝佳催化剂。您可以设计一个“吸引客户”的自助服务计划，然后让他们随着时间的推移增加使用量。换句话说，你的定价模式有内置的扩张收入。然而，如果不知道客户使用水平方面的情况，PAYG 可能会很有挑战性。

	分层布置	现收现付(PAYG)
描述	传统的 SaaS 定价，为每个层预定义了一套功能/容量	基于单位价格的基于使用或基于消耗的定价。
赞成的意见

• Enforce a minimum cost.
• Forecast for customers
• Easy to implement

|

• Better for customers
• Less friction in expansion
• Can "appear" cheaper

|
| 骗局 |

• Friction expansion
• Stiff, not aligned to numerical values

|

• Can upset customers with bill surprises.
• Too complicated to be realized.

|

选择消耗指标

对于基于使用情况的定价，选择正确的度量标准进行计量和计费非常重要，以便与收到的业务价值相关联。对每个 API 调用进行计费可能是一个糟糕的指标，因为有些 API 的价值很低(比如状态探测)。类似地，您可以同时提供批处理和非批处理 API。如果您正在构建一个 SMS API 产品，那么一个 API 调用批量发送 100 条 SMS 消息，然后转录它们，会比一个 API 调用只发送一条 SMS 消息为客户创造更大的价值。在这种情况下，基于发送的 SMS 数量计费比基于 API 调用数量计费更好。

作为第二个例子，假设您的 API 处理发送营销电子邮件，但也提供在平台中存储电子邮件模板的能力。如果您基于存储的模板数量计费，这可能是一个不好的指标，因为客户不太可能仅仅通过在工具中存储额外的模板来获得价值。如果客户起草了大量的电子邮件模板，但从未通过 API 发送过一封电子邮件，他们的账单仍然会很大。另一方面，客户会做出奇怪的行为，比如在旧的电子邮件模板发出后不断删除它，即使将电子邮件模板保存在工具中会更好。在这种情况下，客户通过自动化发送营销电子邮件的过程获得价值。因此，与客户价值相一致的更好的衡量标准是每月发送电子邮件的独特联系人数量或每月发送的电子邮件数量。

常见价值指标

名字	例子	何时使用
交易量	发送的 API 调用和消息的数量	API 和基于事件的平台，如 SMS 和分析
收入/成本份额	收入的百分比，交易费	专注于资金的平台，如支付或费用报告
数据卷宗	发送千兆字节，分钟	侧重于数据的平台，如日志或存储
以用户为中心	每月活跃的唯一用户	现代版的按座位或按用户收费
资源	计算单位，活动时间	计算基础设施，如数据库或虚拟机

3.发票策略

发票策略影响现金流，通常由财务团队驱动。一旦您决定了计费模式和产品的包装方式，您就需要决定何时触发和生成发票。与对产品和扩展收入有影响的计费和包装不同，计价策略对单位经济性有较大影响。通过定期开票，您可以按月或按年等时间表向客户开具发票。另一方面，您也可以在客户达到阈值时(例如当他们达到某个配额或未完成支出时)向客户开具发票。这种类型的发票被称为基于阈值的发票。

经常性发票

经常性发票是这两种方法中更受欢迎的一种，也更易于客户理解。您可以通过预付方式(通常是固定价格)向他们开具发票，或者发送一份账单，说明客户在之前的计费周期内的使用情况。对于企业软件的购买者来说，经常性发票通常是首选，因为它是可预测的，更容易计划。有几个缺点，通常会出现极端的薪酬模式。如果你有一些交易量极低的客户，他们每月只支付几便士或几美元，交易费将超过服务成本。类似地，如果客户可以在一个计费周期内快速积累大量信用，或者收到的价值是非常交易性的，这可能会在计费周期之间产生大量应收账款余额，即使服务已经提供。这在数字广告行业很常见，在这个行业，大笔支出会迅速积累。

基于阈值的发票

为了克服重复开具发票的不良单位经济性，可以利用基于阈值的发票。使用基于阈值的方法，在达到某个阈值之前，不会生成发票。如果预付，这意味着客户正在购买信用额度，然后可以使用(这可能是遥远的未来)。如果是后付费，则在达到阈值(如广告花费 1000 美元)后生成发票。这确保了无论客户每月花费多少，您每次最多只有 1，000 美元的未付款。基于门槛的定价并非没有缺点。这可能会使会计工作变得非常复杂，因为支出是不可预测的，也不完全符合像季度或年度这样的计费周期。时间可以是开放式的，也可以是不明确的。

	循环的	阈值
描述	按照每月、每季度或每年的时间表向客户开具发票	仅在达到信用阈值后向客户开具发票(也可以预付)
赞成的意见

• It's easier for the financial team
• Easier to predict

|

• Reduce transaction costs
• Make it easier to prepay.

|
| 骗局 |

• Bad unit economics is low-cost SaaS.

|

• It is more difficult for finance to recognize income.
• Will increase the company's debt.

|

实施基于使用的定价

实施基于使用量的计费带来了典型分层定价之外的额外复杂性。您需要一种准确的机制来以可靠的方式计量客户的使用情况，并大规模地进行。这种使用必须是可审计的，并且可以用来解决争议。与日志记录或监控工具不同，这些数据必须准确。您不希望出现这样的情况:您认为客户使用了 X，但他们有证据证明并非如此。

Moesif 发布了一套基于使用量的计费功能，使得设置计量规则变得容易。由于 Moesif 为 Stripe 和 Recurly 等计费提供商提供了交钥匙集成，聚合指标和自动为客户开具发票的繁重工作已经完成。

发布后基于使用计费的陷阱

除了实施数据管道来处理基于使用的定价之外，还有许多其他挑战，尤其是在管理客户期望方面。一个常见的问题是，客户的使用速度远远快于预期，产生了一大笔他们没有想到会收到的账单。在具有数据量组件的 API 和工具中尤其如此。

联系客户让他们了解这一点很重要。实现这一点的一种方法是通过自动电子邮件，一旦达到某些预定义的阈值，就警告客户他们的使用情况。在这种情况下，即使配额不是硬性限制，您也让客户知道他们一个月用了多少。

让客户围绕这些阈值进行一些控制也是有帮助的。没有人希望每月收到 10 封关于他们使用情况的电子邮件，即使这是一个可预见的账单。为客户提供调整这些阈值的 UI 有助于确保他们仅在需要时收到警报。

版本化 REST 和 GraphQL APIs 的最佳实践

原文：https://www.moesif.com/blog/technical/api-design/Best-Practices-for-Versioning-REST-and-GraphQL-APIs/

绿地项目是一件美好的事情。我们没有任何遗留负担，可以随心所欲地选择我们 API 的技术和设计，但是蜜月期不会永远持续下去，迟早我们必须发布我们 API 的第一个稳定版本。

在我们达到这个里程碑之前，我们应该考虑将来如何更新我们的 API。

大家都得说说 API 版本的事情。有些人认为我们不应该显式地对我们的 API 进行版本化，并随着时间的推移对它们进行改进，同时始终保持与每个客户端的向后兼容。

其他人说，应该明确地让我们的客户更容易适应新版本，同时告诉他们，他们的旧客户端正在使用即将过时的功能。

此外，最后，当我们决定版本化时，有不同的方法可以实现版本化，每种方法都有其优点和缺点。

在本文中，我解释了维护向后兼容性的不同方法以及它们对 API 开发生命周期的影响。

重点是 GraphQL 和 RESTful APIs。

创作者意见

有两种方法可以保持与现有客户端的向后兼容性。

1. 创建不同的 API 版本
2. 发展一个 API 版本

让我们看看 REST 和 GraphQL 的创造者对这个话题有什么看法。

为了了解 REST 体系结构的创造者的想法，我们可以阅读 Roy Fielding 2000 年的论文。

他没有明确提到版本控制(仅在 HTTP 版本和文档版本的上下文中，这两个版本与我们的 API 版本处于不同的抽象级别)。相反，他谈到了这样一个事实，即不同的客户可能需要不同的媒体类型来表现给定的。

**他写道:

表示的数据格式被称为媒体类型…一些媒体类型旨在用于自动化处理，一些旨在呈现给用户查看，少数媒体类型两者都有。

此外:

所有 REST 交互都是无状态的。也就是说，每个请求包含连接器理解请求所需的所有信息，独立于之前的任何请求。

一个表示是我们从 API 返回的数据。

一个连接器是一个客户端或服务器库。

虽然这并不表示对版本控制的任何意见，但至少它告诉我们，在我们的体系结构中必须有一些编码信息，以便两个连接器能够相互理解。

在我看来，这可以解释为两种方法中的任何一种，版本化和演进。

• 无论出于什么原因，如果我们需要版本，我们必须在请求中对其进行编码
• 如果我们想要演进，我们定义新特性不会影响老客户，所以我们不需要在请求中编码它们。

那么， GraphQL 的创建者对此有什么要说的呢？

虽然没有什么可以阻止 GraphQL 服务像任何其他 REST API 一样被版本化，但是, GraphQL 强烈主张通过为 GraphQL 模式的持续发展提供工具来避免版本化。

他们的观点是，GraphQL 的查询语言足够灵活，可以让老客户忽略添加的新功能，这样他们就不会因更改而中断，同时他们也声明，对于像任何其他 REST API 一样对 GraphQL API 进行版本控制，他们没有什么可说的。

总而言之，GraphQL APIs 应该更喜欢演化而不是版本控制，但是总的来说，没有人对这两种方法有绝对的看法。所以这里的下一步是检查它们的利弊。

版本控制

那么，我们为什么要对我们的 API 进行版本化呢？这是 GraphQL 文档中的另一段引文:

为什么大多数 API 版本？当对从 API 端点返回的数据的控制有限时，任何变更都可以被认为是重大变更，重大变更需要新的版本。

这背后的基本原理是，如果你不定义打破和不打破，一切都有可能打破。

从所有潜在的破坏中，我们需要对 API 的所有更改进行版本控制。

例如，我们可以向 JSON 响应中添加一个新字段，通常这不会导致问题，但是不知何故，某个客户端使用了 JSON 对象中的字段数来获得正确的数据。我们也可能决定发送太多数据，突然有一个客户端跟不上了。

因此，版本控制的一大优势是告诉每个人，他们以他们习惯的方式准确地获得数据。

然后就是弃用。

虽然我们可以构建理论上的边缘案例，在这些案例中，通常不会中断的更改会破坏一些东西，但是有足够多的案例中，更改会破坏客户端，其中之一就是从响应中删除数据。

例如，我们使用firstName和lastName，现在想要走向国际，只需发送一个name，同时也摆脱旧的格式。每个访问不存在的字段的客户端都可能会崩溃。

有了版本控制，我们可以告诉我们的 API 的客户端开发者，如果他们想使用我们的下一个版本，他们需要考虑改变格式，同时如果其他客户端不切换到新版本，他们也可以保持工作。

所以假设是，如果我们不知道什么是突破性的改变，什么不是，我们需要一些方法来通知我们的用户关于这些改变，以便他们可以做出自己的决定。

如果我们在没有任何进一步通知的情况下推出更改，我们的用户可能会陷入维护地狱，他们的客户端总是无缘无故地中断。

演变

采用进化方法而不是版本化所有变更的原因是什么？

让我们看看 GraphQL 的创建者是怎么说的:

GraphQL 只返回明确请求的数据，因此可以通过新类型和这些类型上的新字段添加新功能，而无需进行重大更改。这导致了一种常见的做法，即总是避免破坏性的更改，并提供无版本的 API。

REST 是一种架构风格，GraphQL 是一种规范，就其本质而言，规范比架构风格要严格得多。

虽然 REST API 可以遵循许多 GraphQL 原则，但 REST API 的某些部分通常是不明确的。GraphQL 试图通过定义添加到 API 不会破坏向后兼容性来利用这个规范。

如果我们指定我们的 REST API 保留将来向表示中添加数据的权利，并且客户端应该对这种做法有弹性，那么我们最终也会得到一种定义好的不可破坏的变化，这种变化可以用来发展我们的 API。

这种方法至少允许添加功能，但是删除功能呢？

GraphQL 定义了一个@deprecated 指令来标记不再使用的字段或枚举。

然而，GraphQL 规范并没有定义何时一个不赞成使用的字段或枚举会像语义版本这样的版本化方案一样消失。规范只说自省工具是 GraphQL 不可分割的一部分，应该阻止开发人员使用不推荐使用的字段。

通常情况下，REST APIs 并不使用自省工具进行 API 发现和文档编制，而只是为开发人员提供书面文档。在 REST API 不断发展的情况下，这些文档中应该包含弃用警告。

在这两种情况下，将这些变化告知客户的开发人员是非常重要的。

如何版本化？

如果我们决定对我们的 API 进行版本化，我们现在必须问自己，我们应该如何做？

这个问题可以分成两个问题:

1. 我们应该使用哪种版本控制方案？
2. 我们应该如何向我们的 API 添加版本？

版本控制方案

大多数 API 使用基于语义版本化的定制版本化方案。基本的想法是，我们有三个数字，z.y.x,并且在一个变化上增加一。

如果有所改变

• 是一个错误修正，x 增加。
• 添加一个特征，y 递增。
• 打破向后兼容性，z 递增。

如果 y 增加，那么 x 复位到 0，如果 z 增加，y 和 x 复位到 0。

有细微差别，但这是它的主旨。

版本控制实现

有不同的方法将版本控制编码到我们的 API 中。

• 将版本包含到 URL 中
• 将版本包含在请求标头中

每一种都有不同的利弊。

什么是 Moesif？ Moesif 是最先进的 API 分析服务，被数以千计的平台用来衡量客户对新 API 版本和 SDK 版本的采用率。

URL 中的版本

将版本编码到 URL 中的好处是更好的开发人员体验。

/api/v1.4/products/123 

许多 API 客户端开发人员甚至他们的用户经常使用浏览器来检查和调试 API。复制 API-URL 是一种常见的做法，将版本编码到头文件中可以防止这种情况。

罗伊·菲尔丁在他的论文中写了两件事。首先，REST 架构风格的目标之一是稳定的 URL，每个客户端都应该能够请求它理解的表示格式。

如果我们不向我们的 URL 添加版本，它们会更稳定，所以把它们排除在外会更安全。

此外，如果有人将他们在 API 客户机中使用的 URL 复制到浏览器中，浏览器是一个不同的客户机，应该能够请求它喜欢的表示。也许 API 客户端只能解析 JSON，但是浏览器可以显示完整的 HTML 页面。

所以在 REST 看来，浏览器并不是调试 REST API 的合适工具，像 Postman 这样的工具会更合适，因为它允许开发人员定义头部，进而定义哪个表示将被请求。

然而，我们可以随心所欲，正如 GraphQL 所显示的，如果你想构建一个一致的 API，没有必要坚持 REST。如果我们认为一个不可靠的方法更适合我们的浏览器调试用户，我们可以走这条路。

标题中的版本

另一种方法是将版本放在请求头中。

HTTP 规范说:

接受请求报头字段可用于指定响应可接受的某些媒体类型。

Fielding 写道，一个表示有一种称为媒体类型的数据格式，HTTP 规范定义了一个Accept请求头来指定接受的媒体类型。所以如果我们想让它 RESTful，我们应该把它放在那里，而不是放在客户头中。

供应商(API 创建者)特定介质的定义应如下所示:

type "/" "vnd." subtype ["+" suffix] *[";" parameter] 

• type为以下之一:application、audio、example、font、image、message、model、multipart、text、video
• subtype是类似于mycompany.api的字符串
• suffix为以下之一:xml、json、ber、der、fastinfoset、wbxml、zip、gzipcbor
• parameter是类似于version=1.2.5的字符串

将 API 的版本和格式编码到媒体类型中的一些示例:

application/vnd.mycompany.product+json;version=1.2.3
application/vnd.other-company.api-3.7+xml 

顺便说一句。我的浏览器的 GET 请求的默认Accept标题如下所示:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 

来体验一下当浏览器导航到一个 API 链接时它所期望的媒体类型。

结论

对 API 进行版本控制或进化，以及如何去做，绝不是一个简单的话题。

演进和版本化是我们可以遵循的不同路径，如果我们走版本化的方法，没有一个赢家。

虽然著名的 REST 论文写于 2000 年，但它直接来自 Web 技术领域的一位非常有影响力的人，另一方面，GraphQL 表明，不可靠的 API 设计方法也可以同样成功。

无论我们走哪条路，重要的是始终如一地遵循它，并让我们的用户了解我们的最新计划。**

为 API 产品公司构建与购买行为电子邮件平台

原文：https://www.moesif.com/blog/technical/behavioral-emails/Build-vs-Buy-Behavioral-Email-Platform-for-API-Product-Companies/

行为电子邮件是根据客户的行动或行为自动发送给客户的有针对性的消息。通过触发你的客户如何与你的网站或产品互动，你能够发送内容与他们正在做的事情实际一致的电子邮件，因此更有可能引起共鸣。

API 公司在利用行为电子邮件方面处于独特的位置；如果监控和分析做得好，那么对平台内部正在发生的事情的洞察就可以浮出水面；有洞察力，甚至有先见之明的公报是可以发表的。

API 平台公司中行为电子邮件的常见功能包括帮助开发人员加速 API 集成和尝试新产品功能，以及让客户了解订阅和平台问题。

在之前的一篇文章中，我们介绍了 Moesif 的行为电子邮件解决方案的功能，在另一篇配套文章中，我们详细介绍了每个 API 产品公司应该使用的 5 大行为电子邮件。

在这篇文章中，我们将从技术上分析如何构建你自己的行为邮件解决方案。

构建自己的行为电子邮件解决方案需要什么？

一个行为电子邮件产品至少包括三个部分:

1. 从 API 获取监控数据的方法
2. 一种定义规则和验证监控数据的方法
3. 符合规则时向用户发送特定电子邮件的过程

从 API 获取监控数据

根据您的自信程度，您可以从头开始构建一个完整的监控解决方案，也可以采用现成的开源系统，如 Prometheus 。

Prometheus 是微服务的监控解决方案。通过在您的应用程序中包含一个 Prometheus 客户机，当您想要记录一个指标时，可以调用它。Prometheus 服务器将定期轮询数据源并保存结果。Prometheus docs 有一个设置指南来帮助安装。

Prometheus 客户端自带配置的默认指标，因此您不必手动设置 CPU 或内存监控等基本功能。

对于基于 Node.js/Express.js 的 API，您可以通过 NPM 为 Prometheus 安装 Node.js 客户端,配置只需要几行代码:

const prometheus = require('prom-client');
const register = new prometheus.Registry();
prometheus.collectDefaultMetrics({ register }); 

默认指标是基本的，与 API 无关，因此您必须自己设置更复杂的指标。

一个非常简单的 API 指标的代码可能如下所示:

const activeRequests = new client.Gauge({
  name: 'activeRequests'
});
registry.registerMetric(activeRequests);
api.use((req, res, next) => {
  activeRequests.inc();
  res.on('close', () => activeRequests.dec());
  next();
}); 

根据我们的文章您应该跟踪的 15 个最重要的 API 指标，Prometheus 只涵盖了我们确定的前三个指标，其余的必须用自定义代码定义。

定义规则和验证数据

一旦您在 Prometheus 中存储了监控数据，您需要测试客户是否做了会触发行为电子邮件的事情。顾名思义，行为邮件要求我们观察用户行为。

为此，您必须设置一项服务，让您定义电子邮件规则，轮询监控数据并根据您的规则验证数据。

要轮询数据，您可以使用 Prometheus 的查询语言 PromQL ，它允许通过 HTTP API 收集数据。从 Prometheus 收集了所需的数据后，您可以使用逻辑操作、通配符和正则表达式来定义应该查询监控数据的规则。

状态为 400 的响应的自定义普罗米修斯度量可以定义如下。使用标签功能，可以将自定义数据(如 userID)添加到跟踪的每个值中:

const status400 = new promClient.Counter({
  name: "status_400",
  labelNames: ["userId"],
});

expressApi.use((req, res, next) => {
  res.on("finish", () => {
	if (res.statusCode == 400)
  	status400.labels(req.session.userId).inc();
  });
  next();
}); 

如果您想获得过去 24 小时内的错误，您必须使用 PromQL 查询来查询它们:

status_400{userId="abc-123"}[24h] 

快速编写这些查询变得很复杂，如果您不是工程师，会特别困难。您会让普通商务人士编写这样的查询吗:

rate(http_requests_total{status_code=~"5.*"}[5m]) / rate(http_requests_total[5m]) 

大概不会。所以你也要建立一个编辑器。要么是可视化的，要么带有一些简化的规则语言和自动完成功能，因此没有工程学位的人也可以设置这些东西。

根据这个规则编辑器的复杂程度，它可以根据规则中指定的数据自动生成所需的 PromQL。您还需要另一个可视化编辑器来允许人们将他们的数据需求放在一起。

向用户发送电子邮件

系统的最后一部分实际上是发送电子邮件。您需要一种方法来定义用用户数据填充的电子邮件模板，然后您需要确保它们符合您在上一步中描述的规则。

同样，取决于你的电子邮件创建者的技术技能，这可能需要一个更完善的编辑器。今天，许多人有信心编写 HTML 和 CSS，这是一件好事，因为富文本电子邮件已被证明比纯文本电子邮件更成功。

我们已经为每个普罗米修斯指标关联了一个唯一的用户 ID，所以我们现在需要找到属于该 ID 的电子邮件。电子邮件系统需要访问用户的帐户数据，这在大多数情况下意味着连接到 SQL 数据库并查询其中的用户配置文件。比如 SQL 查询可能是这样的:

SELECT firstName, lastName, email FROM Accounts
WHERE userId=abc-123; 

将电子邮件发送到客户的收件箱是另一个问题。如果你建立自己的电子邮件服务器，它们可能会被放在垃圾邮件文件夹中。解决这个问题的典型方法是在主要电子邮件提供商的允许列表上集成电子邮件传递服务。

其中一个提供者是 SendGrid。他们提供了一个 API，你可以通过他们的服务直接从你的后台发送电子邮件。他们的 Node.js 包使用起来很简单。它甚至带有批处理功能，所以你可以一次发送多封电子邮件，这对我们的用例是一个很好的补充。

与 SendGrid 集成的示例如下所示:

const sendgrid = require("@sendgrid/mail");
sendgrid.setApiKey(SENDGRID_API_KEY);

sendEmails([
  {
	to: "recipient1@example.org",
	from: "sender@example.org",
	subject: "Hello recipient 1",
	text: "Hello plain world!",
	html: "<p>Hello HTML world!</p>",
  },
  {
	to: "recipient2@example.org",
	from: "other-sender@example.org",
	subject: "Hello recipient 2",
	text: "Hello other plain world!",
	html: "<p>Hello other HTML world!</p>",
  },
]);

async function sendEmails(emails) {
  try {
	await sendgrid.send(emails);
  } catch (error) {
	console.error(error);
	if (error.response) console.error(error.response.body);
  }
} 

维护您自己开发的系统

在你建立了你的系统之后，你还需要维护它。它需要更新、修复错误、改进，而且随着您的成长，可能还需要扩展更多的硬件。

最好能够分享你的电子邮件的表现，让同事、经理和合作伙伴都知道它是怎么做的:

• 实际触发了哪些规则？
• 电子邮件会被投递吗？
• 邮件打开了吗？
• 有多少客户打开了哪封邮件？
• 他们打开邮件后对你的 API 做了什么？

还应该构建和维护一个可视化电子邮件数据的用户界面，以便可以在整个公司范围内有效地共享。

摘要

构建一个行为邮件平台并不神奇，可以由精通 API 监控的程序员来完成。可以利用开源工具更快地启动和运行，而不需要从头开始构建一切。

但是，仍然需要大量的定制代码来集成这些工具。行为电子邮件平台需要由非技术团队成员操作，这需要构建图形用户界面，如用于创建查询、规则和电子邮件模板的编辑器。一个允许你查看发生了什么的仪表板也是更好的选择。

构建这些 GUI 是非常代码密集的，并且是一项耗时的任务。如果您经营一家小型 API 公司，或者不想投资构建和维护监控和分析工具，那么您最好使用像 Moesif 这样的工具。

Moesif 专注于 API 分析和监控，并且已经走上了从零开始构建行为电子邮件平台的道路。我们的可扩展解决方案可以处理数十亿个 API 调用和数千封电子邮件，并且只需几行代码即可集成到您的平台中。

构建符合 HIPAA 的 API

原文：https://www.moesif.com/blog/business/compliance/Building-HIPAA-Compliant-APIs/

法律免责声明:此处陈述的任何内容都不是法律建议。它仅供参考。您应该与法律顾问密切合作，以确定 HIPAA 会对您的业务产生怎样的影响。

医疗保健占美国国内生产总值的 17%，2020 年约为 4 万亿美元。COVID 使远程医疗的使用正常化，并加快了医疗保健从医生办公室和医院向智能手机和在线应用程序提供服务的分散。

在这一巨变中，越来越多的病历被数字化、传输、存储和电子利用。API 是在这个迅速发展的市场中迅速启用新服务的先锋。然而，随着这些电子记录的出现以及从 API 获取信息的便利性，现在比以往任何时候都更需要保护患者的数据。

HIPAA/HITECH 法律和您的 API

任何可用于识别患者身份的信息都被视为受保护健康信息，或 ePHI 代表电子受保护健康信息，其使用受联邦法律 HIPAA & HITECH 控制。

与金融科技中的 PCI 标准不同，没有人能够证明你的应用程序符合 HIPAA 作为管理机构的公民权利办公室(OCR)(卫生与公众服务部的一部分)不承认认证。相反，您 API 提供者——有责任执行定期的技术和非技术评估，以确保安全策略和程序符合法律条文。

在过去，OCR 通过民事和刑事处罚，积极寻求对不遵守 HIPAA 的公司做出判决。

健康保险携带和责任法案 (HIPAA)是 1996 年的联邦法律，并在 2009 年由健康信息技术促进经济和临床健康法案 (HITECH)进行了重大修订和扩展。HIPAA/HITECH 的目的是通过标准化和保护健康信息的交流来提高医疗保健系统的效率和有效性，特别关注隐私、安全和电子数据交换。

接触 ePHI 的 API 开发者需要遵守 HIPAA 和 BAAs

最简单的形式是，如果您的 API 接触到 ePHI，那么您必须遵守 HIPAA。

合规性还有另一个问题，如果您接触 ePHI，那么您还需要与该 ePHI 的上游提供商以及您可能与之共享该 ePHI 的下游合作伙伴签署法律协议、业务合作协议(BAAs)。

最终的上游提供商是美国医疗保健和健康保险提供商，他们生产大部分 ePHI，被称为承保实体。业务伙伴是指代表相关实体或其他业务伙伴执行涉及使用该 ePHI 的工作或其他职能的公司。在交换 ePHI 之前，开发人员和他们的供应商/合作伙伴之间的 baa 必须到位，否则交换就违反了 HIPAA。

在大多数情况下，API 产品将在所涵盖的实体本身之外开发，因此这篇博文将专门关注业务伙伴，即那些使用所涵盖的实体和/或其他业务伙伴的 ePHI 创建程序/应用的 API 开发公司。

让我们看看上面的说明性例子。一家 API 公司想要开发一款能够安排医生预约的产品。API 公司需要向医疗机构请求信息，例如姓名、就诊性质、医生的专业等。在发布 ePHI 之前，患者信息的持有者(医疗实践本身或电子医疗记录提供商)需要与 API 公司签署一份 BAA。如果调度公司想要使用另一个供应商的产品，比如显示医生办公室位置的 API 地图服务，那么他们需要与下游合作伙伴签署另一个 BAA。最初的 API 公司及其合作伙伴现在在法律上必须遵守 HIPAA 要求以及 BAAs 中概述的那些法规。

当不遵守 HIPAA 是安全的时候

在四种情况下，您不必遵守 HIPAA:

1.不要传输、存储或处理 ePHI

保护你的公司免受 HIPAA 攻击的一个方法是而不是传输、存储或处理任何 ePHI。因此，您可以高枕无忧，以下是 HIPAA 指定的 18 个唯一标识符(个人可识别信息),当与健康信息结合使用时，它们将成为 ePHI:

• 名字
• 地址
• 与个人相关的日期，如生日或访问日期
• 电话/传真号码
• 电子邮件
• severely subnormal 智力严重逊常
• 病历/健康计划/账号
• 证书或执照号码
• 汽车 VIN/车牌号码
• 设备 ID
• Web URL
• 国际电脑互联网地址
• 指纹或声纹
• 亲戚的名字
• 患者照片
• 能够唯一识别个人的任何其他特征

2.学校或就业记录

就业或学校记录中的健康信息不被视为 ePHI。

3.自我收集的健康数据

用户收集的、未与医生共享的数据不属于 HIPAA 的管辖范围:

• FitBit 上计算的步数
• 卡路里计数器
• 血糖读数
• 心率读数

4.去除标识符的 ePHI

去除了上述标识符的健康数据，也称为去识别或匿名数据，不能用于识别个人身份，因此不必遵守 HIPAA。

有许多数据提供商可以匿名提供医疗保健数据，并提供对总体人口趋势和基于价值的医疗保健项目的见解。

如果您的 API 只使用去标识的医疗保健数据，那么它不必遵守 HIPAA

API 开发者的关键 HIPAA 法规

为了遵守 HIPAA，API 开发人员需要采用管理、物理和技术安全措施来保护 ePHI 的隐私和安全。这不仅仅局限于对静态、传输中和使用中的数据进行加密，它还涉及如何分发加密密钥、在团队成员讨论时如何引用 PHI，以及如何建立对系统的定期内部审计。处理健康信息的每个人都需要充分理解他们在 HIPAA 下的责任，以保护 ePHI、避免责任和保护您的公司。

HIPAA 有 3 个主要规定:

• 隐私规则:规定了保护、使用和披露以任何形式(包括电子和口头形式)持有或传输的 ePHI 的标准和要求
• 安全规则:建立 ePHI 静止或运输时的安全标准
• 违反通知规则:规定违反 ePHI 的通知内容和方式

HIPAA 的隐私规则意味着保存详细的 API 日志

隐私规则定义并限制了贵公司使用和披露 ePHI 的情况，确立了个人在 ePHI 方面的权利，并要求您采取行政、物理和技术保护措施来保护 ePHI 的隐私。基本上，如果你像我们在 CCPA/FDPR 的博文中建议的那样实施隐私最佳实践，那么你将能够遵守 HIPAA 的隐私要求。

作为业务伙伴，您必须向个人授予 HIPAA 为相关实体指定的相同权利。您只能使用或披露与您的相关实体签订的服务协议& BAA 中定义的 ePHI，或者您与适用个人签订的协议中允许的 ePHI。

首先，您必须向个人提供一份隐私实践通知(通常是与您的承保实体合作制定的文件),概述如何使用和不使用 ePHI，以及个人对其 ePHI 拥有的权利和义务。之后，您需要制定协议来尊重以下权利:

请求隐私保护的权利

如果个人提出要求，您必须:

• 限制使用或披露 ePHI(有少数例外)
• 以安全保密的方式将 ePHI 交付给他们
• 使用替代方法向他们传达 ePHI
• 如果个人已经支付了服务费用，则不得向健康计划披露 ePHI

ePHI 披露日志的权利

记录 API 交易对于满足 HIPAA 对个人要求披露其 ePHI 账户的要求至关重要。如果个人要求，您必须提供每个 ePHI 披露的帐户，包括:

• 披露日期
• 收到 ePHI 的实体或个人的名称
• 公开的 ePHI 的简要描述
• 披露目的的简要说明

访问和修改 ePHI 的权利

This is analogous to the Right to Access/Amend/Erase as defined in GPDR and CCPA

请求	要提供什么
接触权	特定格式的 ePHI 或表格的副本
修改权	修正 ePHI 的能力
发送权	向他人传输 ePHI 副本

管理要求

最佳实践要求采用各种管理问题来确保合规性:

• 指定一名隐私官
• 培训员工
• 实施安全措施以防止有意和意外的泄露
• 建立投诉制度
• 制裁违反 HIPAA 政策和程序的员工

HIPAA 的安全规则意味着加密和更多

业务合作伙伴需要确保 ePHI 在传输过程中的保密性，在使用过程中的保密性&，防止对 ePHI 安全的合理预期威胁或危害，并防止隐私规则不允许的使用或披露。

从根本上说，作为 API 开发者，安全性分为三个方面:管理、物理和技术保护。

其中许多都是通用的安全最佳实践，如:保留关于评估/更改内容的审计日志，选择适当的应用程序/计算机密码，不共享密码，以及加密包含 ePHI 的便携式设备。

但有些是 HeathTech 特有的，例如:在使用后注销包含 ePHI 的应用程序，避免在口头交流、电子聊天或未加密的电子邮件中使用个人姓名、医疗记录号码或账号，及时报告 ePHI 的任何丢失或被盗，并通知隐私官 ePHI 的不当使用。

HIPAA 安全的技术保障

技术保护是 API 开发人员在构建兼容应用时将花费大部分时间的地方。为了确保 ePHI 在传输、静止和使用过程中的保密性，应该对 ePHI 进行加密，并且应该特别注意密钥分发。关于什么是合适的加密有很多讨论，HIPAA 仅仅需要一个机制来加密和解密 e-PHI ，但是采用来自 NIST 的最新建议将是一个安全的赌注。

保护	需要什么	如何在 API 环境中实现
访问控制	仅允许授权访问 ePHI 的政策	认证用户
为每个用户分配唯一的 ID
设计访问控制规则
实现自动注销
支持紧急访问 ePHI
审计控制	记录和检查对包含 ePHI 的系统的访问的正式程序	保存所有访问的 API 日志
定期运行风险评估以检查功能是否正常
完整性控制	确保 ePHI 不被不当更改或破坏的政策	跟踪对 ePHI 的任何修改
传输安全性	技术安全措施应防止在运输过程中未经授权访问 ePHI	尽可能使用客户端加密
验证是否使用了 HTTPS

作为可以支持 ePHI 的完全安全的 API 部署的示例，下面的架构显示了 Moesif 的安全代理通过内部客户端加密和自带密钥(BYOK)实现零知识安全。获得了内部安装的隐私优势，而没有构建和扩展您自己的数据基础架构的复杂性。主加密密钥从不存储在 Moesif 服务器上，相反，安全代理支持流行的密钥存储库并自动处理密钥轮换。数据在传输、存放和使用过程中都会被加密。

HIPAA 的违规通知规则会公开所有违规行为

违规被定义为以 HIPAA 隐私规则不允许的方式获取、访问、使用或披露 ePHI，从而危及 ePHI 的安全或隐私。除非根据您的风险评估，您能够证明 ePHI 受损的可能性很低，否则将被视为违规。

作为业务伙伴，如果发生违规，您需要在 60 天内通知相关实体及其客户。

对违规行为的处罚

2018 年，有超过 6.3 万起个人违反 ePHI 的行为，其中 302 起影响了 500 或更多个人，导致 OCR 处以总计 2700 万美元的罚款。

HIPAA/HITECH 定义了一个分级处罚结构，根据违规的性质和情况(包括知情和故意)可分级处罚。违规行为会公之于众，业务伙伴可能会受到民事和刑事处罚。

每次违规的民事处罚从 100 美元到 50，000 美元不等，这取决于与违规相关的知情程度或意图。违反 HIPAA 故意披露 ePHI 的业务伙伴的员工可能会被罚款高达 250，000 美元和监禁 10 年，具体取决于披露背后的意图程度。

医疗保健的颠覆时机已经成熟，而原料药是中心舞台

COVID 充当了现有趋势的催化剂，可能最深刻的错位出现在医疗保健领域。新常态将支持 HealthTech 基于垂直的 API，在幕后简化和自动化遗留业务流程。

构建自己的应用内图表？请改用 Moesif 嵌入式模板！

原文：https://www.moesif.com/blog/technical/api-analytics/Building-your-own-in-app-charts-Use-Moesif-Embedded-Templates-instead/

某些产品可以从实时图表中获益。无论是内部的还是外部的应用程序，当它们被很好地显示时，度量标准真正地变得生动起来。

在过去，要显示这样的图形，您需要实现自己的图表工具，将数据或指标映射到工具中，然后维护这个实现。总的来说，这是一种在应用程序中可视化显示数据的非常低效和麻烦的方式。

有了 Moesif ，添加令人惊叹的可视化效果来显示数据变得简单且无需维护。您在 Moesif 中发现的所有有用的图表都可以很容易地导出并嵌入到您的应用程序中。在 Moesif 中有几种方法可以做到这一点，包括使用嵌入式模板或公共链接在应用程序中显示图表。

让我们探索一下使用嵌入式模板的好处，它们是如何工作的，以及 Moesif 用户利用这一特性的一些真实例子。

为什么要使用嵌入式模板？

许多应用程序都可以从关键指标的可视化中受益。几个例子可以说明:

• 应用流量的历史视图
• 新用户注册
• 您的应用程序中遇到的错误
• 实时显示现场活动

并非所有用户都能访问贵组织的 Moesif 平台，但这并不意味着他们不能访问某些关键图表。嵌入式模板是向用户显示相关数据的好方法，允许他们定制他们的体验和可视化，即使用户不能直接访问 Moesif。

嵌入式模板使用户能够将动态图表添加到他们的应用程序中，而不需要实际编码它们。这种方法节省了时间、支持和精力，同时仍然具有自定义解决方案的所有优势，可以在应用程序和应用程序内图表中显示相关数据。

可以显示哪些类型的数据和图表？

根据您需要显示的数据，在 Moesif 中有两种方法可以做到这一点。您可以利用公共链接或嵌入模板来显示数据。

公共链接是 Moesif 中数据的静态视图。您可以在 Moesif 中设置过滤标准，并导出相应的图表。查看者无法更改标准或向图表输出动态添加变量。这是向经过身份验证和未经身份验证的用户显示特定静态数据集的最佳方式。

嵌入式模板类似于公共链接，但允许使用动态参数来检索和显示数据。根据特定用户 ID、日期范围或其他动态提供给图表呈现的标准进行过滤。这种方法对于经过身份验证的用户更可行。可以根据向查询发送什么参数来过滤或定制数据，并可以呈现相应的图表

在这篇文章中，我们将只关注嵌入式模板。关于公共链接的更多信息，请查看我们的文档。

它是如何工作的？

让嵌入式模板在您的应用程序中工作非常简单。它要求您能够访问 Moesif，拥有 API 服务器，并且能够向前端代码添加 iframe 元素。

让我们进一步分解每一步:

创建图表和/或过滤器

第一步是在 Moesif 中实际呈现一个图表。为此，您可以转到 Metrics 屏幕，添加您的过滤器，然后在屏幕上看到可视化效果。在这个例子中，我在一个实时事件日志中显示了特定用户 ID 的所有事件。

你也可以在时序图中查看相同的数据，这样我可以更容易地看到一段时间内的趋势。

至此，您已经建立了自己的过滤器，在 Moesif 中呈现了一个图表，并且可以实际生成您的嵌入模板了。

创建模板

创建要在 UI 中呈现的模板只需几次点击。在指标屏幕中，您可以单击“嵌入”，并在下拉列表中单击“创建模板”。

下一个屏幕将询问一些细节，包括工作区名称(实际上是您的模板名称)、您的共享类型(公共链接、嵌入式模板等)，以及一个用于选择您想要动态提供给模板的字段的区域。

一旦你这样做了，模板就创建好了，你会看到一些关于如何将图表添加到你的 UI 中的说明。

向 API 服务器添加端点

一旦在 Moesif 中创建了模板，就应该在 API 服务器上创建一个端点来获取数据并将其返回给 UI。返回的数据将包含您在 iframe 中实际呈现图表所需的一切，您将在前端代码中嵌入 iframe。

在 UI 中嵌入 iframe

最后，您需要在 UI 代码中添加一个 iframe 元素。您的代码将调用新的 API 端点，并将这些数据返回给 iframe 进行呈现。一旦从 Moesif(通过您的 API)返回了图表数据，您就可以在 UI 中很好地呈现图表了。

如果你想看这些步骤的更详细的演练，请查看我们关于嵌入式模板的指南。

现实世界的例子

许多 Moesif 客户依赖嵌入式模板为他们提供一种向用户显示重要指标的简单方法。这为他们节省了时间，并使得在他们的应用程序中呈现实时图表变得简单且易于维护。

pVerify ，一款实时保险资格验证软件，使用嵌入式模板帮助客户查看 API 活动和趋势。他们没有创建自己的图表和分析解决方案，而是决定使用 Moesif 轻松地向用户显示所需的信息。

pVerify 还利用 Moesif 中可用的加密来确保在使用嵌入式模板时，它们仍然符合HIPAA。这是解决方案的重要部分，因为 pVerify 处理高度机密的医疗保健信息。

pVerify 有几个例子说明他们如何使用嵌入式模板来帮助客户监控和观察他们的 API 使用情况。这包括使用 Moesif 的实时事件日志显示。

他们还使用时间序列图表来更好地显示趋势。

通过允许用户以不同的方式过滤和查看数据，用户可以轻松地查看趋势，还可以深入到各个电话中进行更详细的探索。

使用嵌入式模板使得 pVerify 只需很少的开发就可以轻松地将图表添加到应用程序中。允许他们的用户安全地进入 API 分析，这一切都由 Moesif 实现。

自己试试吧！

如果您已经在使用 Moesif，那么入门非常简单。所有 Moesif 用户都可以使用嵌入式模板，并且可以轻松添加到您现有的应用程序中。对于新用户，只需注册一个账户，集成你的 API，并开始使用嵌入式模板在你的应用程序中显示你最喜欢的图表。

缓存失效和事物命名:创业命名指南

原文：https://www.moesif.com/blog/startups/branding/Cache-Invalidation-And-Naming-Things/

给创业公司命名

创办一家公司时，首先要做的事情之一就是想出一个名字。对于 Moesif，我们在最终确定名字之前等了一会儿，但是我们不想等太久，因为太多的事情都依赖于一个真实的名字。不形成法定名称很难合并。没有公司，就没有法人实体可以开立银行账户、接受投资、发行股票和发放薪酬。这只是一个合法的名称，你总是可以为其他名称提交一个“做生意”,但最好在开始时使用正确的合法名称，以尽可能保持样板。此外，一旦决定了名称，您就可以注册域名、为员工设置电子邮件以及开设帐户。您可能不希望您的 Mailchimp 和 MixPanel 帐户位于个人电子邮件下，并且希望开始使用标准命名约定，例如以 com.moesif 开头的 moes if Java 包。

重要因素

首先，你要写下你最想成为的 5 个或 10 个名字，然后使用下面的一些策略来缩小范围。

有效性

在我们讨论其他因素之前，必须首先提供名称。我不会把我的公司命名为 Square，因为会有侵犯注册商标的法律后果，而且域名、github 名称等也不会出现。幸运的是，有一个工具https://namechk.com可以同时检查许多常见的服务，以查看该名称是否可用，如 Twitter 句柄、Github 名称、域名等。你仍然需要检查以确保你的名字没有侵犯现有的商标。

SEO/SERP

搜索引擎优化(SEO)和搜索引擎结果页面(SERP)是创业所需的硬艺术之一，但也是一个非常重要的增长渠道。一些行业比电子商务等其他行业更依赖 SEO，但 SEO 通常对大多数初创公司都很重要。如果我用谷歌搜索 Moesif，只有 2440 个结果。如果有人搜索 Moesif，我不必在 SEO 优化方面努力确保 Moesif 在搜索结果的第一页。如果我选择类似于 Errorless 的东西，已经返回了 500，000 个结果。总会有像 mint.com 这样的创业公司逆潮流而动，但你只需要制定出你的 SEO 策略。即使你的主要平台是移动应用而不是网站，应用商店优化(ASO)也同样重要。

记忆和拼写

这是一个棘手的问题，因为独特的名称有利于搜索引擎优化可能会违背一个不同的因素:容易记住和容易拼写。

拼写很难出错

你的名字和它的发音一样吗？如果你在建立一个社交网络，你是在依靠病毒式增长。如果你的 iOS 应用程序的一个用户在酒吧向他/她的朋友展示该应用程序，你要确保他/她的朋友在第二天早上能记住该应用程序的名称。如果很难拼写，那么他/她可能会放弃尝试通过谷歌或应用程序商店找到它。如果应用程序的名称是“Happi ”,朋友可能不记得它是如何拼写的，而只是搜索“happy”。Tumblr 可能运气不错，但情况可能并不总是如此。

难以颠倒顺序

假设你有一家 SaaS 公司，名字叫 Cloudfire，它是由两个词组合而成的。这很容易拼写，所以没有问题；然而，还有第二个问题。反过来说，Firecloud 听起来也是一个很好的名字。这可能会导致一些早期的混淆，因为 Firecloud 和 Cloudfire 听起来都像合法的名称。这并不意味着你不能组合两个词来创造一个名字，不正确的排序应该听起来很尴尬，导致排序大多是单向的。脸书听起来比书呆子好多了。Mixpanel 也很不错，因为 Mixpanel 听起来比 Panelmix 好得多

使用数据

杰夫·贝索斯有一句名言，他选择以字母“A”开头的名字，因为许多目录都是按字母顺序排列的。想想有多少次你在价格聚合器上找到一个产品，然后按字母顺序列出可用的商家。在名字的第一个字母中可能有其他的暗示，正如红点http://tomtunguz.com/startup-names/的汤姆·通古兹所展示的，他试图将投资额与初创公司名字的第一个字符联系起来。尽管请记住，与任何数据挖掘一样，相关性并不总是意味着因果关系。

不要自我设限

Loggly 是一个可爱的名字，听起来很滑稽，也是几年前发生的名词+“-ly”潮流的一部分；然而，一个问题是它可能过于自我限制。Loggly 是描述性的，但是如果 Loggly 扩展到日志之外呢？例如，Splunk 关注的不仅仅是服务器日志。这并不意味着这就是一切，结束一切，因为 Loggly 仍在前进。

小心趋势。

拉夫·劳伦的服装能够经受住时间的考验，尽管可能不如普拉达或其他品牌时尚。当提到命名的趋势时要小心。有一段时间，许多初创公司在名称中添加“实验室”，以隶属于贝尔实验室等知名实验室。一个游戏工作室可能意味着有许多单独的实验，其中一些游戏会失败，但有一个有希望成为热门。随着时间的推移，“实验室”变得被过度使用，人们认为添加实验室稀释了公司的核心使命，因此在公司名称中添加“实验室”不再流行。同样，“-ly”的名字也曾流行过一段时间，但现在听起来已经过时了。

个人关系

如果有个人关系(除了创始人的名字)，这使它更像一个商店，那么这可能是一个好处。我们的下一篇文章将解释为什么 Moesif 与创始人的背景有关。

谢谢

我们感谢我们的精选测试版客户，他们一直在试用 Moesif，为我们提供了宝贵的反馈，使调试变得更加容易。

您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易

了解更多信息

API 程序的 CCPA 要求和符合性清单

原文：https://www.moesif.com/blog/business/compliance/CCPA-Requirements-and-Compliance-Checklist-for-API-Programs/

法律免责声明:以上所述并非法律建议。它仅供参考。你应该与法律和其他专业顾问密切合作，以确定 CCPA 可能适用于或不适用于你，以及你应该如何遵守。

CCPA 要求和符合性清单

加州新隐私法于 2020 年 1 月 1 日生效。现在是检查你是否需要遵守的好时机。如果有，应该采取什么措施来确保平稳运行。

在最基本的层面上，2018 年加州消费者隐私法案(CCPA) 授予加州居民关于如何收集和使用他们的数据的权利。

CCPA 加大了消费者隐私的赌注

其独特之处在于，这是美国第一部为数据泄露提供赔偿的法规，大大增加了集体诉讼的几率。参见库利- CCPA 常见问题解答第 3 部分:诉讼、监管行动和责任了解更多信息。它还扩大了个人信息的定义，包括一个扩展的项目列表，甚至是推论(准个人身份信息)。

个人信息包括… 从数据来源得出的推论“创建反映消费者偏好、特征、心理趋势、偏好、倾向、行为、态度、智力、能力和资质的消费者档案。”

最后，它适用于加州居民(基本上是那些在加州缴纳所得税的人)， 而不考虑 他们的数据被收集时所在的位置。

其他 11 个州也在效仿加州，他们自己版本的数据隐私法将在 2020 年通过立法机构。即使你认为你不需要遵守今天的 CCPA，加州法律的许多元素可能在不久的将来适用于你。

需要遵守吗？

这项规定并不适用于所有企业，而且不像 GDPR，它是一项选择退出的法律；不是选择加入。具体来说，它针对的是拥有加州居民信息并符合以下标准之一的营利性企业:

• 收入超过 2500 万美元
• 收集超过 50，000 个人、家庭或设备的个人信息
• 至少 50%的收入来自销售消费者信息

CCPA 反对出售或共享个人身份数据，他们将其定义为“出于金钱或其他有价值的考虑，向第三方出售、出租、发布、披露……个人信息”

如何遵守？

合规性在很大程度上取决于隐私最佳实践的实施。一般来说，需要满足两方面的要求:

1. 通过隐私声明、服务条款、数据处理协议、政策等告知消费者所收集、披露或出售的个人信息的类别，以及这些信息的用途
2. 实施协议，以便消费者可以请求、查看和删除或以其他方式限制其信息的共享。

我们建议你寻求专业建议来修改你的法律声明，尽管网上有太多的信息可以帮助你。

收到信息请求后，有必要制定以下协议来尊重数据主体的权利:

权利	要提供什么
披露权	有权知道企业收集了哪些关于他们的个人信息，这些信息的来源、用途、是否被披露或出售，以及向谁披露或出售
删除权	删除任何个人信息的权利
退出的权利	选择不允许将个人信息出售给第三方的权利
不受歧视的权利	从企业获得同等服务和价格的权利，即使他们根据法案行使隐私权

协议需要在收到可验证请求的 45 天内完成，因此自动化是关键。

未能遵守

该法律规定，可以通过两种方式实施处罚:

1. 对于故意违规，每次违规的民事处罚高达 7，500 美元，但有 30 天的补救期，
2. 对于数据泄露，消费者可以单独起诉，也可以集体起诉，每次事件的法定赔偿金额从每位居民 100 美元到 750 美元不等。

将这些数字乘以数百万消费者，损失会迅速增加。

加州司法部长计算CCPA 将使企业损失 550 亿美元，75%的加州公司将受到影响。通过遵循隐私最佳实践并从一开始就符合 CCPA 的规则和政策，可以降低成本。

CCPA 如何影响 API 程序？

CCPA 不仅仅停留在一个面向消费者的网站。作为 API 计划的一部分，您可能已经在为 API 日志记录和监控、用户行为分析、安全检查和其他关键业务活动收集个人身份信息。这意味着您需要审核您的内部流程和数据管理，以确保它们符合 CCPA(和 GDPR)的要求。幸运的是，CCPA 已经根据第 1798 条定义了 7 类业务目的，具体如下:

1. 审核与消费者的互动
2. 安全性
3. 调试/维修
4. 某些短期用途
5. 履行服务
6. 技术开发的内部研究
7. 质量和安全维护和验证

这意味着，只要你不出售或分享个人信息以换取金钱或同等价值的东西，如果你只利用 API analytics 所属的 7 个类别之一的数据，你的风险就较低。因为即使是用于合法业务目的的数据也会使您的组织面临风险，所以确保您拥有正确的流程和基础架构来处理 CCPA 和 GDPR 的请求非常重要。

有助于这一过程的一种方法是用生成数据的用户来标记组织内的每一条数据。像 Moesif 这样的 API 分析服务今天已经这样做了，以使合规性自动满足数据主体的请求。这使得非技术用户只需点击几下就能处理 CCPA 主题请求，而不是让您的内部数据工程团队过载 CCPA 主题请求。

原料药的重要程序

不允许匿名访问

不允许匿名访问你的 API。否则，您可能很难审核是谁访问了这些数据，这不仅是为了遵守 CCPA，也是为了帮助进行安全审查。您的 API 应该只允许注册用户访问数据，这通常是通过某种 API 键或令牌来完成的。API 的每个用户都应该有一个主要联系人。

记录对个人数据的访问

作为 API 监控和分析基础设施的一部分，您应该记录对个人数据的每次读写操作。CRUD APIs 是实现这一点的自然方法，因为无论客户端是什么(web 应用程序、合作伙伴程序、内部消费者等)，每次访问都必须通过您的 API。您还应该在一段时间后停用或使用假名这些数据。

不要使用 excel 或手工处理

不要只是将主题请求存储在 Google Sheet 或 Excel 文档中，然后让开发人员手动删除。任何存储个人数据的数据基础设施都应该有一组干净的 API 或 UI 来处理数据主体请求，并在操作完成时有时间戳的审计日志，以确保您的内部流程不会出错。审计日志应该能够在法庭上站得住脚。

选择退出的权利对于试图实现 CCPA 合规性的组织来说，请求是一个棘手的问题，因为数据和工程团队不仅需要构建基础架构来访问和删除用户的历史数据，还需要基础架构来防止未来的数据收集。当扩展到每天数十亿次 API 调用时，必须正确实现这种数据抑制逻辑。

虽然，你可能无法在截止日期前达标，但许多其他人也有同样的情况，据一些人估计高达 50%。好消息是强制执行要到 2020 年中期才会生效。鉴于加州司法部长最近的声明，现在开始为时不晚。

在 NodeJS 栈中为 REST APIs 选择库和框架

原文：https://www.moesif.com/blog/nodejs/frameworks/Choosing-the-Libraries-and-Frameworks-for-REST-APIs-in-the-NodeJS-Stack/

有很多在 NodeJs 上构建 RESTful APIs 的教程，但这些教程通常已经选择了库或框架。本指南旨在提供各种库和设计决策的比较。

介绍

如果将 RESTful APIs 归结为通过 HTTPs 的请求，并通过 JSON 进行通信(大多数情况下)，在 NodeJS 中创建API 会非常简单。

var express = require('express');
var app = express();

app.get('/greeting', function (req, res) {
  res.json({ hello: 'world' });
}); 

我们需要了解帮助我们构建 API 的每一层的设计原则和技术，然后我们可以回过头来选择对我们有帮助的工具和库。

REST 设计原则概述

让我们回顾一下什么是好的 RESTful API 设计。您应该遵循的一些核心原则:

• 语义上有意义:
  • URI 端点应该是资源(即名词)和人类可读的，如/items或/users。功能或操作不是资源。
  • HTTP 动词(GET、POST、PUT、DELETE)表示客户端可以对资源采取的动作。
  • HTTP 响应代码(例如，201(已创建)、404(未找到)和401(未授权))表示发生了什么。
  • 关系可以表示为子资源。同样，它使东西可读。例如，/authors/{id}/posts endpoint 将代表特定作者的帖子。
• 无状态:服务器不需要代表客户端保存状态。这使得扩展 REST APIs 变得容易，因为一个新的请求可以访问负载均衡器后面的任何虚拟机。在请求之间维护临时游标或存储临时文件不是无状态的。
• 优雅地处理重复来电:
  • 可缓存性:GET 和 HEAD 方法通常被缓存。当考虑可变性时，您的 API 应该考虑这一点。
  • 幂等性:对于改变一个资源的状态的动作，“PUT”和“DELETE”，对于相同数据的重复调用会产生相同的结果。
  • Safe: GET、HEAD、OPTIONS 和 TRACE，对于 readonly，不改变状态。

当然，在设计上有许多自以为是的建议，比如命名资源的最佳方式(camel case vs . snake _ case vs . spinal-case，复数 vs .单数)，设置 JSON 模式名称的最佳方式(信封 vs 无信封)，符合 HATEOAS，如何最好地处理过滤器&分页等等。在做出选择之前，请务必阅读并理解它们，这些设计决策应该在您做出任何技术决策之前做出。

设置 Restful API 的主要技术层。

• HTTP 服务器和路由器。
• 数据
• 安全性
• 代理人

HTTP 服务器和路由器

NodeJS 自带一个 Http 服务器。

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    res.write(req.url);
    res.end();
}).listen(8080); 

这个默认服务器不处理我们用来定义端点的路由。我们希望能够将GET /users路由到一个函数，将GET /items路由到另一个函数。由于 HTTP 动词、路径和参数的许多组合，路由可能会变得复杂，但幸运的是，除了用于构建 REST APIs 的其他关键中间件之外，我们还有许多可以处理路由的框架。

• express 是目前最流行的构建 REST APIs 的框架。这也是 Moesif 发布的第一个框架，也是我们最受欢迎的集成。Express 相信组合和代码胜于配置。您的路线直接编码在业务逻辑的旁边。没有集中的“routes.conf”或类似的文件。尽管这个框架很老，但它依靠可选的中间件来保持精简。因此，如果您正在构建一个 REST API，您不会像启用 HTML 模板引擎和 cookie 解析器那样额外膨胀。下面是一个快速路线的例子。

router.get('/:id', function (req, res) {
  // ... where id is parameterized.
}); 

• Koa Koa 被列出，尽管它不支持路由。但是，在某些情况下，它是 Express 的替代选项。，但人们总是把它列为 Express 的替代，你可以单独添加 Koa 路由器。最初创建 Koa 是为了避开回调地狱，这在 express 中很容易发生。Koa 从 co 开始处理 ES2016 之前的异步调用，支持async和await。

• hapi 是由 WalmartLabs 创造的。它遵循配置胜于代码的理念。它从节点的 HTTP 模块中提供了比其他模块更高的抽象层次。

代码如下所示:

server.route({
    method: 'GET',
    path: '/{name}',
    handler: function (request, reply) {
          // ... where name is parameterized
    }
}); 

• restify 是专为 RESTful API 设计的，所以它删除了 express 的一些功能，如 HTML 模板和视图，但增加了 API 所需的其他内置功能，如速率限制和 SPDY 支持。Restify 的语法和 express 非常相似。

我们总是可以添加中间件来为每个框架添加功能和特性。点击此处查看关于中间件的深入文章。

JSON 反序列化

Javascript 原生支持JSON.parse(my_json_string)或JSON.stringify(my_javascript_object)。然而，如果这是自动的和幕后的，生活会更容易。

• 如果使用 Express，可以使用默认的主体解析器中间件。它支持多种类型的文本和二进制数据，当然还有 JSON，4 种最常用的格式 RESTful APIs。

var express = require('express')
var bodyParser = require('body-parser')
var app = express()
// parse application/json
app.use(bodyParser.json()) 

数据库

一旦您选择了一个数据库，您选择的库将主要由与该数据库兼容的内容驱动。节点。JS 生态系统包括许多不同数据库的驱动程序，从 mongojs ，到 mysql ，以及 PostgreSQL 。

虽然每个数据库都有 NodeJS 中的驱动程序，但是您可能希望考虑使用 ORM(对象关系映射),而不管是 SQL 还是非 SQL 技术。ORM 在 Enterprise Java 和 C#世界中已经使用了很长时间，Node.js 也没有什么不同，即使在 Node.js 和 MongoDb 中有原生的 JSON 支持。ORM 允许您在代码中将数据库模式建模为对象，然后 ORM 管理从实际数据库中检索/更新数据，并将它们映射到代码中的域对象。对于需要模式迁移的数据库，ORM 可以简化这个过程。

Node.js 生态系统中的一些常见 ORM:

• mongose:本质上是 MongoDB 的 ORM。鉴于平均堆栈的流行，这是非常受欢迎的。
• Sequelizejs :基于承诺，适用于 PostgreSQL、MySQL、SQLite 和 MSSQL。
• orm :创意命名。
• 书架:构建在 Knex.js 之上，一个查询构建器。
• waterline : Waterline 使用适配器的概念将一组预定义的方法翻译成查询。它还支持各种 SQL 和非 SQL 数据库。

安全性

我们建议回顾一下为 RESTful API 构建认证和授权的步骤，权衡您的认证架构中的各种选项，例如比较 JWT(JSON Web 令牌)与不透明令牌，比较 cookies 与 HTTP 头。

JWT 代币资源

JWT 令牌实际上是一个完整的 JSON 对象，已经过 base64 编码，然后使用对称共享密钥或使用公钥/私钥对进行签名。如果您决定将 JWT 作为您的身份验证令牌，有几个库可以帮助您。

jsonwebtoken 是一个用于签署 jwt 的通用实用程序库。

要为用户生成令牌，请执行以下操作:

var jwt = require('jsonwebtoken');
jwt.sign({
  exp: Math.floor(Date.now() / 1000) + (60 * 60),
  data: 'foobar'
}, 'secret'); 

令牌可以包含任何 JSON，比如 user_id 和允许的范围或角色。

jwt.sign({
  exp: Math.floor(Date.now() / 1000) + (60 * 60),
  admin: true
}, 'secret'); 

因为令牌是使用您的秘密签名的，所以您可以保证令牌没有被恶意方篡改或修改。

尽管您也可以使用 jsonwebtoken 库来解码和验证您接收到的 JWT，但是有另一个库使它更容易与 HTTP 服务器和路由器集成。

express-jwt 是 Auth0 提供的一个开源库，它可以与任何遵循 express like 中间件约定的标准路由器/服务器一起工作。这确保您的令牌已经过检查，并且 base64 解码供您的业务逻辑使用。

使用它非常简单:

var jwtMiddleware = require('express-jwt');

app.get('/protected',
  jwtMiddleware({secret: 'your secret'}),
  function(req, res) {
    if (!req.user.admin) return res.sendStatus(401);
    res.sendStatus(200);
  }); 

您用您的验证密钥初始化中间件，这使中间件能够检查令牌是否由您的秘密签名。base64 解码字段填充在req.user中。

请注意，在将任何代码投入生产使用之前，请审核您的代码。这些例子非常简单，需要做更多的工作才能锁定并投入生产。

不透明代币

如果您选择使用不透明令牌策略，则授权信息(即允许用户访问的内容没有编码在令牌中)，因此需要在 Redis 等数据库中进行查找。

所以这里你需要两项技术。一个处理逻辑的中间件，一个基于 O(1)哈希的数据库，用于查找权限和其他数据。O(1)非常重要，因为每次 API 调用都要调用它。例如，redis 将是一个不错的选择。

至于要使用的中间件，最流行的是 passport.js ，因为它支持许多策略(包括 JWT)。然而，您最有可能对 REST APIs 使用载体策略。这里的授权策略是使用passport.js来确定用户是谁(例如 userId )，然后在 Redis 中查找您授予该 userId 的权限，然后决定是否可以调用 API。

限速

速率限制对于防止 DDoS 攻击或雄心勃勃的自由层用户非常重要。一种与语言无关的方法是使用 API 网关，如 Tyk 或 Apigee 来处理您的 API 管理需求。也有中间件为你处理这些，比如快速限速

反向代理

我们创建的许多 API 将被放在反向代理后面。反向代理可以处理到许多服务和这些服务的版本的高级路由。反向代理还可以处理安全性、日志记录和缓存原因。

Nginx 和 HaProxy 是两个非常流行的高性能 HTTP 代理，但是需要大量的配置工作。Node.js 生态系统有一个非常简单但性能不错的代理，叫做 node-http-proxy ，可以直接在 Node.js 应用中运行。

附加选项

自动生成 API

即使使用路由框架，编写所有的路由回调仍然需要大量的手工工作。如果您的应用程序主要需要 CRUD(创建、读取、更新、删除)操作，而没有大量的自定义逻辑，那么您可以研究更高级别的样板框架，它们可以位于您的数据库前面，并直接基于数据模型生成端点。

• loopback 由 IBM 子公司 StrongLoop 提供支持。它被定位为一个成熟的框架，允许您快速创建主要由数据库驱动的 API。有许多工具可以不费吹灰之力地插入 loopback，例如:Swagger、ORM/ODM(杂耍)和访问级别控制。它采用了约定优于配置的理念，并基于您的模式生成路由。请记住，如果你开始编写不同于常规的东西，框架可能会受到限制。

• Nodal 是一个固执己见的框架，它能为你做很多决定，让你快速开始。生成的路线基于您定义的控制器类别。

• 假设您构建的每个 API 都有需要支持 CRUD 操作的数据对象集合。它还提供了用于创建 API 的 web UI 界面。

• 生成器和样板文件:基于 Yeoman 的生成器很少，它们可以自动设置 API。

Web 套接字

有一些框架允许你使用 WebSockets 而不是 HTTP 来服务你的 API。这对于某些实时应用程序(如聊天应用程序和游戏)非常有用。请记住，web sockets 仍然比典型的 HTTP REST API 更难扩展，并且工具更少。在某些方面，web sockets 是反 REST 的。

• 风帆
• 特性 jss

结论

NodeJS 生态系统可能是更灵活的生态系统之一，并成为构建由流行框架(如 Express 和 React)驱动的 API 的最大生态系统。从而比大多数其他生态系统(如 Ruby 或 Python)允许更多选择。根据我们的使用数据，Node.js 是构建 REST API最流行的

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

了解更多

使用元掩码开发以太坊 dApps 的常见问题

原文：https://www.moesif.com/blog/blockchain/ethereum/Common-Problems-Developing-Ethereum-DApps-With-Metamask/

在我写了一篇关于构建一个集成 Web3 监控的以太坊 DApp 的教程之后，我收到了许多公开和私下的问题。这篇文章收集了一些答案来帮助你开发以太坊 dApps。

未连接到网络

首先，了解将您的 DApp 连接到区块链网络的逻辑。示例 getWeb3.js 实现了连接到 Web3 网络的一种常见模式。

它检查是否有一个web3对象已经被注入到全局作用域中。如果没有，代码会尝试连接到 truffle 在本地运行的测试网络。

在生产中，您的 dApp 的许多用户可能正在使用 Metamask、Mist 或其他以太坊客户端，这些客户端会自动注入 web3 对象并连接到本地或远程以太坊节点。

因此，如果您已经运行了元掩码，元掩码就会将一个web3对象注入到全局作用域中。因为教程示例使用的是 truffle 的测试网络，所以现在您可能想关闭 Metamask 扩展。

让示例使用元掩码

有两件事你需要弄清楚:

• 您计划使用元掩码连接到哪个网络？如果是另一个测试网络还好。确保你有所有需要的数据。
• 您的合同是否部署到元掩码将连接的网络。

将合同部署到不同的网络

在教程示例中，合同被部署到 truffle 开发网络，该网络是在运行truffle develop时创建的。节点在http://127.0.0.1:9545可用。

如果您想要部署到另一个网络，例如ganach，那么您需要修改truffle.js文件。

module.exports = {
  // See <http://truffleframework.com/docs/advanced/configuration>
  // to customize your Truffle configuration!

  networks: {
    ganache: {
      host: "127.0.0.1",
      port: 7545,
      network_id: "*"
    },
    development: {
      host: "127.0.0.1",
      port: 9545,
      network_id: "*" // Match any network id
    }
  }
}; 

然后你需要跑

truffle compile

truffle migrate --network ganache 

当然，用您选择的名称和设置替换 ganache 设置。

如何找到我刚刚部署的智能合约的地址

有几种方法。

首先，当您运行 migrate 命令来部署协定时，该地址会显示在命令行输出中。

Running migration: 1_initial_migration.js
  Replacing Migrations...
  ... 0xbf9932f55ba158d95f4ed41632cf2558c9ce63a63591e6cf45a5b58db435a598
  Migrations: 0x8cdaf0cd259887258bc13a92c0a6da92698644c0
Saving successful migration to network...
  ... 0xd7bc86d31bee32fa3988f1c1eabce403a1b5d570340a3a9cdba53a472ee8c956
Saving artifacts...
Running migration: 2_deploy_contracts.js
  Replacing SimpleStorage...
  ... 0xa19fe7f1c68b20bc7c58ad270cee58767248eef7fa7e58ad847855582f8f1212
  SimpleStorage: 0x345ca3e014aaf5dca488057592ee47305d9b3e10
Saving successful migration to network...
  ... 0xf36163615f41ef7ed8f4a8f192149a0bf633fe1a2398ce001bf44c43dc7bdda0
Saving artifacts... 

请注意:simple storage:0x 345 ca 3e 014 AAF 5 DCA 488057592 ee 47305 d9 B3 e 10

第二种方式:如果您在SimpleStorage.json打开 JSON 工件，您将看到关于它被部署到的地址和网络的数据。

 "networks": {
    "4447": {
      "events": {},
      "links": {},
      "address": "0x345ca3e014aaf5dca488057592ee47305d9b3e10",
      "transactionHash": "0xa19fe7f1c68b20bc7c58ad270cee58767248eef7fa7e58ad847855582f8f1212"
    }
  }, 

第三种方式，在您的 dApp 代码中，如果您有一个已部署契约的实例，就可以获得地址。

const simpleStorage = contract(SimpleStorageContract)
simpleStorage.setProvider(this.state.web3.currentProvider)

simpleStorage.deployed().then((instance) => {
// now you have the instance of the deployed contract, you can get the address.
  console.log(instance.address)
}); 

收件人地址不是合同地址

当您切换到不同的网络时，您需要将合同部署到正确的网络；但是，当您尝试再次运行 migrate 时，可能会出现如下错误。

 Attempting to run transaction which calls a contract function, but recipient address 0x8cdaf0cd259887258bc13a92c0a6da92698644c0 is not a contract address 

要解决这个问题，删除build/contracts下的 JSON 文件，因为这些 JSON 文件有关于它被部署到哪里的元数据。

另一个解决方法是尝试truffle migrate --reset。

我发起了一项交易，但我没有看到任何变化

这可能发生在将网络切换到元掩码并连接之后。

对于每一个使用 ether 的事务，Metamask 将明确地请求用户允许该事务。有时权限弹出窗口是隐藏的。如果发生这种情况，请手动打开元掩码弹出窗口并授予事务权限。

在教程示例中，第一个事务试图设置存储，这会消耗汽油。如果您没有看到存储被设置为 5，请单击元掩码以查看它是否在启动第一个事务之前等待您的批准。

元掩码随机数问题:错误:tx 没有正确的随机数。

如果你使用元掩码进行开发和测试，有时你会看到这样的错误:

message:"Error: Error: [ethjs-rpc] rpc error with payload {"id":8318498190067,"jsonrpc":"2.0","params":["0xf88914843b9aca0082f3ff94345ca3e014aaf5dca488057592ee47305d9b3e1080a460fe47b10000000000000000000000000000000000000000000000000000000000000019822d46a0a3ecf94d503161fbbf914c90c0b18fedf86a382b126314d71b5ec11bf0985b92a0468281983291f396cd02c80f4428898e51d258f57548ddf483da08962a02ad22"],"method":"eth_sendRawTransaction"} Error: Error: the tx doesn't have the correct nonce. account has nonce of: 4 tx has nonce of: 20 

这是在您重新启动测试网络或从另一个测试网络重新启动时造成的。元掩码中的缓存事务历史记录与网络历史记录不匹配。

要解决此问题，请打开 Metamask 中的“设置”选项卡，然后单击重置网络的。

我更换了 web3 提供者，但是我再也看不到 Moesif 捕获的事件了。

默认情况下， Moesif 浏览器 JS SDK 试图在XMLHttpRequest层捕获数据。如果检测到全局 web3 对象，如 Metamask 或 Mist 注入的 web3 对象，Moesif 将检测 web3 对象。

在一些高级场景中，您决定修改全局web3对象，比如创建一个新的 web3 对象或修改底层提供者。例如，你的 dApp 允许用户更换网络或提供商。

对于这些情况，您需要将新的 web3 对象传递给 Moesif，以确保它被正确地插装，这可以通过useWeb3()方法来完成。

moesif.useWeb3(myNewWeb3); 

在 Moesif 中，我看到重复的事件

如前所述， Moesif Browser JS SDK 通过 XMLHttpRequest 和 web3 两种方式捕获数据。

如果您的底层提供者也使用像HTTPProvider这样的XMLHttpRequest，就会发生这种情况。这是可以的，也是意料之中的。

在web3层捕获的所有事件都有一个名为_web3的附加元数据字段，它存储有关使用哪个 web3 的信息。

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

了解更多

开源 API 分析和监控工具的比较

原文：https://www.moesif.com/blog/technical/api-analytics/Comparison-of-Open-Source-API-Analytics-and-Monitoring-Tools/

对于任何以 API 为先的公司来说，实施正确的 API 分析平台对于跟踪 API 的利用率以及发现任何可能影响客户的性能或功能问题都至关重要。您可以利用各种开源项目来构建一个完整的 API 分析平台。

在开始自己构建 API 分析解决方案之前，您应该首先列出您的需求和用例。并非所有工具都直接支持所有用例，并且可能需要在开发和集成方面进行大量投资。

API 分析构建要求

需要回答工程或业务问题

工程师通常求助于 API 日志和指标来了解他们的 API 上发生了什么，检查有效负载，以及他们的服务出现的根本原因问题。实时 API 日志记录功能对于希望依靠其 API 分析解决方案来扑灭因 API 中断或可靠性问题而引发的火灾(希望是远火或少火)的工程师来说是必不可少的。因为实时日志记录会增加计算和存储成本，所以并非所有分析基础架构都维护实时管道。另一方面，只需要最近的数据来回答消防工程问题，因此数据可以在短时间周期后例如 24 小时后被停用。

工程和产品领导基于线而不是点做出战略决策。商业问题是从数据的历史趋势中得到答案的，这些数据可能超过几个月甚至几年。这意味着您的 API 分析构建应该能够长期存储数据，例如多年。这还需要能够汇总和压缩数据的基础架构，因为在原始事件日志上存储和运行聚合会削弱您的分析基础架构

实时警报和监控？

虽然构建仪表板并将其显示在监视器上是监视您的指标的一种很好的方式，但仍然需要定期手动检查它们。为了变得更加主动，许多 API 分析版本还具有某种监控和警报功能。从简单的基于阈值的警报(当指标达到某个值时发送电子邮件)到复杂的监控规则和工作流(可以实时执行复杂的聚合，并将警报发送到 PagerDuty 和 BigPanda 等事件响应平台),情况各不相同。

一些面向客户的团队，如开发人员关系和客户成功，可能希望构建自动化的工作流，以基于复杂的用户行为流通知客户或内部特定的内部利益相关者。

随处访问数据与受控访问

后 COVID 时代加速了在家工作的转变。这意味着您的 API 分析构建的内部用户可能需要在家庭网络上或在没有 VPN 的情况下访问指标。对访问 API 数据设置不必要的安全限制可能会限制您的 API 分析为您的公司提供的价值，甚至可能适得其反，造成不良习惯，如密码共享或将大量数据导出到个人设备，而不是按照设计的方式使用 API 分析构建。

另一方面，从任何地方提供自助式 API 分析也意味着拥有强大的安全性和访问控制。如果您认为将来可能需要典型的企业访问控制，如单点登录和基于角色的访问控制，那么您应该相应地规划您的 API 分析构建，即使不是立即需要。拆除和更改身份验证和授权设计并不是一件容易的事情，可能会导致完全重写。你不希望措手不及，成为未能预示典型未来增强的工程师。

可视化的灵活性

虽然大多数分析平台可以显示事件数据或绘制一段时间内的基本单值指标，但您的平台也可以用于更高级和更专业的分析，如漏斗分析或群组保持分析。这些是营销和发展团队等业务职能部门使用的常见查询，但开发人员自己很少使用。然而，如果没有使用正确的数据模型，构建漏斗可能是一项挑战。

很多时候，您不知道需要显示什么类型的查询，但是应该选择一个在数据模型和可视化层都支持灵活性的项目。

比较

有各种各样的开源分析和监控项目。有些专注于监控基础设施指标，如 Kibana 和 Grafana。而其他人更专注于网络分析，如 Matomo(也称为 Piwik)。虽然这些都不是为 API 产品设计的，但您可以开发定制代码，将一些组件拼凑在一起，构建一个开源 API 分析平台

Kibana

对于工程师来说，Kibana 是事实上的开源日志可视化工具之一。它是官方 ELK stack(Elasticsearch Logstash Kibana)的一部分，由于它与 elastic search 的紧密集成，相对于 Grafana 等设置复杂得多的工具，它是最快的可视化工具之一。Elasticsearch 本身非常适合高基数、高维度的日志数据，这是 API 日志所必须的。不利的一面是，Kibana 只与 Elasticsearch 兼容。如果您想要可视化存储在 SQL 数据库或其他数据存储中的数据，您需要到其他地方寻找。

虽然可以快速设置，但 Kibana 在可视化类型和支持的灵活性方面也相当有限。Kibana 的主要用例是提供日志搜索和对原始事件数据的简单分析，而不是提供真正的 API 监控工具。对于调试用例来说，这可能已经足够了，但是像漏斗和保留分析这样的流行业务度量不能由 Kibana 执行，这限制了它在工程团队之外的应用。

Kibana 和 Elasticsearch 被设计为与 Logstash 实例配对，该实例使您能够设计一个日志管道来处理和丰富 API 日志，例如标准化任何 HTTP 头或向每个 API 调用添加地理 IP 信息。请记住，Logstash 不能一次跨多个事件执行聚合。这种处理需要一个单独的集群计算框架来进行 map-reduce 操作，如 Spark 或 Hadoop。

Kibana 是为您希望以特别的方式浏览数据而不是创建每日仪表板的用例而设计的。您可以利用 Elasticsearch query DSL 或 Lucene 查询语法来提供极大的灵活性，但这些确实有一个陡峭的学习曲线。

默认情况下，Kibana 纯粹是一个可视化工具，这意味着像警报、异常检测和身份验证这样的事情是独立的。这意味着任何可以访问您的 Kibana 端点的人都可以访问您的数据，所以您不应该公开它。

但是，您可以购买并安装 Elasticsearch X-Pack，以获得一些监控功能和访问控制。

格拉夫纳

与专注于日志搜索的 Kibana 不同，Grafana 专注于基于时间序列的指标。您可以可视化各种数据库中的数据，包括 Elasticsearch、InfluxDb、OpenTSDB、Graphite 和 Prometheus。Grafana 做了一件事，而且有一件事做得非常好，那就是用漂亮的仪表板可视化存储在数据库中的时间序列指标。这就把其他所有事情都留给了您，包括配置数据源和将数据处理成可以由 Grafana 显示的时间序列度量。

与 Kibana 相比，Grafana 只处理已经存储在数据库中的时间序列数据，没有任何实时日志搜索，也无法以特别的方式浏览或探索原始数据。Grafana 的主要用例是设计一个仪表板来定期监控时间序列指标，比如在办公室的电视上。例如，您可能希望显示服务器的磁盘利用率、系统 CPI 和每分钟请求数。Grafana 有许多选项可以按照您想要的方式显示您的指标，例如使用基数 2 单位和基于百分比的指标显示存储容量。

由于其基于时间序列的架构，Grafana 在 API 调用的高基数、高维度分析方面的应用是有限的。相反，您需要花时间提前决定您想要跟踪的具体时间序列指标，并相应地对您的数据进行建模。这也限制了 Grafna 的自助式数据探索用例，业务用户可能会在您希望使用多个 group by 的进行细分或关联数据中的多个维度的地方寻找。

与 Kibana 相比，Grafana 以对认证和访问控制的内置支持而闻名。您还可以将 Grafana 实例连接到外部轻量级目录访问协议(LDAP)服务器或 SQL server，以便更好地控制企业设置中的访问。

您还可以将 Grafana 连接到 PagerDuty 等事件响应平台，从您的 Grafana 实例创建和触发警报。请记住，这些警报仅限于您已经在 Grafana 中监控的相同时间序列指标。

Grafana 确实有一个名为 Loiki 的独立产品，它提供了 Kibana 拥有的一些日志探索功能。

贼鸥

像专注于时间序列度量的 Grafana 一样，Jaeger 有一件事做得很好，那就是可视化分布式轨迹。这使得 Jaeger 与 Grafana 和 Kibana 相比有点不同，因为每个跟踪都是单独创建和查看的，而不是随时间监控指标或日志。当请求通过服务网格传播或命中微服务架构中的各种服务时，跟踪是所有上下文和计时信息的快照。因为跟踪生成的开销很大，所以通常采用采样来对每 X 个请求或特定标准进行快照。

与专注于监控时间序列指标的 Grafana 和专注于日志搜索的 Kibana 不同，Jaeger 专注于导致服务网格特定问题或依赖性问题的根源。Jaeger 支持多种数据源，如 Grafana，包括 Cassandra 和 Elasticsearch。

因为跟踪是独立创建的，所以唯一的视图就是预期的跟踪视图。没有办法随着时间的推移创造趋势。Jaeger 也没有任何警报或监控功能，所以你仍然需要一个 Grafana 或类似的实例。

穆塞夫

许多 API 团队发现需要大量的工具来满足他们的监控需求。Grafana 有时间序列指标，而 Kibana 支持日志搜索。一个更快的选择是专门为像 Moesif 这样的 API 产品设计的端到端解决方案。与需要预先计划时间序列指标的 Grafana 不同，Moesif 旨在使用高基数、高维 API 分析进行临时数据探索，这对于希望根据 API 使用数据做出战略决策的产品和工程领导者来说是必不可少的。

与 Kibana 和 Grafana 等基础设施监控工具相比，Moesif 利用了一个以用户为中心的数据模型,通过将 API 指标绑定到单个客户而不是基础设施，使您能够将 API 指标与业务目标保持一致。这也被称为用户行为分析，它能够从整体上理解多个用户操作和 API 调用的复杂用户流，而不是孤立地查看每个时间序列。

用户行为分析的一个经典例子是监控一个转化漏斗，然后根据用户获取渠道将其分解，以决定在哪里投资营销资金，或者查看不同功能或端点的用户留存，以使你的 API 产品更具粘性。这也有助于跟踪更高级别的帐户健康状况，以便进行安全研究和客户成功。

与 Grafana 和 Kibana 相比，Moesif 还提供了精细的实时警报和报告功能。这使您能够看到每个客户电子邮件中哪些终端导致了最多的性能问题。借助行为电子邮件和工作流，您可以通过包含一系列步骤的自动化电子邮件来扩展客户拓展和支持工作。

将 API 日志数据转换为可操作的信息

原文：https://www.moesif.com/blog/api-engineering/api-observability/Convert-API-Log-Data-into-Actionable-Information/

您已经构建了一个 API 来解决技术问题，但您知道这只是开始。除了帮助开发者使用它，你还需要了解他们是如何使用它的。您希望衡量它的性能和受欢迎程度，并根据您的发现进行调整。

也许一些开发人员在进行 API 调用时看到了很多错误，或者他们花了太长时间才到达第一个“Hello World”也许转化为付费用户的开发者数量低于你的预期。你想了解你的 API 的用法，并确保客户长期使用你的 API。

此时，您可能会合理地查看您的 API 日志。您正在寻求对 API 及其用户的深入了解，但默认情况下，您将发现的是原始用法。你如何不仅能形象化用法，还能形象化帮助你采取行动的洞察力？这篇文章将介绍你如何自己解决这个问题，以及 Moesif 如何帮助你在 API 程序中更快地前进。

您的 API 日志包含大量可操作的信息

您可以从 API 日志中获得的大量有价值的信息可能会让您大吃一惊。例如，您可以使用 API 日志数据来回答大量关于您的 API 的问题，例如:

• 发送的请求和响应负载是什么？
• 哪个 API 版本使用最多？
• API 在哪里经历了更高的延迟？
• 导致 POST /*/count/events 错误的事务顺序是什么？
• 哪些 SDK 最常用于访问 API？

您还可以使用 API 日志数据来回答关于您的 API 用户的问题，例如:

• 我的每个客户使用的顶级端点是什么？
• 根据 API 使用情况，谁是我的主要客户？
• 哪些用户正在从 API 中抓取大量数据？
• 哪些客户遇到了 401 未授权错误？
• 特定客户的 API 活动是什么？

您的 API 日志包含有价值的信息，您可以利用这些信息为您的客户和业务带来好处。但是如何访问和分析日志数据呢？

许多 API 产品开发团队寻求 API 日志和度量的第一个工具是 Kibana。

你可能用管道把你的原木输送到基巴纳

如果您想从 API 日志数据中获得洞察力，那么您可能会将这些日志通过管道传输到 Kibana。如果您不熟悉的话，Kibana 是最流行的日志可视化工具之一。它是 Elastic Stack (以前是 ELK Stack)的一部分，后者由三个开源项目组成:Elasticsearch、Logstash 和 Kibana。Elasticsearch 是一个基于 Apache Lucene 的搜索和分析引擎。Logstash 是一个服务器端数据处理管道。Kibana 让你探索和可视化弹性搜索数据。

像任何堆栈一样，您需要将各个部分放在一起。虽然它们可以很好地协同工作，但是这三个工具也可以分开使用。您需要从 UI 到 API 将客户旅程数据缝合在一起。这些痕迹，用 Kibana 术语来说，对于将数据转化为可操作的东西非常重要。这并不像连接日志和完成工作那么简单——您需要确定需要什么，处理冲突，并承担索引增长的持续成本。

Kibana 是一个日志可视化工具，这使得它成为考虑 API 分析的合适起点。然而，Kibana 的主要用例是基础设施监控和度量。它不是专门为 API 产品设计的，所以使用 Kibana 进行 API 日志和度量有一些缺点。

Kibana 对于 API 日志和指标的利弊

如果您已经构建了一个 API 产品，您可能已经使用 Kibana 来深入了解它的性能或开发人员如何使用它。也许您正在考虑使用 Kibana，因为它在日志可视化方面很受欢迎。不管是哪种方式，了解使用 Kibana 进行 API 日志和分析的优缺点都是有帮助的。

Kibana Pros

Kibana 的优点包括:

• 开源，免费使用。
• 擅长可视化 API 日志。
• 您可以探索大量的日志数据。
• 许多有用的功能。尽管需要注意的是，有些功能是单独提供的，有些功能目前还处于试验阶段或测试阶段。
• 它位于 Elasticsearch 之上(也是一个缺点)，非常适合用于高基数、高维日志数据——这是 API 日志的必备特性。

现在说说缺点。

基巴纳监狱

基巴纳的缺点包括:

• 仅与 Elasticsearch 和 Logstash 兼容。如果您想将 Kibana 与其他数据库一起使用，那么您就不走运了
• 专为基础设施指标而设计，而不是专门为 API 产品而设计。您必须为 API 日志用例定制 Kibana。
• 将用户行为和 API 活动连接到一个单独的旅程中是非常手工的，并且随着时间的推移容易出错。您需要使用 Kibana 查询语言(KQL)或 Lucene 查询语法(Kibana 遗留查询语言)进行查询，因此有一个中等至高的学习曲线。
• 维护弹性堆栈需要很大的努力。例如，你必须定期升级堆栈的每个部分，并确保升级不会破坏你正在使用的任何插件，或者要求你重写任何可视化。

当从 API 日志中获得洞察力时，可视化只是一个起点。虽然 Kibana 非常擅长可视化日志，但它经常让你想知道，“下一步是什么？”根据这些数据，我应该采取什么行动？

超越 Kibana，使用 Moesif 从 API 日志中获得可操作的见解

Moesif 不仅仅是日志可视化，我们从您的 API 日志中提取可操作的信息，并指导您如何使用它。Moesif 是一个用户行为 API 分析和监控服务，具有快速查询引擎和基于事件的结构化数据。我们为 API 产品设计了平台，因此我们支持各种 API 协议，包括 REST、GraphQL、JSON-RPC、超媒体(HATEOAS)和 SOAP。

使用 Moesif，您可以过滤和聚合几乎任何字段上的数十亿 API 调用和用户操作，甚至是像会话令牌或用户 id 这样的高基数字段。

Moesif 平台包括许多您在 Kibana 和 Elastic Stack 中找不到的特性和功能，例如:

• 高基数、高维度的 API 指标与任何数据库兼容，而不仅仅是 Elasticsearch。
• REST 和 GraphQL APIs 的自动分析。
• 自动洞察查询参数和 HTTP 文本负载，如 JSON 和 XML。
• 跟踪 API 调用、用户操作和行为以及网站活动。
• 嵌入式 API 日志和图表。

有关更多详细信息，请参见 Moesif 与 Kibana 的完整对比。

Moesif 允许您从 API 日志中获取有价值的信息，并通过定制和预构建的仪表板帮助您了解数据告诉您什么。

理解 API 日志数据告诉你什么

如果您不理解数据告诉您什么，那么从 API 日志中提取数据不会有太大帮助。Kibana 和 Moesif 都提供了定制的仪表板，帮助您理解从 API 日志中获得的数据。然而，与 Kibana 不同的是，Moesif 具有专门为 API 产品设计的预建仪表板，以及嵌入式模板和公共共享链接。您可以使用我们预先构建的仪表板或构建您自己的自定义仪表板，以更好地了解您的 API 日志数据告诉您的信息。

例如，一家金融科技公司(也是 Moesif 的客户)创建了一个仪表板，让他们跟踪关键的 API 和用户指标，其中包括:

• 最近的 API 错误
• HTTP 状态请求
• 产品用途
• 每日活跃用户(DAU)
• 最活跃的用户

通过仪表板，fintech API 产品团队可以看到他们的客户是谁，他们如何将 API 与应用程序集成，以及他们的 API 的用户正在经历什么。该团队还深入了解了他们的 API 的执行情况，以及有多少开发人员从 API 的试用或沙盒版本转移到了生产版本。

不要错过宝贵的见解

您需要超越日志可视化，转向用户行为 API 分析，以便从 API 日志数据中获得可操作的见解。

想进一步了解 Moesif 如何帮助您从 API 日志中获得深刻的见解吗？

使用 Moesif API Analytics 开始构建优秀的 API。了解更多。

创建聚合仪表板以监控您的第三方 API

原文：https://www.moesif.com/blog/technical/api-status/Creating-Aggregate-Dashboards-to-Monitor-Your-Third-Party-APIs/

Moesif 发布了一个免费工具,可以用来监控你的第三方 API。许多 API 提供商都有自己的状态仪表板，如 status.dropbox.com 的或 status.box.com 的或。但是，每一个都托管在单个公司的域中。有时，您只是想要集中或全局地查看您所依赖的所有服务的运行状态，这正是该工具的用武之地。

背景

随着 API 和 SaaS 的增长，一个公司能够将他们的许多非核心产品功能外包给第三方。从 CI/CD 到支付处理的一切都可以外包给第三方。然而，公司现在比以往任何时候都更加依赖这些服务的可靠性。

例如，电子商务移动应用程序可以依赖 Braintree 的正常运行时间或 Recurly 的正常运行时间进行支付， Twilio 的正常运行时间或 Mailgun 的正常运行时间进行短信和电子邮件，甚至 CircleCI 的正常运行时间进行持续集成。

由于这些依赖性，了解这些服务的状态和可用性至关重要。虽然这些公司中的许多都为他们的客户提供了状态页面，但将这些数据统一到一个集中的仪表板中并不容易。

这就是为什么我们创建了一个免费的工具，它可以在一个仪表板中监控多个 API 和服务。

主仪表板

主仪表板为您提供了您选择进行监控的所有 API 和服务的高级视图。服务和 API 由五个主要的状态代码组成:运行、次要、主要、关键、维护。

对于每项服务，都有每项服务组件的状态摘要，以及未解决事件和任何正在进行的维护的突出显示。

选择服务

您可以使用右上角的下拉多选来选择要监控的服务。只需搜索或选择您想要监控的服务。该网址可以加入书签并共享。当您重新访问该 URL 时，将显示您之前选择的相同服务。请务必将您的自定义仪表板加入书签，或者保存链接并与其他人共享。

查看服务详细信息

您可以单击某项服务来查看更多详细信息。详细视图将包含每个组件的状态细分，以及过去事件和维护事件的列表。还有一个用于即将进行的定期维护的部分。

您还可以根据各种数据进行排序和过滤，例如:状态、影响、更新时间、解决时间等等。

将来的

我们确实意识到当前的受支持组织列表并不完整。我们将继续添加您正在使用的缺失服务或 API。为了帮助我们确定优先顺序，请随时联系我们，让我们知道应该添加哪些内容。

许多这样的状态页面都是使用类似 ping 的服务创建的。然而，pings 无法让您深入了解具体的 API 流量或错误发生的原因。如果你想对 API 进行深度分析和错误监控，我们无耻地推荐我们的主要产品: Moesif API analytics 。😃

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

了解更多

使用 Moesif 和 Datadog 创建终极分析堆栈

原文：https://www.moesif.com/blog/technical/api-analytics/Creating-the-Ultimate-Analytics-Stack-with-Moesif-and-Datadog/

当查看 API 分析和监控平台时，许多平台看起来非常相似，以至于很难找出它们之间的差异。我们经常从用户和潜在客户那里听到这种困惑。在一个有这么多可用工具的世界里，我们如何确定哪些是必要的，哪些是多余的？我们被问到的最常见的问题之一是 Moesif 与 Datadog 相比如何，以及它们如何协同工作。我们不认为这是“Datadog vs Moesif”类型的场景，而是认为将两个平台结合起来是创建顶级分析和监控堆栈的一种很好的方式。使用这两者可以确保您的系统正常运行，用户从平台中获得价值。让我们来看看每个平台，它们做什么，以及它们如何协同工作。

什么是 Datadog？

Datadog 是市场上最受欢迎的基础设施和应用程序监控工具之一。Datadog 有大量的内置连接器，许多连接器涵盖不同的云基础设施监控、成本管理、安全监控以及更多的内容。总的来说，Datadog 是监控所有应用程序和系统的端到端健康和操作的一种很好的方式。它还包括强大的可视化工具，可以轻松查看数据趋势。

Datadog 有助于提供以下方面的端到端可见性:

• 基础设施运行状况和性能
• 安全
• 问题跟踪
• 云成本管理
• 还有多得多的

什么是 Moesif？

Moesif 是一个 API 分析平台，主要关注用户和公司如何使用你的平台。Moesif 通过一个插件(用于许多流行的 API 网关和 API 管理工具)或 SDK 与你的 API 集成，并与你的应用的前端 UI 集成。通过监控这两个角度，Moesif 允许平台用户看到端到端的客户旅程，并从这些数据中获得关键的见解和趋势。

Moesif API analytics 对于以 API 为先的公司来说是一笔巨大的财富。对于以产品为导向的组织来说，它也是一个很好的工具，这些组织非常注重使用度量来改进和监控他们的产品。

Moesif 有助于提供以下方面的端到端可见性:

• 详细的 API 用法
• 激活漏斗
• 保留和追加销售机会
• 货币化和配额管理
• 功能采用

平台是为谁准备的？

使用每个平台的一个主要因素是平台能为谁提供最好的服务。

Datadog 可以满足您的开发运维、站点可靠性和工程团队的需求。这些团队关注基础设施和技术运营的健康状况。确保基础设施高效启动和运行至关重要。

Moesif 更适合产品、工程和客户支持团队，他们主要关心的是理解使用和客户满意度。确保用户拥有良好的体验，从平台中获得价值，并留住这些用户是关键目标。

如您所见，这些平台可以协同工作。一个是基础设施和运营监控，以确保用户可以访问平台，另一个是监控用户体验和使用，以保持用户满意，并通过改善体验来吸引新用户。

指标:什么和为什么？

这两个平台之间的差异确实可以根据它们收集、汇总并有助于理解的指标来看。Datadog 用户关注的关键指标包括:

• 正常运行时间和 SLA
• 内存使用
• 潜伏
• 每分钟错误数
• 每分钟请求数

这些指标可以很好地反映基础设施的健康状况，并有助于应用程序性能监控。这是 Datadog 擅长的地方。然而，能够跟踪特定用户旅程中的特定指标在平台中可能是困难的。

Moesif 中收集的指标与 Datadog 中观察到的有所不同。Moesif 中指标的结果有助于支持其他领域，在这些领域中，Datadog 无法在 Datadog 中实现或者实现起来很复杂。这主要是因为 Moesif 中的指标与客户行为高度相关。这意味着可以找到某些见解，因为可以在每个用户和公司的数据中找到关系。

这些指标可以在以下方面提供帮助:

• 采用
• 参与和 API 使用
• 保留

如您所见，这些领域关注客户成功和体验以及打造更好的产品。简而言之，Datadog 可以帮助确保您的产品和服务正常运行，Moesif 可以帮助人们使用您的产品并留住这些用户。

创建分析和监控堆栈

分析和监控极其复杂且涉及多个方面。几乎组织的每个部分和每个团队都可以从坚实的分析基础中受益。利用分析和监控使运营保持最高效率，并确保产品达到最佳状态。

正确的分析和监控工具可以为您的整个组织创造一个有凝聚力的图景。

对于高管来说，C-suite 团队分析有助于显示用户和客户对整个公司不同努力的反应。将销售和营销工作与具体成果联系起来的能力，这些成果可以在数据中轻松跟踪。这可能包括销售拓展、入职培训的改进，甚至是提高用户保留率和支出的改变。每个领域的领导者也可以使用具体的数字来表明努力正在奏效或需要改进。

包括开发者关系在内的销售和营销团队可以快速了解网站和应用流量、流量来源以及各种努力如何吸引和留住客户。当试图扩大你的用户群时，很容易浪费时间、精力和金钱。指标是快速完善战略的关键，以便将浪费降至最低，将单个活动的影响最大化，并且销售团队的外展具有针对性并创造机会。这不仅扩展到新的和即将到来的客户，也扩展到当前的客户，他们可以通过追加销售来提高他们对产品的满意度，并帮助您公司的底线。

产品开发团队可以看到新功能的执行情况，对部署这些功能的基础设施的影响，并给出未来改进的建议。A/B 测试可以用精确的度量标准来审查，并且可以跟踪单个客户的旅程。打造一个更好的产品并不容易，但公式是加倍努力工作，削减任何不工作的东西(如果不能改进的话)。端到端指标可以推动这项工作。

运营团队需要了解其基础架构的运行情况，以便他们能够优化并保持客户之旅顺畅进行。伟大的产品需要坚实的基础设施做后盾。确保事情正常运行的唯一方法是监控关键指标，最好是在事情没有以最佳方式运行时发出警报和通知。

上述所有用途都可以封装在一个度量堆栈中，其中包括 Moesif 和 Datadog。Moesif 可以处理所有的用户监控和指标，并提高入职和留任率。Datadog 可以确保系统的所有基础设施和操作组件正常工作，如果不正常，它会发出警报。由于 Datadog 能够检查基础架构运行状况之外的事情，例如数据库运行状况和云成本管理等，因此有很大的优化和监控空间。

结束

简而言之，Datadog 专注于运营，并确保您的基础架构、安全性和性能保持稳定。如果没有，Datadog 可以迅速让您的团队意识到这些关键问题，并帮助诊断和修复它们。Datadog 提供了大量的集成和美观的图表和仪表板。总的来说，它是市场上最受欢迎的基础设施和平台监控解决方案之一也就不足为奇了。开发人员和技术操作人员从使用 Datadog 及其所有特性中受益匪浅。

Moesif 致力于让你的产品和用户体验更好。该平台有许多工具，可以让你全方位了解你的用户是谁，以及他们如何使用你的 API 驱动的产品。除此之外，Moesif 允许您实际利用这些指标来实现自动化，无论是提醒您的客户成功团队注意问题、在终端上实施治理策略，还是根据用户在您的产品中遇到的某些操作或事件直接向他们发送电子邮件。产品经理、开发人员，甚至营销和销售部门的非技术人员都可以利用 Moesif 来提升他们的产品、客户成功和销售能力。

分析不一定只适用于应用程序或运营的一部分。一个完整的图片可以帮助改进您的产品，提高成本节约的努力，并提供能力，整体管理一切有关您的运作，没有猜测。这些平台提供了细粒度的控制和洞察力，在努力构建最佳产品时变得务实和实用。

客户健康指标有助于 CSM 团队减少客户流失，加快 API 平台公司的追加销售

原文：https://www.moesif.com/blog/customer-success/monitoring/Customer-Health-Metrics-Help-CSM-Teams-Reduce-Churn-and-Accelerate-Upsell-in-API-Platform-Companies/

我们在旧金山的一位 API-first 同仁最近与我们分享了他们如何构建自己的综合测试系统来监控正常运行时间和延迟。这是一项大工程，包括一个巨大的红移仓库、数据狗和许多人工月的工程工作。最后，他们可以测量延迟的完整性，功能是否正确，当超出界限时，提醒 CSM/工程团队。

基础设施指标当然重要，但今天的 CSM 团队最终关心的是他们是否让客户成功，如果没有，他们希望尽早知道。通过跟踪客户健康指标，当客户面临流失风险时，或者相反，当他们已经超出计划时，就有可能变得有先见之明。

csm 总裁

借助 Moesif 以用户为中心的方法，您可以监控端到端的客户体验，并在个别客户遇到功能或性能问题时获得提醒。类似于我们旧金山的 API 优先公司，我们已经建立了一个系统来持续监控和学习正常的 API 行为。然而，我们的 API RUM(真实用户监控)解决方案不仅仅适用于基础设施指标，我们还关注采用、参与和保留阶段的关键客户标准。我们先进的异常检测算法让您发现未知的未知因素和领先的流失指标。

Moesif 不仅有助于管理客户保留，我们的平台还有助于追加销售。正如一句老话所说，时机就是一切——如果你过早提出涨价，你可能会激怒你的客户，而如果你太迟，机会可能会与你擦肩而过。因为留住客户的成本要低得多，尤其是那些超额完成任务的客户，所以找到最佳时机至关重要。在 Moesif 中设置一次 API 调用配额阈值，然后就可以忘记它们了。我们会在后台进行监控，然后在使用水平接近客户的订阅阈值时向您发出警报。以数据为导向，抓住可以扩展的机会。

粒度警报

我们改进了警报功能，以支持每日或每周趋势警报以及实时通知。只需轻轻一点，就可以在任何图表上创建复杂的警报。当客户遇到问题、经历异常或性能问题时，请及时通知。根据每周活跃 API 令牌、每日 4xx 错误、95%延迟等指标，对客户健康状况进行细分、评分和更改。获得向有风险的客户群发送个性化信息的能力。

我们不仅可以确定哪些客户在使用您的 API 时遇到了问题，或者有不良的客户体验，而且我们还可以让您执行根本原因分析，了解客户为什么不再光顾。请参阅我们关于发展平台业务的指南,了解更多关于群组保持分析的信息。

集成和报告

使用您最喜欢的工具(如 PagerDuty 和 Slack)发送具有丰富上下文的警报。相同的警报可以通过多种渠道发送，包括短信和电子邮件，支持逐步升级的通知层级。让第一级岗位放松，然后第二级岗位开火。如果需要，通过 SMS 上报给工程人员或该系统的任何待命人员。

Moesif 还连接到 Salesforce、Hubspot 和 Zendesk 等工具，以客户驱动的方式实现客户成功。

获得关于哪些客户有搅动风险或 API 使用率低的定期报告。从您的报告中轻松创建定制仪表板，用您的数据讲述故事。在您的组织内以及与合作伙伴安全地共享仪表盘。

通过使用 Moesif 的关联引擎和评级系统来整合和过滤重复/无趣的通知，限制报告中无关警报的数量。

以用户为中心的客户健康

获得一个新客户的平均成本介于 5X 和留住一个现有客户的 25 倍之间。那是在前 COVID 时代。在当今世界，可能更多。识别哪些客户有流失风险，哪些客户准备追加销售，现在比以往任何时候都重要。通过 Moesif，您可以获得关键 API 指标的早期警报，将它们与特定客户联系起来，并在为时已晚之前采取主动行动。

数据驱动的客户成功管理以及 API 如何提供客户健康的领先指标

原文：https://www.moesif.com/blog/customer-success/monitoring/Data-Driven-Customer-Success-and-How-API-Data-Provide-the-Leading-Indicator-of-Account-Health/

通过使用 API 分析平台，客户成功管理(CSM)团队可以主动帮助客户实现他们的目标，这反过来又鼓励他们续订和升级合同。相反，在经济衰退时期，这些相同的平台可以帮助 CSM 专业人员识别并最大限度地减少客户流失。通过以客户为中心的 API 分析，让您的客户爱上您是轻而易举的事情:集成将更快，支持将更及时，流失风险将被自动标记，并且您将被设置为提供真正的持续价值。

客户成功源于客户管理。在软件产品的旧世界里，你卖了它，然后他们放你鸽子，如果你幸运的话，客户经理会每年拜访客户一次，除非你的产品爆炸了。谁想要一个生气的顾客？

在基于订阅和消费的软件和服务(SaaS 和云)的新世界中，技术是复杂且不断发展的，因此客户需要持续的帮助来适应和实现价值。客户价值实现是让客户不断回头客的飞轮。CSM 是加速飞轮的动力。但是，如何让客户喜欢你，并不断回来呢？

主动的 CSM 团队

Olivia 是一家领先的订阅管理提供商的 CSM 经理，她颠覆了这一模式。就像销售一样，她的团队是超级主动的，而不是被动的。她有爱她的顾客，而不是生气的顾客。为了达到这一点，她遵循了三步走的方法:

1. 了解客户的业务。尽可能多地收集他们的信息。使用 Datafox、Alexa、网络抓取和 intro 调用来真正理解它们的全部内容。
2. 在整合过程中，尽可能毫不费力地帮助顾客竖起你的产品。因为你已经熟悉了他们的产品，显然也熟悉了你自己的产品，所以你会知道他们最关心的特性，以及可能存在的集成问题，甚至在它们出现之前。
3. 通常，你的客户不会充分利用你的产品。您还将发布新功能。关键问题是要了解你的客户，然后确定该功能是否与他们相关。通过保持领先并让他们了解适合他们的最新和最棒的功能，您将继续提供真正的价值。

“如果我确实遇到了不高兴的客户，那么至少我知道他们可以和我的 CSM 团队谈谈。我的客户告诉我发生了什么，为什么他们不开心，让我放松一下，这样我就可以解决问题了。”奥利维亚，CSM 经理

轻松整合

没有成功的整合，就没有新客户。相反，通过快速整合，你会得到一个满意的客户，并且更有可能升级他们的计划。CSM 的首要工作是确保产品尽可能快速、轻松地集成。

通过使用能够识别和理解常见错误模式的工具，可以避免糟糕的客户体验。同样，如果确实出现了问题，最佳实践表明应该快速对它们进行分类。

更好的 API 分析工具，如 Moesif 的工具，能够深入了解单个客户如何使用您的 API，他们在哪里卡住了，它是如何发生的，以及可以做些什么来减轻它。通过快速解决集成问题，客户可以更快地部署，在几个小时内就能开发出第一个可用的应用程序，而不是几天或几周。

灌输数据驱动的文化

分享信息导致更多的理解。在您的 CSM 团队中、与公司的其他利益相关者以及直接与客户共享关键指标和 SLA，可以在公司范围内以及与客户之间建立更加共生的关系。

通过连接到 Salesforce、Marketo 和 Zendesk 等工具，可以编织更丰富的客户花毯，并且使用 Moesif 等工具，可以在单一窗格中进行管理。

账户健康状况的领先指标

通过 API 分析，CSM 团队可以收集关于客户账户健康状况的独特见解。不仅可以跟踪哪些客户最近集成，您还可以更深入地挖掘使用统计数据，如每周活跃令牌或每周活跃用户。这提供了用户和公司级使用的更完整的图片。通过监控谁在加速平台使用，您可以在关键客户准备追加销售时获得早期警报。

如果可以的话，不要纠结于 SQL 和复杂的可视化工具，只需点击一个按钮，就可以创建实时仪表盘来监控帐户健康状况。Moesif 提供了一套仪表板，可以显示您和 CSM 团队关心的所有关键使用指标。

衰退期间将流失风险降至最低

在经济衰退期间，识别和最小化客户流失风险变得比漏斗增长顶部更重要。很多时候，你可以通过重新安排已经注册和/或正在付费的客户/潜在客户的优先次序来获得额外的增长。通过采用一个分析平台，自动跟踪哪些帐户的平台使用率低或其他指标不合格，当情况不乐观且客户有流失风险时，就有可能收到警报。需要注意的事项包括:

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

继续提供价值

在 Olivia 帮助最近的一个关键客户整合后，她不只是试图给他们发广告进行追加销售，而是带来了他们如何更好地使用她的产品的想法。她在公司的产品路线图中倡导这一点，并让他们了解未来的发展。

CSM 是贵公司内部客户的声音，所以倾听他们的担忧并推动产品变革。

在她亲自进行的高管业务回顾中，她与他们分享了他们的季度平台使用情况仪表板，并回顾了他们的支出，查看了对他们来说重要的其他问题。

结论

CSM 团队在销售和支持之间架起了桥梁，是基于订阅的软件新世界中的一个关键因素。

Moesif API analytics 为 CSM 团队提供了必要的工具，帮助他们了解客户使用情况和参与趋势等，衡量客户健康状况，防止流失，并发展关键合作伙伴关系，所有这些都在一个统一的平台中完成。

使用 Moesif 的 Zendesk 集成有效地调试应用程序错误

原文：https://www.moesif.com/blog/integrations/desk/Debug-App-Errors-Efficiently-Using-Zendesk-Integration/

Moesif 的 ZenDesk 集成和设置指南的快速概述，自动查看 Zendesk 标签中的 HTTP 错误跟踪和应用程序 API 历史

使用 Moesif 和 Zendesk 更快地解决技术问题:

• Moesif 是一个针对 RESTful APIs 和集成应用程序的调试工具，可以帮助您快速解决技术问题。

• 该集成将用户配置文件数据(如浏览器、设备信息、SDK 版本和地理位置)直接导入到 Zendesk 票证中，以避免与客户进行冗长的电子邮件线程来获取调试信息。

• 查看终端用户的 HTTP 请求历史和任何错误，这样您就不必浪费时间手动搜索应用程序日志。

• 在 Zendesk tickets 中即时访问 Moesif 的深度错误分析和分类信息。

如何用 Zendesk 设置 Moesif

本安装指南专门针对 Moesif Zendesk 集成。对于一般 Moesif 信息，查看产品特性和开发者文档了解更多信息。

1. 登录您的 Moesif.com 帐户，获取您的应用程序 ID。你可以在设置->-插件设置的 APPLICATION_ID 下找到

2. 转到 Zendesk 的 Marketplace 上的 Moesif integration 并点击 install。

3. 将插件设置中的集成令牌粘贴到 Zendesk 插件字段中。

结束语

公司希望提供出色的客户体验，以增加客户保留率并确保忠诚满意的客户。不要让未解决的技术问题将客户推向竞争对手。通过使用 Moesif 和 Zendesk 实现流程自动化，确保您能够快速解决客户问题。

使用 SAM CLI 和 VSCode 在本地调试无服务器 AWS Lambda 功能

原文：https://www.moesif.com/blog/technical/serverless/debug-lambda-functions-locally-with-the-sam-cli-and-vscode/

为什么

当我们构建软件时，快速的开发周期总是好的。这种设置对于无服务器开发来说可能有点困难，因为运行我们功能的平台在云中，上传测试并不是我所说的快速。

幸运的是，大多数云提供商为我们提供了减轻这种痛苦的工具，例如，Amazon Web Services 的 SAM CLI。它是一个命令行工具，帮助创建基于 SAM 的应用程序。

在本文中，我们将学习如何使用 SAM CLI 为我们的无服务器应用程序设置本地调试环境。

什么

我们需要下列软件。

SAM CLI 是一个用 Python 编写的命令行工具，可以帮助创建和维护无服务器后端。它使用 AWS SAM ，一种 AWS CloudFormation 的方言，专门用于处理 AWS Lambda、API-Gateway 和 DynamoDB 等无服务器资源。

AWS CLI 用于通过 CLI 访问 AWS；SAM CLI 在后台使用它来修改 AWS 帐户中的资源。

Docker 让我们执行操作系统级别的虚拟化。有了这项技术，我们可以在 Docker 容器中建立一个环境，并在 Docker 本身可以运行的地方运行这个容器。SAM CLI 使用这项技术在我们的机器上模拟 AWS Lambda 进程的云环境。

VSCode 是一个基于电子的代码编辑器，用 TypeScript 编写。它带有一个内置的调试 UI，我们将利用它来调试我们的无服务器 JavaScript 代码。

怎么

我们必须安装 AWS CLI、AWS SAM CLI 和 docker Docker。然后，我们必须创建一个新的 SAM 项目，并将 VSCode 调试 UI 链接到 SAM CLI 为我们启动的 Docker 容器。

设置

首先，我们必须安装 AWS CLI，因为 SAM CLI 建立在它的基础上。

$ curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
$ unzip awscli-bundle.zip
$ ./awscli-bundle/install -b ~/bin/aws 

AWS CLI 也需要用我们的 AWS 凭证进行配置。

$ aws configure 

该命令将询问我们的 IAM 用户凭据。如果你没有 IAM 用户，AWS 为你提供了教程

我们需要安装 Docker、AWS CLI 和 SAM CLI，我将展示一个在 macOS 上安装的示例。

有一个用于 macOS 安装的dmg档案，我们可以在这里下载

要在 macOS 上安装 SAM CLI，我们需要自制软件。我们可以用下面的命令安装它:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 

然后我们点击 AWS tap，访问 AWS brew 包并安装aws-sam-cli包。此下载可能需要几分钟时间。

$ brew tap aws/tap
$ brew install aws-sam-cli 

下一步是用nodejs8.10运行时初始化一个 SAM 项目。如果我们不使用--location命令行参数，SAM CLI 将下载一个 hello world 模板并为其创建一个sam-app目录。

$ sam init --runtime nodejs8.10
$ cd sam-app 

创建的关键文件是保存 AWS Lambda 函数处理程序代码的hello-world/app.js和保存示例事件的event.json。

为了测试这个示例项目仅有的功能，我们可以使用sam local invoke命令:

$ sam local invoke HelloWorldFunction -e event.json 

该命令将在hello-world/app.js中运行我们的HelloWorldFunction函数代码，将event.json的内容传递给它，并在最后给出以下输出:

{"statusCode":200,"body":"{\"message\":\"hello world\"}"} 

现在 SAM CLI 已经启动并运行，我们已经设置好了项目，我们必须将调试器链接到它。

链接调试用户界面

我这里就用 VSCode 内置的调试 UI。

首先，我们必须在要调试的文件中设置一个断点。在我们的例子中，这是hello-world/app.json。

我们还可以添加观看表情。该表达式有助于立即从深度嵌套的对象中获取值，而无需在侧面的变量选项卡中导航到它们。

接下来，我们必须在本地调用该函数，但是使用不同的 CLI 参数。

sam local invoke命令带一个-d参数来配置调试端口。如果我们使用它，SAM CLI 将等待调试器连接到该端口，然后才开始运行我们的代码。

如果我们像这样运行命令:

$ sam local invoke -d 9999 -e event.json HelloWorldFunction 

我们将得到一个输出，告诉我们调试器正在侦听:

Debugger listening on ws://0.0.0.0:9999/a47891d0-d0d3-419e-8123-caf8baf4fbbc 

现在我们有了一个等待调试的过程，我们可以将我们的 VSCode debug-UI 附加到它上面。

为此，我们必须创建一个启动配置。

启动配置特定于 VSCode。我们必须在.vscode/launch.json将它们写入一个新文件。

对于我们的应用程序，它可能是这样的:

{  "version":  "0.2.0",  "configurations":  [  {  "name":  "Attach to SAM CLI",  "type":  "node",  "request":  "attach",  "address":  "localhost",  "port":  9999,  "localRoot":  "${workspaceRoot}/hello-world",  "remoteRoot":  "/var/task",  "protocol":  "inspector",  "stopOnEntry":  false  }  ]  } 

这里最重要的部分是port、type、localRoot和protocol。

我们使用-d 9999运行了 SAM CLI，因此需要在启动配置中相应地设置我们的端口。我们还想使用 inspector 协议调试一个 JavaScript/Node.js 文件，该文件位于我们项目的hello-world目录中。

如果我们的sam local invoke命令仍然在运行并监听调试客户机，我们现在可以在 VSCode 的 debug-UI 中运行我们的启动配置。

如果我们单击“run”按钮，VSCode 应该会将其自身附加到 SAM CLI 进程，这由 VSCode 底部的红色信息栏来指示。

VSCode 突出显示了断点所在的行。

VSCode 中的调试器侧栏应该显示当前作用域的变量，如event和context。

额外奖励:NPM 剧本

为了简化整个过程，我们还可以使用 NPM 脚本来运行 SAM CLI 命令。

为此，我们需要在项目目录中初始化一个 NPM 项目。

$ npm init -y 

然后打开新的package.json并在scripts部分添加一行。

"scripts": {
  "hello-world": "sam local invoke -d 9999 HelloWorldFunction -e "
}, 

该脚本在调试模式下运行 SAM CLI，并需要一个指向 JSON 事件文件的路径。

所以我们可以从这里开始:

$ sam local invoke -d 9999 HelloWorldFunction -e event.json 

要简洁得多:

$ npm run hello-world -- event.json 

--确保下面的event.json参数被传递给 SAM CLI，而不是 NPM。

结论

SAM CLI 工具使 Lambda 函数的调试和测试变得简单。它通过一个标准的调试协议集成了所有流行的 ide 和 debug-ui，所以我们可以使用我们喜欢的工具。

它在后台使用 Docker 的事实减轻了我们设置测试和调试环境带来的巨大负担，并确保我们最终得到类似于云的东西，我们的功能最终将在云中运行。

利用 Moesif 的 Desk.com 集成快速调试技术支持问题

原文：https://www.moesif.com/blog/integrations/desk/Debug-Technical-Support-Issues-Quickly-With-Moesif-Desk-Integration/

Moesif 的Desk.com插件和设置指南的快速概述，可自动将错误跟踪、设备上下文和客户事件导入 Desk.com 票据

使用 Moesif 和 Desk.com 的好处

• Moesif 是一个针对 RESTful APIs 和应用程序的错误分析工具，可以帮助您快速解决技术支持问题。

• 通过快速周转时间而不是因不完整的日志数据而停滞不前，确保您的客户取得成功。借助 Moesif 的托管服务，您可以了解客户的 API 历史、错误跟踪和深入的根本原因分析。

• 通过Desk.com集成，Moesif 将详细的上下文信息发送到您的 Desk.com 票据中，如客户遇到的错误跟踪、版本信息和设备信息。

• 在 Desk.com 代理面板中立即查看客户票证中的错误，而无需求助于手动日志搜索。

如何设置 Desk.com 的 Moesif

本安装指南专门针对 moes if Desk.com 集成。对于一般 Moesif 信息，查看产品特性和开发者文档了解更多信息。

1. 登录您的 Moesif.com 帐户，获取您的令牌。你会在你的 Moesif 账户->-设置->-插件设置中找到你的 Desk.com 积分令牌

2. 在 Desk.com Dash 上，转到管理 > 案例 > 集成 URL，然后添加新的。

在编辑集成 URL 表单中，输入以下内容(用 Moesif 中的令牌替换 YOUR_TOKEN ):

田	价值
开放位置	画布 iFrame
统一资源定位器	https://www.moesif.com/plugin/desk?email={{customer.email | uri_encode}}&externalId={{customer.uid | uri_encode}}&token=YOUR_TOKEN

结束语

随着公司寻求竞争优势，客户体验变得越来越重要。不要让缓慢的技术问题解决引起客户不满。有了 Moesif 和 Desk.com，即使出现问题，您也能确保您的客户保持满意。

在 VS 代码调试器中调试节点 js Express API

原文：https://www.moesif.com/blog/technical/debugging/Debugging-a-Node-JS-Express-API-in-VS-Code-Debugger/

为什么

当我们创建软件时，我们很少做到没有错误。API 创建也不例外，所以迟早我们需要调试它。在 JavaScript 中，调试任务的第一站通常是登录到控制台，但是使用调试器可以给我们更完整的体验。

Node js 是一个跨平台和开源的 JavaScript 运行时环境，允许 JavaScript 在服务器端运行。

有许多指南可以找到最佳的节点 js bootcamp，但在本教程中，我们将学习如何在 Visual Studio 代码(简称 VS 代码)的帮助下调试基于 Express 的 API 。

什么

Express 是一个【Nodejs 的极简 web 框架】。它允许我们将函数直接链接到 API 端点，这是一种快速简单的构建 API 的方法。

Visual Studio Code 是一个“流线型代码编辑器，支持开发操作，如调试，任务运行和版本控制。”

我们还将使用 cURL 向我们的 API 发送请求。

怎么

我们将使用 Express framework 创建一个简单的 API，然后尝试借助 VS Code 的调试功能而不是控制台来调试它。然后，您可以轻松地添加 API 端点并进行 API 调用。

API 设置

首先，我们创建一个新的 Node js 项目并安装我们的依赖项。

$ mkdir api
$ cd api
$ npm init
$ npm i express body-parser 

接下来，我们创建一个index.js文件，它将作为我们的主服务器脚本。

const express = require("express");
const bodyParser = require("body-parser");

const users = [{ id: 0, name: "admin" }];

const server = express();
server.use(bodyParser.json());

server.get("/users", (_, response) => response.send({ users }));
server.get("/users/:id", ({ params: { id } }, response) => {
  const user = users[id];
  response.send({ user });
});
server.post("/users", ({ body }, response) => {
  const { user } = body;
  user.id = users.length;
  users.push(user);
  response.send({ user });
});

server.listen(9999, () =>
  console.log("API running on http://localhost:9999")
); 

我们使用users数组作为内存中的数据存储。它由管理员用户初始化。

接下来，我们创建我们的 Express server并使用bodyParser包的 JSON 中间件；它允许我们访问存储在POST HTTP 请求体中的 JSON 字符串的值。

然后，我们创建三个 API 端点。两个GET端点，因此我们可以请求一个所有用户和一个特定用户的 ID 列表，以及一个POST端点来创建一个新用户。

让我们用下面的命令启动 API！

$ node .
API running on http://localhost:9999 

使用 API

既然我们的 API 已经启动并运行，我们可以尝试用 cURL 查询它。为此，我们需要打开一个新的终端窗口并执行以下命令。

创建用户:

$ curl -H "Content-Type:application/json" -d '{"user":{"name": "kay"}}' localhost:9999/users
{"user":{"id":1,"name":"kay"}} 

列出所有用户:

$ curl localhost:9999/users
{"users":[{"id":0,"name":"admin"},{"id":1,"name":"kay"}]} 

列出一个用户:

$ curl localhost:9999/users/1
{"user":{"id":1,"name":"kay"}} 

创建另一个用户:

$ curl -H "Content-Type:application/json" -d '{"users":{"name": "xing"}}' localhost:9999/users
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
... 

哦不！我们的 JSON 里有个错别字，users而不是user。由于我们没有在我们的POST /users端点中处理这个问题，Express 只是用一个 HTML 格式的错误来响应。

这是一个简单的问题示例，可以很容易地修复，但是让我们用它来启动 VS Code 的调试器，这样我们就可以在运行时直接调查出了什么问题。

使用 VS 代码的调试器

用 VS 代码调试节点 js APIs 非常容易。

我们检查想要调试哪个端点，并在端点触发的函数中设置一个断点。这是通过左击行号来完成的。让我们在第 15 行的上找到它，这应该是我们的POST /users端点函数的第一行。

然后我们通过点击顶部菜单的调试- >开始调试或者按下 F5 来启动调试器。

VS 代码将为我们启动应用程序和调试器。它还将通过 Node.js 的调试协议将两者联系在一起。

然后我们重新发送导致 cURL 错误的请求，并尝试找出发生了什么。

$ curl -H "Content-Type:application/json" -d '{"users":{"name": "xing"}}' localhost:9999/users 

该请求将运行链接到POST /users的函数，并在其第一行的断点处暂停。

如果我们查看代码左侧的侧栏，我们可以看到一个变量类别，以及各种子类别，如块和局部。我们打开本地看看里面有什么。

正如我们所看到的，我们有两个局部变量，body是类型Object和response是类型ServerResponse。

让我们用 F10 进入下一行，看看会发生什么。

一切似乎都像预期的那样工作。

让我们再看下一行。

轰！

不知何故，我们最终在代码库的一个完全不同的地方？

似乎我们通过设置我们的user对象的id创建了一个错误，这是怎么发生的？

让我们再次打开我们的index.js，将断点移动到第 16 行，并通过按 F5 让调试器运行到事件循环的末尾。

然后用 cURL 重新发送请求，看看在我们试图设置user.id之前发生了什么。

当我们查看变量/块类别中的侧栏时，我们可以看到我们的user对象实际上是undefined！如果我们打开变量/局部类别，也能看出原因。

我们的body有一个users属性，但是我们试图在第 15 行中从它那里析构一个user变量，这导致我们试图在第 16 行中写user.id时出错。

现在我们知道了问题所在，让我们停止调试器并修复它。

server.post("/users", ({ body }, response) => {
  const { user } = body;

  if (!(user instanceof Object))
    return response.send({ error: '"user" object missing in JSON!' });

  user.id = users.length;
  users.push(user);
  response.send({ user });
}); 

让我们重新启动服务器，让它运行新代码:

$ node .
API running on http://localhost:9999 

并重新发送我们有问题的请求:

$ curl -H "Content-Type:application/json" -d '{"users":{"name": "xing"}}' localhost:9999/users
{"error":"\"user\" object missing in JSON!"} 

最后，我们得到一个有用的 JSON 格式的错误消息。

结论

借助 VS Code 的集成调试器调试基于节点 js 的 API 是一项简单的任务。我们只需要设置一个断点，不需要额外的代码。

它为我们提供了许多现成的运行时洞察力，包括:

• 当前变量的值
• 观察单个变量的能力
• 当前调用堆栈
• 当前加载的脚本

使用变量和 Moesif 分段调试运行范围测试

原文：https://www.moesif.com/blog/companies/runscope/Debugging-Runscope-Tests-using-Variables-and-Moesif-Segmentation/

Runscope 是测试 API 的一个很好的产品。我们有许多客户询问如何用 Moesif 的实时监控和分析来最好地补充 Runscope 的合成 API 测试和刺激生成。

运行范围桶

Runscope 存储桶是组织测试和请求的一种方式。如果您有一个移动应用程序连接到十个不同的第三方 API，您可以为每个 API 创建一个存储桶。这样，特定公司或服务的所有测试都组织在同一个桶中。

Moesif 分割

Moesif 可以根据 API 调用中的任意字段进行过滤和分组，例如请求路由、响应状态代码，甚至任意 HTTP 请求或响应头。Moesif 还可以使用唯一的会话令牌将多个请求捆绑在一起作为一个跟踪。为了在 Moesif 中组织 Runscope 测试结果数据，我们可以在测试中添加额外的头，以便 Moesif 进行分析。

运行范围测试变量

Runscope 测试支持内置变量和函数，它们可以被添加到测试 API 调用中，比如在 HTTP 请求头中。我们应该使用前缀X-Runscope将它们添加为定制的 HTTP 请求头

我们建议在您的运行范围测试中至少添加以下 HTTP 请求头:(当然，不要忘记您的X-Moeif-Application-Id)

标题键	标题值	描述
x-run scope-环境	{ {运行范围环境}}	用于此测试运行的环境的名称。
X-Runscope-Environment-Uuid	{{runscope_environment_uuid}}	用于此测试运行的环境的唯一 ID。
x-run scope-铲斗	{{runscope_bucket}}	包含执行测试的 Runscope 存储桶的存储桶键。
X-Runscope-Bucket-Name	{{runscope_bucket_name}}	包含执行测试的 Runscope 存储桶的名称。
X-Runscope-Test-Uuid	{{runscope_test_uuid}}	运行范围测试的唯一标识符。
x-运行范围-测试名称	{{runscope_test_name}}	运行范围测试的名称。
x-run scope-区域	{{runscope_region}}	指示启动此测试运行的位置的区域代码。

为了将来自同一个测试的所有 API 请求分组到单个 Moesif 跟踪中，我们还建议设置 X-Moesif-Session-Token 头:

X-Moesif-Session-Token: {{runscope_test_uuid}}

运行测试

一旦我们运行测试，我们将看到事件出现在 Moesif 事件流中，它就像一个流量检查员，但具有过滤和分析功能。由于我们添加了头，我们可以使用左边的请求头过滤器来过滤特定的测试名称。

例如，我们可以只显示来自压力随机测试的事件。

调查 Runscope 测试分析

由于 API 测试结果是由 Moesif 记录的，我们可以使用任何 Moesif 分析图表，如地理热图和分段图表，以更深入地挖掘我们的测试数据。例如，我们可以查看我们的压力随机测试的状态代码的分解。

结束语

将 Moesif 和 Runscope 结合使用可以增强 API 调试工作流，从而可以交付优秀的 API。如果你有任何建议来改进如何一起使用 Runscope 和 Moesif 来获得令人敬畏的 API 调试体验，请随时告诉我们。

用 Postman 和 Moesif 调试 API

原文：https://www.moesif.com/blog/technical/api-debugging/Debugging-Your-APIs-With-Postman-And-Moesif/

对于任何处理 RESTful APIs 的开发人员来说，调试 API 都是一个挑战。尝试创建一个精确的 API 请求，特别是对于具有大型 API 请求体和多个头部的高度复杂的请求，这是必要的，但也是很难做到的。通过使用 Postman 这样的工具来创建用于调试目的的请求，并且作为 API 客户端，您可以轻松地使用原始请求的精确配置来重放 API 请求。这可以让开发人员以一致的方式重现他们试图调试的场景。

Moesif 还可以帮助简化 API 的调试过程。由于 Moesif 接收请求各个方面的数据，因此它是一个很好的平台，可以导出请求的所有细节，这样就可以很容易地重放请求以帮助调试。在 Moesif 中，您可以轻松地将所有 API 调用数据导出到 Postman 集合中。这有助于开发人员通过导入生成的集合来自动复制 Postman 中的调用。

调试最佳实践旨在确保调试错误的条件与导致错误的条件完全匹配。通过使用 Moesif 的导出功能作为调试方法的一部分，可以保证 API 端点和调试器接收到导致错误的相同请求数据。

在 Moesif 中导出呼叫

要从 Moesif 导出呼叫，首先导航至实时事件日志屏幕。

在那里，您可以选择要导出到 Postman 集合中的呼叫。只需选择您想要导出的呼叫旁边的复选框，然后在 Postman 中单击 Run 即可导出它们。

将调用导出到 Postman 集合将包含重新创建 API 调用所需的所有内容。这将包括主体、标题、参数等。

一旦你点击 Run in Postman 按钮，就会出现一个模式让你下载收藏。点击下载邮差收藏将收藏文件下载到本地机器。

在此之后，Postman 集合将被下载并准备加载到 Postman 中。

将集合加载到邮递员中

在 Postman 中，点击屏幕右侧的收藏标签，然后点击导入。

接下来，将出现一个模型，您可以从文件选择器中选择 Postman 集合文件，或者将文件拖放到模型上以导入它。一旦文件被选中，您将看到模式中的内容。

现在，您将点击 Import 来将集合实际引入 Postman。现在，您应该可以在 Postman 的收藏窗格中看到该收藏。

重放请求和调试

现在 Postman 中有了集合，选择一个请求进行重放。

将填充请求的每个细节，包括参数、头和主体。从这里，您可以单击 URL 旁边的蓝色 Send 按钮，发送您正在尝试调试的 web API 请求的精确副本。现在，您的调试器将加载与您当前正在调试的错误调用相同的数据，因为它是从导出的 Postman 集合中加载的。

自己试试吧！

下次调试 RESTful API 代码时，使用 Moesif 快速创建一个 Postman 集合，轻松复制导致问题的请求。不用担心手动将请求输入到 Postman 中会遗漏任何细节。通过从 Moesif 导出请求并通过 Postman 重放请求，您可以在最初导致错误的确切条件下调试 API。只需选择您需要的请求，导出并调试即可。这确保了您将使用原始请求中包含的确切数据来命中调试器断点。在 REST API 中调试错误应该容易且一致。有了邮差和莫西夫，就是了！

今天就开始吧，登录或注册Moesif，将这个伟大的工具添加到您的调试武库中。当你在这里的时候，也可以看看其他伟大的功能，比如我们的提醒、嵌入模板，以及我们的最新计费功能，帮助你将你的 API 货币化。

设计好的静态 REST API 文档

原文：https://www.moesif.com/blog/technical/documentation/Designing-Good-Static-REST-API-Documentation/

设计和编写好的开发人员文档可能是一项艰巨的任务，但对于任何 API 驱动或 business2developer 公司来说，这是确保开发人员成功的关键。您的文档也是您公司的营销资产，可能是新的潜在客户访问的前几页，以了解您的集成有多困难以及产品如何工作。

对于 Moesif，我们进行了大量的研究，以确保我们的文档组织和设计适当，并在本指南的下面发布了研究结果。诸如 Jekyll 和 GitBook 之类的实现将另文讨论。你可以在 www.moesif.com/docs 的和 www.moesif.com/docs/api 的看到结果。API 参考源位于 github.com/Moesif/apidocs

高层组织

在讨论具体的文档特性之前，有必要讨论一下文档的整体组织。每个公司对文档都有特定的要求，但是您可以通过查看其他公司的文档来获得一些想法，这些文档通常分为以下三类:

• 1。具有独立 API 引用的集中文档
• 2。结合 API 引用的集中单据
• 3。分散单据

1。带有单独的 API 引用的集中文档

属于这一类的公司通常至少有两层文档:开发者文档和 API 参考。

同时拥有文档和 API 参考的公司将文档访问者分为两类:

• 对高级集成或 SDK 感兴趣的开发人员
• 对原始 REST API 或 API 包装库感兴趣的开发人员

主开发者文档根本没有讨论 REST API，也没有讨论 API 包装库。取而代之的是，从文档到一个独立的 API 参考网站的导航链接。很多时候，API 参考使用了与文档的其他部分不同的设计或布局，例如 3 列与 2 列。然后，主要的开发人员文档将重点放在入门 api 指南以及如何使用或集成每个产品功能上。

遵循这种方法的公司可能非常注重 API 或开发人员，但已经有了更高层次的集成，因此不需要直接使用 API。这样的公司有 Stripe 、 Auth0 、 Moesif 。例如，Stripe 有自己的 Stripe.js 和 Android/iOS SDK，与 REST API 相比，它们位于前端和中心。Auth0 有他们的 Lock SDK ，允许新开发人员在几分钟内启动并运行身份验证。而他们的 API 可供高级用户使用和定制。

T2】

类似地，对于 Moesif，许多开发人员不需要直接使用 REST API，因为有更高级别的集成可以开始。因此，第一次访问文档的新 NodeJS 开发人员可能会对 moesif-express 中间件更感兴趣，而不是阅读原始的 NodeJS API 包装器库。看看主开发者文档和 API 参考之间的主题差异如果 NodeJS 和 Express 中间件处于同一级别，新的开发者可能会对是开始使用 Express 中间件还是 NodeJS API 库感到困惑。请记住，虽然您可能对自己的 API 及其 SDK 非常熟悉，但新开发人员可能不熟悉。

利益

• 可以引导新员工使用合适的入门指南，避免过多集成带来的困惑。
• 可以专门为文档类型设计导航布局。例如，API 引用可以是一个很长的页面，而一般的文档被分割成许多较小的网页
• 单独的 API 参考对于记录非常像 CRUD 的 REST APIs 很有用
• 为超级用户提供了一个优秀的书签化和 SEO 优化的 api 参考 URL，用于实体模式之类的东西，而无需深入研究冗长的 API 入门指南
• API 参考站点可以使用单独的工具链，并利用 Swagger 之类的工具
• 对于在谁拥有 API 参考和开发人员文档& api 指南之间有明确责任划分的公司来说是理想的

下降趋势

• 不适合具有单一集成层的公司
• 可以人为地强制 API 引用进入后台，这可能不是您的业务需求
• 对于拥有许多不同产品线的公司来说，集中式导航可能不太适合
• 简洁的 API 文档可能会吓跑非开发人员
• 像搜索这样的关键导航元素可以分散吗

2。集中文档结合和 API 引用

属于这一类别的公司将他们的 HTTP API 参考与他们的其他开发人员文档结合在一起，并且没有单独的 API 参考网站。很多时候，虽然 API 参考与其他开发人员文档结合在一起，但是有一个单独的非开发人员帮助区域。虽然情况并不总是如此，但出于讨论的目的，我将假设这是因为流行。

合并开发者文档的公司通常将访问者分成至少一个群组:

• 可能使用 SDK、集成或原始 REST API 的开发人员
• 可选的非开发人员，他们只需要了解如何使用仪表板或产品。

Mixpanel 和 Amplitude 都非常接近这种方法。Square 也在此之后添加了 Square 文档。

T2】

这些公司面向开发者和非开发者进行营销。对于 Mixpanel 和 Amplitude，主要用户不一定是集成产品的开发人员。相反，Mixpanel 和 Amplitude 正在向对数据好奇的营销人员和产品经理推销他们的产品。Square 正在向商家和零售商推销他们的产品。这些公司推销的是产品的灵活性，而不是 API 的灵活性。

这些类型的公司可能需要面向开发人员和非开发人员的文档。添加第三层 API 引用会导致导航混乱或者吓跑主要用户。为什么？一个单独的 API 参考将创建三个级别的文档:非开发者帮助、开发者文档和 API 参考。

当集成 SDK 与 REST API 和 API 包装之间没有明显区别时，也可以使用组合文档。如果你所有的集成都是以 API 为中心的，而你不能干净地将你的集成分成以 API 为中心的和以非 API 为中心的两个桶，那么你可能会制造一个导航噩梦，如果你使用单独的 API 文档，很难在一个地方查看和搜索所有的集成。将 HTTP API reference 与其他 api-guide 相结合，可以让您轻松地将所有的操作指南集中在一个站点中进行搜索。

如果你看一下 Algolia 的文档，虽然它们确实在某种程度上分离了它们的 raw REST API，但所有其他的集成都处于同一水平。在很大程度上，Algolia 融合了第一类和第二类。

利益

• 避免有太多的文档站点，比如非开发者帮助、开发者文档、API 参考等等。
• 确保 HTTP API 与其他集成处于同一级别，而不是在后台
• 为内容最少的新产品编写新文档时，最简单的布局
• 如果一些特性需要您的 API，而其他特性需要 SDK，那么文档搜索可以是集中的，非常有用
• 避免让文档过于简洁和“以开发人员或 API 为中心”而吓跑非开发人员

下降趋势

• 如果您同时拥有较低级别和较高级别的集成，可能会因集成过载而导致混乱
• 难以扩展内部团队，尤其是如果 API 维护者不同于一般的开发人员文档
• 必须在导航设计上妥协，因为某些元素可能更适合导航 API 参考而不是导航通用文档

3。分散的文档

分散式文档与其他两类文档有很大的不同。他们没有将各种类型的文档集中在同一个站点，而是选择了其他支柱来组织他们的文档，比如产品线。

这些公司将 doc 访问者分为其他一些群体，例如:

• 根据参观者感兴趣的产品线

举例来说，Twilio 的产品不仅包括短信，还包括认证和视频，因此它们按照产品线而不是文档与 API 参考来存储 Twilio 的文档。许多想要集成 Twilio 短信产品的 Twilio 用户可能并不关心他们的认证产品 Authy 。

这些公司并没有在一个集中的文档站点上杂乱无章，而是分散开来，这样当你查看 Twilio 的 API 参考时，你只能看到与你相关的文档。如果对 Authy 感兴趣，那么你只需要浏览 Authy(他们有一个很酷的文档功能，你可以同时浏览多个产品)分散的文档可以帮助没有集中文档团队的大公司，每个产品拥有各自的文档。

T2】

利益

• 整理复杂的产品线，对大型企业产品非常有用
• 使公司能够通过产品团队来扩展文档。只需要一个小的中心团队来维护跨领域的设计和基础设施。

下降趋势

• 可以人为地将本应互联的产品孤立起来。对于 Twilio 来说，SMS 和 Authy 是真正不相关的产品。然而，你不会想在的同一产品中分离、关联特性。
• 如果跨产品线使用相同的库或集成，很难组织入门 api 指南

粘性导航

这个特性可以帮助任何访问长文档的人。当一个访问者滚动浏览你的长文档时，他/她不应该仅仅为了看到导航而滚动到顶部。不管你看的是 Auth0 的还是 Algolia 的文档，它们都有一个共同点:左边栏有粘性工具条

保存的滚动状态

如果用户刷新页面，保存滚动状态会很有用。游客不会失去他/她的位置。更重要的是用最近的链接更新 url 散列标签链接。通过这种方式，如果访问者从浏览器中复制 url 并通过电子邮件发送给一位同事，这位同事就可以跳转到正确的位置。

侧栏导航样式

许多文档都是围绕左侧的网站地图菜单组织的。像 Navgoco 这样的折叠式导航很受欢迎，可以帮助整理长边栏，比如来自 REST API 参考文档的边栏(其中每个子菜单都是一个简单的 CRUD 操作)。

其他的，比如 Moesif 和 Mixpanel 的文档选择了静态的两级侧边栏。

3 栏文档

如前所述，我们的文档是受 Stripe 的 3 列 API 参考的启发，使用github.com/lord/slate作为样板。3 列文档对于 API 引用来说可能很漂亮，因为它允许文档的核心文本对于每种语言都是相同的，同时允许访问者选择他们特定的语言。API 参考是这种格式的理想选择，因为无论使用原始 HTTP 请求、Java 库还是 NodeJS 库，您的实体模式和方法名称/端点通常都是相同的。

我们已经看到文档设计者试图使用 Stripe 的三列格式实现入门 api 指南或非 API 参考文档。有时它可以工作，但很多时候它不是正确的设计选择。

T2】

长单页与多页

一个单独的页面对于 API 参考是很有用的，允许访问者使用浏览器搜索来跳过整个规范。例如，搜索模式中支持特定 JSON 键的所有端点，用户不希望在单独的浏览器选项卡中打开所有文档页面。与此同时，单个页面可能无法很好地适应一般的非 api 参考文档，因为这些文档包含数百个操作方法和 API 入门指南。

在 Github 按钮上编辑

将您的源代码存储在 Github 上可以让您的开发人员社区更容易地参与并编辑文档以确保正确性。直接链接到源代码可以进一步展示您的公司对反馈的开放态度。只是不要添加不必要的登录门来建议编辑。甚至像微软 Azure 这样的大型组织也在 Github 上有 azure-docs

降价

Markdown 使得像 wiki 一样标记静态页面变得容易，同时避免了定制模板语言或 HTML。大多数为 Github repo 编写 README.md 的开发人员都知道 markdown。有了像 markdown-preview 这样的 Atom 插件，你可以拥有一个免费的所见即所得解决方案。只要记住你选择什么样的减价食品和口味就行了，因为有几种。如果你支持 GitHub 风味的 Markdown (GFM ),你应该会很好，因为许多开发人员会很熟悉它。

谢谢

特别感谢github.com/lord/slate，这是 Moesif 的 API 参考的基础。如果你对这个主题感兴趣，Moesif 的 API 参考源代码位于 github.com/Moesif/apidocs的。此外，特别感谢最小错误，这是 Moesif 文件的基础。你可以在www.moesif.com/docs和www.moesif.com/docs/api看到结果，并期待它们和其他模板/样板的更多更新。

开发者体验:4 个可用性技巧

原文：https://www.moesif.com/blog/technical/developer-experience/Developer-Experience-4-Usability-Tricks/

什么是开发者体验(DX)？

API 开发者体验是第三方开发者使用平台或服务的整体体验，包括 API 设计、可用性和情感体验等项目。

为什么重要？

现在越来越多的公司开放 API，考虑 DX。与移动优先的 UX 浪潮类似，公司正在意识到 API 可以成为额外收入渠道的有力工具。在竞争激烈的世界里；然而，公司需要吸引拥有出色体验的开发者，以区别于过去刻板的企业应用。今天的开发人员在制定业务线决策方面拥有更大的权力，而这些决策过去是委托给其他业务部门的。

这些例子从可用性的角度为 API 供应商展示了良好的开发者体验。值得注意的是，这篇文章中的一些公司只是作为例子，与 Moesif 没有任何关系。

1.测量第一个 hello world 的时间(TTFHW)

快速的集成时间对于确保开发人员满意非常重要。人们很容易忘记，开发人员集成您的服务并不只是为了好玩。他们出于个人或商业原因使用你的服务。你的服务是一个工具，应该很容易上手。衡量新开发人员集成您的服务所需的平均时间。需要 30 分钟还是 12 小时？如何降低这个指标？看看 Mixpanel 。他们在接纳新客户方面做得很好:

• 指定完成漫游之前的确切步骤数，没有歧义。
• 在示例代码中直接嵌入 API 令牌，可以快速复制/粘贴以开始使用。
• 提供首选安装语言的快速选择
• 验证集成以防止漏船。

记下复制/粘贴的次数，因为它们会累加。开发人员不需要首先复制/粘贴库名，然后是 API 基 url，然后是示例代码，最后是 API 键，等等。

此外，验证是防止早期流失的关键。如果开发人员的集成不起作用，通过电子邮件指导他们提供帮助甚至联系比让开发人员沮丧地离开更容易。你已经在努力招聘开发人员，不要强迫他/她离开。

2.有效地沟通和教育

不要错误地认为你的开发人员和你一样熟悉你的 API。好的文档总是很重要的，但是也应该对不同的专业水平感同身受。一个刚开始新的集成的前端 web 开发人员可能不像已经开发 web 服务多年的后端工程师那样熟悉 RESTful API 架构。一组不同的文档，如演练、视频和典型的 3 栏文档，确保每个开发人员都可以通过他们熟悉的最佳方法进行学习。

看看像 Stripe 和 Twilio 这样的公司，它们都为自己的 API 提供了很好的文档。

例如，条纹:

• 有授权、错误和语言的快速链接。
• 不强迫用户寻找基本 API URL。每个端点都有完整的 URLapi.example.com/some_resource/{id}，而不仅仅是路径。
• 这是一个允许利用强大的浏览器搜索跳转的单一页面。

T2】

像在侧边栏中放置粘性 API 令牌或在 CURL 命令中嵌入它们这样的小事可以确保您的开发人员能够快速找到他们想要的东西。

3.让开发人员更容易调试

调试 API 问题总是一件痛苦的事，但是对于不熟悉 API 的开发人员来说就更难了。给你合适的工具，比如 Moesif 的 API 调试器，让你的开发者生活得更好，他们会感谢你的低流失率，并告诉他们的同事你的 API 是多么容易调试和使用。

T2】

当你的开发者成功了，你也成功了。换句话说，通过提供更易于集成和使用的 API，您可以更快地为您的公司创造收入。

4.需要时给予及时的帮助

开发者现在希望通过公共 Slack 频道等工具获得即时帮助。不要只依赖电子邮件，要全渠道。监控像 Stack Overflow 或者 Quora 这样的公共论坛。甚至推荐你的开发者用你公司的名字来标记帖子。这允许您的开发人员支持团队定期检查这些站点的相关问题。

此外，它有助于在内部记录一切！对于任何集成，总会有问题，但是开发人员在寻求帮助时并不总是提供重现问题的说明。你应该能够找到开发者问题的根本原因，而不需要一长串来回的电子邮件来询问额外的信息。

结束语

开发者体验一如既往的重要，不应该被轻视。如果你没有好的开发者体验，你的竞争对手会。请继续关注我们下一篇关于开发者体验的文章。

开发者体验:最重要的指标

原文：https://www.moesif.com/blog/developer-marketing/api-analytics/Developer-Experience-the-Metrics-That-Matter-Most/

开发者体验。如果你提供 API 或 API 优先的产品，你可能会经常听到“T2”这个词。毕竟，你需要开发者来开发一个成功的 API 如果他们没有很好的体验，他们就会离开。

什么是开发者体验？

开发人员体验(DevEx 或 DX)是用户体验(UX)的延伸，其焦点是受技术方面影响的用户——例如，工具、语言和工作流。但是 DevEx 不仅仅是“开发人员的 UX”:它意味着确保开发人员能够容易地理解和利用他们自己的应用程序和用例的 API。当你与你的开发者用户交流，理解并直接满足他们的需求时，就会有很好的发展。如果你能赢得开发者，你就能围绕你的产品建立一个庞大而繁荣的生态系统。

什么指标重要？这取决于你的角色

著名的管理顾问彼得·德鲁克可能说得最好:“如果你不能衡量它，你就不能管理它。”

提高 DevEx 从指标开始。您将想要衡量对 DevEx 最重要的事情，避免虚荣度量并将特定的 API 事务与商业价值联系起来。然而，对你来说什么最重要取决于你在改进 DevEx 中的作用。

在您的组织中，可能有三个不同的角色专注于 DevEx:开发人员体验经理、开发人员关系专家和 API 产品经理。这些角色的关注点有所重叠，但侧重点不同。这些不同的焦点将在他们最关心的指标中得到体现。

开发者体验经理

DevEx 经理关注开发人员使用的 API 或 API 优先产品的有效性。他们还寻找改进过程的方法，以便开发人员取得成功。DevEx 管理器负责运行开发人员访问和使用的一切—从开发人员门户和文档到代码示例和 SDK。

DevEx 经理确保开发人员对与产品相关的工具和过程有很好的体验。因此，他们最关心的指标包括以下内容。

用户激活时间

一旦开发者完成注册，他们需要多长时间开始使用 API 几小时、几天、几周？如果开发人员没有及时集成或激活，这可能表明有问题。也许你的文档令人困惑，或者你没有流行语言的 SDK。如果一个开发者没有在几天内集成或激活，一个好的 DevEx 经理会注意到的。

第一个 Hello World 的时间

Time to First Hello World(TTF HW)衡量一个新的开发人员需要多长时间才能上手并运行，实现 API 的最低价值水平。每个开发者对第一次成功有不同的标准。它可能是第一次调用 API 并得到响应。它可能是创建一个简单的测试应用程序，并完成一个验证 API 是否符合开发人员需求的事务。但是在任何情况下，开发人员用你的 API 取得一点成功所需的时间是他们是否会继续使用它并转化为付费用户的一个关键指标。

需要支持的开发人员数量

有多少开发人员在某个问题上寻求支持？许多开发人员都遇到了同样的问题吗？DevEx 经理应该在内部记录所有集成问题，并跟踪有多少开发人员需要帮助。

支持解决方案的时间

如果您有支持系统，您的团队需要多长时间来解决技术支持问题？开发人员不想等着用你的 API 或集成解决他们的问题。他们希望迅速得到答案，以帮助他们前进并实现发展目标。

开发者关系专家

开发者关系(DevRel)专业人员的目标是让开发者采用 API 或 API 平台，并用它来完成他们的目标。典型的 DevRel 角色包括开发者传道者、开发者倡导者和社区管理者。

DevRel 专业人员专注于建立和维护与开发人员以及产品或服务所服务的开发人员社区的关系。DevRel 职位上的人关心与开发人员建立联系，倾听他们的想法，并找出如何解决他们的需求。它们还帮助开发人员理解如何使用 API 或产品，提供演示和引导教育活动，如黑客马拉松和聚会。

DevRel 专业人员的两个北极星指标是 TTFHW 和每周活跃令牌(WAT)。

每周活跃代币(WAT)

DevRel 专业人员想看看这个 API 有多大的吸引力，开发者社区是否在增长。为了帮助解决这个问题，他们可以查看 API 的每周活动令牌(WAT)。大多数 API 限制经过身份验证的用户访问，因此他们可以跟踪每周有多少独特的令牌访问 API 平台。如果他们将这一指标缩小到每周活跃的集成公司，DevRel 团队可以计算出在开发者拓展和营销方面投入更多时间和精力的地方。

其他发展指标

虽然 TTFHW 和 WAT 是 DevRel 专业人员关注的两个主要指标，但他们也可能对以下指标感兴趣

• 该公司的文档、指南和快速入门资源覆盖面有多大？
• 开发人员多久和参考文档进行一次交互？哪些部分？
• 开发者对他们得到的支持有多满意？
• 团队创建内容来支持开发人员的频率如何？
• 开发人员是否参与了公司提供的教学内容？

API 产品经理

API 产品管理有些新，所以这个角色的职责根据公司和它提供的 API 产品而有所不同。一般来说， API 产品经理了解 API 或 API 平台的业务合理性，以及公司 API 计划的高层目标。他们还需要平衡内部利益相关者和产品开发人员的需求与客户的要求。

API 产品经理主要关注用户增长、用户保持和使用模式。他们需要知道开发人员使用最多(和最少)的特性和端点来确定开发的优先级。他们还需要了解 API 变化对客户的影响，比如不推荐的端点和新的 API 版本。

API 产品经理关注一系列指标，但是最常见的两个是 API 使用增长和独特的 API 消费者。

API 使用增长

API 产品经理需要衡量 API 的采用情况，他们通过观察 API 使用的增长来做到这一点。他们在很长一段时间内(如几周或几个月)测量 API 的使用情况，以发现关键的增长趋势。

独特的 API 消费者

有时，API 使用的增加是因为单个客户帐户，而不是唯一的用户增长。原料药产品经理应当衡量他们的原料药的每月或每日唯一消费者的数量。他们还应该每天或每月监控这些用户，看他们是否仍然活跃。观察月活跃用户或日活跃用户(MAU/DAU)可以告诉你 API 使用的增加是来自新客户、现有客户，还是两者都有。

API 产品经理关注的其他指标包括

• 开发人员何时、如何以及多久使用 API？
• 开发人员使用或不使用哪些 API 特性？
• 具体的产品特性得到了什么样的反馈？
• 与整体产品采用相比，花费的资金如何？

跟踪 DevEx 指标

虽然您团队中的每个 DevEx 专业人员关心不同的事情，但是他们都需要一个工具来帮助他们有效地跟踪和测量相关的指标。你目前的工作重点是 DevEx 吗？然后，您需要一个有效的 API 分析工具来跟踪和测量您关心的指标和对其他角色重要的指标。

您选择的工具应该提供对所有 API 的可见性——例如 REST、RPC、SOAP、超媒体——以及运行在 GraphQL 等查询语言上的 API。它应该包括插件和 SDK，这样你就可以与流行的服务器集成，而不必编写大量的定制代码。最后，它应该包括预先构建的仪表板，以跟踪每个团队关心的指标——从工程和安全到产品和客户成功。

你不用找太远就能找到具有这些特性的分析工具——moes if API 体验平台拥有所有这些特性。可以免费试用平台14 天。

开发者体验与用户体验

原文：https://www.moesif.com/blog/developer-relations/developer-marketing/Developer-Experience-Vs-User-Experience/

虽然乍看之下它们似乎很相似，但是开发者体验(DX)不仅仅是“开发者的用户体验(UX)”。更确切地说，DX 是 UX 的一个扩展，专注于使用技术语言和工具进行构建的用户。DX 遵循与 UX 相同的核心原则，但通过认识到技术细节和机械过程可以被开发者有效地理解和利用，对其进行了扩展。

当开发人员感到有人在和他们说话，并且他们的需求得到了直接满足时，伟大的 DX 就发生了。这意味着展示代码，提供大量细节，并对多种用例给出清晰的说明。

用户体验是一套最常用于最终用户的通用原则，这些最终用户可能不是技术人员，他们使用软件来满足业务需求和个人消费。开发人员体验的重点是让开发人员能够使用软件构建解决方案。UX 和 DX 之间的区别来自于最终用户和开发者的不同需求。在这篇文章中，我们将探索什么是好的 UX 和 DX，它们之间的主要区别，以及当你为开发者开发产品时的实际区别。

伟大的 DX 始于 UX 的原则

好的 UX 有两个组成部分:让开始使用你的产品变得容易，并确保继续使用它是令人愉快的。开发人员经验扩展了这些相同的核心思想，应用于面向目标的技术受众。

首先，尽可能容易地开始使用新产品。在 UX，这通常意味着尽可能避免注册流程，或者在必要时保持简单。产品应该是直观的——最终用户或开发者应该能够开始使用你的产品，并在最少的指导下实现他们的目标。记住你的产品提供的价值也很重要。您可以使用一些相同的工具来评估 UX 和 DX，如 A/B 测试、用户调查和分析软件。

UX 和 DX 的第一个关键区别是用户体验。好的 UX 让你的产品的用户之旅尽可能简单明了。太多的选择会让最终用户不知所措，这使得完成任务和从产品中获取价值变得更加困难。好的 DX 需要更多的灵活性来支持许多不同的可能的开发者目标。类似地，虽然最终用户不需要技术细节就能成功地使用你的产品，但是开发者需要获得详细的信息，这样他们的需求才能得到评估。好的 DX 让开发人员很容易理解产品或服务是如何工作的，这样他们就可以成功地使用它。

虽然良好的 UX 使具有不同技术能力的用户同样可以使用产品，但 DX 应该考虑不同用户的技术能力，并提供不同级别的支持。经验丰富的开发人员希望使用更强大的工具，而经验不足的开发人员可能需要从更简单的工作流开始，这可能更容易配置。为了让你的开发者体验更好地适应你的产品，了解你的主要用户的技术能力水平是很重要的。

既然我们已经比较了开发人员体验和用户体验之间的高层次差异，我们就来看一个应用程序示例，它展示了实践中的差异。

UX Vs. DX -一个实际的例子

让我们看看 UX 和 DX 在现实世界中的样子。

我们大多数人可能都是消费者购物应用的最终用户。想象一个用户第一次使用一个新的购物应用程序，寻找一件新毛衣。他们可能会在搜索框中输入搜索词“毛衣”，或者点击分类导航。然后，他们会选择他们喜欢的毛衣，并将其添加到购物车中。为了结账，他们可能需要创建一个包含账单和运输信息的账户，或者他们可以简单地点击“用 PayPal 支付”,让网站处理剩下的事情。我们的用户现在需要做的就是等待他们的毛衣到达。

现在，想象一个开发人员在一个新的应用程序中构建相同的功能。抛开任何用于搜索功能的 API 不谈，他们至少会有一个 API 来处理认证和计费，甚至更多。首先，他们必须安装任何必需的库或 SDK，并解决依赖性问题。接下来，开发人员将生成一个 API 密钥，并将其添加到应用程序的环境变量中，以实现可重用性。然后，开发人员将为用户编写对身份验证端点的 API 调用，并编写一个侦听器来确认用户已经过身份验证。下一步是编写一个对应用程序后端的调用，以确认仍然有毛衣可用，并编写一个 API 调用来处理付款。最后，如果支付成功，开发人员应该编写代码来侦听来自 API 的响应，更新后端以从库存中删除一件毛衣，向履行中心发送信息，并安排包裹的交付。

开发人员要成功构建这款应用，需要了解要使用哪些 API 端点、不同端点允许哪些方法、期望从 API 获得哪些响应，以及如何使用 API 密钥安全地验证 API 调用。没有好的 DX，如果开发人员不能快速解决问题，他们可能会在任何时候悄悄地放弃您的产品，或者如果他们没有信心能够成功，他们可能永远不会尝试实现。

正如消费者在购买毛衣时有很多选择一样，开发人员也有很多工具选择。让您的选择成为一个令人信服的选择始于良好的 DX。如果开发者觉得有信心可以使用你的产品，他们会选择你的产品，如果他们觉得成功，他们会继续使用你的产品。

出色的开发者体验始于了解开发者作为用户的独特需求。在下一节中，我们将看看一般的 UX 标准如何应用于面向开发人员的产品，以及如何针对开发人员的受众对它们进行定制。

通过良好的开发人员体验释放 API 产品价值

开发人员体验包括开发人员在构建过程中与您的服务或产品进行交互时发生的事情。开发人员希望感受到创造和创新的力量，好的 DX 帮助他们看到实现想法的可能性和步骤。您需要建立一种激发信心的开发人员体验，然后进行监控以确保您的用户成功并扩展他们的集成。

让我们更详细地看看好的 DX 的特性，以及它们在实践中通常是如何实现的。

开发人员需要能够配置他们使用的服务，以适应各种工作流。线性的用户旅程并不理想，因为它不能反映开发人员的工作方式或应用程序的构建方式。Great DX 提供了支持灵活性的工具和信息，因此您的产品应该尽可能支持不同的配置。实现这一点的好方法包括:

• 提供一系列范围明确的 API 端点
• 用多种语言开发 SDK
• 将代码分割成更小的可重用方法
• 创建可读的无术语代码
• 全面记录你的产品

你必须给开发者足够的信息来理解你产品的技术细节。

您的文档是开发人员进入您的产品的切入点，并告知他们实现产品的决定。如果开发人员能够理解您的产品是如何工作的，他们就可以放心地在他们的工作流程中实现它。您需要清晰、最新和全面的文档，以便开发人员可以学习如何使用您的产品、解决问题以及将其集成到他们现有的工作流中。如果您为具有不同技能和专业水平的开发人员构建产品，这一点尤其重要。

最终，开发人员需要感觉到你理解他们的痛点，并且你的产品、工具和文档解决了他们的问题。有了好的 DX，任何开发人员都应该能够用最少的指令建立产品的基本实现。更有经验的开发人员应该有信心扩展产品的功能以适应独特的用例。您可以通过展示示例代码、在您的文档中提供详细的解释、使用 API 分析来了解开发人员如何使用您的 API，以及演示多个用例的清晰示例来实现这一点。

开发者体验:超越第一印象

留住开发者需要的不仅仅是第一印象。正如良好的 UX 需要评估，完善，并随着时间的推移测试，良好的 DX 是一项长期投资。如果不使用分析来评估您的 DX 和测试更改，您将不会知道自己取得了多大的成功。监控您的 API 有助于您识别未能成功进行 API 调用的用户，为开发人员找到成功和失败的模式，并了解不同用户如何随着时间的推移使用您的产品。虽然对于关注最终用户的产品来说，跟踪 UX 指标相对简单，但是 DX 指标在很多重要方面有所不同。你需要为 API 分析制定一个好的策略，这样你就可以跟踪相关的商业价值指标，同时避免虚荣指标。

虽然开发者体验分享了用户体验的许多关键方面，但重要的是要记住，开发者有超出标准 UX 原则的特定需求。当您为开发人员构建产品时，您需要理解 DX，这样您就可以吸引开发人员用户，激发他们的信心和创造力，并随着时间的推移支持他们日益复杂的集成。构建良好的 UX 和 DX 可能具有挑战性，但是使用 Moesif API Analytics 您可以监控您的 API，并使用指标来打造完美的 API 开发人员体验。

跟踪开发人员从文档访问和注册到第一次 API 调用的旅程

原文：https://www.moesif.com/blog/api-product-management/developer-journey/Tracking-a-Developer

如果你的商业模式包括向开发者销售，你可能已经意识到许多适用于传统企业销售或消费者营销的传统流程和指标并不适用。具体来说，向开发者销售通常意味着将他们吸引到你的平台，并帮助他们成功地构建一些东西，无论是新的应用程序、集成还是内部流程的自动化。让开发人员采用您的平台可能会令人望而生畏，需要在产品、入职和开发人员体验以及文档方面进行投资。然而，产品经理和开发者关系负责人可以用来衡量和改善体验的工具很少。

像 Mixpanel 和 Amplitude 这样的网络和移动分析工具只能测量网站本身的活动，然而大多数开发者平台都是根据 API 发生的事情来定价的，而不是通过网站活动。另一方面，大多数 API 监控工具只能跟踪基础设施指标，如每分钟请求数和 CPU 利用率，而没有任何用户上下文。为了准确衡量您的采用和转化漏斗，您需要跟踪整个平台的使用情况，从最初的广告点击和注册，到新开发人员对您的 API 的使用。

什么是开发者第一的营销策略

大多数开发者优先的平台都有一个 B2D (business2developer)走向市场战略，这与推动消费者采用的 B2C 公司有着独特的区别，但也不同于维持大量销售队伍以将他们的解决方案推向其他企业的 B2B 公司。事实上，B2D 介于 B2B 和 B2C 之间。

B2D 就像 B2C 一样:

• 自助注册和信用卡支付优先于销售演示和合同谈判
• SEO 优化内容、SEM 和合作伙伴关系等低成本获取渠道优先于发送电子邮件的大型昂贵销售开发团队。
• 因为几乎一切都是自助和在线的，你可以非常数据驱动的产品指标，而不是只关注 1:1 的关系。

B2D 也像 B2B 一样:

• 开发人员仍然在一家公司工作，该公司通过购买来解决一个难题，而不是一个寻找最新小工具或在线闲逛点的个人。
• 销售流程仍然很复杂，涉及多个利益相关方，需要技术验证。
• 开发人员仍然是实施复杂解决方案的人，可能需要高接触度的专门支持，而 B2C 的支持是超级事务性的，处理密码重置和返回。

构建跨 web 和 API 的跨平台漏斗

API 产品经理可以在任何给定时间专注于任何数量的计划，无论是 API 功能、定价和包装，还是漏斗收购的顶部。为了知道应该关注哪个领域，你应该从第一次广告点击到完全激活的客户付费并推荐其他客户，绘制出你的整个漏斗图。当访问者注册使用你的 API 时，你的漏斗可能会从你的网站开始。然而，一旦他们创建了一个 API 密匙，很多神奇的事情就发生在 API 端，而不是 web 端。许多开发者平台围绕基于使用的定价建立他们的商业模式，这意味着你的收入与 API 使用相关，而不是网站使用。

| 漏斗阶段 | 来源 | 描述 | 要找什么 |
| 参加报名 | 网站(全球资讯网的主机站) | 开发者做的第一步是对你的平台表现出兴趣。对于开发人员工具，这通常意味着注册并生成一个 API 密钥。 | 你的分析解决方案应该使用 UTM 参数、推荐追踪等来追踪用户来自哪个渠道，以及哪个页面推动了注册。 |
| 进行第一次 API 调用 | 应用程序接口 | 这是一个巨大的里程碑，因为许多注册从未达到这个阶段。开发人员能够理解您的 API 并给它一个旋转。 | 监控 TTFHW(首次 Hello World 的时间)和转化率。你应该继续观察哪些渠道驱动了最多的激活。 |
| 进行了 100 多次 API 调用 | 应用程序接口 | 在大约 100 次 API 调用之后，你可以认为开发人员是“活跃的”，因为他们构建了一个真正的集成，而不仅仅是用 Postman 或 Curl 进行测试 | 上一步的低转换率可能意味着你的 SDK 有困难或者集成步骤不清楚。 |
| 接近自由极限 | 应用程序接口 | 大多数 API 产品都是根据使用情况来定价的。为了成为付费客户，他们需要超过一些限制。 | 如果极少数长期“活跃”的开发者超越了他们的极限，那么你可能需要优化你的包装和定价。 |
| 转换为付费 | 网站(全球资讯网的主机站) | 恭喜你。你现在有付费客户了。 | 大多数开发者有不止一个价值标准来定价。留意哪些是推动付费转化的。 |
| 宣传你的 API | 网站(全球资讯网的主机站) | 开发者在网上分享和讨论你的平台吗？ | 通过添加一个机制来跟踪推荐，您可以看到哪些渠道和媒介表现最好。一个完整的分析平台可以跟踪 UTM 参数和涉及领域等事情。通过一种为每个客户生成唯一链接的机制，您还可以跟踪哪些类型的客户共享最多。 |

为用户和公司链接 web 和 API 活动

Business2developer 走向市场模型具有 B2C 和 B2B 的元素，涉及个人开发者以及公司或客户。它还涉及跨 web 和 API 的跨平台跟踪。这可能会使准确的漏斗和转换报告复杂化。你是跟踪个人用户的注册漏斗还是跟踪集成和使用 API 的公司？如果一个开发者点击了一个广告词，用他或她的 GitHub 账户注册了，但什么也没做，会发生什么？如果这个人邀请了一个同事来做整合，那么这个人可能只能归因于“直接流量”或“邀请推荐”，这取决于你的营销归因。我们仍然需要把成功的整合归功于一次广告词点击。

解决这个问题的一个方法是绘制一个 4x4 网格来跟踪:

| 活跃在 API 上的开发人员 | 活跃于 API 的公司 |
| 活跃在网站上的开发者 | 网站上活跃的公司 |

并不是所有的 API 平台都会遵循这个模型，可能会用一个“不在乎”来填充一些盒子。例如，许多 API 并不关心或跟踪哪个开发者正在访问该 API，然而了解哪个公司正在使用该 API 是很重要的。在这种情况下，我们希望跟踪以下内容:

| 不适用 | 积极参与 API 的公司 |
| 活跃在网站上的开发者 | 网站上活跃的公司 |

解决跨平台跟踪

为了解决这个问题，像 Moesif 这样的分析平台通过用户 id和公司 id链接一切，而不管会话。无论平台如何，您的 API 和网站都应该使用相同的标识，以获得准确的报告。通过将公司建模为用户组，可以简化链接。这提供了选择是否仅在用户级别、仅在公司级别、或者分别为 API 和网站跟踪使用的灵活性。

虽然拥有永久标识符很好，但有时当 API 调用或用户操作被记录时，我们并没有所有可用的信息。为了解决这些情况，我们利用网站会话令牌或 API 密钥来唯一地标识个人和公司。将会话令牌与用户/公司 id 以及 API 密钥与用户/公司 id 相链接的别名表实现了端到端的漏斗跟踪。

结束语

2020 年，随着领导力从不惜一切代价的增长转变为由产品优化驱动的高效增长，准确跟踪使用和留存至关重要。你不能再仅仅衡量浏览量和注册量这样的虚荣指标。相反，你应该衡量整个漏斗，并了解影响每个阶段的输入。价格和包装的变化如何改变你从活跃开发者到转变为付费用户的转化率。

在表格中显示 Moesif 报告

原文：https://www.moesif.com/blog/technical/dashboards/Display-Moesif-Reports-Within-Tableau/

作为产品领导者，没有比用图形显示关键数据更好的方式来展示你的 API 平台的价值了。如果你已经在使用 Tableau，很容易从 Moesif 的仪表板中提取关键图表，或工作区，并将其插入到你的可视化平台中。

来自 Moesif 的信息将作为网页对象插入 Tableau。网页对象是基于微软 IE 的全功能网络浏览器窗口，因此，窗口中的所有按钮、链接和导航功能将像普通浏览器一样运行。

本指南将带您完成在 Tableau 仪表板中设置和显示 Moesif 工作区所需的步骤:就像 1-2-3 一样简单。

第一步。Moesif 的工作空间公共链接

在 Moesif 的 API 分析平台中，为您想要跟踪的指标创建一个工作空间。

将工作空间另存为公共工作空间。

我们将使用共享链接，如下所示，将工作区直接嵌入 Tableau 中。

第二步。Tableau 的 Web 对象

一旦你创建了 Tableau 仪表板，你需要插入一个新的网页对象。

点击对象下的网页图标，如下图所示，将其拖动到仪表盘上您想要插入 Moesif 工作空间的位置。

释放图标时，会出现一个弹出窗口。在步骤 1 中输入来自共享链接的 URL。

应该会出现 Moesif 工作区。调整 Tableau 仪表板中的图块大小，以最佳方式显示您的新指标。

第三步。添加更多工作区

重复步骤 1 和 2，用 Moesif 的关键指标填充 Tableau 仪表板，展示 API 平台的价值。

以下示例显示了产品经理的现有 Tableau 仪表板，其中插入了两个 Moesif 工作区:

• 按公司域分组的每周 API 使用情况
• 新激活的客户

在 Tableau 中轻松可视化关键 API 产品指标

数据和分析堆栈已成为您企业解决方案的重要组成部分。Tableau 是一款流行的产品，可以可视化数据仓库中的数据。通过使用 web 页面对象，您现在可以毫不费力地从 Moesif 引入关键的 API 产品指标。

该组合解决方案为您的决策过程提供了单一参考点。

不要把你的 API 数据塞进振幅里

原文：https://www.moesif.com/blog/technical/api-analytics/Dont-Shove-API-Data-Into-Amplitude/

当达到最小可行产品(MVP)时，只关注你的核心特性是谨慎的商业实践。微服务架构允许您将解决方案的非差异化部分外包给第三方提供商；使用其他人进行用户管理、计费和帐户管理。

乍一看，开发自己的 API 分析解决方案似乎很有吸引力，也许是通过构建在 web 分析工具之上，如 Amplitude、MixPanel 或 Segment。但是一旦你剥开洋葱皮，你很快就会意识到你会因为上传限制、最小的维度支持和有缺陷的可视化而不必要地削弱你的解决方案。

为工作使用正确的工具，并采用最佳案例分析解决方案，一个专为 API 产品构建的解决方案，如 Moesif API Analytics。

Web 分析与 API 分析非常不同

Amplitude 非常适合跟踪用户旅程，并通过简单的 logEvent API 调用分析实时用户交互。当一个 Amplitude 开发者加入这个平台时，一些开发者会尝试使用 Amplitude 作为一个包罗万象的整体平台来满足他们的分析需求。然而，在实现阶段，开发人员会发现 Amplitude 平台在上传限制(批次/秒)、字段限制、维度限制和规模限制方面有严重的局限性。由于这些限制，开发人员将很难在 Amplitude 上构建他们的整个分析解决方案，并且需要购买其他解决方案来满足他们的分析需求。

最重要的是，产品经理(pm)和产品营销经理(pmm)需要报告 KPI，但不一定拥有开发知识或技术资源来实现复杂的自我报告仪表板。因此，振幅有时在大型组织中无法使用，因为 KPI 仪表板需要在业务单位的基础上进行定制。有了 Moesif，任何项目经理或 PMM 想要的所有 API/KPI 数据都可以在一个简单的下拉菜单界面中获得。在本文中，我们将讨论为什么不应该将 API 数据硬塞进 Amplitude，而应该考虑一个为 API 的独特需求定制的解决方案。

使用 Moesif 轻松跟踪 API 数据

Amplitude 的客户加入该平台时设想，他们将拥有创建图表来跟踪重要 KPI 和指标数据的无缝体验。然而，一旦实现了 Amplitude，项目经理和他们的开发团队很快就发现建立图表来跟踪这些度量是一项单调乏味的手工工作。

开箱即用的 Moesif 使您的团队能够跟踪对您的基础设施和平台/营销团队都很重要的 API 指标。无论您是在开发运维、产品管理、应用工程还是发展领域，Moesif 都旨在跟踪您关心的指标数据。在某种程度上，您的 API 数据最初并不是为您配置的，并且您跟踪单个用户数据或总体公司指标的选项非常有限。穆塞夫

这是一个指标数据的列表，可以用 Moesif 跟踪，并且必须在振幅中自定义创建:

• API 使用增长
• 独特的 API 消费者(API DAU 和 MAU)
• 按 API 使用情况列出的顶级客户
• API 保留
• 第一个 Hello World (TTFHW)的时间到了
• 正常运行时间、CPU 和内存使用量
• 每分钟请求数(RPM)、平均和最大延迟、每分钟错误数

您的团队应该跟踪的顶级 API 指标的完整概要在[companion]((https://www . moesif . com/blog/technical/API-Metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/？UTM _ campaign = Int-site & UTM _ source = blog & UTM _ medium = body-CTA & UTM _ term = API-solutions){:target = " _ blank " }博客文章。

借助 Moesif 的保存工作区功能，团队可以保存报告并在整个组织内共享。有没有一些只有你想看的报告？使用 Moesif 创建私有仪表板很容易，只需修改您工作区的“编辑共享”设置，并选择您希望您的工作区是私有的、与您的团队共享的还是公共的。要了解有关该功能的更多信息，请点击此处。

Moesif 与振幅 API 数据限制

Amplitude 对每月可以触发的事件数量以及每秒可以发送的事件数量有限制。Moesif 有一些限制，比如 JSON 负载大小，但是正如您从下表中看到的，Moesif 更具成本效益，并且不需要您注册昂贵的企业计划来访问超过 1000 个事件/秒。通过 Moesif 的现收现付定价，您只需为您使用的活动付费，如果您超出分配的计划，Moesif 不会阻止您的请求:

	穆塞夫	振幅
批量	12MB	20MB
上传限制	没有限制	100 批/秒和 1000 个事件/秒，超过 1000 个事件/秒需要企业计划
设备限制	没有限制	每个请求 2000 个事件，小于 1MB
请求限制	没有限制	跨所有 REST API 端点的 5 个并发请求
事件类型	没有限制	每个项目 2000 个事件类型
事件属性	没有限制	每个项目 2000 个事件属性
用户属性	没有限制	每个项目 1000 个用户属性

使用 Moesif，在 API 数据跟踪方面没有上限。Moesif 允许开发人员收集客户想要发送的任意多的事件。该基础架构是围绕集群和节点设计的，可以轻松地进行动态扩展。使用 Moesif，负载在多个集群/节点之间平衡，这允许您的 API 数据无限扩展。

使用 Moesif 的 API 安全性和可伸缩性

Moesif 在其平台中实施了顶级的安全性，并且完全符合 GDPR 和 SOC 2 标准。所有的 API 令牌都使用 HMAC SHA-256 进行签名，Moesif 的 SSL 实现在 Qualsys 的 SSL 实验室分析中获得了 A+，所有 Moesif 的 SDK 和代理都被配置为默认使用 HTTPS。借助 Moesif 的安全代理，HIPAA 合规性与本地客户端加密和自带密钥(BYOK)无缝结合。这些安全特性将使您能够在跟踪 API 分析时，在任何行业或用例中实现 Moesif。

使用 Moesif vs Amplitude 的 API 分析管理

如您所见，使用 Moesif 管理您的 API 分析使您的企业能够快速创新，并使您的开发人员能够轻松构建完全可扩展和兼容的分析仪表板。Moesif 使组织能够创建强大的仪表板，跟踪常见的 KPI 和可根据您的业务需求定制的指标数据。此外，Moesif 不会对 API 的使用设置任意的限制，因为没有理由忽略一个 API 请求。准确的数据报告是为您的客户建立强大、可靠业务的基础，Moesif 非常乐意通过我们强大的 API 分析平台帮助您实现这些目标。要了解更多关于 Moesif 的信息并查看其工作原理的简要概述，请查看我们的介绍视频。

使用 Moesif Plus Chargebee 轻松实现 API 货币化

原文：https://www.moesif.com/blog/developer-platforms/chargebee/Easily-Monetize-Your-APIs-With-Moesif-Plus-Chargebee/

能造出赚钱的东西总是很棒的。最成功的企业通常会找到最简单、最有效的方法来赚钱，同时将成本和支持保持在最低水平。毕竟，最好的企业和产品就是那些知道如何创造收入的企业和产品。许多公司现在希望将他们的 API 货币化作为他们整体货币化战略的一部分。

然而，API 货币化并不总是容易的。它通常需要大量的集成、大量的代码和定制，还会导致巨大的支持负担。当出现账单问题时尤其如此。简而言之，无论是在实施过程中，还是在计费系统启动并运行后，都存在挑战。

如果有一种更简单的方法是可能的呢？在 Moesif，我们最近为计费表引入了一项功能。这是一种使用进入 Moesif 的数据来监控用户使用情况、将这些数据发送给计费提供商，并向用户提供准确账单的方法，所有这些工作只是实现定制解决方案所需工作的一小部分。

为了说明它是如何工作的，让我们假设我们有一个 API，我们希望对客户的使用进行收费。作为一个例子，让我们假设我们已经创建了一个新的信用评分 API，公司可以使用它将消费者的信用评级带回他们的应用程序。我们的 API 将是 /getCreditScore ，用户将为他们发送到端点的每个查询/调用付费。我们的 API 货币化模型将非常简单，我们将对我们的 /getCreditScore 端点的每次调用收取 0.10 美元。

收款人将是我们用来向客户开具发票和收取使用费的账单提供商。Chargebee 易于使用，使我们能够轻松设置计划和定价，以遵守上述定价方案。

我们现在将使用 Moesif 来统计端点的使用情况，并将使用指标发送给 Chargebee。然后，被收费人可以使用这些指标，根据指标对应的层级，向客户开出相应的账单，并收取费用。

将您的应用和 API 与 Moesif 集成

为了使用 Moesif 中的计费表特性，您需要将您的 API 与 Moesif 集成。这是因为 Moesif 将使用存储在其中的指标，然后向 Chargebee 提供它需要的信息。一旦您的 API 与 Moesif 集成，您还可以使用与我们的计费表功能配合良好的其他功能，包括行为电子邮件、治理规则和警报。

如果您目前没有使用 Moesif 来监控您的 API，那么可以用几种不同的方式来完成集成。如果你正在使用 API 网关或 API 管理平台，你可以使用我们众多插件中的一个，它允许你快速向 Moesif 提供分析。如果你没有使用第三方网关或管理平台，或者想在 API 代码层面上做，你可以使用我们的一个 SDK。Moesif SDK 将允许您直接从代码中轻松地将 Moesif 与您的节点、Python 或 Java APIs(以及更多的语言和框架)集成。这两种方式都很容易支持。

为了让计费正常工作，您需要部署的另一个 Moesif 特性是实现用户和公司跟踪。通常，这可以通过几个简单的步骤来设置。我们需要启用此功能，以便 Moesif 中的使用数据可以绑定到特定的用户和公司。这是 Chargebee 将用量映射到 Chargebee 内部客户的方式，因此可以对他们进行相应的计费。

一旦您与 Moesif 集成，并启用了用户和客户跟踪，您的下一步将是在 Chargebee 中实际创建您的计划，以便它们可以在 Moesif 中使用。

负责创建计划和价格

创建收费帐户并登录后，您可以开始创建您的计划。出于我们的目的，我们需要创建一个包含使用标准定价的价格的计划。

你需要创建一个负责人计划，这是计量。价格应该设置为每月计费间隔，以便在月底总计使用量。单价也需要设置为 0.10 美元。

例如，设置计划将如下所示:

每月定价详细信息如下所示:

现在，在月末，当 Chargebee 创建发票时，它将合计总使用量并相应地向客户开出账单。当然，在这一点上，我们只定义了计划，但没有人会被收费，因为我们还没有任何使用数据被发送到 Chargebee。

将收费对象与 Moesif 集成

我们仍然需要将数据从 Moesif 传递到 Chargebee，反之亦然。有两种机制用于此:webhook 和 Chargebee API。在促进平台之间的数据共享方面，两者各有不同的作用。

通过将 webhook 添加到 Chargebee 中，订阅更新可以发送回 Moesif。通过使用 Chargebee API，Moesif 可以向 Chargebee 发送使用详细信息，还可以在 Chargebee 中检索可用计划和价格的详细信息。这两个联系点是 Chargebee 和 Moesif 集成所需要的。幸运的是，当您将 Chargebee 设置为计费提供商时，Moesif 会带您完成这一步，并提供所有需要的详细信息。具体情况，您也可以查看我们关于 Chargebee integration 的文档。

设置您的计费参数

一旦您将 Chargebee 集成到 Moesif 中，您就可以设置您的计费表了。对于我们的例子，这将是非常简单的。我们要做的是，每当对 /getCreditScore 的 API 调用返回“200 OK”响应时，就向 Chargebee 发送使用指标。这意味着我们将只对成功的呼叫计费，而不会意外地对出现错误的呼叫计费。

一旦我们创建了计费表，每个小时每个客户的使用量将被发送给被计费人。月底，Chargebee 将根据我们的定价结构开具发票，并向用户收费。

您还可以使用 Moesif 为每一次成功的通话自动发送行为电子邮件，即使他们即将进入下一个折扣级别。您还可以使用 Moesif 的治理规则来阻止发票过期的用户访问 API，直到他们的发票得到结算。

你自己试试吧

如您所见，离易于实现和支持的健壮 API 货币化只有几步之遥。通过同时使用 Moesif 和 Chargebee，您将能够在几分钟内向客户收取使用费，管理订阅，甚至可以使用 Moesif 的其他功能来创建最终的客户体验。我们的计费设置非常简单，甚至不需要任何开发人员的技能就可以完成。

所有 Moesif 用户均可使用计费表功能。立即注册moes if，立即访问我们的计费表功能，开始为您客户的 API 使用计费。如果你已经在使用 Moesif，点击左侧导航菜单中的计费表并查看我们的文档以显示让你将 API 货币化的具体步骤。

用 Moesif Plus Recurly 轻松赚钱

原文：https://www.moesif.com/blog/developer-platforms/recurly/Easily-Monetize-Your-APIs-With-Moesif-Plus-Recurly/

能造出赚钱的东西总是很棒的。最成功的企业通常会找到最简单、最有效的方法来赚钱，同时将成本和支持保持在最低水平。毕竟，最好的企业和产品就是那些知道如何创造收入的企业和产品。许多公司现在希望将他们的 API 货币化作为他们整体货币化战略的一部分。

然而，API 货币化并不总是容易的。它通常需要大量的集成、大量的代码和定制，还会导致巨大的支持负担。当出现账单问题时尤其如此。简而言之，无论是在实施过程中，还是在计费系统启动并运行后，都存在挑战。

如果有一种更简单的方法是可能的呢？在 Moesif，我们最近为计费表引入了一项功能。这是一种使用进入 Moesif 的数据来监控用户使用情况、将这些数据发送给计费提供商，并向用户提供准确账单的方法，所有这些工作只是实现定制解决方案所需工作的一小部分。

为了说明它是如何工作的，让我们假设我们有一个 API，我们希望对客户的使用进行收费。作为一个例子，让我们假设我们已经创建了一个新的信用评分 API，公司可以使用它将消费者的信用评级带回他们的应用程序。我们的 API 将是 /RetrieveCreditScore ，用户将为他们发送到端点的每个查询/调用付费。

我们的 API 货币化模型将非常简单。我们将有 3 个使用层级来决定向用户收取多少费用:

• 每月 1-100 次查询(每次查询 5 美元)
• 每月 101-1000 次查询(每次查询 3 美元)
• 每月 1001 次以上的查询(每次查询 2 美元)

这种分级定价模式很常见，使用的服务越多，折扣就越大。

Recurly 将是我们用来为客户的使用开具发票和收费的计费提供商。Recurly 易于使用，将允许我们轻松地设置计划和附加组件，以遵守上述定价方案。

我们现在将使用 Moesif 来统计端点的使用情况，并将使用情况度量发送给 Recurly。Recurly 随后可以使用这些指标，根据指标对应的层级，向客户开出相应的账单，并收取费用。

将您的应用和 API 与 Moesif 集成

为了使用 Moesif 中的计费表特性，您需要将您的 API 与 Moesif 集成。这是因为 Moesif 将使用存储在其中的指标，然后递归地反馈它需要的信息。一旦您的 API 与 Moesif 集成，您还可以使用与我们的计费表功能配合良好的其他功能，包括行为电子邮件、治理规则和警报。

如果您目前没有使用 Moesif 来监控您的 API，那么集成可以通过几种不同的方式来完成。如果您使用的是 API 网关或 API 管理平台，您可以使用我们众多插件中的一个，该插件允许您快速向 Moesif 提供分析。如果您不使用第三方网关或管理平台，或者想在 API 代码级别使用，您可以使用我们的 SDK 之一。Moesif SDK 将允许您直接从代码中轻松地将 Moesif 与您的 Node、Python 或 Java APIs(加上许多、许多语言和框架)集成在一起。两种方式都很容易支持。

为了让计费正常工作，您需要部署的另一个 Moesif 特性是实现用户和公司跟踪。通常，这可以通过几个简单的步骤来设置。我们需要启用此功能，以便 Moesif 中的使用数据可以绑定到特定的用户和公司。这就是 Recurly 如何将使用情况映射到 Recurly 内部的客户，因此他们可以相应地被计费。

一旦您与 Moesif 集成，并启用了用户和客户跟踪，您的下一步将是在 Recurly 中实际创建您的计划，以便它们可以在 Moesif 中使用。

在递归中创建计划和附加组件

创建递归帐户并登录后，您可以开始创建您的计划。出于我们的目的，我们需要创建一个计划，其中包括使用分层定价的附加产品。

您需要在 Recurly 中创建一个后付费(在计费周期结束时收到的付款)的计划，价格是每单位。除此之外，对于我们的定价方案，我们将创建一个具有分层定价方案的附加组件。递归地看起来是这样的:

现在，在月末，当 Recurly 创建发票时，它将基于这些层来这样做。当然，在这一点上，我们只定义了计划，但没有人会被收费，因为我们还没有任何使用数据被发送到 Recurly。

% include cta_section.html 摘录= '轻松集成计量计费' image =img/posts/CTA/CTA-monitoring . SVG ' button _ text = '了解更多' URL = ' https://www . moes if . com/solutions/Metered-API-Billing？UTM _ campaign = Int-site & UTM _ source = blog & UTM _ medium = body-CTA & UTM _ term = money-with-recurly ' % }

与 Moesif 递归集成

我们仍然需要从 Moesif 到 Recurly 获取数据，反之亦然。有两种机制用于此:webhook 和 Recurly API。在促进平台之间的数据共享方面，两者各有不同的作用。

通过将 webhook 添加到 Recurly 中，订阅更新可以发送回 Moesif。通过使用 Recurly API，Moesif 可以向 Recurly 发送使用细节，还可以在 Recurly 中检索可用计划和附加组件的细节。这两个接触点是 Recurly 和 Moesif 集成所需要的。幸运的是，当您将 Recurly 设置为计费提供商时，Moesif 会带您完成这一步，并提供所有需要的详细信息。关于细节，你也可以查看我们关于递归集成的文档。

设置您的计费参数

一旦你递归地集成到 Moesif 中，你就可以设置你的计费表了。对于我们的例子，这将是非常简单的。我们要做的是，每当对 /RetrieveCreditScore 的 API 调用返回“200 OK”响应时，将使用度量发送给 Recurly。这意味着我们将只对成功的呼叫计费，而不会意外地对出现错误的呼叫计费。

一旦我们创建了计费表，每个小时每个客户的使用量将被发送到 Recurly。在月底，Recurly 将根据我们的分级价格结构创建发票，并向用户收费。

您还可以使用 Moesif 为每一次成功的通话自动发送行为电子邮件，即使他们即将进入下一个折扣级别。您还可以使用 Moesif 的治理规则来阻止发票过期的用户访问 API，直到他们的发票得到结算。

你自己试试吧

如您所见，离易于实现和支持的健壮 API 货币化只有几步之遥。通过一起使用 Moesif 和 Recurly，您可以在几分钟内向客户收取使用费，管理订阅，甚至可以使用 Moesif 的其他功能来创建最终的客户体验。我们的计费设置非常简单，甚至不需要任何开发人员的技能就可以完成。

所有 Moesif 用户均可使用计费表功能。立即注册moes if，立即访问我们的计费表功能，开始为您客户的 API 使用计费。如果你已经在使用 Moesif，点击左侧导航菜单中的计费表并查看我们的文档以显示让你将 API 货币化的具体步骤。

向客户嵌入具有表面反应指标的仪表板

原文：https://www.moesif.com/blog/technical/dashboard/Embedding-Dashboards-with-React-to-Surface-Metrics-to-Customers/

嵌入式仪表板是一种简单的方式，可以让您在团队中以及与客户分享从 Moesif 获得的见解。您定义指标，构建仪表板，然后在您的开发人员门户中共享它们，按公司或用户进行筛选。

从技术角度来看，它们只是可以显示在网页某处 iframe 中的网站。但是，为了防止用户看到来自其他用户的数据，在完成所有授权检查之后，您必须在后端获取仪表板 URL。

在一篇配套的博客文章中，我们向您展示了如何创建一个定制的仪表板，以及如何用您的数据讲述一个故事。在这篇文章中，我们将在 React 应用程序中嵌入一个 Moesif 仪表板。我们将创建一个获取仪表板 URL 的后端和一个基于 React 钩子的 React 组件，它与我们的后端对话。

先决条件

按照这个方法，你需要一个 Moesif 账户和节点. js 。

正在初始化项目

要初始化新项目，您必须运行以下命令:

$ mkdir moesif-dashboard
$ cd moesif-dashboard
$ npm init -y 

创建后端

我们将使用 Express 创建一个后端，并将 Axios 作为 HTTP 客户端，与 Moesif dashboard 服务进行对话。后端将服务于前端和我们的仪表板的 URL。首先，我们需要安装软件包:

$ npm i axios express 

之后，我们可以创建一个包含以下内容的server.js文件:

const axios = require("axios");
const express = require("express");
const fs = require("fs");

const clientHtml = fs.readFileSync(__dirname + "/client.html");

const app = express();

app.get("/", (request, response) => response.end(clientHtml));
app.get("/dashboards/:worspaceId", async ({ params, user }, response) => {
  const url = `https://api.moesif.com/v1/portal/~/workspaces/${params.workspaceId}/access_token`;
  const body = { template: { values: { company_id: user.companyId } } };
  const headers = { Authorization: "<MOESIF_AUTH_TOKEN>" };
  const { data } = await axios.post(url, body, { headers });
  response.end(JSON.stringify(data));
});

app.listen(8888); 

GET /dashboards/:workspaceId路由将把我们的工作空间 URL 传递给客户机，以便在 iframe 中使用它。

你必须用你自己的替换掉<MOESIF_AUTH_TOKEN>。

company_id将是为一家公司过滤仪表板的动态值。

在 Express 中，认证通常通过一些中间件来完成，表示为authMiddleware()。它查看请求，以某种方式验证它，并向请求对象添加一个用户对象。用户对象有一个companyId属性，用于从 Moesif API 获取仪表板 URL。

该路线有一个用于workspaceId的参数。此参数使路线更加灵活。它现在可以为不同的仪表板提供 URL。

Moesif API 返回带有一个access_token和一个url的 JSON，我们简单地将它们传递给我们的后端客户端。通过该 URL 可以访问由一家公司筛选的单个仪表板；这样，我们可以防止用户访问他们不应访问的仪表板。

创建前端

前端将是一个简单的反应应用程序。用以下代码创建一个client.html:

<!DOCTYPE html>

<title>Embedded Dashboard</title>

<div id="app"></div>

<script src="https://unpkg.com/react@16.13.1/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom@16.13.1/umd/react-dom.production.min.js"></script>
<script src="https://unpkg.com/@babel/standalone@7.11.6/babel.js"></script>

<script script type="text/babel">
  function App() {
    return (
      <div>
        <h1>Embedded Dashboard</h1>
        <Dashboard workspaceId="<WORKSPACE_ID>" />
      </div>
    );
  }

  function Dashboard({ workspaceId }) {
    const [dashboardUrl, setDashboardUrl] = React.useState("");

    React.useEffect(() => {
      fetch("/dashboards/" + workspaceId)
        .then((r) => r.json())
        .then(({ url }) => setDashboardUrl(url));
    }, [workspaceId]);

    return (
      <iframe src={dashboardUrl} frameborder="0" noresize="noresize"></iframe>
    );
  }

  ReactDOM.render(<App />, document.getElementById("app"));
</script> 

这里的Dashboard组件是必不可少的。它需要一个workspaceId prop 从我们的后端获取仪表板 URL。useEffect钩子会跟踪这个道具；每次有新值进来，它都会从后端获取仪表板 URL。这样，我们可以为不同的仪表板创建组件的多个实例，并且我们还可以通过组件的一个实例来更改当前仪表板。

链接嵌入式仪表板

下一步是从我们想要嵌入的仪表板中收集 worksapce IDs。要找到这些 id，您必须导航到 Moesif 控制台的“仪表板”页面。在那里你必须选择一个你想要整合的仪表板，然后点击它的标题。

在仪表板的详细信息页面上，您必须点击右上角的橙色“共享”按钮。

选择“共享并嵌入模板”。从那里，您可以提取工作区 ID，这是我们的仪表板组件所需要的，就在 cURL 示例中。

使用应用程序

要使用这个示例，您必须使用 Node.js 运行服务器:

$ node server.js 

前端将在 http://localhost:8888/ 可用。

摘要

如果您有一个用 React 创建的开发人员门户，那么在其中嵌入一个仪表板是非常容易的。您可以创建一个Dashboard组件，封装从服务器获取仪表板 URL 所需的所有客户端逻辑，并在 iframe 中显示它。

如果你想让它可配置不同的仪表盘，你得给它一个workspaceId作为道具；然后，您可以在多个地方使用它来加载不同的仪表板。

通过 Moesif 实现 API 货币化

原文：https://www.moesif.com/blog/technical/stripe/Enabling-API-Monetization-With-Moesif/

作为一个 API 提供者，你可能会把你的 API 带来某种形式的收入作为你的商业模式的一部分。当你第一次开始你的 API 产品的货币化之旅时，你可能会发现货币化的复杂性根深蒂固。很多时候，解决这个问题超出了典型 API 网关或 API 管理平台的能力。问题开始出现，比如“您是按 API 调用收费还是按用户收费？”或者“如果 API 用户有过期发票，我如何阻止他们使用 API？”。要解决这些问题，需要大量的定制、测试和支持。幸运的是，有了 Moesif，通过该平台提供的端到端货币化，为用户创造一个顺畅的旅程变得极其简单。Moesif 可以作为一个 API 货币化平台，提供大量的灵活性。它还提供了其他工具，可以补充您的用户旅程，推动 API 的采用，并改进您的 API 产品。

让我们来看看如何使用 Moesif，通过利用 Moesif 的 API 货币化功能实现 API 货币化策略来增加收入。

账单提供商

根据您的具体使用情况，您可能会倾向于选择最符合您需求的计费提供商。目前，Moesif 支持 3 个不同的计费提供商。账单提供商包括:

• 种类
• 递归地
• 受款人

这些平台各有利弊。要了解更多相关信息，请查看这篇很棒的文章，它讲述了每个平台的所有错综复杂之处。根据您的 API 货币化模型，您可能会发现这些平台中的一个或多个将支持您的用例。

通过 Moesif，这些计费提供商可以连接到 Moesif，以便可以将使用数据发送给提供商，并且提供商也可以将数据发送回 Moesif，例如发票详细信息或订阅更新。通过使用 Moesif 向提供商发送计费数据并接收返回的数据，Moesif 可以在 API 的整体盈利中发挥关键作用，并允许轻松配置和维护/故障排除。

计费仪表

将 Moesif 连接到计费提供商后，您将能够创建计费表。计费仪表主要做两件事:

• 允许您创建一个过滤器来监控和统计 API 使用情况
• 将 API 资源的使用情况发送给选定的计费提供商

Moesif 是启动您的计费流程的最佳地点，因为它拥有来自 API 调用的所有数据以及创建复杂计费标准的能力。

要创建计费表，只需登录 Moesif 并从左侧导航导航至计费表屏幕。从那里，点击添加计费仪表按钮。

在下一个屏幕上，您可以设置过滤器，以指定您希望对哪些流量进行计费。例如，我们可以为一个特定的端点和状态代码设置一个过滤器，比如只对收到一个 200 OK 响应状态代码的 /myservice 端点的 API 调用计费。此时，您还将选择要计费的指标。我们将为此选择事件计数，这样每个 API 调用都将被计为一个单元，但其他选项也是可用的，包括按唯一用户、响应主体计数，或使用自定义指标。

您还需要确保在 Moesif 中配置了账单提供商。这可以在短短 5 分钟内完成！好奇有多简单？查看我们的指南，了解如何使用、和。创建计费计量器后，使用情况将自动同步到您为计费计量器选择的计费提供商。在几分钟内，您将拥有通过 Moesif 利用计量计费的货币化 API。如需更深入的示例，请使用孔、孔和节点查看我们的端到端指南。

治理规则

API 货币化是一回事，但基于计费状态控制访问是另一回事。如果用户有过期发票或已超出其批准的支出，您可能希望暂停他们的访问。这可以在 Moesif 中使用治理规则来完成。治理规则很容易建立。只需导航到治理规则屏幕并点击添加新的。

然后我们将添加一个新的用户规则。

在下一个屏幕上，将配置规则以阻止属于未支付发票的用户群的用户。我们将返回一个带有 402 -付款要求响应代码和概述问题的响应主体的响应。

一旦这个治理规则被创建，它将有效地阻止用户访问 API，直到他们的发票被结算。对于预付费场景，您还可以使用一个治理规则在用户的信用余额达到 0 美元时阻止呼叫。要更详细地了解这个预付费场景，请查看我们关于 Moesif 预付费计费的博客。

关于 Moesif 中的治理规则，有两个重要注意事项。首先，治理规则是企业计划的一个特性，因此您需要企业订阅。其次，并不是所有的 SDK 和插件都支持治理规则。在尝试实施治理规则之前，请验证您的特定设置和计划将支持治理规则。

行为电子邮件和警报

尽管是可选的，使用 Moesif 的行为电子邮件和提醒功能可以增强用户对货币化 API 的体验。这两种功能都使用可定制的过滤器来建立发送电子邮件或警报的条件。

行为电子邮件可用于指导用户注册您的 API，通知他们可能发生的问题以及如何解决这些问题，或者在货币化 API 的情况下，让用户知道他们有一张未结发票阻止他们访问 API。

例如，我们可以设置一个行为电子邮件，当一个 API 消费者试图访问一个未支付发票的 API 时，该电子邮件将被发送。为此，导航至行为电子邮件屏幕，并选择创建模板。

在这里，我们将填写详细信息，并创建一封简单的电子邮件，让用户知道他们的 API 访问因未结发票而暂停，以及如何付款。

一旦创建了电子邮件，只要用户成为未支付发票的用户的一部分，他们就会自动收到一封电子邮件，帮助他们重新获得 API 的访问权限。

警报可用于提醒内部团队有关事件，如用户遇到大量错误或集成问题。然而，就 API 货币化而言，您可以进一步使用警报，让销售和客户成功团队了解可能需要拓展或允许可能的追加销售机会的某些情况。

根据上面的示例，我们还可以提醒客户成功团队(或会计团队，在他们负责跟进过期帐户之前)，让他们知道客户可能需要帮助来结算过期发票。要创建警报，导航至警报规则屏幕并选择 +警报规则。

从这里开始，我们将配置警报，每当有人在 15 分钟的时间内试图访问 API 超过 5 次时，就会向我们的支持团队发送电子邮件。

一旦警报被激活，我们的客户成功团队将会收到通知。当然也有通过短信，Slack，PagerDuty，或者自定义 Webhook 配置来告警的方式。关于警报规则的更多信息可以在文档中找到。

试试吧！

实施货币化战略一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个货币化的 API。

最重要的是，通过治理规则、行为电子邮件和提醒来指导客户并为客户提供良好的体验，支持客户变得更加容易。Moesif 是市场上最灵活、最易用的端到端 API 货币化产品。想试试吗？立即注册开始将您的 API 货币化，并在几分钟内增加您的 API 收入。

利用 AWS API Gateway、Stripe 和 Moesif 实现端到端 API 货币化

原文：https://www.moesif.com/blog/technical/stripe/aws-api-gateway/End-To-End-API-Monetization-With-AWS-API-Gateway-Stripe-And-Moesif/

许多 API 开发者和公司都在努力寻找简单的方法来建立系统，以使他们的 API 货币化。有些很简单，但不可定制，有些很复杂，需要大量的工程工作才能真正运行起来。

为了让事情变得更容易，Moesif 几个月前创建了一个名为计费表的功能，它提供了巨大的可定制性，但只需要最少的代码和工程工作。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、AWS API Gateway 和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 您有一个有效的 AWS 帐户
• 您有一个正在运行的 AWS API 网关实例(创建了一个端点)
• 您的 AWS API 网关实例正在使用 API 密钥保护您的端点
• 您已经在 AWS API 网关中创建了一个使用计划
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户
• 您已经配置了 Moesif 和 AWS API 网关集成

在 AWS 控制台中配置 Moesif 时，日志格式必须包括以下内容:

"user": "$context.identity.apiKeyId"

这将把 API Key ID 映射到 Moesif UserId。这是一个关键的配置步骤，否则下面的示例代码将不会像预期的那样工作。

从外观上看，设置非常简单。我们将创建一个 /register 端点，它:

• 使用 AWS API 网关客户端 SDK 生成 API 密钥
• 将 API 密钥添加到使用计划中
• 在条带中注册用户
• 为用户订阅产品
• 在 Moesif 中注册用户和公司
• 将 API 密钥返回给用户

我还为它创建了一个小小的前端，它是一个简单的表单，通过调用 /register 端点来注册用户，然后为新注册的用户显示生成的 API 密钥。

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当你将 Stripe 集成到 Moesif 中时，你已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

名称

这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

定价模式

在 Stripe 中可以设置一些不同的定价模型。这些定价模型包括:

• 标准定价
  • 如果您希望对每个 API 调用收取相同的费用，请使用此选项。
• 包
  • 如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。
• 毕业了
  • 使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。
• 体积
  • 如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的单价为 10.00 美元，100 个单位的单价为 7.00 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每天地；天天地
• 一周的
• 每月
• 每 3 个月
• 每 6 个月
• 每年的
• 习俗

对于您的 Moesif 配置，我们建议将计费周期设置为每月。我们还建议，如果您正在使用 Moesif 的计费计量功能，也要检查使用量是否被计量框。

按计量使用收费

一旦选择了计量使用量复选框，将出现计量使用量的收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

• 期间使用值的总和
  • 在整个计费周期中，用户都要为其记录的使用付费
• 期间内最近的使用值
  • 根据计费周期结束前记录的最后一次使用情况向用户收费
• 最近使用值
  • 在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费
• 期间的最大使用价值
  • 用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时段期间的使用值总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选字段，但建议填写。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费表，在 Moesif 中，您将导航至计费表屏幕。您可以从右侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的+添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

计费电表名称

这是您的新计费仪表的 Moesif 内部名称

账单提供商

在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。

产品(仅条纹)

在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。

价格(仅条纹)

计费计数器的计费提供者设置中的最后一个字段，在这里您可以选择您要将使用指标绑定到哪个价格。

过滤器

在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。

指标

在这里，您可以选择希望计费的指标。可用选项包括:

• 事件计数
  • 这将增加符合过滤标准中列出的标准的每个事件的使用量。
• 唯一用户
  • 每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。
• 自定义
  • 这使您能够构建自己的指标，如接收的数据、美元量的百分比、计算单位的总和或任何其他与 API 相关的消耗指标。Moesif 支持 API 主体字段、用户操作等方面的度量。

有关常见消费指标的更多示例，请查看基于使用计费的最佳实践以实现 API 货币化

例如，在本指南中，我们将创建一个计费计量器，用于过滤单个端点的流量，以及请求收到成功 HTTP 200 响应的位置。我们将使用事件计数指标来确保每个请求都被添加到计数中并被发送到计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将单击创建。这将创建并激活计费计数器。然后，当您返回计费表仪表板时，您将看到新的计费表出现。

Moesif 现在将汇总使用情况，并将这些详细信息发送给 Stripe。现在计费表已经配置好了，我们将建立一个流程让用户注册、订阅并发布一个 API 密匙，这样他们就可以使用我们的货币化 API。

4 -创建/register 端点

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关中的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 API 密钥，该密钥将跟踪他们的使用情况。

由于我们使用 Moesif、Stripe 和 AWS API Gateway 作为我们整体解决方案的一部分，我们需要确保每个组件都能正常工作。

端点将执行以下操作:

• 使用 AWS API Gateway JS 客户端创建 API 密钥，并将其添加到使用计划中
• 在条带中创建用户
• 为新用户订阅条带中的 API 订阅
• 在 Moesif 中创建 CompanyID(这将是 API 密钥 ID)
• 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
• 创建 API 密钥

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在本例中，我将使用 Express 创建一个简单的 NodeJS API 来完成上述任务。

创建国家预防机制项目

首先，我们将创建一个名为 moesif-monetization 的文件夹，我们将在其中添加 API 代码。然后我们将运行npm init来转变货币化，这样我们就可以在我们的项目中使用 npm。为此，您将在 moesif-monetization 目录中运行以下命令。

$ npm init 

创建 npm 项目时，您可以根据需要填写详细信息或使用默认值。

然后你应该会在你的moesif-monetary文件夹中看到一个 package.json 文件。

现在，在您喜欢的 IDE 或文本编辑器中打开这个目录。在本教程的剩余部分，我将使用 VS 代码进行所有的编码。

添加项目依赖项

我们现在将使用正确的依赖项编辑我们的 package.json 文件。在 package.json 中，我们将在依赖关系对象下添加以下条目。

 "dependencies":  {  "@aws-sdk/client-api-gateway":  "^3.131.0",  "@stripe/stripe-js":  "^1.29.0",  "body-parser":  "^1.20.0",  "dotenv":  "^16.0.0",  "express":  "^4.17.1",  "http":  "0.0.1-security",  "moesif-nodejs":  "^3.1.14",  "node-fetch":  "^2.6.5",  "path":  "^0.12.7",  "stripe":  "^8.219.0"  } 

保存文件，然后导航到终端并运行:

$ npm install 

现在，您的依赖项将被引入到项目中，并添加到 node_modules 文件夹中。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，以及我们将内置到应用程序中的各种其他功能。

创建。环境文件

我们不会将条带键和其他静态值硬编码到我们的应用程序中，而是将它们抽象到一个. env 文件中。我们可以使用添加到名为 dotenv 的 package.json 中的依赖项来实现这一点。

在根目录下，创建一个名为的文件。env 。在这个文件中，我们将添加几个条目，其中包含代码中使用的键和值。

STRIPE_KEY="sk_test_XXX"
STRIPE_PRICE_KEY="price_XXX"
MOESIF_APPLICATION_ID="YOUR_MOESIF_APP__ID"
AWS_INVOKE_URL="https://your-aws-api-gateway.execute-api.region.amazonaws.com"
AWS_REGION="aws-region"
AWS_ACCESS_KEY_ID="awsaccesskeyid"
AWS_SECRET_ACCESS_KEY="awssecretaccesskey"
AWS_USAGE_PLAN_KEY_TYPE="API_KEY"
AWS_USAGE_PLAN_ID=”usageplan" 

这里的值可以在以下位置找到:

STRIPE_KEY

这可以在我们之前为计费表获取 Stripe 和 Moesif 集成密钥的相同位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，仅包含每个函数所需的范围。

STRIPE_PRICE_KEY

这将是您之前在 Stripe 中创建的价格的价格键。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。

MOESIF_APPLICATION_ID

这可以在 Moesif 中找到，方法是转到屏幕左下方的菜单链接(将显示您的姓名)并选择 API 键。

然后，密钥将出现在出现在收集器应用 Id 下的页面上。

AWS_INVOKE_URL

这将是您的 AWS API 网关的 URL。这可以通过在 AWS API 网关控制台中导航到您的 API，导航到阶段，选择您的阶段，并复制屏幕上的调用 URL 来找到。

AWS_REGION

该值将基于运行 AWS API 网关的 AWS 区域。一个示例值是“美国东部-2”。

AWS_ACCESS_KEY_ID

关于这个和下面提到的秘密访问密钥的信息可以在这里找到。

AWS_SECRET_ACCESS_KEY

这将是您的 AWS 秘密访问密钥。您可能需要生成一个新的，并可以在这里查看 AWS 团队的说明。

AWS_USAGE_PLAN_KEY_TYPE

AWS 允许多种使用计划密钥类型，但出于我们的目的，我们将使用 API_KEY 作为此处的值。

AWS_USAGE_PLAN_ID

可以通过在 AWS API 网关控制台中转至您的使用计划来访问该值。您可以在 AWS 控制台中导航到您的 API，单击 Usage Plans，选择您的计划，然后复制 ID。

用九个键值对填充文件后，保存文件。在本教程的剩余部分，我们不需要再接触这个文件。

创建 app.js 文件

在我们的应用程序的根目录中，我们将创建一个 app.js 文件(如果还没有创建的话)。在这个文件中，我们将添加下面的代码来添加我们的依赖项并创建一个基本的 REST 端点。

const express = require('express')
const path = require("path");
require('dotenv').config()
var bodyParser = require('body-parser')
const moesif = require('moesif-nodejs');
const Stripe = require('stripe');
// npm i --save node-fetch@2.6.5
const fetch = require('node-fetch');
// npm install @aws-sdk/client-api-gateway
const { APIGatewayClient, CreateApiKeyCommand, CreateUsagePlanKeyCommand } = require("@aws-sdk/client-api-gateway");

const app = express();
app.use(express.static(path.join(__dirname)));

const port = 5000;
const stripe = Stripe(process.env.STRIPE_KEY);

var jsonParser = bodyParser.json();

config = {
 invokeUrl: process.env.AWS_INVOKE_URL,
 region: process.env.AWS_REGION,
 credentials: {
   accessKeyId: process.env.AWS_ACCESS_KEY_ID,
   secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
 }
}

const client = new APIGatewayClient(config);

const moesifMiddleware = moesif({
 applicationId: process.env.MOESIF_APPLICATION_ID
});

app.use(moesifMiddleware);

app.post('/register', jsonParser,
 async (req, res) => {
 }
)
app.listen(port, () => {
 console.log(`Example app listening at http://localhost:${port}`);
}) 

在上面的代码中，我们是:

• 导入一些依赖项
• 配置条带依赖关系
• 配置我们的 AWS API 网关客户端
• 配置 Moesif 中间件
• 创建/注册端点
• 将我们的应用程序设置为在端口 5000 上运行，并启动我们的节点应用程序

你会注意到我们在代码中有 process.env.STRIPE_KEY 、process . env . moes if _ APPLICATION _ ID和其他环境变量。这些值将来自。我们在最后一步中创建的 env 文件。

实现/register 终结点

我们的下一步是实现 /register 端点。这个端点将在 AWS API Gateway、Stripe 和 Moesif 之间创建我们的绑定。结果将是从 AWS API 网关生成的 API 密钥，该密钥将使用情况与 Moesif 中的用户相关联，然后将报告给 Stripe。

我们将添加到 __ /register__ 端点的第一段代码是创建 API 密钥，并将该 API 密钥与一个使用计划相关联。为此，我们将使用 AWS API 网关客户端 SDK ，它是 CreateApiKeyCommand 和createusageplankeymond。

 const params = {
     name: req.body.email,
     enabled: true,
   };
   const command = new CreateApiKeyCommand(params);
   const response = await client.send(command);
   const awsApiKeyId = response.id;
   const awsApiKey = response.value;

   const usageKeyCommand = new CreateUsagePlanKeyCommand({
keyId: response.id, 
keyType: process.env.AWS_USAGE_PLAN_KEY_TYPE, 
usagePlanId: process.env.AWS_USAGE_PLAN_ID
   });
   const usageKeyResponse = await client.send(usageKeyCommand); 

流程的下一步是创建 Stripe 中的客户。我们将使用我们的 Stripe JS 依赖来做到这一点。我们将使用请求正文中的参数(电子邮件、名字、姓氏)通过使用 stripe.customers.create 函数在 Stripe 中创建客户。我们还将把 AWS API 网关生成的 API 密钥 ID 存储在条带元数据对象中。然后，我们将把创建的客户存储在一个自定义变量中，这样，如果需要，我们可以访问 Stripe 中生成的客户 ID 。

 const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
     metadata: {
       'awsAPIKeyId': awsApiKeyId,
     }
   }); 

接下来，我们将为这个新用户订阅我们之前在 Stripe 中创建的 API 订阅。我们将使用stripe . subscriptions . create函数，并使用从之前的函数调用中生成的客户 ID 来订阅它们。这将返回一个订阅对象，其中包含一个我们稍后会用到的 ID。

 const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   }); 

现在，我们将使用 Moesif 中间件来创建用户，并将他们的相关细节添加到 Moesif 中。首先，我们将调用 Moesif 中间件的 updateCompany 函数，将条带 subscription.id 映射到 Moesif 中的 companyId 。

 var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company); 

然后，我们将对 updateUser 函数执行类似的步骤，并使用它将 AWS API Key ID 映射到 userId ，将 Stripe subscription.id 映射到 companyId ，并将我们收集的关于用户的一些其他元数据映射到 Moesif。

 var user = {
     userId: awsApiKeyId,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
       apikey: awsApiKey,
     }
   };
   moesifMiddleware.updateUser(user); 

最后，我们将向调用者返回一个 200 OK 响应，在响应体中包含 API 键。

 res.status(200)
   res.send({ apikey: awsApiKey }); 

完整的端到端功能如下所示:

app.post('/register', jsonParser,
 async (req, res) => {
   console.log(req.body);

   // Generate API key
   const params = {
     name: req.body.email,
     enabled: true,
   };
   const command = new CreateApiKeyCommand(params);
   const response = await client.send(command);
   const awsApiKeyId = response.id;
   const awsApiKey = response.value;
   console.log(response);

   // Associate the API key with a usage plan
   const usageKeyCommand = new CreateUsagePlanKeyCommand({
keyId: response.id, 
keyType: process.env.AWS_USAGE_PLAN_KEY_TYPE, 
usagePlanId: process.env.AWS_USAGE_PLAN_ID
   });
   const usageKeyResponse = await client.send(usageKeyCommand);
   console.log(usageKeyResponse);

   // create Stripe customer
   console.log('create stripe customer');
   const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
     metadata: {
       'awsAPIKeyId': awsApiKeyId,
     }
   });
   console.log('stripe customer created');

   // create Stripe subscription
   console.log('create stripe subscription');
   const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   });
   console.log('stripe subscription created: ' + subscription.id);

   // create user and company in Moesif
   var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company);
   console.log("Moesif create company");

   var user = {
     userId: awsApiKeyId,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
       apikey: awsApiKey,
     }
   };
   moesifMiddleware.updateUser(user);
   console.log(user);
   console.log("Moesif create user");

   res.status(200)
   res.send({ apikey: awsApiKey });
 }
) 

有了这些，我们现在可以实际测试我们的端点，以确保每一部分都按预期工作。结果应该是一个注册用户与一个 API 密钥，将记录和报告使用数据到条纹。让我们继续测试它。

5 -向/register 端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，它将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 AWS API Gateway、Stripe 和 Moesif 中正确配置系统和配置文件所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

在 Postman 中，我们将使用以下信息创建我们的请求:

• 请求类型:发布

• 端点 URL:http://localhost:5000/register

• 请求正文:

  {  "firstname":  "Userfirstname",  "lastname":  "Userlastname",  "email":  "test@test.com"  } 
  

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

一旦发送了请求，响应应该包含新注册用户可以使用的 API 键。

我们现在将检查 Stripe，以确保我们注册的信息正确输入到系统中。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。您还应该在元数据下看到 awsAPIKeyID 也存在。

awsAPIKeyID 的存在很重要，因为这是我们用来将使用数据映射到 Moesif 的 Stripe 的机制的一部分。如果不存在，请确保上述代码已被正确配置，以将其添加到条带客户元数据中。

完成这些检查后，我们可以放心地假设/register 端点正在 Stripe 中正确地设置我们的用户帐户和订阅。

6 -使用生成的 API 密钥调用您的 API

我们的下一步是实际使用我们生成的 API 密钥。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向 AWS API Gateway 上的端点发送请求。这是我们在上面的步骤 3 中为其设置计费计量器的端点。

在《邮差》中，我们将:

• 将 AWS API 网关 API 端点的调用 URL 作为请求 URL
• 选择授权选项卡
• 选择类型作为 API 键
• 填充 API 键详细信息
  • 将密钥设置为“x-api-key”
  • 将该值设置为生成的 API 键
  • 将添加到字段值设置为“标题”

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 send。

一旦发送，您的请求应该通过 AWS Api 网关代理，Api 调用分析应该在 Moesif 着陆。

确认 Moesif 收到了请求信息

回到 Moesif，您将导航到实时事件日志屏幕，在这里您将看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 应该与您的 AWS API 网关 API 密钥 ID 相匹配，订阅 ID 应该类似于“sub_XXXX”。

如果您点击显示在现场活动日志屏幕条目中的用户 ID ，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的 + 按钮来创建一个新列，我们将在其中添加条带元数据。

您可能需要向右滚动才能看到它，这取决于您的分辨率和屏幕大小，以便看到+按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

现在，我们已经确认了通过 AWS API Gateway 代理的 API 调用正在工作，并在 Moesif 中标记了正确的用户(API 密钥 ID)和公司(条带订阅 ID)详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过 Postman 调用我们的 API 键了。我们将制作一个快速的注册表单，然后返回一个 API 密钥供新注册的用户使用。

将您的前端文件添加到应用程序

在应用程序的根目录中，我们将添加两个文件。我们将添加一个index.html和一个索引. js 。

添加您的路由以提供静态 html 文件

在 app.js 文件中，我们将添加一个路由来服务静态 HTML 文件。在我们的 /register 端点代码下面，我们将添加另一个端点。添加以下代码:

pp.get("/", function (_req, res) {
 res.sendFile(path.join(__dirname, "index.html"));
 res.sendFile(path.join(__dirname, "index.js"));
}); 

现在，当您导航到 http://localhost:5000/ 时，这段代码将加载网站(一旦我们插入了代码)。

编写前端表单和逻辑

最后，让我们添加前端 HTML 和 JavaScript 功能的代码。在 index.html 文件中，我们将添加如下所示的标记:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1" />
   <meta name="theme-color" content="#000000" />
   <meta
     name="description"
     content="Moesif Embedded Dashboard example"
   />
   <title>None React App Example</title>
 </head>
 <body>
   <noscript>You need to enable JavaScript to run this app.</noscript>
   <h1>
     Moesif Monetization Example
   </h1>
   <div id="form-input">
     email: <input id="email-input" placeholder="email" />
     first name: <input id="firstname-input" placeholder="first name" />
     last name: <input id="lastname-input" placeholder="last name" />
     <button onClick="submitRegistration()">Register</button>
   </div>
   <div id="apikey-output"></div>
   <p id="error-message"></p>
   <script src="index.js"></script>
 </body>
</html> 

他的标记将显示一个允许用户输入电子邮件、名字和姓氏的表单。它还有一个 Register 按钮，该按钮将为 submitRegistration() 调用 JavaScript 函数。该函数将在我们的 index.js JavaScript 文件中。

index.js 文件将如下所示:

async function submitRegistration() {
  const email = document.getElementById("email-input").value;
  const firstname = document.getElementById("firstname-input").value;
  const lastname = document.getElementById("lastname-input").value;
  const errorElement = document.getElementById("error-message");
  const apikey = document.getElementById("apikey-output");

  var body = { email, firstname, lastname };
  console.log(body);
  var response = await fetch('http://localhost:5000/register', {
    method: 'post',
    body: JSON.stringify(body),
    headers: {'Content-Type': 'application/json'}
  });
  var data = await response.json();
  console.log(data);
  apikey.innerHTML = data.apikey;
} 

该函数将从表单中获取输入，将其发送到我们的/register 端点，并在屏幕上显示返回的 API 键。

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到 。然后，您将看到表单出现。

填写表单字段并提交

现在已经加载了表单，填写字段并点击注册按钮。这将获取信息，将其发送到我们的/注册端点，并给我们生成的 API 密钥。

建议您使用不同于之前通过/register 端点直接创建 API 密钥时使用的电子邮件。

确认 API 密钥已返回

单击 submit 按钮后，几秒钟后，API 键应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复从步骤 6 开始的步骤，以确认用户和公司 id 已正确填充，并且为该用户和新的 API 密钥返回了条带元数据。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 API 键调用 API 后，请确认以下内容:

• 在条纹中
  • 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
  • 确认客户订购了正确的产品和价格
  • 确认生成的 AWS API 密钥 ID 在客户元数据中列出
• 在 AWS API 网关中
  • API 密钥已创建并附加到使用计划
• 中的莫西
  • 您的 API 调用被记录在 Moesif 的实时事件日志中
  • 您的 API 调用在 Moesif 的用户和公司字段中分别具有 AWS API 网关 API 密钥 ID 和条带订阅 ID。
  • 确认在 Moesif 中填充了条带元数据

11 -检查条带的使用情况

最后，几个小时后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍然没有数据，请确保您遵循了本指南中概述的所有步骤。这包括确保来自 Moesif 的用户和公司 ID 正确地映射到 Stripe 中相应的密钥。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，可能需要一个小时才能向条带化报告使用情况。如果您的数据还没有，请稍后回来查看更新。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

–>

Azure APIM、Stripe 和 Moesif 的端到端 API 货币化

原文：https://www.moesif.com/blog/api-monetization/azure/End-To-End-API-Monetization-With-Azure-APIM-Stripe-And-Moesif/

许多 API 开发者和公司努力寻找建立系统的方法，以便轻松地将他们的 API 货币化。有些很简单，但不可定制，有些很复杂，需要大量的工程工作才能真正运行起来。

为了让事情变得更简单，Moesif 创建了计费表特性，它提供了巨大的可定制性，但只需要最少的代码和工程工作来实现 API 的货币化。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、Azure API 管理和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 你有一个 Azure API 管理服务的运行实例(创建了一个端点/API)
• 您的 Azure API 管理实例正在您的端点上强制执行订阅所需的，并且将标头名称配置为api-key
  • 这可以通过在 Azure APIM 访问你的 API，点击设置标签，配置订阅下的值来配置
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户
• 您已经为 Azure API 管理安装并配置了 Moesif 插件

从外观上看，设置非常简单。我们将创建一个/register 端点，它:

• 在条带中注册用户
• 为该用户订阅产品
• 在 Azure Api 管理中创建用户
• 在 Moesif 中注册用户和公司
• 在 Azure API 管理中为用户创建订阅并生成 API 密钥

我还为它创建了一个小小的前端，它是一个简单的表单，通过调用 /register 端点来注册用户，然后为新注册的用户显示生成的 API 密钥。

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当你将 Stripe 集成到 Moesif 中时，你已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

名称

这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

定价模式

在 Stripe 中可以设置一些不同的定价模型。这些定价模型包括:

• 标准定价
  • 如果您希望对每个 API 调用收取相同的费用，请使用此选项。
• 包
  • 如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。
• 毕业了
  • 使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。
• 体积
  • 如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的费用为每单位 10 美元，100 个单位的费用为每单位 7 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每天地；天天地
• 一周的
• 每月
• 每 3 个月
• 每 6 个月
• 每年的
• 习俗

对于您的 Moesif 配置，我们建议将计费周期设置为每月。我们还建议，如果您正在使用 Moesif 的计费计量功能，也要检查使用量是否被计量框。

按计量使用收费

一旦选择了计量使用量复选框，将出现计量使用量的收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

• 期间使用值的总和
  • 在整个计费周期中，用户都要为其记录的使用付费
• 期间内最近的使用值
  • 根据计费周期结束前记录的最后一次使用情况向用户收费
• 最近使用值
  • 在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费
• 期间的最大使用价值
  • 用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时段期间的使用值总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选字段，但建议填写。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费表，在 Moesif 中，您将导航至计费表屏幕。您可以从右侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的+添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

计费电表名称

这是您的新计费仪表的 Moesif 内部名称

账单提供商

在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。

产品(仅条纹)

在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。

价格(仅条纹)

计费计数器的计费提供者设置中的最后一个字段，您可以在这里选择要将您的使用指标绑定到哪个价格。

过滤器

在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。

指标

在这里，您可以选择希望计费的指标。可用选项包括:

• 事件计数
  • 这将增加符合过滤标准中列出的标准的每个事件的使用量。
• 唯一用户
  • 每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。
• 自定义
  • 这使您能够构建自己的指标，如接收的数据、美元量的百分比、计算单位的总和或任何其他与 API 相关的消耗指标。Moesif 支持 API 主体字段、用户操作等方面的度量。

有关常见消费指标的更多示例，请查看基于使用计费的最佳实践以实现 API 货币化

例如，在本指南中，我们将创建一个计费计量器，用于过滤单个端点的流量，以及请求收到成功 HTTP 200 响应的位置。我们将使用事件计数指标来确保每个请求都被添加到计数中并被发送到计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将单击创建。这将创建并激活计费计数器。然后，当您返回计费表仪表板时，您将看到新的计费表出现。

Moesif 现在将汇总使用情况，并将这些详细信息发送给 Stripe。现在计费表已经配置好了，我们将建立一个流程让用户注册、订阅并发布一个 API 密匙，这样他们就可以使用我们的货币化 API。

4 -创建/register 端点

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关内的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 API 密钥，该密钥将跟踪他们的使用情况。

由于我们使用 Moesif、Stripe 和 Azure APIM 作为我们整体解决方案的一部分，我们需要确保每个组件都能正常工作。

端点将执行以下操作:

• 在条带中创建用户
• 为新用户订阅条带中的 API 订阅
• 在 Azure APIM 中创建用户(在用户的名称字段中使用 Stripe 客户 ID)
• 在 Moesif 中创建 CompanyID(这将是条带订阅 ID)
• 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
• 创建 API 密钥

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在本例中，我将使用 Express 创建一个简单的 NodeJS API 来完成上述任务。

创建国家预防机制项目

首先，我们将创建一个名为 moesif-monetization 的文件夹，我们将在其中添加 API 代码。然后我们将运行npm init来转变货币化，这样我们就可以在我们的项目中使用 npm。为此，您将在 moesif-monetization 目录中运行以下命令。

$ npm init 

创建 npm 项目时，您可以根据需要填写详细信息或使用默认值。

然后你应该会在你的moesif-monetary文件夹中看到一个 package.json 文件。

现在，在您喜欢的 IDE 或文本编辑器中打开这个目录。在本教程的剩余部分，我将使用 VS 代码进行所有的编码。

添加项目依赖项

我们现在将使用正确的依赖项编辑我们的 package.json 文件。在 package.json 中，我们将在依赖关系对象下添加以下条目。

"dependencies":  {  "@stripe/stripe-js":  "^1.29.0",  "body-parser":  "^1.20.0",  "dotenv":  "^16.0.0",  "express":  "^4.17.1",  "http":  "0.0.1-security",  "moesif-nodejs":  "^3.1.14",  "node-fetch":  "^2.6.5",  "path":  "^0.12.7",  "stripe":  "^8.219.0"  } 

保存文件，然后导航到终端并运行:

$ npm install 

现在，您的依赖项将被引入到项目中，并添加到 node_modules 文件夹中。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，以及我们将内置到应用程序中的各种其他功能。

创建。环境文件

我们不会将条带键和其他静态值硬编码到我们的应用程序中，而是将它们抽象到一个. env 文件中。我们可以使用添加到名为 dotenv 的 package.json 中的依赖项来实现这一点。

在根目录下，创建一个名为的文件。env 。在这个文件中，我们将添加几个条目，其中包含代码中使用的键和值。

STRIPE_KEY="sk_test_XXX"
STRIPE_PRICE_KEY="price_XXX"
MOESIF_APPLICATION_ID="YOUR_MOESIF_APP__ID"
AZURE_URL="https://management.azure.com/subscriptions"
AZURE_MANAGEMENT_API_TOKEN="Bearer my_token"
AZURE_RESOURCE_GROUP_NAME="MY_RGN"
AZURE_SERVICE_NAME="MY_SN"
AZURE_SUBSCRIPTION_ID="MY_SUB_ID"
AZURE_API_VERSION="2021-08-01" 

这里的值可以在以下位置找到:

STRIPE_KEY

这可以在我们之前为计费表获取 Stripe 和 Moesif 集成密钥的相同位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，仅包含每个函数所需的范围。

STRIPE_PRICE_KEY

这将是您之前在 Stripe 中创建的价格的价格键。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。

MOESIF_APPLICATION_ID

这可以在 Moesif 中找到，方法是转到屏幕左下方的菜单链接(将显示您的姓名)并选择 API 键。

然后，密钥将出现在出现在收集器应用 Id 下的页面上。

AZURE_URL

这将是 Azure APIM 管理 API URL。该值可能是“https://management . azure . com/subscriptions”

AZURE_MANAGEMENT_API_TOKEN

这将是一个不记名令牌，它将验证您的 Azure APIM 管理 API 调用。从长远来看，您可能希望创建一个功能，该功能将根据当前使用的令牌的到期时间自动更新此不记名令牌。更多细节可以在这里找到

AZURE_RESOURCE_GROUP_NAME

这是部署服务的资源组名称。这可以在你的网关服务的概述页面的 Azure APIM 仪表盘中的概要选项卡下找到。

AZURE_SERVICE_NAME

这是您的网关服务的实际名称。这也可以在屏幕左上方的 Azure APIM 仪表盘中找到，位于您的网关服务的概述页面上。

AZURE_SUBSCRIPTION_ID

这是您的 Azure 订阅 ID。这也可以在你的网关服务的概述页面的 Azure APIM 仪表盘中的概要下找到。

AZURE_API_VERSION

这是您将使用的管理 API 版本。对于这个例子，我们使用2021-08-01

用九个键值对填充文件后，保存文件。在本教程的剩余部分，我们不需要再接触这个文件。

创建 app.js 文件

在我们的应用程序的根目录中，我们将创建一个 app.js 文件(如果还没有创建的话)。在这个文件中，我们将添加以下代码，添加我们的依赖项，定义我们的 Azure APIM 管理 API URL，并为 /register 创建一个基础 REST 端点。

const express = require('express')
const path = require("path");
require('dotenv').config()
var bodyParser = require('body-parser')
const moesif = require('moesif-nodejs');
const Stripe = require('stripe');
// npm i --save node-fetch@2.6.5
const fetch = require('node-fetch');

const app = express();
app.use(express.static(path.join(__dirname)));
const port = 5000;
const stripe = Stripe(process.env.STRIPE_KEY);
var jsonParser = bodyParser.json();
const AZURE_MANAGEMENT_API_ROUTE = `${process.env.AZURE_URL}/${process.env.AZURE_SUBSCRIPTION_ID}/resourceGroups/${process.env.AZURE_RESOURCE_GROUP_NAME}/providers/Microsoft.ApiManagement/service/${process.env.AZURE_SERVICE_NAME}`;

const moesifMiddleware = moesif({
 applicationId: process.env.MOESIF_APPLICATION_ID
});

app.use(moesifMiddleware);

app.post('/register', jsonParser,
 async (req, res) => {
 }
)
app.listen(port, () => {
 console.log(`Example app listening at http://localhost:${port}`);
}) 

在上面的代码中，我们是:

• 导入一些依赖项
• 配置条带依赖关系
• 配置 Moesif 中间件
• 创建/注册端点
• 将我们的应用程序设置为在端口 5000 上运行，并启动我们的节点应用程序

你会注意到我们有 process.env.STRIPE_KEY 和process . env . moes if _ APPLICATION _ ID。这些值将来自。我们在最后一步中创建的 env 文件。

实现/register 终结点

我们的下一步是实现 /register 端点。这个端点将在 Azure APIM、Stripe 和 Moesif 之间创建我们的绑定。结果将是一个从 Azure APIM 生成的 API 密钥，它将使用情况与 Moesif 中的用户相关联，然后将被报告给 Stripe。

你会注意到我们没有使用 Azure APIM 的 JavaScript 客户端，而是使用纯 HTTP 调用。如果您使用 JavaScript 之外的东西来构建您的 /register 端点，这是为了实现可移植性。

我们流程中的第一步是创建 Stripe 中的客户。我们将使用我们的 Stripe JS 依赖来做到这一点。我们将使用请求正文中的参数(电子邮件、名字、姓氏)通过使用 stripe.customers.create 函数在 Stripe 中创建客户。然后，我们将把创建的客户存储在一个自定义变量中，这样我们就可以访问 Stripe 中生成的客户 ID 。

const customer = await stripe.customers.create({
  email: req.body.email,
  name: `${req.body.firstname}  ${req.body.lastname}`,
  description: 'Customer created through /register endpoint',
}); 

接下来，我们将为这个新用户订阅我们之前在 Stripe 中创建的 API 订阅。我们将使用stripe . subscriptions . create函数，并使用从之前的函数调用中生成的客户 ID 来订阅它们。这将返回一个订阅对象，其中包含一个我们稍后会用到的 ID。

const subscription = await stripe.subscriptions.create({
  customer: customer.id,
  items: [
    { price: process.env.STRIPE_PRICE_KEY },
  ],
}); 

然后，我们将在 Azure APIM 中创建用户。这将允许我们稍后为该用户生成一个订阅 /API 密钥。我们将通过 Azure APIM 管理 API 向 Azure APIM 的/用户端点发送一个 PUT 请求。这将生成一个 ID 等于他们的 Stripe 客户 ID (上面创建的)的用户，并填充他们的电子邮件、名字和姓氏的用户详细信息。

var body = {
  properties: {
    firstName: req.body.firstname,
    lastName: req.body.lastname,
    email: req.body.email,
  }
};

var response = await fetch(`${AZURE_MANAGEMENT_API_ROUTE}/users/${customer.id}?api-version=${process.env.AZURE_API_VERSION}`, {
  method: 'put',
  body: JSON.stringify(body),
  headers: {
    'Content-Type': 'application/json',
    'Authorization': process.env.AZURE_MANAGEMENT_API_TOKEN
  }
});
var data = await response.json(); 

一旦在 Azure APIM 创建了用户，我们现在将使用 Moesif 中间件来创建用户，并将他们的相关详细信息添加到 Moesif 中。首先，我们将调用 Moesif 中间件的 updateCompany 函数，将条带 subscription.id 映射到 Moesif 中的 companyId 。

 var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company); 

然后，我们将对 updateUser 函数执行类似的步骤，并使用它将条带 customer.id 映射到 userId ，将条带 subscription.id 映射到 companyId ，并将我们收集的关于用户的一些其他元数据映射到 Moesif。

var user = {
  userId: customer.id,
  companyId: subscription.id,
  metadata: {
    email: req.body.email,
    firstName: req.body.firstname,
    lastName: req.body.lastname,
  }
};
moesifMiddleware.updateUser(user); 

在这一点上，我们现在已经将所有的用户详细信息插入到必要的平台中。我们的下一步是在 Azure APIM 为这个用户生成一个订阅/API 密钥。为此，我们将使用/subscriptions/{ subscription id }端点再次调用 Azure APIM 管理 API。这将创建一个新的订阅，其 ID 与上面生成的 Stripe 订阅 ID 相匹配，并返回一个订阅对象，该对象包含一个 API 键以传递回正在注册的用户。我们通过data . properties . primary key访问那个 API 键。

body = {
  properties: {
    displayName: subscription.id,
    ownerId: `/subscriptions/${process.env.AZURE_SUBSCRIPTION_ID}/resourceGroups/${process.env.AZURE_RESOURCE_GROUP_NAME}/providers/Microsoft.ApiManagement/service/${process.env.AZURE_SERVICE_NAME}/users/${customer.id}`,
    scope: `/subscriptions/${process.env.AZURE_SUBSCRIPTION_ID}/resourceGroups/${process.env.AZURE_RESOURCE_GROUP_NAME}/providers/Microsoft.ApiManagement/service/${process.env.AZURE_SERVICE_NAME}/apis`,
    state: "active"
  }
};

var response = await fetch(`${AZURE_MANAGEMENT_API_ROUTE}/subscriptions/${subscription.id}?api-version=${process.env.AZURE_API_VERSION}`, {
  method: 'put',
  body: JSON.stringify(body),
  headers: {
    'Content-Type': 'application/json',
    'Authorization': process.env.AZURE_MANAGEMENT_API_TOKEN
  }
});
var data = await response.json();
var apiKey = data.properties.primaryKey; 

可选地，我们也将把用户 API 键添加到 Moesif 中的元数据中。出于测试目的，如果你失去了密钥的踪迹，并且不想回到 Azure APIM 来取回它，这使得获得密钥变得容易。我们将在 Moesif 中间件中再次使用 updateUser 函数来完成这项工作，在元数据对象中提供生成的 API 键。

var user = {
  userId: customer.id,
  metadata: {
    apiKey
  }
};
moesifMiddleware.updateUser(user); 

最后，我们将向调用者返回一个 200 OK 响应，在响应体中包含 API 键。

res.status(200)
res.send({ apiKey }); 

完整的端到端功能如下所示:

app.post('/register', jsonParser,
 async (req, res) => {
   // create Stripe customer
   const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   });

   // create Stripe subscription
   const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   });

   //create Azure APIM user
   var body = {
     properties: {
       firstName: req.body.firstname,
       lastName: req.body.lastname,
       email: req.body.email,
     }
   };
   var response = await fetch(`${AZURE_MANAGEMENT_API_ROUTE}/users/${customer.id}?api-version=${process.env.AZURE_API_VERSION}`, {
     method: 'put',
     body: JSON.stringify(body),
     headers: {
       'Content-Type': 'application/json',
       'Authorization': process.env.AZURE_MANAGEMENT_API_TOKEN
     }
   });
   var data = await response.json();

   // create user and company in Moesif
   var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company);

   var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user);

   // Create subscription and API Key in Azure APIM
   body = {
     properties: {
       displayName: subscription.id,
       ownerId: `/subscriptions/${process.env.AZURE_SUBSCRIPTION_ID}/resourceGroups/${process.env.AZURE_RESOURCE_GROUP_NAME}/providers/Microsoft.ApiManagement/service/${process.env.AZURE_SERVICE_NAME}/users/${customer.id}`,
       scope: `/subscriptions/${process.env.AZURE_SUBSCRIPTION_ID}/resourceGroups/${process.env.AZURE_RESOURCE_GROUP_NAME}/providers/Microsoft.ApiManagement/service/${process.env.AZURE_SERVICE_NAME}/apis`,
       state: "active"
     }
   };

   var response = await fetch(`${AZURE_MANAGEMENT_API_ROUTE}/subscriptions/${subscription.id}?api-version=${process.env.AZURE_API_VERSION}`, {
     method: 'put',
     body: JSON.stringify(body),
     headers: {
       'Content-Type': 'application/json',
       'Authorization': process.env.AZURE_MANAGEMENT_API_TOKEN
     }
   });
   var data = await response.json();
   var apiKey = data.properties.primaryKey;

   // update Moesif user with API key
   var user = {
     userId: customer.id,
     metadata: {
       apiKey
     }
   };
   moesifMiddleware.updateUser(user);

   // return API key to caller
   res.status(200)
   res.send({ apiKey });
 }
) 

有了这些，我们现在可以实际测试我们的端点，以确保每一部分都按预期工作。结果应该是一个注册用户与一个 API 密钥，将记录和报告使用数据到条纹。让我们继续测试它。

5 -向/register 端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，它将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 Azure APIM、Stripe 和 Moesif 中正确配置系统和配置文件所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

注意:对于 /register 调用，我们将只通过 localhost 调用它。最理想的情况是，你可以通过 Azure APIM 代理它，并通过那里访问它。为简洁起见，我们将只在本地使用端点。如果你把它作为一个端点添加到 Azure APIM，实际的功能不会改变，但是 URL 会有所不同。

在 Postman 中，我们将使用以下信息创建我们的请求:

• 请求类型:发布
• 端点 URL:http://localhost:5000/register
• 请求正文:

{  "firstname":  "Userfirstname",  "lastname":  "Userlastname",  "email":  "test@test.com"  } 

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

一旦发送了请求，响应应该包含新注册用户可以使用的 API 键。

我们现在将检查 Azure APIM 和 Stripe，以确保我们注册的信息正确输入到每个目标系统中。我们首先要检查的是条纹。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。

一旦这两个条目在 Stripe 中得到确认，您就可以转移到 Azure APIM 来确保用户也在那里被正确设置。

使用 Azure APIM 用户界面，导航到用户屏幕。在这里，您应该看到一个条目，其中姓名、全名和电子邮件字段被设置为提供的参数，并且姓名字段应该与 Stripe 客户 ID 相匹配。

点击该条目会将您带到用户详细信息屏幕。在这里，点击订阅菜单项将显示为该用户生成的 API 密钥，您会注意到 Stripe 订阅 ID 在 Azure APIM 中也被列为订阅 ID。显示的主键/API 键应该与 Postman 中返回的键相匹配。

完成这些检查后，我们可以安全地假设我们的 /register 端点正在 Azure APIM 和 Stripe 中正确地设置我们的用户帐户和订阅。

6 -使用生成的 API 密钥调用您的 API

我们的下一步是实际使用我们生成的 API 密钥。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向/test-service 端点发送一个请求。这是我们在上面的步骤 3 中为其设置计费计量器的端点。

在《邮差》中，我们将:

• 将/test-service API 端点作为请求 URL
• 为授权添加一个请求头，并将您的 API 密钥添加到值字段中

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 send。

一旦发送，你的请求应该通过 Azure APIM 代理，API 调用分析应该在 Moesif 着陆。

确认 Moesif 收到了请求信息

回到 Moesif，您将导航到 Events 屏幕，在这里您将看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 看起来像“库斯 _XXXX ”,订阅 ID 看起来像“sub_XXXX”。

如果您点击显示在现场活动日志屏幕条目中的用户 ID ，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的 + 按钮来创建一个新列，我们将在其中添加条带元数据。

您可能需要向右滚动才能看到它，这取决于您的分辨率和屏幕大小，以便看到+按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

在这一点上，我们现在已经确认我们的 API 调用，通过 Azure APIM 代理，正在工作，并在 Moesif 中加盖了正确的用户和公司详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过 Postman 调用我们的 API 键了。我们将制作一个快速的注册表单，然后返回一个 API 密钥供新注册的用户使用。

将您的前端文件添加到应用程序

在应用程序的根目录中，我们将添加两个文件。我们将添加一个index.html和一个索引. js 。

添加您的路由以提供静态 html 文件

在 app.js 文件中，我们将添加一个路由来服务静态 HTML 文件。在我们的 /register 端点代码下面，我们将添加另一个端点。添加以下代码:

pp.get("/", function (_req, res) {
 res.sendFile(path.join(__dirname, "index.html"));
 res.sendFile(path.join(__dirname, "index.js"));
}); 

现在，当您导航到 http://localhost:5000/ 时，这段代码将加载网站(一旦我们插入了代码)。

编写前端表单和逻辑

最后，让我们添加前端 HTML 和 JavaScript 功能的代码。在 index.html 文件中，我们将添加如下所示的标记:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1" />
   <meta name="theme-color" content="#000000" />
   <meta
     name="description"
     content="Moesif Monetization example"
   />
   <title>None React App Example</title>
 </head>
 <body>
   <noscript>You need to enable JavaScript to run this app.</noscript>
   <h1>
     Moesif Monetization Example
   </h1>
   <div id="form-input">
     email: <input id="email-input" placeholder="email" />
     first name: <input id="firstname-input" placeholder="first name" />
     last name: <input id="lastname-input" placeholder="last name" />
     <button onClick="submitRegistration()">Register</button>
   </div>
   <div id="apikey-output"></div>
   <p id="error-message"></p>
   <script src="index.js"></script>
 </body>
</html> 

这个标记将显示一个允许用户输入电子邮件、名字和姓氏的表单。它还有一个 Register 按钮，该按钮将为 submitRegistration() 调用 JavaScript 函数。该函数将在我们的 index.js JavaScript 文件中。

index.js 文件将如下所示:

async function submitRegistration() {
  const email = document.getElementById("email-input").value;
  const firstname = document.getElementById("firstname-input").value;
  const lastname = document.getElementById("lastname-input").value;
  const errorElement = document.getElementById("error-message");
  const apikey = document.getElementById("apikey-output");

  var body = { email, firstname, lastname };
  console.log(body);
  var response = await fetch('http://localhost:5000/register', {
    method: 'post',
    body: JSON.stringify(body),
    headers: {'Content-Type': 'application/json'}
  });
  var data = await response.json();
  console.log(data);
  apikey.innerHTML = data.apikey;
} 

该函数将从表单中获取输入，将其发送到我们的/register 端点，并在屏幕上显示返回的 API 键。

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到 http://localhost:5000/ 。然后，您将看到表单出现。

填写表单字段并提交

现在已经加载了表单，填写字段并点击注册按钮。这将获取信息，将其发送到我们的/注册端点，并给我们生成的 API 密钥。

建议您使用不同于之前通过/register 端点直接创建 API 密钥时使用的电子邮件。

确认 API 密钥已返回

单击 submit 按钮后，几秒钟后，API 键应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复从步骤 6 开始的步骤，以确认用户和公司 id 已正确填充，并且为该用户和新的 API 密钥返回了条带元数据。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 API 键调用 API 后，请确认以下内容:

• 在条纹中
  • 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
  • 确认客户订购了正确的产品和价格
• 在蔚蓝的 APIM
  • 用户已创建
  • Users Name 字段匹配 Stripe 中的客户 ID(以 cus_XXXX 开头)
  • 创建用户订阅，并且订阅 ID 等于条带订阅 ID
• 中的莫西
  • 您的 API 调用被记录在 Moesif 的实时事件日志中
  • 您的 API 调用在 Moesif 的用户和公司字段中分别有 Stripe 客户 ID 和订阅 ID。
  • 确认在 Moesif 中填充了条带元数据

11 -检查条带的使用情况

最后，过一段时间后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍没有数据，您可以从计费表屏幕进行计费表测试以确保系统按预期运行，如果您在首次创建计费表时还没有这样做的话。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，可能需要一个小时才能向条带化报告使用情况。如果您的数据还没有，请稍后再回来查看更新。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

Django、Stripe 和 Moesif 的端到端 API 货币化

原文：https://www.moesif.com/blog/technical/stripe/End-To-End-API-Monetization-With-Django-Stripe-And-Moesif/

许多 API 开发者和公司都在努力寻找简单的方法来建立系统，以使他们的 API 货币化。有些很简单，但不可定制，有些很复杂，需要大量的工程工作才能真正运行起来。

为了让事情变得更简单，Moesif 创建了一个名为 Billing Meters 的特性，它提供了巨大的可定制性，但只需要最少的代码和工程工作。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、Django 和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 您的机器上安装了一个工作 Python 环境
  • 我们使用 Python 3.10.5，这是撰写本文时可用的最新版本
  • 我们还使用 pipenv 在虚拟环境中管理我们的项目
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户

从外观上看，设置非常简单。我们将创建一个 /register 端点，它:

• 在条中注册一个新用户
• 为该用户订阅产品
• 在 Moesif 中注册用户和公司
• 创建一个 JWT 来认证/授权对我们货币化终端的呼叫

我还使用 Django Forms 创建了一个前端，它包含一个简单的表单，通过调用 /register 端点来注册用户，然后为新注册的用户显示生成的 JWT。

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当您将 Stripe 集成到 Moesif 中时，您已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

产品资料

名字

• 这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

• 此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

图像

• 可以选择上传一张图片，帮助您轻松识别产品页面上的商品。在这个例子中，我们将使用默认的占位符图像。

定价信息

定价模型

在 Stripe 中可以设置一些不同的定价模式。这些定价模型包括:

• 标准定价
  • 如果您希望对每个 API 调用收取相同的费用，请使用此选项。

• 套餐定价
  • 如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。

• 分级定价
  • 使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。

• 批量定价
  • 如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的单价为 10.00 美元，100 个单位的单价为 7.00 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每日
• 每周一次
• 每月
• 每 3 个月一次
• 每 6 个月一次
• 每年
• 客户

对于您的 Moesif 配置，我们建议将计费周期设置为每月月。我们还建议，如果您正在使用 Moesif 的计费计量功能，请同时选中用量被计量框。

按计量使用收费

一旦选择了用量计量复选框，将出现计量用量收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

• 期间使用值总和
  • 在整个计费周期中，用户都要为其记录的使用付费
• 期间的最近使用值
  • 根据计费周期结束前记录的最后一次使用情况向用户收费
• 最近使用值
  • 在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费
• 期间最大使用值
  • 用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时间段内使用值的总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选字段，但建议填写。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费表，在 Moesif 中，您将导航至计费表屏幕。您可以从左侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的 +添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

• 计费电表名称
  • 这是您的新计费仪表的 Moesif 内部名称
• 账单提供商
  • 在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。
• 产品(仅条纹)
  • 在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。
• 价格(仅条纹)
  • 计费计数器的计费提供者设置中的最后一个字段，您可以在这里选择要将您的使用指标绑定到哪个价格。
• 使用乘数
  • 在将数据发送给选定的计费提供商之前，可以选择将您的使用量乘以一个比率。
• 舍入模式
  • 如果 usage multiplier 设置为小于 1.0 的任何值，Moesif 可以在几种不同的模式下取整。那些模式分别是上、下、半上、半下、半平。
• 过滤器
  • 在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。
• 指标

  • 在这里，您可以选择希望计费的指标。可用选项包括:

  • 事件计数

    • 这将增加符合过滤标准中列出的标准的每个事件的使用量。

  • 唯一用户

    • 每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。

  • 唯一会话/API 密钥

    • 每当使用唯一的会话或 API 键来发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的会话或 API 键，无论该特定会话或 API 键的事件计数如何，计数都将增加 1。

  • 自定义

    • 这允许配置标准与过滤器提供的标识符相同。

指标下还有其他选项，但以上 4 个选项最适用于基于使用的计费。

例如，在本指南中，我们将创建一个计费计量器，用于过滤单个端点的流量，以及请求收到成功 HTTP 200 响应的位置。我们将使用事件计数指标来确保每个请求都被添加到计数中并被发送到计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将单击创建。这将创建并激活计费表。然后，当您返回计费表仪表板时，您将看到新的计费表出现。

Moesif 现在将汇总使用情况，并将这些详细信息发送给 Stripe。现在计费表已经配置好了，我们将设置一个流程让用户注册、订阅并创建一个 JWT，这样他们就可以使用我们的货币化 API。

4 -创建/register 端点

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关中的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 JWT，它将跟踪他们的使用情况。

由于我们使用 Moesif、Stripe 和 Python 作为我们整体解决方案的一部分，我们需要确保每个组件都能正常工作。

端点将执行以下操作:

• 创建带条纹的客户
• 为新客户订阅条带中的 API 订阅
• 在 Moesif 中创建 CompanyID(这将是条带订阅 ID)
• 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
• 创建一个带有包含条带客户 ID 的id字段的 JWT

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在这个例子中，我将使用 Django REST 框架创建一个简单的 Django API 来完成上述任务。

安装必要的 python 依赖项

如前所述，我们将利用pipenv在虚拟环境中安全地管理我们的依赖关系。Pipenv 为开发人员提供了一种设置工作环境的简单方法。使用 pipenv 给了我们一些更高级的特性，但最重要的是包括对环境变量的内置支持。

我创建了一个名为moesif-monetization-django的文件夹，我将在其中工作，但你可以随意命名你的文件夹。在您喜欢的 IDE 或文本编辑器中打开此目录。在本教程的剩余部分，我将使用 Visual Studio 代码进行所有编码。打开 Code 的集成终端，使用pipenv安装以下依赖项，以便在您的虚拟环境中使用。

pipenv install django djangorestframework moesifdjango stripe pyjwt 

您将看到Pipfile和Pipfile.lock文件都已创建。

这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，生成和验证 jwt，以及我们将构建到应用程序中的各种其他功能。

如果您愿意，使用 pip 并全局安装您的依赖项是一个非常好的选择。如果您使用 pip，您将需要安装 django-environ 包来管理环境变量。您将使用的命令如下所示:pip install django moesifdjango stripe django-environ。

启动 pipenv shell

让我们进入虚拟环境的外壳，开始设置我们的项目。

pipenv shell 

创建 Django 项目

接下来，我们将使用django-admin startproject命令创建一个名为 moesif _ monetization 的文件夹，并准备我们的项目。这是我们添加 API 代码的地方。运行以下命令:

django-admin startproject moesif_monetization . 

您将在当前工作目录中看到一个 moesif _ monetary 文件夹以及一个manage.py文件。

最后，我们将通过运行以下命令来应用必要的迁移:

python manage.py migrate 

确认项目相关性

您可以仔细检查您的 Pipfile 文件是否包含正确的依赖关系:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
django = "*"
moesifdjango = "*"
stripe = "*"
djangorestframework = "*"
pyjwt = "*"
moesifapi = "*"

[dev-packages]

[requires]
python_version = "3.10" 

您的依赖项将被引入项目并安装到我们的虚拟环境中。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，生成和验证 jwt，以及我们将构建到应用程序中的各种其他功能。

创建。环境文件

我们不会将条带键和其他静态值硬编码到我们的应用程序中，而是将它们抽象到一个. env 文件中。同样，我们将利用pipenv对环境变量的内置支持。

在根目录下，创建一个名为的文件。env 。在这个文件中，我们将添加几个条目，其中包含代码中使用的键和值。

STRIPE_API_KEY="sk_test_XXX"
STRIPE_PRICE_KEY="price_XXX"
MOESIF_APPLICATION_ID="YOUR_MOESIF_APPLICATION_ID"
TOKEN_SECRET_KEY="YOUR_TOKEN_SECRET_KEY” 

这里的值可以在以下位置找到:

STRIPE_KEY 这可以在我们之前为计费表获取条带和 Moesif 集成密钥的相同位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，其范围正好是每个功能所需的范围。

STRIPE_PRICE_KEY 这将是您之前在 Stripe 中创建的价格的价格键。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。

MOESIF_APPLICATION_ID 这可以在 Moesif 中找到，方法是转到屏幕左下方的菜单链接(会显示你的名字)并选择 API 键。

该密钥将出现在采集器应用 Id 下的页面上。

这将是用于生成和验证 jwt 的一部分的秘密。

用四个键值对填充文件后，保存文件。在本教程的剩余部分，我们不需要再接触这个文件。

设置 settings.py 文件

我们需要对 Django 为我们生成的默认设置文件进行一些修改。我们将添加几个应用程序，这个术语包括 python 包、模型、视图、模板、模板标签、静态文件、URL 和我们项目中使用的中间件。

首先，将以下导入添加到文件中。

import os, jwt 

接下来，我们将把rest_framework添加到我们的INSTALLED_APPS定义中。

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
] 

注释掉CsrfViewMiddleware并将moesif_middleware添加到MIDDLEWARE定义中。

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'moesifdjango.middleware.moesif_middleware'
] 

接下来，我们将定义我们的identifyUser函数，它使我们能够跟踪 Moesif 中的用户并配置我们的 Moesif 中间件。

def identifyUser(req, res):
    customerID = ""

    try:
        jwt_token = req.headers['Authorization']
        tokenArray = jwt_token.split(" ");
        decodedJWT = jwt.decode(tokenArray[1], os.environ['TOKEN_SECRET_KEY'], algorithms=["HS256"])
        customerID = decodedJWT.get("id")
    except Exception as exception:
        print(exception)
        customerID = ""

    if customerID != "":
        # Sending customerID to Moesif...
        return customerID
    else:
        # CustomerID not found - possibly not included in request authorization header
        return None

MOESIF_MIDDLEWARE = {
    'APPLICATION_ID': os.environ['MOESIF_APPLICATION_ID'],
    'CAPTURE_OUTGOING_REQUESTS': False, # Set to True to also capture outgoing calls to 3rd parties.
    'IDENTIFY_USER': identifyUser, # Optional hook to link API calls to users } 

我们的identifyUser函数有点超前了。当我们的 Django 服务器收到一个 API 调用时，它的内容就会被转发给 Moesif。在这个函数中，我们将从请求的Authorization Header中提取 JWT。我们将解析它，并对照我们的令牌密钥进行检查，这样我们就可以提取出customerID,从而在 Moesif 中实现用户跟踪。

我们还用我们的应用程序 ID 定义和配置 Moesif 中间件。我们将需要稍后重新访问这个文件，但是现在让我们继续站立我们的 API。

编辑 urls.py 文件

在我们 app 的根目录下，我们将编辑生成的 urls.py 文件。在这个文件中，我们将添加下面的代码，它简单地定义了我们的端点:

from django.contrib import admin
from django.urls import path
from moesif_monetization import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('test-service/', views.test_service),
    path('register/', views.register),
] 

我们稍后还将回到这一点，以便为我们的前端配置端点。

创建 views.py 文件

我们的下一步是实现我们的/注册和/测试服务端点的逻辑。

/register 端点将在我们生成的 JWT、条带和 Moesif 之间创建绑定。结果将是一个生成的 JWT，它将使用情况与 Moesif 中的用户相关联，然后报告给 Stripe。

首先，让我们定义我们的导入并配置我们的 api 客户机。

import os, stripe, jwt, json
from moesifapi.moesif_api_client import *
from moesifapi.models import *
from django.http.response import JsonResponse
from rest_framework import status

stripe.api_key = os.environ['STRIPE_API_KEY']
api_client = MoesifAPIClient(os.environ['MOESIF_APPLICATION_ID']).api 

现在我们将定义我们的register函数。我们流程中的第一步是创建 Stripe 中的客户。我们将使用 Stripe python 包来做到这一点。我们将使用来自请求正文的参数(电子邮件、名字、姓氏)来使用条带创建条带中的客户。创建函数。然后，我们将把创建的客户存储在一个自定义变量中，这样我们就可以访问 Stripe 中生成的客户 ID 。

def register(request):
  request_body = json.loads(request.body.decode('utf-8'))

  # Create Stripe Customer
  customer = stripe.Customer.create(
    email = request_body['email'],
    name = request_body['firstname'] + ' ' + request_body['lastname'],
    description = 'Customer created through /register endpoint'
  )
  print("Creating Stripe Customer Complete. Returned ID: " + customer.id) 

在同一个函数体中，我们将为这个新用户订阅我们之前在 Stripe 中创建的 API 订阅。我们将使用条纹。Subscriptions.create 函数并使用从前面的函数调用中生成的客户 ID 来订阅它们。这将返回一个订阅对象，其中包含一个我们稍后会用到的 ID。

 # Create Stripe Subscription
  subscription = stripe.Subscription.create(
    customer = customer.id,
    items = [{'price': os.environ['STRIPE_PRICE_KEY']}]
  )
  print("Creating Stripe Subscription Complete. Returned ID: " + subscription.id) 

在 Stripe 中创建了我们的客户和订阅之后，我们将使用 Moesif 中间件来创建用户，并将他们的相关详细信息添加到 Moesif 中。首先，我们将调用 Moesif 中间件的 update_company 函数，将条带 subscription.id 映射到 Moesif 中的 companyId 。

 # Create Company in Moesif
  company = {'company_id': subscription.id}
  update_company = api_client.update_company(company) 

我们的下一步是生成附加了 Stripe 客户 ID 的 JWT。这一行将为我们创建一个用于端点的 JWT。

 token = jwt.encode({'id': customer.id}, os.environ['TOKEN_SECRET_KEY']) 

然后，我们将对 update_user 函数执行类似的步骤，并使用它将条带 customer.id 映射到 userId ，将条带 subscription.id 映射到 companyId ，并将我们收集的关于用户的一些其他元数据映射到 Moesif。

可选地，我们将把我们的 JWT 添加到我们的 Moesif 用户元数据中，以便于使用。不建议在生产环境中使用这种方法，但在测试您的设置时会有所帮助，如果您丢失了之前生成的 JWT，可以不生成新的。

 # Create User in Moesif
  user = {
    'user_id': customer.id,
    'company_id': subscription.id,
    'metadata': {
      'email': request_body['email'],
      'first_name': request_body['firstname'],
      'last_name': request_body['lastname'],
      'metadata': {
        'jwt': token
      }
    }
  }
  update_user = api_client.update_user(user) 

最后，我们将向调用者返回一个200 OKJSON 响应，并在响应体中包含 JWT。

 return JsonResponse(data=token, status=status.HTTP_200_OK, safe=False, encoder=json.JSONEncoder) 

完成的函数将如下所示:

def register(request):
  request_body = json.loads(request.body.decode('utf-8'))

  # Create Stripe Customer
  customer = stripe.Customer.create(
    email = request_body['email'],
    name = request_body['firstname'] + ' ' + request_body['lastname'],
    description = 'Customer created through /register endpoint'
  )
  print("Creating Stripe Customer Complete. Returned ID: " + customer.id)

  # Create Stripe Subscription
  subscription = stripe.Subscription.create(
    customer = customer.id,
    items = [{'price': os.environ['STRIPE_PRICE_KEY']}]
  )
  print("Creating Stripe Subscription Complete. Returned ID: " + subscription.id)

  # Create Company in Moesif
  company = {'company_id': subscription.id}
  update_company = api_client.update_company(company)

  # Encode JWT
  token = jwt.encode({'id': customer.id}, os.environ['TOKEN_SECRET_KEY'])

  # Create User in Moesif
  user = {
    'user_id': customer.id,
    'company_id': subscription.id,
    'metadata': {
      'email': request_body['email'],
      'first_name': request_body['firstname'],
      'last_name': request_body['lastname'],
      'metadata': {
        'jwt': token
      }
    }
  }
  update_user = api_client.update_user(user)

  return JsonResponse(data=token, status=status.HTTP_200_OK, safe=False, encoder=json.JSONEncoder) 

接下来，我们将实现我们的/测试服务端点的逻辑。

def test_service(request):
  try:
    # Parse request headers and jwt token array
    jwt_token = request.headers['Authorization']
    token_array = jwt_token.split(" ")

    # Attempt to decode JWT
    print("JWT tokenized: " + token_array[1]);
    decoded = jwt.decode(token_array[1], os.environ['TOKEN_SECRET_KEY'], algorithms=["HS256"])
    print("Decoded: " + decoded.get("id"))
  except Exception:
    return JsonResponse(data="Bad Auth Token", status=status.HTTP_401_UNAUTHORIZED, safe=False)

  return JsonResponse(data={token_array[0]: token_array[1]}, status=status.HTTP_200_OK, safe=False) 

我们将尝试解析我们传递的 JWT 的授权头。然后，我们将尝试使用我们的.env文件中的TOKEN_SECRET_KEY来解码 JWT。根据结果，我们将返回适当的JsonResponse对象，成功地包含我们的 JWT 令牌用于审计目的。

有了这个，我们现在可以实际测试我们的端点，以确保每个部分都按预期工作。结果应该是一个注册用户与相关的 JWT，将记录和报告使用数据到条纹。让我们继续测试它。通过运行以下命令启动服务器:

python manage.py runserver 

5 -向/register 端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，该请求体将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 Stripe 和 Moesif 中配置我们的系统和配置文件以及生成 JWT 所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

在 Postman 中，我们将使用以下信息创建我们的请求:

请求类型: POST

端点 URL: http://127.0.0.1:8000/register

请求正文:

{  "firstname":  "Userfirstname",  "lastname":  "Userlastname",  "email":  "test@test.com"  } 

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

发送请求后，响应应该包含新注册用户可以使用的 JWT。

我们现在将检查 Stripe，以确保我们向客户注册的信息正确输入到 Stripe 中。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。

检查完成后，我们可以放心地假设我们的 /register 端点正在 Stripe 中正确地设置我们的用户帐户和订阅。

6 -使用生成的 JWT 调用您的 API

我们的下一步是实际使用我们生成的 JWT。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向 /test-service 端点发送一个请求。这是我们在上面的步骤 3 中为其设置计费计量器的端点。

在《邮差》中，我们将:

• 将/测试服务 API 端点作为请求 URL
• 选择授权选项卡
• 选择类型作为不记名令牌
• 填充令牌详细信息
• 将令牌设置为从我们的/register 调用收到的 JWT

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 send。

一旦发送，API 调用分析应该在 Moesif 着陆。

确认 Moesif 收到了请求信息

回到 Moesif，您将导航到实时事件日志屏幕。您可以通过点击新建按钮并选择实时事件日志来完成此操作。

在这个屏幕上，您应该会看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 看起来像“库斯 _XXXX ”,订阅 ID 看起来像“sub_XXXX”。

如果您单击实时事件日志屏幕上条目中显示的用户 ID，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的 + 按钮来创建一个新列，我们将在其中添加条带元数据。

您可能需要向右滚动才能看到它，这取决于您的分辨率和屏幕大小，以便看到+按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

在这一点上，我们现在已经确认我们的 API 调用正在工作，并且在 Moesif 中使用了正确的用户和公司详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过邮递员调用我们的 JWT。我们将制作一个快速的小注册表单，然后返回一个 JWT 供我们新注册的用户使用。

首先，我们将创建几个模板文件，然后编辑 settings.py 文件，将 moesif _ monetary 项目作为应用程序添加进来，并让 Django 找到我们的模板文件。然后，我们将更新我们的 urls.py 文件，以引入一些新的端点。接下来，我们将实现 html 页面的标记。此外，我们将创建 Django 表单，用于协调视图之间的数据传递。最后，我们将更新 views.py 文件，并对我们的函数进行一些更改，以适应从前端接收数据。

添加前端文件

在应用程序的 moesif_monetization 目录中，我们将创建一个名为templates的文件夹。然后，我们将在该文件夹中添加一个base.html、一个index.html和一个registered.html文件。

此外，在 moes if _ monetary 目录中创建一个 forms.py 文件。

编辑 settings.py 文件

将moesif_monetization或者您的项目名称添加到INSTALLED_APPS数组中。这允许 Django 将我们的项目视为一个应用程序本身，并呈现我们的前端。

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
    'moesif_monetization'
] 

此外，将以下内容添加到TEMPLATES部分的DIRS部分。这允许 Django 定位我们的模板文件。

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
] 

编辑 url.py 文件

在 urls.py 文件中，我们将添加路由来服务静态 HTML 文件。用以下代码替换我们之前输入的内容:

urlpatterns = [
    path('', views.index, name='index'),
    path('admin/', admin.site.urls),
    path('test-service/', views.test_service),
    path('register/', views.register),
    path('registered/', views.registered, name='registered'),
] 

现在，当您导航到 http://127.0.0.1:8000/ 时，该代码将加载网站(一旦我们插入代码)。

编写前端表单代码

最后，让我们添加前端 HTML 和 Django 表单功能的代码。在base.html文件中，我们将添加如下所示的标记:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Moesif Monetization Demo</title>

    <!-- Bootstrap CSS -->
    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous">

    <script src="https://code.jquery.com/jquery-3.2.1.slim.min.js" integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN" crossorigin="anonymous"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js" integrity="sha384-ApNbgh9B+Y1QKtv3Rn7W3mgPxhU9K/ScQsAP7hUibX39j7fakFPskvXusvfa0b4Q" crossorigin="anonymous"></script>
    <script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js" integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl" crossorigin="anonymous"></script>

    <script src="https://unpkg.com/htmx.org@1.6.1"></script>
</head>
<body>

    <div class="container mt-4">
        {% block content %}
        {% endblock %}
    </div>

</body>
</html> 

另外，在index.html文件中。

{% extends 'base.html' %}
{% block content %}

<form method="post">
  {{ form.as_p }}
  <input type="submit" value="Register">
</form>

{% endblock %} 

最后，registered.html文件。

{% extends 'base.html' %}
{% block content %}

<p>
  {{ jwt }}
</p>
<a href="../">Go Back</a>

{% endblock %} 

创建注册表单

在我们的 forms.py 文件中，让我们定义我们的注册表单。

from django import forms

class RegistrationForm(forms.Form):
  first_name = forms.CharField(label='First Name', max_length=100)
  last_name = forms.CharField(label='Last Name', max_length=100)
  email = forms.EmailField(label='Email', max_length=100) 

这个标记与我们的 forms.py 文件相结合，将显示一个允许用户输入电子邮件、名字和姓氏的表单。它还有一个注册按钮，可以调用我们将要实现的新的 register_frontend python 函数。该函数将在我们的 views.py 文件中。

编辑 views.py 文件

我们将添加以下三个函数和导入来完成我们的 views.py 文件。

...

from django.shortcuts import render
from .forms import RegistrationForm

...

def index(request):
  context = {'form': RegistrationForm()}
  if request.method == 'POST':

    # create a form instance and populate it with data from the request:
    form = RegistrationForm(request.POST)

    # check whether it's valid:
    if form.is_valid():
      response = register_frontend(form.cleaned_data['email'], form.cleaned_data['first_name'], form.cleaned_data['last_name'])
      print("get_registration_info - Valid")
      jwt = (response.content.decode("utf-8").strip('"'))
      request_context = {'jwt': jwt}
      return render(request, 'registered.html', request_context)
    else:
      print("get_registration_info - not valid")
  else:
      print("get_registration_info - Not Post")

  return render(request, 'index.html', context)

def registered(request):
  return render(request, 'registered.html')

def register_frontend(email, firstname, lastname):

  # Create Stripe Customer
  customer = stripe.Customer.create(
    email = email,
    name = firstname + ' ' + lastname,
    description = 'Customer created through /register endpoint'
  )
  print("Creating Stripe Customer Complete. Returned ID: " + customer.id)

  # Create Stripe Subscription
  subscription = stripe.Subscription.create(
    customer = customer.id,
    items = [{'price': os.environ['STRIPE_PRICE_KEY']}]
  )
  print("Creating Stripe Subscription Complete. Returned ID: " + subscription.id)

  # Create Company in Moesif
  company = {'company_id': subscription.id}
  update_company = api_client.update_company(company)

  token = jwt.encode({'id': customer.id}, os.environ['TOKEN_SECRET_KEY'])

  # Create User in Moesif
  user = {
    'user_id': customer.id,
    'company_id': subscription.id,
    'metadata': {
      'email': email,
      'first_name': firstname,
      'last_name': lastname,
      'metadata': {
        'jwt': token
      }
    }
  }
  update_user = api_client.update_user(user)

  return JsonResponse(data=token, status=status.HTTP_200_OK, safe=False, encoder=json.JSONEncoder) 

register_frontend 函数本质上与我们之前实现的 register 函数相同，只是做了一些小的改动，以适应前端如何将数据传递给后端。

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到 http://127.0.0.1:8000/ 。然后，您将看到表单出现。

填写表单字段并提交

现在表单已经加载到屏幕上，请填写字段并单击 Register 按钮。这将获取信息，将其发送到我们的 /register_frontend 端点，并给我们生成的 JWT。

建议您使用一个不同的电子邮件，而不是之前通过 /register 端点直接创建 JWT 时使用的电子邮件。

确认 JWT 回来了

单击提交按钮后，几秒钟后，JWT 应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复从步骤 6 开始的步骤，以确认用户和公司 id 已正确填充，并且为该用户和新 JWT 返回了条带元数据。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 JWT 调用 API 后，请确认以下内容:

成条纹状

• 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
• 确认客户订购了正确的产品和价格

在默西迪斯

• 您的 API 调用被记录在 Moesif 的实时事件日志中
• 您的 API 调用在 Moesif 的用户和公司字段中分别有 Stripe 客户 ID 和订阅 ID。
• 确认在 Moesif 中填充了条带元数据

11 -检查条带的使用情况

最后，几个小时后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍然没有数据，请确保您遵循了本指南中概述的所有步骤。这包括确保来自 Moesif 的用户和公司 ID 正确地映射到 Stripe 中相应的密钥。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，Moesif 向 Stripe 报告时会有延迟。如果您的数据还没有，请稍后再回来查看。

12 -确定计费仪表是否正常工作

测试创建的计费表很容易，没有测试表功能。从左侧导航窗格导航至您创建的计费表，并选择您的条带测试计费表。选择右上方的测试仪。

Moesif 将等待在 Stripe 内创建的订阅，这些订阅将在 Moesif 自身内关联。此页面会自动更新，无需刷新。

然后，Moesif 将使用为我们创建的 JWT，等待对与我们的计费表相关联的任何端点的 API 调用。

最后，Moesif 将每隔 15 分钟将所有使用数据同步到条带。该步骤可能需要几分钟时间，具体取决于 API 调用的启动时间，但会按照给定的时间间隔进行更新。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

利用 Java Spring、Stripe 和 Moesif 实现端到端 API 货币化

原文：https://www.moesif.com/blog/api-monetization/stripe/End-To-End-API-Monetization-With-Java-Spring-Stripe-And-Moesif/

许多 API 开发者和公司都在努力寻找简单的方法来建立系统，以使他们的 API 货币化。有些很简单，但不可定制，有些很复杂，需要大量的工程工作才能真正运行起来。

为了让事情变得更简单，Moesif 几个月前创建了一个名为 Billing Meters 的功能，它提供了大量的可定制性，但只需要最少的代码和工程工作。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、Java Spring 和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 您的机器上安装了 Java
  • 我们将使用 openJDK 17 和 Gradle
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户

从外观上看，设置非常简单。我们将创建一个 /register 端点，它:

• 在条带中注册用户
• 为该用户订阅产品
• 在 Moesif 中注册用户和公司
• 创建一个 JWT 来认证/授权对我们货币化终端的呼叫

我还为它创建了一个小小的前端，这是一个注册用户的简单表单，然后为新注册的用户显示生成的 JWT。

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当您将 Stripe 集成到 Moesif 中时，您已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

产品资料

名字

• 这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

• 此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

图像

• 可以选择上传一张图片，帮助您轻松识别产品页面上的商品。在这个例子中，我们将使用默认的占位符图像。

定价信息

定价模型

在 Stripe 中可以设置一些不同的定价模式。这些定价模型包括:

• 标准定价
  • 如果您希望对每个 API 调用收取相同的费用，请使用此选项。

• 套餐定价
  • 如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。

• 分级定价
  • 使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。

• 批量定价
  • 如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的单价为 10.00 美元，100 个单位的单价为 7.00 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每日
• 每周一次
• 每月
• 每 3 个月一次
• 每 6 个月一次
• 每年
• 客户

对于您的 Moesif 配置，我们建议将计费周期设置为每月月。我们还建议，如果您正在使用 Moesif 的计费计量功能，请同时选中用量被计量框。

按计量使用收费

一旦选择了用量计量复选框，将出现计量用量收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

• 期间使用值总和
  • 在整个计费周期中，用户都要为其记录的使用付费
• 期间的最近使用值
  • 根据计费周期结束前记录的最后一次使用情况向用户收费
• 最近使用值
  • 在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费
• 期间最大使用值
  • 用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时间段内使用值的总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选字段，但建议填写。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费表，在 Moesif 中，您将导航至计费表屏幕。您可以从左侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的 +添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

• 计费电表名称

  • 这是您的新计费仪表的 Moesif 内部名称

• 账单提供商

  • 在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。

• 产品(仅条纹)

  • 在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。

• 价格(仅条纹)

  • 计费计数器的计费提供者设置中的最后一个字段，在这里您可以选择您要将使用指标绑定到哪个价格。

• 过滤器

  • 在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。

• 指标

  • 在这里，您可以选择希望计费的指标。可用选项包括:

• 事件计数

  • 这将增加符合过滤标准中列出的标准的每个事件的使用量。

• 唯一用户

  • 每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。

• 独特的公司

  • 每当一家独特的公司发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的公司，无论该公司的事件计数如何，计数都将增加 1。

• 唯一会话/API 密钥

  • 每当使用唯一的会话或 API 键来发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的会话或 API 键，无论该特定会话或 API 键的事件计数如何，计数都将增加 1。

指标下还有其他选项，但以上 4 个选项最适用于基于使用的计费。

例如，在本指南中，我们将创建一个计费计量器，它将过滤名为/test-service的单个端点的流量，其中请求接收到一个成功的 HTTP 200 响应。我们将使用事件计数指标来确保每个请求都被添加到计数中并发送给计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将单击创建。这将创建并激活计费表。将出现一个模式，通知您计费表已经创建，并提供一个引导，以确保计费表配置正确。

首先，我们将建立一个流程，让用户注册、订阅并创建一个 JWT，这样他们就可以使用我们的货币化 API。一旦完成，我们将返回并继续进行演练。

4 -创建 API

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关中的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 JWT，它将跟踪他们的使用情况。

由于我们使用 Moesif、Stripe 和 Java Spring 作为我们整体解决方案的一部分，我们需要确保每个组件都能正常工作。

端点将执行以下操作:

• 创建带条纹的客户
• 为新客户订阅条带中的 API 订阅
• 在 Moesif 中创建 CompanyID(这将是条带订阅 ID)
• 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
• 创建一个带有包含条带客户 ID 的jti字段的 JWT

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在本例中，我们将创建一个简单的 Java Spring API 来完成上述任务。

创建 Java Spring 项目

我们将使用 Spring Initializr 工具来帮助创建我们的初始项目。Spring Initializr 生成器提供了许多选项，允许快速定制我们的 starter 项目。

这些选项包括:

• 项目
  • 与项目一起使用的生成工具的类型
• 语言
  • 项目将使用的语言
• Spring Boot
  • 要使用的 Spring Boot 版本
• 项目元数据
  • 组名
    • 在所有项目中唯一标识您的项目
  • 神器名称
    • 没有版本的 jar 的名称
  • 名称
    • 项目名称
  • 描述
    • 项目的描述
  • 包名
    • 包的名称，通常是组名和工件名的组合
  • 包装类型
    • 生成项目时创建的包的类型
  • Java 版本
    • 项目中要使用的 Java 版本
• 依赖关系
  • 选择并包含许多依赖项，从开发人员工具和数据库到 web 和安全框架

我们将在项目中使用以下设置:

选择 Generate 将启动样本项目的下载。在您最喜欢的编辑器中，解压并打开 Spring Initializr 生成的文件夹，在我们的例子中称为 monetizationDemo。这是我们添加 API 代码的地方。运行./gradlew build以确保我们的项目一开始就正确构建。

添加项目依赖项

现在，我们将使用正确的依赖项编辑 build.gradle 文件。在 build.gradle 中，我们将在 dependencies 对象下添加以下条目。

dependencies {
 implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
 implementation 'org.springframework.boot:spring-boot-starter-web'
 implementation 'com.moesif.servlet:moesif-servlet:1.7.4'
 implementation 'com.stripe:stripe-java:21.8.0'
 implementation 'io.jsonwebtoken:jjwt-api:0.11.5'
 implementation "jakarta.xml.bind:jakarta.xml.bind-api:2.3.2"
 implementation "org.glassfish.jaxb:jaxb-runtime:2.3.2"
 implementation 'io.jsonwebtoken:jjwt-impl:0.11.5'
 implementation 'io.jsonwebtoken:jjwt-jackson:0.11.5'
 testImplementation 'org.springframework.boot:spring-boot-starter-test'
} 

保存文件，然后导航到终端并运行:

./gradlew build

现在，您的依赖项将被引入到项目中，并在必要时进行编译。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，生成和验证 jwt，以及我们将构建到应用程序中的各种其他功能。

由于我们选择使用 Web MVC 框架，我们有许多依赖于其他类并与之交互的类。在接下来的部分中，我们将构建这些类中的每一个。如果您的项目开始抛出错误，那么在继续阅读本指南后，应该会将它们整理出来。

定义 Moesif 过滤器

接下来，我们将把/src/main/java/com/username/monetizationDemo称为我们的工作目录。

在我们的工作目录中，我们将创建名为MoesifConfig.java的文件。在这个文件中，我们将添加以下代码，这些代码将允许我们通过使用 JSON Web 令牌(JWT)以及其他一些使过滤器能够工作的代码来识别 moesif 中的用户。

import java.util.Base64;
import javax.servlet.Filter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.moesif.servlet.MoesifFilter;
import com.moesif.servlet.MoesifConfiguration;
import org.json.JSONObject;
import org.springframework.context.annotation.*;
import org.springframework.web.servlet.config.annotation.*;
import org.springframework.web.servlet.view.InternalResourceViewResolver;

@Configuration
@EnableWebMvc
@ComponentScan
public class MoesifConfig {
  public String applicationId = "YOUR_MOESIF_APPLICATION_ID";

  @Bean
  public Filter moesifFilter() {

    MoesifConfiguration config = new MoesifConfiguration() {

      @Override
      public String identifyUser(HttpServletRequest request, HttpServletResponse response) {
        String customerID = null;

        try {
          // Obtain Stripe customerID from JWT included in header
          String token = request.getHeader("Authorization");
          String[] chunks = token.split("\\.");
          Base64.Decoder decoder = Base64.getUrlDecoder();
          String payload = new String(decoder.decode(chunks[1]));
          JSONObject jsonObject = new JSONObject(payload);
          customerID = jsonObject.getString("jti");
        } catch (Exception e) {
          System.out.print("Auth payload could not be parsed into JSON object: " + e.toString());
        }

        if (customerID == null) {
          return null;
        }

        return customerID;
      }

      @Override
      public String getSessionToken(HttpServletRequest request, HttpServletResponse response) {
        return request.getHeader("Authorization");
      }

      @Override
      public String getApiVersion(HttpServletRequest request, HttpServletResponse response) {
        return request.getHeader("X-Api-Version");
      }
    };

    MoesifFilter moesifFilter = new MoesifFilter(applicationId, config, true);

    // Set flag to log request and response body
    moesifFilter.setLogBody(true);

    return moesifFilter;
  }

  @Bean
  public InternalResourceViewResolver viewResolver() {
    InternalResourceViewResolver resolver = new InternalResourceViewResolver();
    resolver.setPrefix("/WEB-INF/jsp/");
    resolver.setSuffix(".jsp");
    return resolver;
  }
} 

这里我们配置了 Moesif 过滤器，包括实现 identifyUser 函数从 JWT 中提取客户 ID，以便在 Moesif 中进行用户跟踪。

我们还声明了我们的 Moesif 应用程序 ID。这可以在 Moesif 界面中找到。

获取您的 Moesif 应用程序 ID

进入屏幕左下方的菜单链接(将显示您的姓名)，选择 API 键，即可在 Moesif 中找到您的 Moesif 应用 ID。

然后，密钥将出现在出现在收集器应用 Id 下的页面上。

创建 Moesif 服务

在我们的工作目录中，我们将创建名为MoesifService.java的文件。我们将创建一个 config 对象，它利用了我们在上一步中创建的 MoesifConfig，一个用于在发送请求之前拦截和处理请求的 filter 对象，以及一些 helper 方法。

import com.moesif.api.APIHelper;
import com.moesif.api.models.UserModel;
import com.moesif.api.models.UserBuilder;
import com.moesif.api.models.CompanyModel;
import com.moesif.api.models.CompanyBuilder;
import com.moesif.servlet.MoesifFilter;
import com.moesif.servlet.MoesifConfiguration;
import io.jsonwebtoken.io.IOException;

public class MoesifService {

  MoesifConfig config = new MoesifConfig();
  MoesifFilter moesifFilter = new MoesifFilter(config.applicationId, new MoesifConfiguration(), true);

  public String updateUser(String customerId, String subscriptionId, String email, String firstname, String lastname, String jwt) {
    try {
      UserModel user = new UserBuilder()
          .userId(customerId)
          .companyId(subscriptionId)
          .metadata(APIHelper.deserialize("{" +
              "\"email\": \"" + email + "\"," +
              "\"first_name\": \"" + firstname + "\"," +
              "\"last_name\": \"" + lastname + "\"," +
              "\"metadata\": {" +
              "\"jwt\": \"" + jwt + "\"" +
              "}" +
              "}"))
          .build();

      moesifFilter.updateUser(user);
    } catch (IOException ex) {
      ex.printStackTrace();
    } catch (Throwable t) {
      System.out.println("Error while updating the user profile.");
      t.printStackTrace();
    }

    return "user updated, check moesif";
  }

  public String updateCompany(String subscriptionId) {
    try {
      CompanyModel company = new CompanyBuilder()
          .companyId(subscriptionId)
          .metadata(APIHelper.deserialize("{" +
              "\"org_name\": \"Stripe Subscription\"" +
              "}"))
          .build();

      moesifFilter.updateCompany(company);
    } catch (IOException ex) {
      ex.printStackTrace();
    } catch (Throwable t) {
      System.out.println("Error while updating the company profile.");
    }

    return "company updated, check moesif";
  }
} 

我们定义的方法将使用 Stripe 返回的信息(如客户 id、订阅 id 和价格键)在 Moesif 中创建用户和公司。

创建注册服务

在我们的工作目录中，创建名为 RegistrationService.java 的文件。这个类提供了一些方法，分别通过使用createCustomer和createSubscription在 Stripe 中创建客户和订阅。

import java.util.Map;
import java.security.Key;
import java.util.HashMap;
import com.stripe.Stripe;
import com.stripe.model.Customer;
import com.stripe.model.Subscription;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.JwtBuilder;
import io.jsonwebtoken.SignatureAlgorithm;
import javax.crypto.spec.SecretKeySpec;
import javax.xml.bind.DatatypeConverter;

public class RegistrationService {

  public String createCustomer(String email, String firstname, String lastname) {
    String id = null;
    try {
      Stripe.apiKey = "STRIPE_SECRET_OR_RESTRICTED_KEY";
      Map<String, Object> customerParams = new HashMap<>();
      customerParams.put("description", "Customer created through /register endpoint");
      customerParams.put("email", email);
      customerParams.put("name", String.format("%s %s", firstname, lastname));

      // create the new customer
      Customer customer = Customer.create(customerParams);
      id = customer.getId();
    } catch (Exception ex) {
      ex.printStackTrace();
    }
    return id;
  }

  public String createSubscription(String customerId, String plan) {
    String id = null;
    try {
      Stripe.apiKey = "STRIPE_SECRET_OR_RESTRICTED_KEY";
      Map<String, Object> item = new HashMap<>();
      item.put("plan", plan);

      Map<String, Object> items = new HashMap<>();
      items.put("0", item);

      Map<String, Object> params = new HashMap<>();
      params.put("customer", customerId);
      params.put("items", items);

      Subscription sub = Subscription.create(params);
      id = sub.getId();
    } catch (Exception ex) {
      ex.printStackTrace();
    }
    return id;
  }

   public String generateJWT(String id) {
    SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
    byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary("TOKEN_SECRET");
    Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
    JwtBuilder builder = Jwts.builder().setId(id)
        .signWith(signingKey, signatureAlgorithm);
    return builder.compact();
  }
} 

我们还将创建一个generateJWT方法，它将为我们的授权目的生成一个 JWT。我们将把 JWT 作为一个承载令牌，它将 API 调用归属于特定的用户。

获取您的条带 API 和价格密钥

您将在上面的代码示例中看到，我们需要为我们的createCustomer和createSubscription方法提供一个秘密或受限密钥。

您的 Stripe API 密钥可以在我们之前为计费表获取 Stripe 和 Moesif 集成密钥的同一位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，仅包含每个函数所需的范围。

现在，让我们抓住我们的 Stripe 产品的price键。我们将在下一节用到它。您的 Stripe 价格密钥是您之前在 Stripe 中创建的价格的标识符。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。_

创建您的秘密令牌

这将是用于生成和验证 jwt 的一部分的秘密。这可以是您喜欢的任何 256 位字符串，但是，出于生产目的，您最好使用某种生成方式，并且显然将这个键存储在其他地方，并使用 Java Spring 的外部化配置支持引入。

创建 API 控制器

在我们的工作目录中，我们将创建文件名为 APIController.java的文件。在这个文件中，我们定义了我们的MoesifConfig和MoesifFilter对象以及我们的RegistrationService和MoesifService对象。

我们还将为我们的 API 创建三个端点。

• 一个基础端点- /
  • 简单地用来测试我们的 API 是否在工作
• 注册端点- /register
  • 这个端点将在我们生成的 JWT、条带和 Moesif 之间创建绑定。结果将是一个生成的 JWT，它将使用情况与 Moesif 中的用户相关联，然后报告给 Stripe
• 一个测试服务端点- /test-service
  • 返回一个简单的字符串，但更重要的是，实现了@Request Header注释来传递 JWT 无记名令牌

import java.util.Map;
import java.util.HashMap;
import com.moesif.servlet.MoesifFilter;
import com.moesif.servlet.MoesifConfiguration;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.bind.annotation.PostMapping;

@RestController
public class APIController {

  MoesifConfig config = new MoesifConfig();
  MoesifFilter moesifFilter = new MoesifFilter(config.applicationId, new MoesifConfiguration(), true);

  private RegistrationService registrationService = new RegistrationService();
  private MoesifService moesifService = new MoesifService();

  @RequestMapping("/")
  public String hello(@RequestParam(value="name", defaultValue="") String name) {
    return "{ \"message\": \"Hello World!\" }";
  }

  @PostMapping("/register")
  public Map<String, Object> registerUser(@RequestBody Map<String, Object> payload) {
    String email = payload.get("email").toString();
    String firstname = payload.get("firstname").toString();
    String lastname = payload.get("lastname").toString();

    // Create Stripe customer and subscription
    String customerId = registrationService.createCustomer(email, firstname, lastname);
    String subscriptionId = registrationService.createSubscription(customerId, "price_1LpI5yGa4tYEM7sSR5G1QWP0");

    // Generate JWT for user using customerID
    String jwt = registrationService.generateJWT(customerId);

    // Create Moesif User and Company
    moesifService.updateCompany(subscriptionId);
    moesifService.updateUser(customerId, subscriptionId, email, firstname, lastname, jwt);

    // Build json response
    Map<String, Object> jsonResponse = new HashMap<>();
    jsonResponse.put("JWT", jwt);
    return jsonResponse;
  }

  @RequestMapping("/test-service")
  @ResponseBody
  public String simpleString(@RequestHeader (name="Authorization") String token) {
    return "this is a simple string";
  }

} 

/register端点接收我们的用户名和电子邮件，然后我们的RegistrationService在 Stripe 内创建一个客户和订阅，返回必要的标识符。然后使用客户标识符创建一个 JWT，最后将所有这些数据传递给我们的MoesifService,在 Moesif 中创建一个用户和公司。JWT 在我们从对/register端点的调用中得到的响应中传递，我们将在对/test-service端点的调用中使用它作为承载令牌。

有了这些，我们现在可以实际测试我们的端点，以确保每一部分都按预期工作。结果应该是一个注册用户与相关的 JWT，将记录和报告使用数据到条纹。让我们继续测试它。

构建您的项目:

./gradlew build 

然后部署它:

java -jar build/libs/monetizationDemo-0.0.1-SNAPSHOT.jar 

如果您在构建依赖项时遇到问题，请尝试:./gradlew clean build --refresh-dependencies

5 -向/register 端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，该请求体将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 Stripe 和 Moesif 中配置我们的系统和配置文件以及生成 JWT 所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

在 Postman 中，我们将使用以下信息创建我们的请求:

请求类型: POST

端点 URL: http://localhost:8080/register

请求正文:

{  "firstname":  "Userfirstname",  "lastname":  "Userlastname",  "email":  "test@test.com"  } 

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

发送请求后，响应应该包含新注册用户可以使用的 JWT。

我们现在将检查 Stripe，以确保我们向客户注册的信息正确输入到 Stripe 中。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。

检查完成后，我们可以放心地假设我们的 /register 端点正在 Stripe 中正确地设置我们的用户帐户和订阅。

6 -使用生成的 JWT 调用您的 API

我们的下一步是实际使用我们生成的 JWT。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向 /test-service 端点发送一个请求。这是我们在上面的步骤 3 中为其设置计费计量器的端点。

在《邮差》中，我们将:

• 将/测试服务 API 端点作为请求 URL
• 选择授权选项卡
• 选择类型作为不记名令牌
• 填充令牌详细信息
• 将令牌设置为从我们的/register 调用收到的 JWT

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 send。

一旦发送，API 调用分析应该在 Moesif 着陆。

使用个人资料仪表板确认 Moesif 收到了请求信息

回到 Moesif，您将导航到实时事件日志屏幕。您可以通过点击新建按钮并选择实时事件日志来完成此操作。

在这个屏幕上，您应该会看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 看起来像“库斯 _XXXX ”,订阅 ID 看起来像“sub_XXXX”。

如果您单击实时事件日志屏幕上条目中显示的用户 ID，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的 + 按钮来创建一个新列，我们将在其中添加条带元数据。

您可能需要向右滚动才能看到它，这取决于您的分辨率和屏幕大小，以便看到+按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

在这一点上，我们现在已经确认我们的 API 调用正在工作，并且在 Moesif 中使用了正确的用户和公司详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过邮递员调用我们的 JWT。我们将制作一个快速的小注册表单，然后返回一个 JWT 供我们新注册的用户使用。

将 html 文件添加到应用程序

在应用程序的src/main/resources目录下，创建一个名为templates的文件夹，我们将添加两个文件。我们将添加一个 registration.html 的和一个 result.html 的文件。****

编写前端表单和逻辑

让我们添加前端 HTML 的代码。在registration.html文件中，我们将添加如下所示的标记:

<!DOCTYPE HTML>
<html xmlns:th="https://www.thymeleaf.org">
<head>
    <title>Moesif Monetization Example</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
  <h1>Moesif Monetization Example</h1>
    <form action="#" th:action="@{/registration}" th:object="${registration}" method="post">
      <p>Email: <input type="text" th:field="*{email}" /></p>
      <p>First Name: <input type="text" th:field="*{firstname}" /></p>
      <p>Last Name: <input type="text" th:field="*{lastname}" /></p>
      <form:hidden path="jwt" />
      <p><input type="submit" value="Register" /> <input type="reset" value="Reset" /></p>
    </form>
</body>
</html> 

这个标记将显示一个允许用户输入电子邮件、名字和姓氏的表单。它还有一个注册按钮，将输入的数据传递给我们马上要创建的RegistrationController。

接下来，我们将把以下标记添加到我们的result.html文件中:

<!DOCTYPE HTML>
<html xmlns:th="https://www.thymeleaf.org">
<head>
    <title>Moesif Monetization Example</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
  <h1>Moesif Monetization Example Results</h1>
    <p th:text="'Email: ' + ${registration.email}" />
    <p th:text="'First Name: ' + ${registration.firstname}" />
    <p th:text="'Last Name: ' + ${registration.lastname}" />
    <p th:text="'JWT: ' + ${registration.jwt}" />
    <a href="/registration">Submit another registration</a>
</body>
</html> 

在我们的注册流程完成后,result.html文件将显示从控制器收到的数据。

创建注册模型

回到我们的“工作目录”(/src/main/java/com/username/monetizationDemo)，创建下面两个文件，Registration.java和RegistrationController.java。

在Registration.java文件中，我们将创建一个用于为我们的用户建模的类:

public class Registration {

  private String email;
  private String firstname;
  private String lastname;
  public String jwt;

  public String getEmail() {
    return email;
  }

  public void setEmail(String email) {
    this.email = email;
  }

  public String getFirstname() {
    return firstname;
  }

  public void setFirstname(String firstname) {
    this.firstname = firstname;
  }

  public String getLastname() {
    return lastname;
  }

  public void setLastname(String lastname) {
    this.lastname = lastname;
  }

  public String getJWT() {
    return jwt;
  }

  public void setJWT(String jwt) {
    this.jwt = jwt;
  }

} 

创建注册控制器

RegistrationController用于呈现我们的表单，接收从前端输入的数据，并将其传递给我们的后端RegistrationService。其结果将显示给最终用户，返回的 JWT 用于授权呼叫。

import java.util.Map;
import java.util.HashMap;
import org.springframework.ui.Model;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.ModelAttribute;

@Controller
public class RegistrationController {

  @GetMapping("/registration")
  public String registrationForm(Model model) {
    model.addAttribute("registration", new Registration());
    return "registration";
  }

  @PostMapping("/registration")
  public String registrationSubmit(@ModelAttribute Registration registration, Model model) {
    // Create payload from form data for registration
    Map<String, Object> payload = new HashMap<>();
    payload.put("email", registration.getEmail());
    payload.put("firstname", registration.getFirstname());
    payload.put("lastname", registration.getLastname());

    // Register User and add generated JWT to result form response
    Map<String, Object> jsonResponse = new APIController().registerUser(payload);
    registration.setJWT(jsonResponse.get("JWT").toString());
    model.addAttribute("registration", registration);
    return "result";
  }
} 

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到http://localhost:8080/registration。然后，您将看到表单出现。

填写表单字段并提交

现在表单已经加载到屏幕上，请填写字段并单击 Register 按钮。这将获取信息，将其传递给我们的RegistrationController，并给我们生成的 JWT。

建议您使用不同的电子邮件地址，而不是您之前通过 /registration 端点直接创建 JWT 时使用的电子邮件地址。

确认 JWT 回来了

单击提交按钮后，几秒钟后，JWT 应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复从步骤 6 开始的步骤，以确认用户和公司 id 已正确填充，并且为该用户和新 JWT 返回了条带元数据。我们应该会在实时事件日志中看到这些呼叫。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 JWT 调用 API 后，请确认以下内容:

成条纹状

• 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
• 确认客户订购了正确的产品和价格

在默西迪斯

• 您的 API 调用被记录在 Moesif 的实时事件日志中
• 您的 API 调用在 Moesif 的用户和公司字段中分别有 Stripe 客户 ID 和订阅 ID。
• 确认在 Moesif 中填充了条带元数据
• 所有计费仪表测试条件均已通过

11 -检查条带的使用情况

最后，几个小时后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍然没有数据，请确保您遵循了本指南中概述的所有步骤。这包括确保来自 Moesif 的用户和公司 ID 正确地映射到 Stripe 中相应的密钥。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，Moesif 向 Stripe 报告时会有延迟。如果您的数据还没有，请稍后再回来查看。

12 -确定计费仪表是否正常工作

测试创建的计费表很容易，没有测试表功能。从左侧导航窗格导航至您创建的计费表，并选择您的条带测试计费表。选择右上方的测试仪。

Moesif 将等待在 Stripe 内创建的订阅，这些订阅将在 Moesif 自身内关联。此页面会自动更新，无需刷新。

然后，Moesif 将使用为我们创建的 JWT，等待对与我们的计费表相关联的任何端点的 API 调用。

最后，Moesif 将每隔 15 分钟将所有使用数据同步到条带。该步骤可能需要几分钟时间，具体取决于 API 调用的启动时间，但会按照给定的时间间隔进行更新。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

Kong、Stripe 和 Moesif 的端到端 API 货币化

原文：https://www.moesif.com/blog/technical/stripe/kong/End-To-End-API-Monetization-With-Kong-Stripe-And-Moesif/

许多 API 开发者和公司都在努力寻找简单的方法来建立系统，以使他们的 API 货币化。有些很简单，但不可定制，而另一些很复杂，需要大量的工程工作才能真正运行。

为了让事情变得更简单，Moesif 创建了计费表功能，允许以最少的代码和工程工作量进行大规模定制。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、Kong 和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 您有一个正在运行的 Kong 实例(创建了一个端点和一个路由)
• 您的 Kong 实例为您的端点启用了密钥授权
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户
• 您已经在 Kong 中安装并配置了 Moesif 插件

从外观上看，设置非常简单。我们将创建一个 /register 端点，它:

• 在条带中注册用户
• 为该用户订阅产品
• 在香港创建用户/消费者
• 在 Moesif 中注册用户和公司
• 使用 Kong 生成 API 密钥

我们还将为它创建一个简单的前端，它包含一个通过调用 /register 端点注册用户的表单，然后为新注册的用户显示生成的 API 密钥。

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当你将 Stripe 集成到 Moesif 中时，你已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

名称

这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

定价模式

在 Stripe 中可以设置一些不同的定价模型。这些定价模型包括:

• 标准定价
  • 如果您希望对每个 API 调用收取相同的费用，请使用此选项。
• 包
  • 如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。
• 毕业了
  • 使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。
• 体积
  • 如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的费用为每单位 10 美元，100 个单位的费用为每单位 7 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每天地；天天地
• 一周的
• 每月
• 每 3 个月
• 每 6 个月
• 每年的
• 习俗

对于您的 Moesif 配置，我们建议将计费周期设置为每月。我们还建议，如果您正在使用 Moesif 的计费计量功能，也要检查使用量是否被计量框。

按计量使用收费

一旦选择了计量使用量复选框，将出现计量使用量的收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

• 期间使用值的总和
  • 在整个计费周期中，用户都要为其记录的使用付费
• 期间内最近的使用值
  • 根据计费周期结束前记录的最后一次使用情况向用户收费
• 最近使用值
  • 在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费
• 期间的最大使用价值
  • 用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时段期间的使用值总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选字段，但建议填写。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费表，在 Moesif 中，您将导航至计费表屏幕。您可以从右侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的+添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

计费电表名称

这是您的新计费仪表的 Moesif 内部名称

账单提供商

在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。

产品(仅条纹)

在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。

价格(仅条纹)

计费计数器的计费提供者设置中的最后一个字段，在这里您可以选择您要将使用指标绑定到哪个价格。

过滤器

在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。

指标

在这里，您可以选择希望计费的指标。可用选项包括:

• 事件计数
  • 这将增加符合过滤标准中列出的标准的每个事件的使用量。
• 唯一用户
  • 每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。
• 自定义
  • 这使您能够构建自己的指标，如接收的数据、美元量的百分比、计算单位的总和或任何其他与 API 相关的消耗指标。Moesif 支持 API 主体字段、用户操作等方面的度量。

有关常见消费指标的更多示例，请查看基于使用计费的最佳实践以实现 API 货币化

例如，在本指南中，我们将创建一个计费计量器，用于过滤单个端点的流量，以及请求收到成功 HTTP 200 响应的位置。我们将使用事件计数指标来确保每个请求都被添加到计数中并被发送到计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将单击创建。这将创建并激活计费计数器。然后，当您返回计费表仪表板时，您将看到新的计费表出现。

Moesif 现在将汇总使用情况，并将这些详细信息发送给 Stripe。现在计费表已经配置好了，我们将建立一个流程让用户注册、订阅并发布一个 API 密匙，这样他们就可以使用我们的货币化 API。

4 -创建/register 端点

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关中的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 API 密钥，该密钥将跟踪他们的使用情况。

因为我们使用 Moesif、Stripe 和 Kong 作为我们整体解决方案的一部分，所以我们需要确保每个组件都能正常工作。

端点将执行以下操作:

1. 在条带中创建用户
2. 为新用户订阅条带中的 API 订阅
3. 在 Kong 创建用户/消费者(使用 Stripe 客户 ID 作为 custom_id 字段)
4. 在 Moesif 中创建 CompanyID(这将是条带订阅 ID)
5. 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
6. 创建 API 密钥

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在本例中，我将使用 Express 创建一个简单的 NodeJS API 来完成上述任务。

创建国家预防机制项目

首先，我们将创建一个名为 moesif-monetization 的文件夹，我们将在其中添加 API 代码。然后我们将运行npm init来转变货币化，这样我们就可以在我们的项目中使用 npm。为此，您将在 moesif-monetization 目录中运行以下命令。

$ npm init 

创建 npm 项目时，您可以根据需要填写详细信息或使用默认值。

然后你应该会在你的moesif-monetary文件夹中看到一个 package.json 文件。

现在，在您喜欢的 IDE 或文本编辑器中打开这个目录。在本教程的剩余部分，我将使用 VS 代码进行所有的编码。

添加项目依赖项

我们现在将使用正确的依赖项编辑我们的 package.json 文件。在 package.json 中，我们将在依赖关系对象下添加以下条目。

"dependencies":  {  "@stripe/stripe-js":  "^1.29.0",  "body-parser":  "^1.20.0",  "dotenv":  "^16.0.0",  "express":  "^4.17.1",  "http":  "0.0.1-security",  "moesif-nodejs":  "^3.1.14",  "node-fetch":  "^2.6.5",  "path":  "^0.12.7",  "stripe":  "^8.219.0"  } 

保存文件，然后导航到终端并运行:

$ npm install 

现在，您的依赖项将被引入到项目中，并添加到 node_modules 文件夹中。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，以及我们将内置到应用程序中的各种其他功能。

创建。环境文件

我们不会将条带键和其他静态值硬编码到我们的应用程序中，而是将它们抽象到一个. env 文件中。我们可以使用添加到名为 dotenv 的 package.json 中的依赖项来实现这一点。

在根目录下，创建一个名为的文件。env 。在这个文件中，我们将添加几个条目，其中包含代码中使用的键和值。

STRIPE_KEY="sk_test_XXX"
STRIPE_PRICE_KEY="price_XXX"
MOESIF_APPLICATION_ID="YOUR_MOESIF_APP__ID"
KONG_URL="http://KONG_URL:8001" 

这里的值可以在以下位置找到:

STRIPE_KEY

这可以在我们之前为计费表获取 Stripe 和 Moesif 集成密钥的相同位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，仅包含每个函数所需的范围。

STRIPE_PRICE_KEY

这将是您之前在 Stripe 中创建的价格的价格键。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。

MOESIF_APPLICATION_ID

这可以在 Moesif 中找到，方法是转到屏幕左下方的菜单链接(将显示您的姓名)并选择 API 键。

然后，密钥将出现在出现在收集器应用 Id 下的页面上。

KONG_URL

这将是 Kong 管理 API 的 URL。通常，这将在端口 8001 上托管，但如果您有自定义配置，它可能会有所不同。

用四个键值对填充文件后，保存文件。在本教程的剩余部分，我们不需要再接触这个文件。

创建 app.js 文件

在我们的应用程序的根目录中，我们将创建一个 app.js 文件(如果还没有创建的话)。在这个文件中，我们将添加下面的代码来添加我们的依赖项并创建一个基本的 REST 端点。

require('dotenv').config();
const express = require('express');
const path = require("path");
const bodyParser = require('body-parser');
const moesif = require('moesif-nodejs');
const Stripe = require('stripe');
// npm i --save node-fetch@2.6.5
const fetch = require('node-fetch');

const app = express();

const port = 5000;
const stripe = Stripe(process.env.STRIPE_KEY);

var jsonParser = bodyParser.json();

const moesifMiddleware = moesif({
 applicationId: process.env.MOESIF_APPLICATION_ID
});

app.use(moesifMiddleware);

app.post('/register', jsonParser,
 async (req, res) => {
 }
)
app.listen(port, () => {
 console.log(`Example app listening at http://localhost:${port}`);
}) 

在上面的代码中，我们是:

• 导入一些依赖项
• 配置条带依赖关系
• 配置 Moesif 中间件
• 创建/注册端点
• 将我们的应用程序设置为在端口 5000 上运行，并启动我们的节点应用程序

你会注意到我们有 process.env.STRIPE_KEY 和process . env . moes if _ APPLICATION _ ID。这些值将来自。我们在最后一步中创建的 env 文件。

实现/register 终结点

我们的下一步是实现 /register 端点。这个端点将在 Kong、Stripe 和 Moesif 之间创建我们的绑定。结果将是从 Kong 生成的 API 密钥，该密钥将使用与 Moesif 中的用户相关联，然后将该密钥报告给 Stripe。

我们流程中的第一步是创建 Stripe 中的客户。我们将使用我们的 Stripe JS 依赖来做到这一点。我们将使用请求正文中的参数(电子邮件、名字、姓氏)通过使用 stripe.customers.create 函数在 Stripe 中创建客户。然后，我们将把创建的客户存储在一个自定义变量中，这样我们就可以访问 Stripe 中生成的客户 ID 。

const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   }); 

接下来，我们将为这个新用户订阅我们之前在 Stripe 中创建的 API 订阅。我们将使用stripe . subscriptions . create函数，并使用从之前的函数调用中生成的客户 ID 来订阅它们。这将返回一个订阅对象，其中包含一个我们稍后会用到的 ID。

 const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   }); 

然后，我们将在 Kong 中创建消费者，允许我们为这个用户生成一个密钥。我们将通过 Kong 管理 API 发布到 Kong 的/消费者端点。这将生成一个用户，该用户使用提供的电子邮件作为他们的用户名，并将条带 customer.id 作为 Kong 中的 custom_id 字段。

 var body = { username: req.body.email, custom_id: customer.id };
   var response = await fetch(`${process.env.KONG_URL}/consumers/`, {
     method: 'post',
     body: JSON.stringify(body),
     headers: {'Content-Type': 'application/json'}
   });
   var data = await response.json(); 

一旦在 Kong 中创建了用户，我们现在将使用 Moesif 中间件来创建用户，并将他们的相关详细信息添加到 Moesif 中。首先，我们将调用 Moesif 中间件的 updateCompany 函数，将条带 subscription.id 映射到 Moesif 中的 companyId 。

 var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company); 

然后，我们将对 updateUser 函数执行类似的步骤，并使用它将条带 customer.id 映射到 userId ，将条带 subscription.id 映射到 companyId ，并将我们收集的关于用户的一些其他元数据映射到 Moesif。

 var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user); 

在这一点上，我们现在已经将所有的用户详细信息插入到必要的平台中。我们的下一步是为这个用户生成一个 API 密钥。为此，我们将使用/consumers/{ user }/key-auth端点再次调用 Kong 管理 API。这将在响应中为用户返回一个 API 密钥。我们通过数据访问那个 API 密匙。

 var response = await fetch(`${process.env.KONG_URL}/consumers/${req.body.email}/key-auth`, {
     method: 'post',
   });
   var data = await response.json();
   var kongAPIKey = data.key; 

可选地，我们也将把用户 API 键添加到 Moesif 中的元数据中。为了测试的目的，如果你找不到它，并且不想回到 Kong 去找回它，这使你很容易得到它。我们将在 Moesif 中间件中再次使用 updateUser 函数来完成这项工作，在元数据对象中提供生成的 API 键。

 var user = {
     userId: customer.id,
     metadata: {
       apikey: kongAPIKey,
     }
   };
   moesifMiddleware.updateUser(user); 

最后，我们将向调用者返回一个 200 OK 响应，在响应体中包含 API 键。

 res.status(200);
   res.send({ apikey: kongAPIKey }); 

完整的端到端功能如下所示:

app.post('/register', jsonParser,
 async (req, res) => {
   // create Stripe customer
   const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   });

   // create Stripe subscription
   const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   });

   //create Kong consumer 
   var body = { username: req.body.email, custom_id: customer.id };
   var response = await fetch(`${process.env.KONG_URL}/consumers/`, {
     method: 'post',
     body: JSON.stringify(body),
     headers: {'Content-Type': 'application/json'}
   });
   var data = await response.json();

   // create user and company in Moesif
   var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company);

   var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user);

   // send back a new API key for use
   var response = await fetch(`${process.env.KONG_URL}/consumers/${req.body.email}/key-auth`, {
     method: 'post',
   });
   var data = await response.json();
   var kongAPIKey = data.key;

   // add API key to users metadata in Moesif
   var user = {
     userId: customer.id,
     metadata: {
       apikey: kongAPIKey,
     }
   };
   moesifMiddleware.updateUser(user);

   res.status(200);
   res.send({ apikey: kongAPIKey });
 }
) 

有了这些，我们现在可以实际测试我们的端点，以确保每一部分都按预期工作。结果应该是一个注册用户与一个 API 密钥，将记录和报告使用数据到条纹。让我们继续测试它。

5 -向/register 端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，该请求体将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 Kong、Stripe 和 Moesif 中正确配置我们的系统和配置文件所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

在 Postman 中，我们将使用以下信息创建我们的请求:

• 请求类型:发布

• 端点 URL:http://localhost:5000/register

• 请求正文:

  {  "firstname":  "Userfirstname",  "lastname":  "Userlastname",  "email":  "test@test.com"  } 
  

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

一旦发送了请求，响应应该包含新注册用户可以使用的 API 键。

我们现在将检查 Kong 和 Stripe，以确保我们注册的信息正确输入到每个目标系统中。我们首先要检查的是条纹。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。

一旦在 Stripe 中确认了这两个条目，您就可以转到 Kong，以确保在那里也正确地设置了用户。

使用 Kong Manager，导航至消费者屏幕。这里您应该看到一个条目，其中用户名和 Custom_ID 字段分别设置为提供的电子邮件和用户条带客户 ID。

点击该条目会将您带到消费者详细信息屏幕。在这里，单击凭证选项卡将显示为该用户生成的 API 密钥。显示的 API 键应该与 Postman 中返回的相匹配。

如果您没有使用 Kong 的企业版，也可以使用 Kong 管理 API 来检索这些信息

完成这些检查后，我们可以安全地假设我们的 /register 端点在 Kong 和 Stripe 中正确地设置了我们的用户帐户和订阅。

6 -使用生成的 API 密钥调用您的 API

我们的下一步是实际使用我们生成的 API 密钥。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向/test-service 端点发送一个请求。这是我们在上面的步骤 3 中为其设置计费计量器的端点。

在《邮差》中，我们将:

• 将/test-service API 端点作为请求 URL
• 选择授权选项卡
• 选择类型作为 API 键
• 填充 API 键详细信息
  • 将密钥设置为“apikey”，或者您在 Kong 中设置的任何密钥
  • 将该值设置为生成的 API 键
  • 将“添加到”字段值设置为“标题”

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 send。

一旦发送，您的请求应该通过孔代理，API 调用分析应该在 Moesif 着陆。

确认 Moesif 收到了请求信息

回到 Moesif，您将导航到 Events 屏幕，在这里您将看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 看起来像“库斯 _XXXX ”,订阅 ID 看起来像“sub_XXXX”。

如果您点击显示在现场活动日志屏幕条目中的用户 ID ，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的 + 按钮来创建一个新列，我们将在其中添加条带元数据。

您可能需要向右滚动才能看到它，这取决于您的分辨率和屏幕大小，以便看到+按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

现在，我们已经确认了通过 Kong 代理的 API 调用正在工作，并且在 Moesif 中标记了正确的用户和公司详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过 Postman 调用我们的 API 键了。我们将制作一个快速的注册表单，然后返回一个 API 密钥供新注册的用户使用。

将您的前端文件添加到应用程序

在应用程序的根目录中，我们将添加两个文件。我们将添加一个index.html和一个索引. js 。

添加您的路由以提供静态 html 文件

在 app.js 文件中，我们将添加一个路由来服务静态 HTML 文件。在我们的 /register 端点代码下面，我们将添加另一个端点。添加以下代码:

pp.get("/", function (_req, res) {
 res.sendFile(path.join(__dirname, "index.html"));
 res.sendFile(path.join(__dirname, "index.js"));
}); 

现在，当您导航到 http://localhost:5000/ 时，这段代码将加载网站(一旦我们插入了代码)。

编写前端表单和逻辑

最后，让我们添加前端 HTML 和 JavaScript 功能的代码。在 index.html 文件中，我们将添加如下所示的标记:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1" />
   <meta name="theme-color" content="#000000" />
   <meta
     name="description"
     content="Moesif Embedded Dashboard example"
   />
   <title>None React App Example</title>
 </head>
 <body>
   <noscript>You need to enable JavaScript to run this app.</noscript>
   <h1>
     Moesif Monetization Example
   </h1>
   <div id="form-input">
     email: <input id="email-input" placeholder="email" />
     first name: <input id="firstname-input" placeholder="first name" />
     last name: <input id="lastname-input" placeholder="last name" />
     <button onClick="submitRegistration()">Register</button>
   </div>
   <div id="apikey-output"></div>
   <p id="error-message"></p>
   <script src="index.js"></script>
 </body>
</html> 

他的标记将显示一个允许用户输入电子邮件、名字和姓氏的表单。它还有一个 Register 按钮，该按钮将为 submitRegistration() 调用 JavaScript 函数。该函数将在我们的 index.js JavaScript 文件中。

index.js 文件将如下所示:

async function submitRegistration() {
  const email = document.getElementById("email-input").value;
  const firstname = document.getElementById("firstname-input").value;
  const lastname = document.getElementById("lastname-input").value;
  const errorElement = document.getElementById("error-message");
  const apikey = document.getElementById("apikey-output");

  var body = { email, firstname, lastname };
  console.log(body);
  var response = await fetch('http://localhost:5000/register', {
    method: 'post',
    body: JSON.stringify(body),
    headers: {'Content-Type': 'application/json'}
  });
  var data = await response.json();
  console.log("Kong create consumer");
  console.log(data);
  apikey.innerHTML = data.apikey;
} 

该函数将从表单中获取输入，将其发送到我们的/register 端点，并在屏幕上显示返回的 API 键。

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到 。然后，您将看到表单出现。

填写表单字段并提交

现在已经加载了表单，填写字段并点击注册按钮。这将获取信息，将其发送到我们的/注册端点，并给我们生成的 API 密钥。

建议您使用不同于之前通过/register 端点直接创建 API 密钥时使用的电子邮件。

确认 API 密钥已返回

单击 submit 按钮后，几秒钟后，API 键应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复从步骤 6 开始的步骤，以确认用户和公司 id 已正确填充，并且为该用户和新的 API 密钥返回了条带元数据。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 API 键调用 API 后，请确认以下内容:

• 在条纹中
  • 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
  • 确认客户订购了正确的产品和价格
• 在孔
  • 消费者已被创建
  • 消费者 custom_id 字段匹配 Stripe 中的客户 id(以 cus_XXXX 开始)
• 中的莫西
  • 您的 API 调用被记录在 Moesif 的实时事件日志中
  • 您的 API 调用在 Moesif 的用户和公司字段中分别有 Stripe 客户 ID 和订阅 ID。
  • 确认在 Moesif 中填充了条带元数据

11 -检查条带的使用情况

最后，几个小时后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍然没有数据，请确保您遵循了本指南中概述的所有步骤。这包括确保来自 Moesif 的用户和公司 ID 正确地映射到 Stripe 中相应的密钥。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，可能需要一个小时才能向条带化报告使用情况。如果您的数据还没有，请稍后回来查看更新。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

利用 NodeJS、Stripe 和 Moesif 实现端到端 API 货币化

原文：https://www.moesif.com/blog/api-monetization/stripe/End-To-End-API-Monetization-With-NodeJS-Stripe-And-Moesif/

许多 API 开发者和公司都在努力寻找简单的方法来建立系统，以使他们的 API 货币化。有些很简单，但不可定制，有些很复杂，需要大量的工程工作才能真正运行起来。

为了让事情变得更简单，Moesif 几个月前创建了一个名为 Billing Meters 的功能，它提供了大量的可定制性，但只需要最少的代码和工程工作。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、NodeJS 和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 您的计算机上安装了 NodeJS
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户

从外观上看，设置非常简单。我们将创建一个 /register 端点，它:

• 在条带中注册用户
• 为该用户订阅产品
• 在 Moesif 中注册用户和公司
• 创建一个 JWT 来认证/授权对我们货币化终端的呼叫

我还为它创建了一个小小的前端，它是一个简单的表单，通过调用 /register 端点来注册用户，然后为新注册的用户显示生成的 JWT。

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当您将 Stripe 集成到 Moesif 中时，您已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

产品资料

名字

• 这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

• 此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

图像

• 可以选择上传一张图片，帮助您轻松识别产品页面上的商品。在这个例子中，我们将使用默认的占位符图像。

定价信息

定价模型

在 Stripe 中可以设置一些不同的定价模式。这些定价模型包括:

• 标准定价
  • 如果您希望对每个 API 调用收取相同的费用，请使用此选项。

• 套餐定价
  • 如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。

• 分级定价
  • 使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。

• 批量定价
  • 如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的单价为 10.00 美元，100 个单位的单价为 7.00 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每日
• 每周一次
• 每月
• 每 3 个月一次
• 每 6 个月一次
• 每年
• 客户

对于您的 Moesif 配置，我们建议将计费周期设置为每月月。我们还建议，如果您正在使用 Moesif 的计费计量功能，请同时选中用量被计量框。

按计量使用收费

一旦选择了用量计量复选框，将出现计量用量收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

• 期间使用值总和
  • 在整个计费周期中，用户都要为其记录的使用付费
• 期间的最近使用值
  • 根据计费周期结束前记录的最后一次使用情况向用户收费
• 最近使用值
  • 在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费
• 期间最大使用值
  • 用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时间段内使用值的总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选字段，但建议填写。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费表，在 Moesif 中，您将导航至计费表屏幕。您可以从左侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的 +添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

• 计费电表名称
  • 这是您的新计费仪表的 Moesif 内部名称
• 账单提供商
  • 在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。
• 产品(仅条纹)
  • 在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。
• 价格(仅条纹)
  • 计费计数器的计费提供者设置中的最后一个字段，您可以在这里选择要将您的使用指标绑定到哪个价格。
• 过滤器
  • 在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。
• 指标
  • 在这里，您可以选择希望计费的指标。可用选项包括:
• 事件计数
  • 这将增加符合过滤标准中列出的标准的每个事件的使用量。
• 唯一用户
  • 每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。
• 独特的公司
  • 每当一家独特的公司发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的公司，无论该公司的事件计数如何，计数都将增加 1。
• 唯一会话/API 密钥
  • 每当使用唯一的会话或 API 键来发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的会话或 API 键，无论该特定会话或 API 键的事件计数如何，计数都将增加 1。

指标下还有其他选项，但以上 4 个选项最适用于基于使用的计费。

例如，在本指南中，我们将创建一个计费计量器，用于过滤单个端点的流量，以及请求收到成功 HTTP 200 响应的位置。我们将使用事件计数指标来确保每个请求都被添加到计数中并被发送到计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将单击创建。这将创建并激活计费表。然后，当您返回计费表仪表板时，您将看到新的计费表出现。

Moesif 现在将汇总使用情况，并将这些详细信息发送给 Stripe。现在计费表已经配置好了，我们将设置一个流程让用户注册、订阅并创建一个 JWT，这样他们就可以使用我们的货币化 API。

4 -创建/register 端点

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关中的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 JWT，它将跟踪他们的使用情况。

由于我们使用 Moesif、Stripe 和 NodeJS 作为我们整体解决方案的一部分，我们需要确保每个组件都能正常工作。

端点将执行以下操作:

• 创建带条纹的客户
• 为新客户订阅条带中的 API 订阅
• 在 Moesif 中创建 CompanyID(这将是条带订阅 ID)
• 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
• 创建一个带有包含条带客户 ID 的id字段的 JWT

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在本例中，我将使用 Express 创建一个简单的 NodeJS API 来完成上述任务。

创建国家预防机制项目

首先，我们将创建一个名为 moesif-monetization 的文件夹，我们将在其中添加 API 代码。然后我们将运行npm init来转变 moesif 货币化，这样我们就可以在我们的项目中使用 npm。为此，您将在 moesif-monetary 目录中运行以下命令。

npm init 

创建 npm 项目时，您可以根据需要填写详细信息或使用默认值。

然后，您应该会在 moesif-monetary 文件夹中看到一个 package.json 文件。

现在，在您喜欢的 IDE 或文本编辑器中打开这个目录。在本教程的剩余部分，我将使用 VS 代码进行所有的编码。

添加项目依赖项

现在，我们将使用正确的依赖项编辑 package.json 文件。在 package.json 中，我们将在 dependencies 对象下添加以下条目。

 "dependencies": {
   "@stripe/stripe-js": "^1.29.0",
   "body-parser": "^1.20.0",
   "cors": "^2.8.5",
   "dotenv": "^16.0.0",
   "express": "^4.17.1",
   "express-jwt": "^5.3.1",
   "http": "0.0.1-security",
   "jsonwebtoken": "^8.5.1",
   "moesif-nodejs": "^3.1.14",
   "path": "^0.12.7",
   "stripe": "^8.219.0"
 } 

保存文件，然后导航到终端并运行:

npm install

现在，您的依赖项将被引入到项目中，并添加到 node_modules 文件夹中。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，生成和验证 jwt，以及我们将构建到应用程序中的各种其他功能。

创建。环境文件

我们不会将条带键和其他静态值硬编码到我们的应用程序中，而是将它们抽象到一个. env 文件中。我们可以使用添加到名为 dotenv 的 package.json 中的依赖项来实现这一点。

在根目录下，创建一个名为的文件。env 。在这个文件中，我们将添加几个条目，其中包含代码中使用的键和值。

STRIPE_KEY="sk_test_XXX"
STRIPE_PRICE_KEY="price_XXX"
MOESIF_APPLICATION_ID="YOUR_MOESIF_APP__ID"
TOKEN_SECRET="YOUR_TOKEN_SECRET” 

这里的值可以在以下位置找到:

STRIPE_KEY 这可以在我们之前为计费表获取条带和 Moesif 集成密钥的相同位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，其范围正好是每个功能所需的范围。

STRIPE_PRICE_KEY 这将是您之前在 Stripe 中创建的价格的价格键。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。

MOESIF_APPLICATION_ID 这可以在 Moesif 中找到，方法是转到屏幕左下方的菜单链接(会显示你的名字)并选择 API 键。

该密钥将出现在采集器应用 Id 下的页面上。

这将是用于生成和验证 jwt 的一部分的秘密。这可以是您喜欢的任何字符串，但是，出于生产目的，您最好使用 NodeJS Crypto 库来生成这个字符串。

用四个键值对填充文件后，保存文件。在本教程的剩余部分，我们不需要再接触这个文件。

创建 app.js 文件

在我们的应用程序的根目录中，我们将创建一个 app.js 文件(如果还没有创建的话)。在这个文件中，我们将添加下面的代码来添加我们的依赖项并创建一个基本的 REST 端点。

require('dotenv').config();
const express = require('express');
const path = require("path");
const bodyParser = require('body-parser');
const moesif = require('moesif-nodejs');
const Stripe = require('stripe');
// npm install express-jwt@5.3.1
const ejwt = require('express-jwt');
// npm install jsonwebtoken
const jwt = require('jsonwebtoken');

const app = express();
app.use(express.static(path.join(__dirname)));
const port = 3000;

const stripe = Stripe(process.env.STRIPE_KEY);
var jsonParser = bodyParser.json();

const moesifMiddleware = moesif({
 applicationId: process.env.MOESIF_APPLICATION_ID,
 identifyUser: function (req, _res) {
   return req.user ? req.user.id : undefined;
 },
});

app.use(moesifMiddleware);

app.post('/register', jsonParser,
 async (req, res) => {
 }
)

app.get('/test-service/',
  ejwt({ secret: process.env.TOKEN_SECRET, algorithms: ["HS256"] }),
  (_req, res) => {
    res.status(200)
    res.send('this is a response');
  }
)
app.listen(port, () => {
 console.log(`Example app listening at http://localhost:${port}`);
}) 

在上面的代码中，我们是:

• 导入一些依赖项
• 配置条带依赖关系
• 配置 Moesif 中间件，包括实现 identifyUser 函数，从 JWT 中提取id字段，以便在 Moesif 中进行用户跟踪
• 创建/寄存器端点(还没有任何逻辑)
• 创建一个简单的/测试服务端点(这将是我们的货币化 API)
• 将我们的应用程序设置为在端口 3000 上运行，并启动我们的节点应用程序

你会注意到我们有 process.env.STRIPE_KEY 、process . env . moes if _ APPLICATION _ ID和 process.env.TOKEN_SECRET 。这些值将来自。我们在最后一步中创建的 env 文件。

/测试服务端点使用 express-jwt 依赖来验证附加到请求的 jwt。如果你不熟悉 express-jwt 的工作方式，可以查看他们的 github 来找到更多信息。

实现/register 终结点

我们的下一步是实现 /register 端点。这个端点将在我们生成的 JWT、条带和 Moesif 之间创建绑定。结果将是一个生成的 JWT，它将使用情况与 Moesif 中的用户相关联，然后报告给 Stripe。

我们流程中的第一步是创建 Stripe 中的客户。我们将使用我们的 Stripe JS 依赖来做到这一点。我们将使用请求正文中的参数(电子邮件、名字、姓氏)通过使用 stripe.customers.create 函数在 Stripe 中创建客户。然后，我们将把创建的客户存储在一个自定义变量中，这样我们就可以访问 Stripe 中生成的客户 ID 。

const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   }); 

接下来，我们将为这个新用户订阅我们之前在 Stripe 中创建的 API 订阅。我们将使用stripe . subscriptions . create函数，并使用从之前的函数调用中生成的客户 ID 来订阅它们。这将返回一个订阅对象，其中包含一个我们稍后会用到的 ID。

 const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   }); 

在 Stripe 中创建了我们的客户和订阅之后，我们将使用 Moesif 中间件来创建用户，并将他们的相关详细信息添加到 Moesif 中。首先，我们将调用 Moesif 中间件的 updateCompany 函数，将条带 subscription.id 映射到 Moesif 中的 companyId 。

 var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company); 

然后，我们将对 updateUser 函数执行类似的步骤，并使用它将条带 customer.id 映射到 userId ，将条带 subscription.id 映射到 companyId ，并将我们收集的关于用户的一些其他元数据映射到 Moesif。

 var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user); 

我们的下一步是生成附加了 Stripe 客户 ID 的 JWT。为此，首先，我们将创建一个从 jsonwebtoken 依赖项调用 jwt.sign 函数的函数。这个名为 generateAccessToken 的方法将创建一个 JWT 供我们与端点一起使用。

const generateAccessToken = async (id) => {
 const token = await jwt.sign(id, process.env.TOKEN_SECRET);
 console.log(token);
 return token;
} 

在我们的/register 端点中，我们将调用我们的 generateAccessToken 函数，并传递 Stripe 客户 ID 以将其注入 JWT。我们将在将用户和公司添加到 Moesif 的最后一段代码的下面执行此操作。

const token = await generateAccessToken({ id: customer.id }); 

可选地，一旦创建了 JWT，我们将把它添加到我们的 Moesif 用户元数据中，以便于使用。不建议在生产环境中使用这种方法，但在测试您的设置时会有所帮助，如果您丢失了之前生成的 JWT，可以不生成新的。

var user = {
     userId: customer.id,
     metadata: {
       jwt: token,
     }
   };
   moesifMiddleware.updateUser(user); 

最后，我们将向调用者返回一个 200 OK 响应，在响应体中包含 JWT。

 res.status(200)
   res.send({ jwt: token }); 

完整的端到端功能如下所示:

const generateAccessToken = async (id) => {
  const token = await jwt.sign(id, process.env.TOKEN_SECRET);
  console.log(token);
  return token;
}

app.post('/register',
 jsonParser,
 async (req, res) => {
   // create Stripe customer
   const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   });

   // create Stripe subscription
   const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   });

   // create user and company in Moesif
   var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company);

   var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user);

   // generate new jwt for user
   const token = await generateAccessToken({ id: customer.id });

   // [optional] update user profile with jwt
   var user = {
     userId: customer.id,
     metadata: {
       jwt: token,
     }
   };
   moesifMiddleware.updateUser(user);

   res.status(200)
   res.send({ jwt: token });
 }
) 

有了这些，我们现在可以实际测试我们的端点，以确保每一部分都按预期工作。结果应该是一个注册用户与相关的 JWT，将记录和报告使用数据到条纹。让我们继续测试它。

5 -向/register 端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，该请求体将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 Stripe 和 Moesif 中配置我们的系统和配置文件以及生成 JWT 所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

在 Postman 中，我们将使用以下信息创建我们的请求:

请求类型: POST

端点 URL: http://localhost:3000/register

请求正文:

{
   "firstname": "Userfirstname",
   "lastname": "Userlastname",
   "email": "test@test.com"
} 

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

发送请求后，响应应该包含新注册用户可以使用的 JWT。

我们现在将检查 Stripe，以确保我们向客户注册的信息正确输入到 Stripe 中。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。

检查完成后，我们可以放心地假设我们的 /register 端点正在 Stripe 中正确地设置我们的用户帐户和订阅。

6 -使用生成的 JWT 调用您的 API

我们的下一步是实际使用我们生成的 JWT。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向 /test-service 端点发送一个请求。这是我们在上面的步骤 3 中为其设置计费计量器的端点。

在《邮差》中，我们将:

• 将/测试服务 API 端点作为请求 URL
• 选择授权选项卡
• 选择类型作为不记名令牌
• 填充令牌详细信息
• 将令牌设置为从我们的/register 调用收到的 JWT

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 send。

一旦发送，API 调用分析应该在 Moesif 着陆。

确认 Moesif 收到了请求信息

回到 Moesif，您将导航到实时事件日志屏幕。您可以通过点击新建按钮并选择实时事件日志来完成此操作。

在这个屏幕上，您应该会看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 看起来像“库斯 _XXXX ”,订阅 ID 看起来像“sub_XXXX”。

如果您单击实时事件日志屏幕上条目中显示的用户 ID，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的 + 按钮来创建一个新列，我们将在其中添加条带元数据。

您可能需要向右滚动才能看到它，这取决于您的分辨率和屏幕大小，以便看到+按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

在这一点上，我们现在已经确认我们的 API 调用正在工作，并且在 Moesif 中使用了正确的用户和公司详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过邮递员调用我们的 JWT。我们将制作一个快速的小注册表单，然后返回一个 JWT 供我们新注册的用户使用。

将您的前端文件添加到应用程序

在应用程序的根目录中，我们将添加两个文件。我们将添加一个index.html和一个索引. js 。

添加您的路由以提供静态 html 文件

在 app.js 文件中，我们将添加一个路由来服务静态 HTML 文件。在我们的 /register 端点代码下面，我们将添加另一个端点。添加以下代码:

app.get("/", function (_req, res) {
 res.sendFile(path.join(__dirname, "index.html"));
 res.sendFile(path.join(__dirname, "index.js"));
}); 

现在，当您导航到 http://localhost:3000/ 时，这段代码将加载网站(一旦我们插入了代码)。

编写前端表单和逻辑

最后，让我们添加前端 HTML 和 JavaScript 功能的代码。在 index.html 文件中，我们将添加如下所示的标记:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1" />
   <meta name="theme-color" content="#000000" />
   <meta
     name="description"
     content="Moesif Embedded Dashboard example"
   />
   <title>None React App Example</title>
 </head>
 <body>
   <noscript>You need to enable JavaScript to run this app.</noscript>
   <h1>
     Moesif Monetization Example
   </h1>
   <div id="form-input">
     email: <input id="email-input" placeholder="email" />
     first name: <input id="firstname-input" placeholder="first name" />
     last name: <input id="lastname-input" placeholder="last name" />
     <button onClick="submitRegistration()">Register</button>
   </div>
   <div id="apikey-output"></div>
   <p id="error-message"></p>
   <script src="index.js"></script>
 </body>
</html> 

这个标记将显示一个允许用户输入电子邮件、名字和姓氏的表单。它还有一个 Register 按钮，该按钮将为 submitRegistration() 调用 JavaScript 函数。该函数将在我们的 index.js JavaScript 文件中。

index.js 文件将如下所示:

async function submitRegistration() {
   const email = document.getElementById("email-input").value;
   const firstname = document.getElementById("firstname-input").value;
   const lastname = document.getElementById("lastname-input").value;
   const errorElement = document.getElementById("error-message");
   const apikey = document.getElementById("apikey-output");

   var body = { email, firstname, lastname };
   console.log(body);
   var response = await fetch('http://localhost:3000/register', {
     method: 'post',
     body: JSON.stringify(body),
     headers: {'Content-Type': 'application/json'}
   });
   var data = await response.json();
   console.log(data);

   apikey.innerHTML = data.apikey;
 } 

该函数将从表单中获取输入，将其发送到我们的 /register 端点，并在屏幕上显示返回的 JWT。

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到 http://localhost:3000/ 。然后，您将看到表单出现。

填写表单字段并提交

现在表单已经加载到屏幕上，请填写字段并单击 Register 按钮。这将获取信息，将其发送到我们的 /register 端点，并给我们生成的 JWT。

建议您使用一个不同的电子邮件，而不是之前通过 /register 端点直接创建 JWT 时使用的电子邮件。

确认 JWT 回来了

单击提交按钮后，几秒钟后，JWT 应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复从步骤 6 开始的步骤，以确认用户和公司 id 已正确填充，并且为该用户和新 JWT 返回了条带元数据。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 JWT 调用 API 后，请确认以下内容:

成条纹状

• 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
• 确认客户订购了正确的产品和价格

在默西迪斯

• 您的 API 调用被记录在 Moesif 的实时事件日志中
• 您的 API 调用在 Moesif 的用户和公司字段中分别有 Stripe 客户 ID 和订阅 ID。
• 确认在 Moesif 中填充了条带元数据

11 -检查条带的使用情况

最后，几个小时后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍然没有数据，请确保您遵循了本指南中概述的所有步骤。这包括确保来自 Moesif 的用户和公司 ID 正确地映射到 Stripe 中相应的密钥。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，Moesif 向 Stripe 报告时会有延迟。如果您的数据还没有，请稍后再回来查看。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

利用 Tyk、Stripe 和 Moesif 实现端到端 API 货币化

原文：https://www.moesif.com/blog/technical/stripe/tyk/End-To-End-API-Monetization-With-Tyk-Stripe-And-Moesif/

许多 API 开发者和公司都在努力寻找简单的方法来建立系统，以使他们的 API 货币化。有些很简单，但不可定制，有些很复杂，需要大量的工程工作才能真正运行起来。

为了让事情变得更容易，Moesif 几个月前创建了一个名为计费表的功能，它提供了巨大的可定制性，但只需要最少的代码和工程工作。

对于这个实际上可以开箱即用的例子，我们将使用 Moesif、Tyk 和 Stripe 向用户收取 API 使用费。对于这种设置，有一些假设:

• 您有一个正在运行的 Tyk 实例(已经创建了一个 API 端点)
• Tyk 中的 API 端点认证模式被设置为认证令牌
• 您有一个有效的 Stripe 帐户
• 您有一个有效的 Moesif 帐户
• 您已经在 Tyk 中安装并配置了 Moesif 插件

从外观上看，设置非常简单。我们将创建一个 /register 端点，它:

• 在条带中注册用户
• 为该用户订阅产品
• 在 Moesif 中注册用户和公司
• 使用 Tyk 生成 API 密钥

我还为它创建了一个小小的前端，它是一个简单的表单，通过调用 /register 端点来注册用户，然后为新注册的用户显示生成的 API 密钥。

想在 GitHub 中查看完整的代码？点击查看我们的知识库

1 -以条纹形式创建您的产品和价格

我们将采取的第一步是创建一个 Stripe 产品和价格。最好先完成这一步，因为当您将 Stripe 集成到 Moesif 中时，您已经有了一些 Moesif 的定价计划。然后，可以将定价计划与 Moesif 计费仪表中设置的特定计费标准相关联。

要创建产品和价格，请登录 Stripe 并进入 Stripe UI 中的产品页面。在那里，点击右上角的 +添加产品按钮。

然后，您可以添加产品的详细信息和价格。您产品的表单将有几个要填写的字段。

名称

这是您产品的名称。在下面的例子中，我们使用名称“我的 API”。

描述

此字段是可选的，但您可以在此输入产品的简要描述。在下面的例子中，我们使用了“这是一个货币化的 API”的描述。

定价模式

在 Stripe 中可以设置一些不同的定价模型。这些定价模型包括:

标准定价

如果您希望对每个 API 调用收取相同的费用，请使用此选项。

包裹

如果您按包或一组单位对 API 使用收费，请使用此选项。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。

分等级的

使用分级定价层，这可能会导致订单中的某些产品价格不同。例如，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。如今，这仅适用于经常性价格。

卷

如果您根据售出的总数量对每个单位收取相同的价格，请使用。例如，50 个单位的费用为每单位 10 美元，100 个单位的费用为每单位 7 美元。

价格

根据所选的定价模型，可以在此字段中设置价格。

计费周期

计费周期可以设置为:

• 每天地；天天地
• 一周的
• 每月
• 每 3 个月
• 每 6 个月
• 每年的
• 习俗

对于您的 Moesif 配置，我们建议将计费周期设置为每月。我们还建议，如果您正在使用 Moesif 的计费计量功能，也要检查使用量是否被计量框。

按计量使用收费

一旦选择了计量使用量复选框，将出现计量使用量的收费选项。此字段允许您选择计量使用的计算和收费方式。该字段的可用值为:

期间使用值的总和

在整个计费周期中，用户都要为其记录的使用付费

期间内最近的使用值

根据计费周期结束前记录的最后一次使用情况向用户收费

最近使用值

在每个计费周期结束时，用户需要为在整个订阅周期中记录的最后一次使用付费

期间的最大使用价值

用户按计费周期内记录的最高金额付费

Moesif 计费仪表的最佳设置是将该值设置为时段期间的使用值总和，因为 Moesif 每小时向条带报告使用情况

价格描述

这是一个可选的但推荐的字段。您可以在这里简单描述您的价格。这将使您更容易理解您在 Moesif 的计费表中选择的价格，尤其是在一种产品有多个价格的情况下。

输入产品和价格的所有详细信息后，您可以点击屏幕右上角的保存产品。

当您创建产品时，您将能够在产品屏幕上查看和编辑它们。

2 -启用 Moesif-条带集成

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。默认设置将适用于本指南，不需要进行任何更改。如果您确实需要定制它，这些设置允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

3 -创建计费计数器

一旦您在 Moesif 中激活了条带集成，您就可以开始设置您的计费表了。在 Moesif 中创建的计费表做两件事:根据特定的标准跟踪使用情况，并向计费提供者报告使用情况。Moesif 允许您相对容易地设置非常简单和非常复杂的计费表。

要创建计费计数器，在 Moesif 中，您将导航至计费计数器屏幕。您可以从右侧菜单中完成此操作。

在计费表屏幕上，点击屏幕右上角的 +添加计费表。

下一个屏幕是您可以实际输入计费表标准的地方。

该屏幕上的字段包括:

计费电表名称

这是您的新计费仪表的 Moesif 内部名称

账单提供商

在此下拉列表中，您可以选择要将您的使用指标发送给哪个计费提供商。

产品(仅条纹)

在这里，您可以选择您在 Stripe 中设置的产品，您希望您的使用指标与该产品相关联。

价格(仅条纹)

计费计数器的计费提供者设置中的最后一个字段，您可以在这里选择要将您的使用指标绑定到哪个价格。

过滤器

在过滤器配置下，您将配置您的计费标准，以仅包括符合特定标准的请求。

指标

在这里，您可以选择希望计费的指标。可用选项包括:

事件计数

这将增加符合过滤标准中列出的标准的每个事件的使用量。

唯一用户

每当唯一用户发送符合过滤标准的请求时，这将增加使用量。对于每个唯一用户，无论该用户的事件计数是多少，计数都将增加 1。

独特的公司

每当一家独特的公司发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的公司，无论该公司的事件计数如何，计数都将增加 1。

唯一会话/API 密钥

每当使用唯一的会话或 API 键来发送符合过滤标准的请求时，这将增加使用量。对于每个唯一的会话或 API 键，无论该特定会话或 API 键的事件计数如何，计数都将增加 1。

指标下还有其他选项，但以上 4 个选项最适用于基于使用的计费。

例如，在本指南中，我们将创建一个计费计量器，它将过滤单个端点的流量，以及请求接收到成功的 HTTP 200 响应的位置。我们将使用事件计数指标来确保每个请求都被添加到计数中并发送给计费提供者。

在 Moesif 中，计费表的配置如下所示。

然后，我们将点击屏幕右上角的创建按钮。这将创建并激活计费计数器。然后，当您返回计费表仪表板时，您将看到新的计费表出现。

Moesif 现在将汇总使用情况，并将这些详细信息发送给 Stripe。现在计费表已经配置好了，我们将建立一个流程让用户注册、订阅并发布一个 API 密匙，这样他们就可以使用我们的货币化 API。

4 -创建/注册端点

我们将构建自己的流程，而不是使用预先构建的入职流程，例如通过 API 网关中的开发人员门户。我们将创建一个名为 /register 的端点，然后我们可以用它来装载想要使用 API 的用户。结果将是用户收到一个他们可以使用的 API 密钥，该密钥将跟踪他们的使用情况。

因为我们使用 Moesif、Stripe 和 Tyk 作为我们整体解决方案的一部分，所以我们需要确保每个组件都能正常工作。

端点将执行以下操作:

• 在条带中创建用户
• 为新用户订阅条带中的 API 订阅
• 在 Moesif 中创建 CompanyID(这将是条带订阅 ID)
• 在 Moesif 中创建 UserID(这将是 Stripe 客户 ID)
• 创建 API 密钥(使用条带客户 ID 作为令牌别名)

如果您在 Moesif 和其他系统中已经有了您想要使用的用户和公司标识符，而不是使用 Stripe 的客户和订阅作为您的 id，您可以在 Moesif 中的 Stripe 配置设置下这样做。

在本例中，我将使用 Express 创建一个简单的 NodeJS API 来完成上述任务。

创建国家预防机制项目

首先，我们将创建一个名为 moesif-monetization 的文件夹，我们将在其中添加 API 代码。然后我们将运行 npm init 来转变 moesif 货币化，这样我们就可以在我们的项目中使用 npm。为此，您将在 moesif-monetization 目录中运行以下命令。

npm init

创建 npm 项目时，您可以根据需要填写详细信息或使用默认值。

然后你应该会在你的moesif-monetary文件夹中看到一个 package.json 文件。

现在，在您喜欢的 IDE 或文本编辑器中打开这个目录。在本教程的剩余部分，我将使用 VS 代码进行所有的编码。

添加项目依赖项

我们现在将使用正确的依赖项编辑我们的 package.json 文件。在 package.json 中，我们将在依赖关系对象下添加以下条目。

 "dependencies": {
   "@stripe/stripe-js": "^1.29.0",
   "body-parser": "^1.20.0",
   "dotenv": "^16.0.0",
   "express": "^4.17.1",
   "http": "0.0.1-security",
   "moesif-nodejs": "^3.1.14",
   "node-fetch": "^2.6.5",
   "path": "^0.12.7",
   "stripe": "^8.219.0"
 } 

保存文件，然后导航到终端并运行:

npm install

现在，您的依赖项将被引入到项目中，并添加到 node_modules 文件夹中。这些依赖项将帮助我们调用 REST 端点，连接到 Stripe 和 Moesif，以及我们将内置到应用程序中的各种其他功能。

创建。环境文件

我们不会将条带键和其他静态值硬编码到我们的应用程序中，而是将它们抽象到一个. env 文件中。我们可以使用添加到名为 dotenv 的 package.json 中的依赖项来实现这一点。

在根目录下，创建一个名为的文件。env 。在这个文件中，我们将添加几个条目，其中包含代码中使用的键和值。

STRIPE_KEY="sk_test_XXX"
STRIPE_PRICE_KEY="price_XXX"
MOESIF_APPLICATION_ID="YOUR_MOESIF_APP_ID"
TYK_AUTH_KEY="TYK_AUTH_ID"
TYK_API_ID="TYK_API_ID"
TYK_API_NAME="API_NAME"
TYK_URL="http://TYK_URL:3000" 

这里的值可以在以下位置找到:

STRIPE_KEY

这可以在我们之前为计费表获取 Stripe 和 Moesif 集成密钥的相同位置找到。实际上，您可以为两者使用同一个键，或者创建一个受限键，仅包含每个函数所需的范围。

STRIPE_PRICE_KEY

这将是您之前在 Stripe 中创建的价格的价格键。这可以通过转到条带中的产品并从 API ID 列中获取值来找到。

MOESIF_APPLICATION_ID

这可以在 Moesif 中找到，方法是转到屏幕左下方的菜单链接(将显示您的姓名)并选择 API 键。

然后，密钥将出现在出现在收集器应用 Id 下的页面上。

TYK_AUTH_KEY

这个键是向 Tyk Dashboard API 发送请求所需的键。这可以在 Tyk 中通过导航到用户页面并点击一个用户的条目(可能是你自己的)来找到。

单击用户后，您将能够看到用户的 Tyk Dashboard API 访问凭证。这是您将插入到配置中的密钥。

TYK_API_ID

可以通过转到API并复制端点的 ID 来找到端点的 API ID。

TYK_API_NAME

端点的 API 名称可以在与 API ID 相同的地方找到。

TYK_URL

这将是 Tyk 仪表板 API 的 URL。通常，这将在端口 3000 上托管，但如果您有自定义配置，它可能会有所不同。

一旦用七个键值对填充了文件，保存文件。在本教程的剩余部分，我们不需要再接触这个文件。

创建 app.js 文件

在我们的应用程序的根目录中，我们将创建一个 app.js 文件(如果还没有创建的话)。在这个文件中，我们将添加以下代码，这些代码添加了我们的依赖项并创建了一个基础 REST 端点。

require('dotenv').config();
const express = require('express');
const path = require("path");
const bodyParser = require('body-parser');
const moesif = require('moesif-nodejs');
const Stripe = require('stripe');
// npm i --save node-fetch@2.6.5
const fetch = require('node-fetch');

const app = express();

const port = 5000;
const stripe = Stripe(process.env.STRIPE_KEY);

var jsonParser = bodyParser.json();

const moesifMiddleware = moesif({
 applicationId: process.env.MOESIF_APPLICATION_ID
});

app.use(moesifMiddleware);

app.post('/register', jsonParser,
 async (req, res) => {
 }
)
app.listen(port, () => {
 console.log(`Example app listening at http://localhost:${port}`);
}) 

在上面的代码中，我们是:

• 导入一些依赖项
• 配置条带依赖关系
• 配置 Moesif 中间件
• 创建/注册端点
• 设置我们的应用程序在端口 5000 上运行，并启动我们的节点应用程序

你会注意到我们有 process.env.STRIPE_KEY 和process . env . moes if _ APPLICATION _ ID。这些值将来自。我们在最后一步中创建的 env 文件。

实现/register 终结点

我们的下一步是实现 /register 端点。这个端点将在 Tyk、Stripe 和 Moesif 之间创建我们的绑定。结果将是 Tyk 生成的 API 密钥，该密钥将使用情况与 Moesif 中的用户相关联，然后将报告给 Stripe。

我们流程中的第一步是创建 Stripe 中的客户。我们将使用我们的 Stripe JS 依赖来做到这一点。我们将使用请求正文中的参数(电子邮件、名字、姓氏)通过使用 stripe.customers.create 函数在 Stripe 中创建客户。然后，我们将把创建的客户存储在一个自定义变量中，这样我们就可以访问 Stripe 中生成的客户 ID 。

const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   }); 

接下来，我们将为这个新用户订阅我们之前在 Stripe 中创建的 API 订阅。我们将使用stripe . subscriptions . create函数，并使用从之前的函数调用中生成的客户 ID 来订阅它们。这将返回一个订阅对象，其中包含一个我们稍后会用到的 ID。

 const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   }); 

一旦在 Stripe 中创建了用户和订阅，我们现在将使用 Moesif 中间件来创建用户，并将他们的相关详细信息添加到 Moesif 中。首先，我们将调用 Moesif 中间件的 updateCompany 函数，将条带 subscription.id 映射到 Moesif 中的 companyId 。

 var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company); 

然后，我们将对 updateUser 函数执行类似的步骤，并使用它将条带 customer.id 映射到 userId ，将条带 subscription.id 映射到 companyId ，并将我们收集的关于用户的一些其他元数据映射到 Moesif。

 var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user); 

在这一点上，我们现在已经将所有的用户详细信息插入到必要的平台中。我们的下一步是为这个用户生成一个 API 密钥。为此，我们将使用 /api/keys 端点调用 Tyk Dashboard API。这将在响应中为用户返回一个 API 密钥。我们通过 data.key_id 访问那个 API 密匙。

var body = {
     alias: customer.id,
     last_check: 0,
     allowance: 1000,
     rate: 1000,
     per: 60,
     expires: 0,
     quota_max: 10000,
     quota_renews: 1424543479,
     quota_remaining: 10000,
     quota_renewal_rate: 2520000,
     access_rights: {
       [process.env.TYK_API_ID]: {
         api_id: process.env.TYK_API_ID,
         api_name: process.env.TYK_API_NAME,
         versions: [
           "Default"
         ]
       }
     }
   }
   var response = await fetch(`${process.env.TYK_URL}/api/keys`, {
     method: 'post',
     body: JSON.stringify(body),
     headers: {
       'Content-Type': 'application/json',
       "Authorization": process.env.TYK_AUTH_KEY
     }
   });
   console.log(response);
   var data = await response.json();
   console.log("Tyk create API key");
   console.log(data);
   var tykAPIKey = data.key_id; 

您将在请求体中看到，我们正在创建一个相当大的 JSON 对象。几个重要的字段是:

• 别名 -这将是我们的 Stripe 客户 ID，它将映射到 Moesif 中的用户 ID
• 访问权限
  • api_id -这将从中提取 API ID 。env 文件
  • API _ Name——这将从中拉出 API 名称。env 文件。

其余的字段可以根据需要进行定制。

可选地，我们也将用户的 API 键添加到 Moesif 中的元数据中。出于测试的目的，如果您丢失了密钥，并且不想回到 Tyk 中检索它，这使得获取密钥变得很容易。我们将在 Moesif 中间件中再次使用 updateUser 函数来完成这项工作，在元数据对象中提供生成的 API 键。

 var user = {
     userId: customer.id,
     metadata: {
       apikey: tykAPIKey,
     }
   };
   moesifMiddleware.updateUser(user); 

最后，我们将向调用者返回一个 200 OK 响应，在响应体中包含 API 键。

 res.status(200)
   res.send({ apikey: tykAPIKey }); 

完整的端到端功能如下所示:

app.post('/register', jsonParser,
 async (req, res) => {
   // create Stripe customer
   const customer = await stripe.customers.create({
     email: req.body.email,
     name: `${req.body.firstname}  ${req.body.lastname}`,
     description: 'Customer created through /register endpoint',
   });

   // create Stripe subscription
   const subscription = await stripe.subscriptions.create({
     customer: customer.id,
     items: [
       { price: process.env.STRIPE_PRICE_KEY },
     ],
   });

   // create user and company in Moesif
   var company = { companyId: subscription.id };
   moesifMiddleware.updateCompany(company);

   var user = {
     userId: customer.id,
     companyId: subscription.id,
     metadata: {
       email: req.body.email,
       firstName: req.body.firstname,
       lastName: req.body.lastname,
     }
   };
   moesifMiddleware.updateUser(user);

   // send back a new API key for use
   var body = {
     alias: customer.id,
     last_check: 0,
     allowance: 1000,
     rate: 1000,
     per: 60,
     expires: 0,
     quota_max: 10000,
     quota_renews: 1424543479,
     quota_remaining: 10000,
     quota_renewal_rate: 2520000,
     access_rights: {
       [process.env.TYK_API_ID]: {
         api_id: process.env.TYK_API_ID,
         api_name: process.env.TYK_API_NAME,
         versions: [
           "Default"
         ]
       }
     }
   }
   var response = await fetch(`${process.env.TYK_URL}/api/keys`, {
     method: 'post',
     body: JSON.stringify(body),
     headers: {
       'Content-Type': 'application/json',
       "Authorization": process.env.TYK_AUTH_KEY
     }
   });
   var data = await response.json();
   var tykAPIKey = data.key_id;

   var user = {
     userId: customer.id,
     metadata: {
       apikey: tykAPIKey,
     }
   };
   moesifMiddleware.updateUser(user);

   res.status(200)
   res.send({ apikey: tykAPIKey });
 }
) 

有了这些，我们现在可以实际测试我们的端点，以确保每一部分都按预期工作。结果应该是拥有 API 密钥的注册用户将记录和报告使用数据到 Stripe。让我们继续测试它。

5 -向/寄存器端点发送测试请求

一旦您的 /register 端点被编码和部署，就该测试它了。现在我们将简单地使用 Postman 来发送请求。我们的请求将包含一个 JSON 请求体，它将包含:

• 西方人名的第一个字
• 姓
• 电子邮件

当然，这是我们在 Tyk、Stripe 和 Moesif 中正确配置系统和配置文件所需的最少信息。您可以根据特定用例的需要轻松添加更多字段。

在 Postman 中，我们将使用以下信息创建我们的请求:

• 请求类型:发布

• 端点 URL:http://localhost:5000/register

• 请求正文:

  {  "firstname":  "Userfirstname",  "lastname":  "Userlastname",  "email":  "test@test.com"  } 
  

一旦所有东西都插入到 Postman 中，它应该看起来像下面这样:

一旦发送了请求，响应应该包含新注册用户可以使用的 API 键。

我们现在将检查 Tyk 和 Stripe，以确保我们注册的信息正确输入到每个目标系统中。我们首先要检查的是条纹。

重新登录 Stripe，您将导航至客户屏幕。您应该会在列表中看到新创建的用户。

单击列表中新添加的客户。在下一个屏幕上，您应该看到该客户也订阅了您的 API 订阅。

一旦在 Stripe 中确认了这两个条目，您就可以转到 Tyk，以确保在那里也正确地设置了用户。

使用 Tyk 仪表板，导航至键屏幕。这里您应该看到一个键的条目，其中的别名等于用户的条带客户 ID。

完成这些检查后，我们可以放心地假设我们的 /register 端点正在正确地设置我们的用户在 Tyk 和 Stripe 中的帐户和订阅。

6 -使用生成的 API 密钥调用您的 API

我们的下一步是实际使用我们生成的 API 密钥。然后，我们将确认所有正确的信息都已添加到 Moesif 中。我们正在确认的数据包括:

• 条带客户 ID 映射到 Moesif 用户 ID
• 条带订阅 ID 映射到 Moesif 公司 ID
• Moesif 包含用户配置文件中的条带元数据

使用邮递员发送请求

接下来，让我们使用 Postman 或另一个平台向 /my_api 端点发送请求。这是我们在上面的步骤 3 中为其设置计费计量的端点。

在《邮差》中，我们将:

• 将 /my_api API 端点作为请求 URL
• 选择授权标签
• 选择类型作为 API 键
• 填充 API 键详细信息
• 将键设置为“授权”
• 将值设置为生成的 API 密钥
• 将添加到字段值设置为“标题”

下面是 Postman 中填充请求配置的一个示例。

要将请求发送到我们的端点，请单击 Send 。

一旦发送，您的请求应该通过 Tyk 代理，API 调用分析应该在 Moesif 着陆。

确认 Moesif 收到了请求信息

回到 Moesif，您将导航到 Events 屏幕，在这里您将看到您刚刚发送的请求。您应该会看到该条目包含一个用户 ID 和一个公司 ID，其中填充了 Stripe 用户和订阅 ID。条目应该如下所示:

客户 ID 看起来像“库斯 _XXXX ”,订阅 ID 看起来像“sub_XXXX”。

如果您点击显示在现场活动日志屏幕条目中的用户 ID ，您将进入用户资料页面。在此页面上，我们将确认条带元数据是否存在。我们需要在配置文件中添加一个新列来显示条带数据。为此，在个人资料页面，点击 …更多操作按钮，然后点击自定义个人资料的布局。

然后，我们将为条带元数据添加一个新列。您将单击屏幕最右侧的+按钮来创建一个新列，我们将在其中添加条带元数据。

根据您的分辨率和屏幕大小，您可能需要向右滚动才能看到 + 按钮。

然后，您将深入到元数据>条带>客户>创建，并在新行中使用该字段。我还改变了一个更适合的列图像。您可以通过点击图片并选择最合适的图片进行定制。

您还可以添加其他字段，但是目前仅这一个字段就足以告诉我们 Moesif 正在正确地从 Stripe 接收数据。

如果您没有看到条带元数据条目作为可用字段，请等待几分钟。如果几分钟后条带元数据不存在，请确保 Moesif 中的条带配置是正确的。在确认或编辑它之后，尝试创建一个新用户并再次发送请求以确认集成正在工作。

现在，我们已经确认了通过 Tyk 代理的 API 调用正在工作，并且在 Moesif 中标记了正确的用户和公司详细信息。我们还确认了 Stripe 正在将数据发送回 Moesif，这些数据被正确地映射到相应的用户配置文件，这是通过 Moesif 中的 Stripe 元数据确认的。

7 -创建前端

接下来，我们想添加一个简单的小前端，这样我们就不需要通过 Postman 调用我们的 API 键了。我们将制作一个快速的注册表单，然后返回一个 API 密钥供新注册的用户使用。

将您的前端文件添加到应用程序

在应用程序的根目录中，我们将添加两个文件。我们将添加一个index.html和一个索引. js 。

添加您的路由以提供静态 html 文件

在 app.js 文件中，我们将添加一个路由来服务静态 HTML 文件。在我们的 /register 端点代码下面，我们将添加另一个端点。添加以下代码:

app.get("/", function (_req, res) {
 res.sendFile(path.join(__dirname, "index.html"));
 res.sendFile(path.join(__dirname, "index.js"));
}); 

现在，当您导航到 http://localhost:5000/ 时，这段代码将加载网站(一旦我们插入了代码)。

编写前端表单和逻辑

最后，让我们添加前端 HTML 和 JavaScript 功能的代码。在index.html文件中，我们将添加如下所示的标记:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1" />
   <meta name="theme-color" content="#000000" />
   <meta
     name="description"
     content="Moesif Embedded Dashboard example"
   />
   <title>None React App Example</title>
 </head>
 <body>
   <noscript>You need to enable JavaScript to run this app.</noscript>
   <h1>
     Moesif Monetization Example
   </h1>
   <div id="form-input">
     email: <input id="email-input" placeholder="email" />
     first name: <input id="firstname-input" placeholder="first name" />
     last name: <input id="lastname-input" placeholder="last name" />
     <button onClick="submitRegistration()">Register</button>
   </div>
   <div id="apikey-output"></div>
   <p id="error-message"></p>
   <script src="index.js"></script>
 </body>
</html> 

这个标记将显示一个表单，允许用户输入电子邮件、名字和姓氏。它还有一个 Register 按钮，该按钮将为 submitRegistration() 调用 JavaScript 函数。该函数将在我们的 index.js JavaScript 文件中。

index.js 文件将如下所示:

async function submitRegistration() {
   const email = document.getElementById("email-input").value;
   const firstname = document.getElementById("firstname-input").value;
   const lastname = document.getElementById("lastname-input").value;
   const errorElement = document.getElementById("error-message");
   const apikey = document.getElementById("apikey-output");

   var body = { email, firstname, lastname };
   var response = await fetch('http://localhost:5000/register', {
     method: 'post',
     body: JSON.stringify(body),
     headers: {'Content-Type': 'application/json'}
   });
   var data = await response.json();
   apikey.innerHTML = data.apikey;
 } 

该函数将从表单中获取输入，将其发送到我们的 /register 端点，并在屏幕上显示返回的 API 键。

8 -测试前端

要测试前端，保存您的代码更改并重启服务器。然后，在浏览器中，导航到 。然后，您将看到表单出现。

填写表单字段并提交

现在表单已经加载到屏幕上，填写字段并点击注册按钮。这将获取信息，将其发送到我们的/注册端点，并给我们生成的 API 密钥。

建议您使用不同的电子邮件，而不是之前直接通过 /register 端点创建 API 密钥时使用的电子邮件。

确认 API 密钥已返回

单击 submit 按钮后，几秒钟后，API 键应该会返回到 UI。

9 -向您的货币化 API 发送请求

我们将再次希望确保所有东西都与我们的 UI 一起工作，直到我们的后端系统。为此，只需重复步骤 6 中的步骤，确认用户和公司 id 已正确填充，并且为该用户和新的 API 密钥返回了条带元数据。

10 -确认所有部件工作正常

尽管这是可选的，但这一步可能有助于解决我们之前步骤中可能出现的任何问题。这里有几件事需要检查，以确保一切正常。通过 UI 创建新用户并使用生成的 API 键调用 API 后，请确认以下内容:

• 成条纹状
  • 确认已经使用您在 UI 中输入的详细信息在 Stripe 中创建了一个客户
  • 确认客户订购了正确的产品和价格
• 在 Tyk
  • API 密钥是在 Tyk 中创建的
  • 密钥别名字段匹配来自条带(以 cus_XXXX 开始)的客户 ID
• 在默西迪斯
  • 您的 API 调用被记录在 Moesif 的实时事件日志中
  • 您的 API 调用在 Moesif 的用户和公司字段中分别有 Stripe 客户 ID 和订阅 ID。
  • 确认在 Moesif 中填充了条带元数据

11 -检查条带的使用情况

最后，几个小时后，最好进入 Stripe，确认使用情况是否被添加到用户订阅中。确保您已经发送了几个请求，以确保您有一些应该发送到条带的数据。

从 Moesif 到条带化可能需要几个小时。如果几个小时后 Moesif 中仍然没有数据，请确保您遵循了本指南中概述的所有步骤。这包括确保来自 Moesif 的用户和公司 ID 正确地映射到 Stripe 中相应的密钥。

要检查使用情况，在 Stripe 中，您需要导航到客户屏幕，并选择与您进行 API 调用的客户。一旦选中，您应该会看到您通过 /register 端点注册的用户的一些活动订阅。我们之前创建的那个叫做我的 API 。单击订阅条目。

在下一个屏幕上，点击价格条目旁边的查看用法。

现在应该会弹出一个模型，向您显示已经从 Moesif 中剥离的 API 的用法。

请记住，Moesif 向 Stripe 报告时会有延迟。如果您的数据还没有，请稍后再回来查看。

包扎

货币化一直是一个难以逾越的障碍。许多定制解决方案提供了灵活性，但工程和支持成本非常高。有了 Moesif，API 货币化就有可能在极短的时间内实现。正如本文所展示的，通过一点点配置和最少的代码，我们可以在最短的时间内创建一个生产就绪的后付费货币化方案。

在 API 产品公司中在家工作的四个最重要的问题

原文：https://www.moesif.com/blog/business/tools/Four-Of-The-Most-Important-Issues-When-Working-From-Home-In-An-API-Product-Company/

“当你在家工作时，你应该试着系统地、有条理地去做，”在家工作的老手约翰·贝内特说。“这很像在家做生意，我就是这么做的”。

约翰可能对此略知一二，因为他在新罕布什尔州南部的家中工作了 15 年。他的公司约翰·贝内特战略营销，客户从大牌公司到初创公司，包括 Heroku、戴尔、Savvius、Yubico 和 Proofpoint 等。

在家工作最重要的考虑因素可以分为 4 个简单的要素:

• 物理空间
• 时间管理
• 技术
• 对齐

物理空间

把办公室留在办公室，把家留在家里

有一个专用的工作空间是个好主意。然后是你家的其他地方。单独的办公室是理想的，但即使你没有，也要分配一个你可以在一天结束时离开的空间。关上门；你的工作结束了。拔掉你的工作脑。

这很重要，原因有二:

• 你工作时不太可能被打扰或打断。你不希望孩子们在电话会议上走进房间，或者被你的妻子打断，她想知道如何为她五年级的班级设置 Zoom 分组讨论室。
• 为了你自己的理智，工作不要占据整个地方也很重要。你不会想让自己感觉从未离开过工作场所:话题不断出现，设备不断报时，项目计划摆在早餐桌上。

你的家庭工作空间类似于大学时代的音乐教室。你希望有一些分离，这样如果你在演奏一种安静的乐器，比如录音机或大键琴，你就不会想听到隔壁房间里传出的电吉他声。你需要一些分离。所以当你选择你的位置时，你能做到多孤立呢？是一个可以关上门的房间，还是一个走廊然后一扇门？选择一个你能真正隔绝声音的地方。

时间

把你的一天分成可管理的几部分。你知道什么时候你最有效率，所以把你的一天安排在那个时候。试着遵守时间表，尤其是在一天开始和结束的时候。

因为你不在办公室，也不与其他人交往——例如，你不必去三号楼从另一个项目组的人那里得到答案——你可能会久坐不动。所以，养成散步的习惯是个好主意，假设你能在隔离期间这样做。

“当我在处理一些特别困难的事情时，比如为客户发送复杂的信息，我会快速散步 15 分钟来理清思绪。这让世界变得不同，”约翰说。

远程贸易的工具

我们可能在技术领域工作，但在家工作时，我们也是技术的大消费者。如果没有可靠的安全性、备份、分散注意力、协作和项目管理软件，我们就无法完成远程工作。

安全性

你在工作，使用电脑、平板电脑和手机。您需要确保您的设备是安全的，这样您才能高效工作。他们的所有操作系统都应该是最新的，并且应该运行安全/防病毒软件。我们很喜欢 Bitdefender 和 Malwarebytes ，但是还有很多其他很棒的选项。

Security Vendors

支持

远离 IT 管理员的神奇力量时，您最不想做的事情就是丢掉工作。无论是将 Word 中的最新产品规格上传到 Google Drive，将新代码分支推送到 GitHub 的资源库，还是将那些 Illustrator 文件保存到 Dropbox，都要一直备份。并将备份设置为自动运行。

有许多成熟的供应商在将工作备份到云方面做得很好。明显的候选人包括使用他们的 Sync &备份应用、 Carbonite 、 Box 和 Dropbox 的 Google Drive。

Cloud Backup Vendors

分散注意力最小化

如果你担心被网站、游戏甚至应用程序分散注意力，那么就有一些拦截器可以限制任何东西，从网站到整个互联网，或者从单个桌面应用程序到你的整个电脑。大部分都是免费的，或者是负担得起的，你可以做一些事情，比如说，从早上 8:00 到中午 12:30 到下午 6:00 封锁 Facebook.com。看看冷火鸡、自由或聚焦了解更多关于如何恢复生产力的细节。

Anti-Distraction Vendors

合作

在办公室之外，软件协作工具已经取代了饮水机旁的聊天、纸张、活动挂图、便利贴和白板。作为在家工作的员工，我们将在 Slack 和 G Suite 以及 Zoom 和 UberConferences 中度过我们的时间。不要低估面对面看到某人并在视频通话开始时询问他们怎么样的力量。当其他人知道你是谁，并能把你的名字与面孔对应起来时，他们更有可能与你分享信息。

Collaboration Vendors

有了空闲的即时性，和同事聊天就成了快速的 DM away。记得表明你什么时候有空，这样合作者就不会在等待回应时失去理智。如果他们不在，使用谷歌日历来预定听众。最终，视频聊天和聊天消息都是短暂的信息源。这就给我们带来了技术难题的最后一块……

项目管理

如果你作为团队的一员远程工作，那么你将需要跟踪任务并与他人协调正在发生的事情。项目管理行业的领导者是阿萨纳和特雷罗。对于处理多个项目，我们最喜欢的项目管理工具是 monday.com 的。所有这些管理工具使得分配任务、查看整个团队正在做什么以及在团队内部就项目和任务进行交流变得容易。

Project Management Vendors

对齐

当你早上没有和其他十个人在会议室时，你很难知道公司的状况。这不仅仅是项目管理的问题，而是与业务指标、目标和 KPI 保持同步。

公司在哪里，它需要去哪里？我们做得怎么样，我们需要做出什么反应？有哪些机会？下一步是什么？

如果你试图在你的公司灌输一种数据驱动的文化，那么让每个人都与相同的产品 KPI 和业务目标保持一致是很重要的。在一个分散的环境中，对于不涉及业务方面的团队来说，例如工程，特别容易与更大范围内发生的事情失去联系。

API 产品公司已经成功地使用 Moesif.com 的仪表板功能来跟踪他们的业务指标。例如，我们的一个金融科技客户定期在整个公司共享一个仪表板，其中包含每日活跃用户(DAU)、集成漏斗、HTTP 状态请求、KYC 产品使用、最活跃用户、最近的 API 错误等图表。他们的仪表板显示如下。

Moesif Dashboarding To Track And Share Business Metrics

由于我们的仪表板可以安全共享，因此重要信息可以轻松地在整个组织中传播，告知所有利益相关方客户流失、产品战略、客户使用情况和许多其他重要业务指标的状态。

结论

由于我们中的许多人都在原地躲避，面临长期的自我隔离，远程工作需要尽可能简单。通过控制你工作的时间和地点，通过使用最合适的行业工具，你可以走很长一段路，让你的工作经历变得愉快。

作为一个独自坐在办公室里工作的人，很容易想到“好吧，这里需要那块。另一件作品发行了。那些顾客做得很好。那些其他的有搅动的危险。”在方便的仪表盘中了解企业的当前状态比以往任何时候都更加重要。您的公司仪表板已经成为一种导航地图，将帮助您的企业到达它想去的地方。

免费 API 分析，用于新冠肺炎应对工作

原文：https://www.moesif.com/blog/announcements/covid-19/Free-API-Analytics-For-COVID-19-Response-Efforts/

如果你正在为新冠肺炎的救援工作开发一个 API 产品，那么我们将随时为你提供帮助。无论您是初创企业、企业、非政府组织还是政府机构，我们都将免费提供我们的 API 分析平台三个月。

dev 社区正在积极利用其技能来创建以疫情为重点的工具、资源和研究。Moesif 致力于将这些有影响力的想法变成现实。

新冠肺炎计划的免费 Moesif 增长计划

此类项目包括促进在家工作时的沟通，或开发一个新的电子商务平台，以帮助因客流量减少而遭受损失的当地企业。

如果您正在构建或组织一些有助于疫情的东西，并且正在利用 API，那么 Moesif 可以帮助您缩短发布时间，在特定用户出现问题时获得警报，并且只需单击一下即可在任何仪表板上创建实时监视器。

填写表格以利用我们免费成长计划的全套产品功能。

对创业公司和大型企业的支持

随着市场的低迷，我们在经济衰退期间的 SaaS 平台上推出了一本电子书。利用许多开发者平台和 API 已经内置的技巧和策略，在这个不确定的时代变得更有弹性。

从 GraphQL 模式生成 REST APIs，教程

原文：https://www.moesif.com/blog/technical/graphql/Generating-Rest-APIs-from-GraphQl-Schemas/

关于技术选择的争论是一件大事，RESTFul 和 GraphQL 的争论就是一个例子。但有时也有方法把不同的方式结合起来。 Sofa 就是试图将 REST 和 GraphQL 结合起来的其中一家。

为什么

REST 和 T2【graph QL 是构建基于 HTTP 的 API 的不同方法，但是对于哪种方法最适合某个问题，不同的开发者有不同的看法。

我不知道其中一种是否优于另一种，但是如果我们只为客户提供一种类型的 API，有时它会成为一个障碍。

Sofa 允许我们从 GraphQL 模式自动生成 REST API，这样我们就不必自己实现两个 API。

什么

Sofa 是一个 Node.js 包，它采用一个 GraphQL 模式定义，并从中创建一个 Express 中间件。这个中间件提供了 REST-API 端点。

怎么

让我们在 Sofa、GraphQL 和 Express 的帮助下建立一个小的 API 服务器，然后尝试从它创建和读取消息。

履行

首先，我们使用 npm 初始化一个新的 Node.js 项目并安装软件包。

$ mkdir api-server
$ cd api-server
$ npm init
$ npm i express express-graphql graphql-tools sofa-api 

接下来，我们在一个新的schema.gql文件中创建一个 GraphQl 模式。

type  Message  {  id:  ID!  text:  String!  }  type  Query  {  message(id:  ID!):  Message  messages:  [Message!]  }  type  Mutation  {  writeMessage(title:  String!):  Message  }  schema  {  query:  Query  mutation:  Mutation  } 

我们只有一个Message类型和相应的查询和突变类型。

我们还需要为每个查询和变异定义解析器。让我们为此创建一个新的resolver.js文件。

const messages = [];

module.exports = {
  Query: {
    message: (_, { id }) => messages[id],
    messages: () => messages
  },
  Mutation: {
    writeMessage: (_, { text }) => {
      const message = { id: messages.length, text };
      messages.push(message);
      return message;
    }
  }
}; 

我们使用message数组作为数据存储，使用它的length为我们的消息生成 id。这就足够了，因为我们没有可能搞乱 IDs 的删除突变。

现在，我们用 GraphQL 和 Sofa 连接模式。我们在一个新的index.js文件中这样做。

const fs = require("fs");
const { makeExecutableSchema } = require("graphql-tools");
const express = require("express");
const graphql = require("express-graphql");
const sofa = require("sofa-api").default;

const typeDefs = fs.readFileSync("./typeDefs.gql", "utf8");
const resolvers = require("./resolvers");

const schema = makeExecutableSchema({ typeDefs, resolvers });

const server = express();

server.use("/graphql", graphql({ schema, graphiql: true }));
server.use("/rest", sofa({ schema }));

server.listen("9999"); 

让我们看一下这份文件的关键部分。

首先，我们从磁盘读取 GraphQL 类型定义，并需要相应的解析器。

然后我们使用graphql-tools从解析器和类型定义中创建一个模式。

之后，我们创建一个 Express 服务器，并为两个端点/graphql和/rest设置中间件。

我们还启用了默认的 GraphQL UIgraphiql，这样我们就可以在浏览器中测试 graph QL 端点。

最后，我们在端口9999上启动一个服务器。

使用

让我们启动服务器。

$ node . 

并在浏览器中打开 Graphiql:http://localhost:9999/graphql

在左边的文本区域，我们现在可以输入查询和突变。让我们从一个突变开始，因为我们的商店目前是空的。

mutation  {  writeMessage(text:  "my messsage")  {  id  text  }  } 

我们可以用 Ctrl+Enter 将消息发送到服务器。

答案应该如下:

{  "data":  {  "writeMessage":  {  "id":  "0",  "text":  "my messsage"  }  }  } 

让我们用不同的文本再做一次，看看 id 是否像预期的那样增加了:

mutation  {  writeMessage(text:  "another message")  {  id  text  }  } 

返回的 JSON 应该反映新的text和id。

让我们试试这些查询。

首先加载所有邮件:

query  {  messages  {  id  text  }  } 

这将为 JSON 提供我们所有消息的列表。

只缺少一个查询:message

这一次我们需要提供想要加载的消息的 ID。

query  {  message(id:  1)  {  id  text  }  } 

我们现在知道 GraphQL API 按预期工作，让我们试试 REST 版本。

变异通过 POST 请求工作，这可以用 cURL 来完成。

$ curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"text":"REST message"}' \
  http://localhost:9999/rest/add-message 

这些查询处理 GET 请求，因此我们可以在浏览器中使用一个简单的链接。

列出所有邮件:

http://localhost:9999/rest/messages

收到一条消息:

http://localhost:9999/rest/message/2

结论

沙发当然是一个有趣的解决方案，可以解决休息的问题，休息的问题，休息的问题，休息的问题，T2 的问题，图表的问题。它利用了这样一个事实，即 GraphQL 需要一个标准化的模式和解析器来将许多概念映射回 REST APIs。

这允许 API 创建者为他们的客户提供不同的 API 类型，而只需要维护一个代码库。

Python 和 GraphQL 入门——第 2 部分

原文：https://www.moesif.com/blog/technical/graphql/Getting-Started-with-GraphQL-Part2/

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

在本教程中，我们将讨论认证。Django 有一个内置的用户概念，所以我们需要通过向服务器发送数据来创建用户。

我们将创建一个新文件夹users和新文件schema.py

from django.contrib.auth import get_user_model
import graphene
from graphene_django import DjangoObjectType

class UserType(DjangoObjectType):
    class Meta:
        model = get_user_model()

class CreateUser(graphene.Mutation):
    user = graphene.Field(UserType)

    class Arguments:
        username = graphene.String(required=True)
        password = graphene.String(required=True)
        email = graphene.String(required=True)

    def mutate(self, info, username, password, email):
        user = get_user_model()(
            username=username,
            email=email,
        )
        user.set_password(password)
        user.save()

        return CreateUser(user=user)

class Mutation(graphene.ObjectType):
    create_user = CreateUser.Field() 

当使用突变向服务器发送数据时，我们将发送username、password和email。服务器将返回创建的带有所有信息的User对象，客户端可以询问它想要的字段。

在执行它之前，我们需要将新的突变放在根文件schema.py中。

import graphene
import events.schema
import users.schema

# Query for getting the data from the server. class Query(events.schema.Query, graphene.ObjectType):
    pass

# Mutation for sending the data to the server. class Mutation(users.schema.Mutation, events.schema.Mutation, graphene.ObjectType):
    pass

# Create schema schema = graphene.Schema(query=Query, mutation=Mutation) 

使用失眠症执行下面的代码，我们可以看到新用户被创建。

查询用户

为了列出所有用户，我们将创建一个查询并发送给服务器。

我们将把以下内容添加到users/schema.py文件中。

class Query(graphene.ObjectType):
    users = graphene.List(UserType)

    def resolve_users(self, info):
        return get_user_model().objects.all() 

我们还将更新根查询类以支持用户查询。

class Query(users.schema.Query, events.schema.Query, graphene.ObjectType):
    pass 

我们将向服务器发送一个查询来列出所有用户。

用户认证

在 Django 中，默认情况下使用会话启用身份验证。我们将使用django-graphql-jwt库在 GraphQL 中实现 JWT 令牌。

当用户注册或登录时，标识用户的一段数据被发送给用户。当需要身份验证时，用户应该在请求的 HTTP 授权头中发送相同的令牌。

我们将通过在settings.py文件中添加一个新的中间件来配置django-graphql-jwt。在同一个文件中，我们将添加身份验证后端设置。

MIDDLEWARE = [
    # After django.contrib.auth.middleware.AuthenticationMiddleware...
    'graphql_jwt.middleware.JSONWebTokenMiddleware',
]

# Authentication backends AUTHENTICATION_BACKENDS = [
    'graphql_jwt.backends.JSONWebTokenBackend',
    'django.contrib.auth.backends.ModelBackend',
] 

什么是 Moesif？ Moesif 是最先进的 REST 和 GraphQL 分析平台，被数以千计的平台用来衡量您的查询执行情况，并了解您最忠实的客户正在使用您的 API 做什么。

接下来，我们将导入库并更新Mutation类，使schema.py文件中包含以下变量。

import graphene
import graphql_jwt

# Mutation for sending the data to the server. class Mutation(users.schema.Mutation, events.schema.Mutation, graphene.ObjectType):
    token_auth = graphql_jwt.ObtainJSONWebToken.Field()
    verify_token = graphql_jwt.Verify.Field()
    refresh_token = graphql_jwt.Refresh.Field() 

该文库产生三种突变:

我们将使用TokenAuth来验证用户的用户名和密码，并获得 JSON Web 令牌。

我们将使用VerifyToken来验证作为参数传递的令牌是有效的令牌。

RefreshToken将在更新的过期时间内为未过期的令牌生成新令牌。

测试身份验证

为了测试我们的身份验证是否有效，我们将创建一个名为me的查询，如果登录，它将返回用户的信息，否则将抛出一个错误。

首先，我们将在schema.py文件的查询类中添加me查询。

class Query(graphene.ObjectType):
    me = graphene.Field(UserType)
    users = graphene.List(UserType)

    def resolve_users(self, info):
        return get_user_model().objects.all()

    def resolve_me(self, info):
        user = info.context.user
        if user.is_anonymous:
            raise Exception('Authentication Failure!')
        return user 

为了进行测试，我们需要使用tokenAuth突变获得一个令牌，并通过添加前缀JWT在我们的查询中使用 HTTP 授权头。

我们将添加带有令牌内容的 HTTP 授权头，前缀为单词JWT。

最后，我们将进行me查询，该查询将识别我们的用户。

我们能够创建用户并与他们一起登录。如果我们在没有 HTTP 头的情况下进行查询，我们会得到错误消息。

好吧，就让我玩玩吧！要查看 GraphQL 的运行情况，您可以从 GitHub 克隆并运行这个示例应用程序。

在下一篇教程中，我们将讨论如何监控 GraphQL APIs。同时，如果您有任何问题，请联系 Moesif 团队。

本系列前情提要:

• Python 和 GraphQL 入门第 1 部分

Python 和 GraphQL 入门——第 1 部分

原文：https://www.moesif.com/blog/technical/graphql/Getting-Started-with-Python-GraphQL-Part1/

自从脸书提出 GraphQL 以来，它就一直被认为是 REST APIs 的替代品。最近 Github 也宣布了对他们的一个 API 的 GraphQL 支持。因为 GraphQL 不仅仅是 REST 的进化替代品，所以这篇博客将有助于介绍 GraphQL 的基础知识，并使用 Python Django 和 Graphene 开发 GraphQL APIs。

GraphQL 简介

GraphQL 是什么？

GraphQL 是一种强类型查询语言，描述了如何请求数据。GraphQL 将所有东西都声明为图。你要求你想要的，然后你会得到你期望的。不多不少。

考虑一个有两个表projects和user的数据库。项目包含字段title和project_name，而user包含字段user_name和email。

现在，如果您想知道项目的标题和与该项目相关的用户电子邮件，该怎么办呢？你的第一直觉是什么？除非已经创建了 API 端点，否则您可能会对GET /projects和GET /users进行 HTTP 调用。在客户端，您可以在收到两个查询后进行连接。一些 REST API 可能会提供一些灵活性，比如GET/projects?include=user。然而，这样的查询需要提前整合到 API 的设计中。如果您的查询更加模糊，比如获取与项目相关的用户的经理电子邮件，该怎么办？GraphQL 允许您准确地声明查询所需的实体和相关实体，并且可以在单个客户端到服务器中完成，从而减少 API 的“闲聊”和往返延迟。

作为一种强类型查询语言，它允许您确定需要什么数据，从而避免与未充分利用的数据相关的问题。

GraphQL 有时被视为 API 理解的革命性方式。与使用严格定义的端点(如 REST API 的情况)不同，通过单个客户机/服务器往返来接收必要的数据，这确保了前端和后端团队之间的平稳工作流。换句话说，客户机可以准确地指定它需要什么，而不是让服务器创建客户机可能查询什么的人工查询。

听起来很刺激，不是吗？如果您目前正在使用 REST API，并且想知道迁移到 GraphQL 是否能解决您的业务问题，请查看这篇对 REST 与 Graph 架构的深入分析。

入门指南

继续之前，请确保您安装了 Python 3.6。

我们要建造什么？

在这篇博客中，我们将使用 Django 和 Graphene 创建一个示例项目。 Graphene 是 Python 的 GraphQL 框架。该项目将具有以下特点:

• Events有name和url字段的创作
• 搜索和过滤Events数据

创建您的本地环境

在使用 Python 时，我们建议使用虚拟环境来将所有项目的依赖项与其他项目隔离开来。

conda create -n graphql python=3.6 anaconda # Create the environment
source activate graphql # Activate the environment 

安装依赖项

pip install django==2.0.2 graphene==2.0.1 graphene-django==2.0.0 django-filter==1.1.0 

配置石墨烯 Django

在{django_project_name}/settings.py上，添加以下内容:

INSTALLED_APPS = (
    # At the end of all the default packages
    'graphene_django',
) 

在文件底部添加:

GRAPHENE = {
    'SCHEMA': '{django_project_name}.schema.schema',
} 

创建一个Event应用

在{django_project}根上，创建events应用程序

python manage.py startapp events 

接下来，我们需要定义数据库和 Django 之间的层。

# Defining Event model class Event(models.Model):
    name = models.TextField(blank=True)
    url = models.URLField() 

最后，我们需要配置 Django 在{django_project_name/settings.py}文件上使用新的events应用程序:

INSTALLED_APPS = (
    # After the graphene_django app
    'events',
) 

创建数据库表

python manage.py makemigrations
python manage.py migrate 

打开 Django shell python manage.py shell并创建一些数据。

from events.models import Event
Event.objects.create(name='API Analytics', url='https://www.moesif.com/')
Event.objects.create(name='Trove Marketplace', url='https://www.trove.com/') 

介绍失眠/图形 1

我们可以使用 REST 客户端或浏览器中的图形交互界面来运行查询。

创建您的第一个模式

当开始使用 GraphQL 时，我们的第一个问题是如何构建我们的 GraphQL 服务器？由于 GraphQL 已经作为规范发布，我们可以用任何编程语言构建服务器。

模式是可能包含多个字段的对象的集合。每个字段都通过返回值的解析器进行计算。字段的解析函数将访问数据库并返回一个对象。

模式是严格类型化的，描述了所有可能接收到的数据。GraphQL 查询模式和您的数据库结构没有连接。

为模式创建文件{django_project_name}/schema.py。

import graphene
import events.schema

# Query for getting the data from the server. class Query(events.schema.Query, graphene.ObjectType):
    pass

# Create schema schema = graphene.Schema(query=Query) 

创建您的第一个查询

GraphQL 查询语言完全是关于选择对象上的字段。

我们从“根”对象开始，并在其上选择events字段。从事件返回的对象中，我们将选择id、name和url字段。

创造你的第一个突变

向服务器发送数据的过程称为变异。

定义突变类似于我们定义查询的方式。我们可以定义您可以发送到服务器的数据。突变方法将使用用户发送的数据在数据库上创建一个事件。

再次尝试查询数据，您将看到新事件被创建。

查询和变异定义了 GraphQL API 的入口点。每个 GraphQL 服务都有一个查询类型，可能有也可能没有突变类型。

搜索和过滤

一旦我们有了数据，我们就可以根据需求进行搜索和过滤。我们可以搜索第一/最后“n”个记录，跳过“n”个记录或搜索任何术语。

只有事件 Id 和名称字段的最后 n 条记录:

在名称或 url 字段中搜索特定术语:

我们还可以一起搜索和过滤:

好吧，就让我玩玩吧！要查看 GraphQL 的运行情况，您可以从 GitHub 克隆并运行这个示例应用程序。

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

本系列的下一篇:

• Python 和 GraphQL 入门第 2 部分

让您的开发人员看到出色开发人员体验的价值

原文：https://www.moesif.com/blog/developer-relations/monitoring/Getting-your-Developers-to-See-Value-with-a-Great-Developer-Experience/

使用 API 的好处之一是它们可以方便实用地共享数据和应用程序。API 实现了从依赖定制集成的界面到现在相对简化的流程的转变。也就是说，由于他们的敏捷框架，一些公司忽略了提供良好的开发者集成体验的重要性，并且没有采取必要的步骤来帮助推动第一个 Hello World 的时间。

不幸的是，围绕 API 管理有一种太普遍的情绪，即集成应该留给超级智能的开发人员来解决，标准的 onboarding 工作流是不必要的奢侈品。然而，这是一个被误导的概念；开发人员不希望被当作二等公民对待，他们希望被展示如何集成，并会欣赏简化工作流的便利。

也就是说，越来越多的 API 驱动的组织正试图颠覆这一概念。这些组织认为，集成过程对他们的业务的成功至关重要，因为它为与他们的开发人员的整个合作期奠定了基础。因此，这些组织正在不知疲倦地帮助他们的开发者尽快实现第一个 Hello World。面对这样的现实，如果他们的入职工作流需要太长的时间来集成，开发人员会沮丧地收拾行李离开。相反，如果这些组织很快就能让他们的开发人员惊叹并帮助他们取得成功，那么这些组织很可能会有一个持久而富有成效的关系。

与一个完全不同的行业进行比较，但在产品采用方面提供了一个相关的教训，那就是特斯拉的汽车行业。特斯拉的设计师竭尽全力确保驾驶者的初始体验完美无缺。例如，无缝推动启动引擎，现代的内饰，流线型的用户界面，以及像火箭一样发射你的引擎。所有这些添加的细节最终形成了最初的体验，赋予价值并帮助客户迅速爱上他们的产品。

与特斯拉的设计师类似，API 产品和工程领导者应该致力于为他们的开发人员提供世界级的集成体验，这种体验是精简的，并使采用过程变得轻松。

要实现这一目标，首先要做的一件事就是创建一份漏斗采用报告。一个基本采用漏斗的例子可能是:(1)初始注册，(2)第一次使用 Hello World，以及(3)价值实现时间。一旦你的漏斗报告被建立，它将使你能够测量到达你的漏斗中的每个独特阶段所花费的时间，并帮助你理解 API 的哪些方面有助于开发者的成功。此外，报告还应该确定在每个阶段退出的开发人员的百分比，这反过来暴露了开发人员可能会在哪里遇到麻烦。

虽然创建一个开发人员采用漏斗肯定是朝着正确方向迈出的一步，但它本身并不能为您提供全貌。为了扩大范围，添加额外的视角和指标将是有益的。下面列出了一些您可以考虑用于开发人员采用漏斗的顶级指标:

合格的产品线索 -当开发人员与您的 API 集成时，了解他们是否是您服务的合格未来用户是很重要的。在许多情况下，开始集成过程的开发人员只是在试探，并没有成为订户的实际意图。这些人应该标上星号，因为他们不能提供你的采用漏斗的有效性的真实感觉。此外，对于满足您业务需求的开发人员，支持团队应该联系他们，加倍努力帮助他们完成集成过程。

利用像 Clearbit 这样的扩展将帮助你展现相关的人口统计信息，比如角色、行业和公司规模。这将让你集中精力关注谁有可能成为你的下一个最佳客户。

营销渠道 -营销团队正在努力优化他们的广告支出，以确保他们吸引到合适类型的开发者，这些开发者有很高的转化可能性。因此，为了帮助营销团队最大限度地增加未来的广告支出并吸引合适的受众，跟踪哪些广告渠道能够产生最高的 API 转化率是至关重要的。

SDK 的类型 -了解您的开发人员正在使用的 SDK 是一个很好的衡量标准，可以确定某些类型的集成如何影响开发人员的成败。例如，你的 Python SDK 比你的 GO SDK 有更高的流失率吗？如果是这种情况，这将是一个强有力的指标，表明您的 Python SDK 中可能有一个 bug，您的工程团队应该研究诊断这个问题。

错误——跟踪错误是暴露开发人员在与 API 集成时遇到的摩擦点的好方法。如果您在漏斗中的特定阶段看到错误增加，它使您能够主动介入并消除未来的瓶颈，防止开发人员下降。

现在问题落到了你的身上，你的 API 集成过程是否类似于一辆特斯拉汽车让你的开发人员重视起来？否则，为了达到这个黄金标准，API 驱动的组织必须不断地监控和分析他们的集成漏斗，以便改进工作流，消除摩擦点，并帮助加快 Hello World 的实现。

企业中的 GraphQL:构建、部署和监控新的企业 GraphQL 服务需要什么

原文：https://www.moesif.com/blog/technical/graphql/GraphQL-In-Enterprise-What-It-Takes-To-Build-Deploy-And-Monitor-A-New-Enterprise-GraphQL-Service/

新技术在融入企业堆栈之前，总是需要一些规划、变更和试验。GraphQL 的采用也不例外。Airbnb、网飞、Shopify 和其他行业巨头等公司都已经开始使用这一有前途的技术。在这篇博客中，我将概述创建新服务、部署新服务和监控新服务的一些关键注意事项。这里假设您对 GraphQL 有一个基本的了解，了解一些关键的用例，并且知道一些关于采用的问题。记住这一点，让我们开始吧。

GraphQL 与。休息一下

在构建 GraphQL 服务之前，重要的是要考虑构建 Web APIs 的主流方法:REST。对 GraphQL 的一个常见误解是，它是 REST 的替代品。从这个角度考虑这项技术是非常错误的。GraphQL 和 REST 可以互为补充，大多数企业会混合使用这两种方法。

当企业从 SOAP 转移到 REST 时，这种转变更容易看到和描绘出来。两者都包含请求和响应的严格契约，这意味着将 SOAP 服务转换成 RESTful 服务很有意义。有些甚至可以以“对等”的方式进行转换。

对于 GraphQL，与 SOAP 和 REST 相比，这是一条更艰难的比较和迁移路径。没有 GraphQL 请求和响应契约，因为它们是在执行查询时定义的。GraphQL API 的调用者发送获得所需结果所需的任何数据，并以调用者请求的格式返回。这打破了 RESTful API 设计建立的传统模式，在这种模式下，端点有非常明确定义的请求和响应对象。

GraphQL 相对于 REST 的最大好处是用户可以检索他们需要的任何数据，而不必为每个变体创建一个新的端点。这无疑可以改善开发人员对 API 和数据的体验。对于 REST，这实际上导致了一个 API 问题，有时创建一个新的端点比修改一个现有的端点更容易，并可能破坏使用它的其他应用程序。结果是一大堆略有不同的 API，以及维护它们所需的大量支持工作。

当决定将您的新 API 构建为 GraphQL 还是 REST 时，您将希望确保您需要 GraphQL 的灵活性，或者您可能只需要一个小型 RESTful API 的简单性。

你真的需要 GraphQL 吗？

确定你是否真的需要 GraphQL 是一个非常重要的问题。随着 GraphQL 的采用，给工程师和支持团队带来了学习曲线，以及复杂性。

使用 GraphQL 的最佳时机是:

• 您有大量的关系数据，并且您不确定消费者将如何查询这些数据
• 您目前正面临 REST 端点复制的问题，并希望减少您必须支持的单个端点的数量
• 您有许多公开您需要的数据的服务，并且想要一种更简单的方法来查询它，而不需要创建许多新的端点
• 您希望订阅数据中的更改，可能使用 GraphQL 订阅作为解决方案

在以下情况下休息可能更好:

• 您的应用程序只需要简单的、预定义的 CRUD 操作
• 您正在添加到一个已经使用 RESTful 方法高效运行的现有项目中
• 你需要严格的利率限制和配额管理
• 您需要大量缓存或者需要设计吞吐量

当然，对于为什么应该使用其中一种技术来代替另一种技术，有许多不同的观点。以上只是每种方法的一些注意事项。

如果您想公开您的数据，以便多个应用程序可以完全按照他们认为合适的方式使用它，GraphQL 是一个很好的解决方案。如果你比其他人更需要一个简单的 CRUD 接口，更简单的解决方案可能是更好的选择。

构建新 GraphQL 服务的选项

GraphQL 服务本质上可以适应熟悉的“构建还是购买”的困境。构建 GraphQL 服务的原始且最灵活的方法是选择一种语言和框架，然后“从头”构建。几乎每种语言中都存在大量的框架。GraphQL.org有一个全面的列表所有支持 GraphQL 的语言和框架。

当从头开始构建一个框架时，你将拥有最大的灵活性，但也有最陡峭的学习曲线。如果出现问题，您的支持团队也需要尽快了解代码的复杂性。高灵活性和定制化的代价是构建时间、学习框架以及在定制代码投入生产后对其的支持。

一个看起来学习曲线更低的替代方法是使用一个产品来构建，该产品允许您使用现有的基础设施来创建您的 GraphQL 服务。一些例子包括:

• 哈苏拉
  • 连接您喜欢的数据库并自动创建一个 GraphQL API 服务
• 动物群 T3
  • 从单个模式创建数据库和 GraphQL API 服务
• Tyk 的通用数据图
  • 使用现有的 RESTful APIs 创建一个新的 GraphQL API 服务，不需要任何代码
• Mulesoft 的任意点数据图
  • 使用您已经构建的 API 来公开新的 GraphQL 服务

其中许多解决方案允许您使用现有的基础设施、服务和数据来创建全新的 GraphQL 服务。几乎所有的都不需要额外的代码，除了您可能想要实现的定制，这意味着学习曲线和构建时间大大减少。与构建“基础”服务相比，这种方法提供的灵活性稍低，但却能让用户快速进入市场。

不要忘记前端的变化

将 GraphQL 引入企业的另一个部分是对您的前端和任何将使用该 API 的客户端进行更改。在现有的前端项目中，目前可能使用 RESTful 端点，要集成和运行 GraphQL 可能需要大量的工作。每个 RESTful 调用都需要映射到等价的 GraphQL 调用，并在应用程序中处理返回的数据。为了映射这些操作，这可能需要对 GraphQL 模式有深入的了解。

仅代码更改一项就要花费大量的时间，在计划 GraphQL 转换项目时应该对其进行预算。如果前端团队不知道如何利用这项技术，他们也需要接受 GraphQL 方面的教育。这还将包括添加一个前端 GraphQL 客户端，如 Apollo Client，并学习如何使用它与您的新 GraphQL 服务进行交互。从项目一开始就使用 GraphQL，这显然不那么麻烦。

最后要考虑的是，一旦 GraphQL 发生变化，产品或系统需要多少回归测试。需要进行端到端测试，以确保 API 按照预期工作，以及服务中支持响应的任何逻辑。同样的测试方法也必须应用于前端 UI 体验，以确保应用程序像最初一样工作。

管理常见的 GraphQL 问题

GraphQL 仍处于起步阶段，在选择使用和实现它时，需要考虑一些问题。下面我们将回顾一些在实现 GraphQL 时需要注意的最常见的问题。

安全性

许多 GraphQL 采用者最担心的是 GraphQL 内置的漏洞。尽管许多经验丰富的 GraphQL 用户都知道它们，但是很容易忘记通过 GraphQL 服务暴露的许多攻击媒介。这些攻击包括 SQL 注入、查询遍历攻击和许多其他易于执行但难以发现的攻击。在的这篇文章中，WunderGraph 对许多最重要的漏洞进行了完整的分析。

贮藏

GraphQL 以其缓存的复杂性而闻名。与容易缓存的 REST 响应不同，GraphQL 提出了独特的挑战。大量的缓存问题已经由单独的解决方案解决了，但是实现起来可能很复杂，并且不是所有的解决方案都能全面地解决这个问题。本文中的对 GraphQL 中缓存的所有方面进行了很好的概述。

复杂性

实现 GraphQL 有时会比用传统的 RESTful 方法解决问题更复杂。有时 GraphQL 服务的构建和支持变得非常复杂，即使它们提供的数据本质上很简单。这也可能导致消费者需要对底层数据结构和可用字段有更复杂的理解。对于不熟悉 GraphQL API 的开发人员来说，不得不编写复杂的查询也会增加困惑。在企业层面，这可能意味着围绕现有消费者的服务能力进行大量培训。

速率限制和配额

对于 RESTful 端点，在特定端点上实施速率限制和配额相对简单。GraphQL 服务是通过单个端点提供的，这使得这一点有点困难。您可以对 GraphQL 端点强制实施速率限制和配额，但是这留下了很少的灵活性和定制性。实施速率限制和配额的最佳方式是限制每个字段，或者更常见的是，通过进行 GraphQL 查询成本计算并为每个用户分配特定数量的点数。几年前，Shopify 的工程团队在这个项目上做了一篇的精彩报道。像 Moesif 的治理特性这样的工具可以为特定的 GraphQL 字段和操作符计量和执行配额。

错误处理

GraphQL 中处理错误的方式与 RESTful 服务略有不同。使用 REST，当调用或事务中出现问题时，会返回错误代码。这在很大程度上是一个“全有或全无”的事务，要么调用成功，要么返回大量可能的错误响应之一。使用 GraphQL，即使响应包含错误或者某些字段无法解析，响应状态仍将显示为成功。这意味着错误处理必须比仅仅查看 HTTP 响应状态代码更加明确。GraphQL 规范本身甚至包含关于如何格式化 GraphQL 响应中的错误的非常模糊的指导。在的上一篇文章中，Apollo GraphQL 提供了一些如何解决这种挫折的小技巧。

部署 GraphQL 服务

部署 GraphQL 服务(包括 GraphQL 服务器和相应的前端 GraphQL 实现)的工作方式与使用框架构建 RESTful API 服务的工作方式相同。

当谈到许多“购买”的解决方案，如 Hasura 或动物群时，这些解决方案中的大多数都是作为 SaaS 式的托管部署提供的。这意味着部署只需要最少的工作和配置就可以启动并运行。如果需要，其中一些解决方案还提供自我管理的本地解决方案。显然，以自我管理的方式管理您自己的部署和资源将需要更多的努力和支持资源。

负责部署解决方案的团队应该知道如何配置它，并且对于“购买”的 GraphQL 产品，应该知道如何将逻辑和其他依赖项从开发环境转移到生产环境。

监控 GraphQL 服务

一旦您的 GraphQL 服务在生产中启动并运行，监控它的错误、使用情况和采用情况是非常重要的。传统的 APM 供应商很难监控 GraphQL，因为他们只查看 URL 和状态代码。但是，GraphQL 调用通常是针对同一个/graphql API 端点的，不一定利用 HTTP 状态代码。最好的 GraphQL 监控工具提供了分析特定操作和主体字段的灵活性。像 Moesif 这样的解决方案允许您在出现 response.body.error 这样的特定主体字段时得到警告，这是 GraphQL APIs 的一种常见错误格式。

Moesif 还可以提供与 REST APIs 相比，如何访问 GraphQL APIs 的产品见解。这使您能够跟踪从 REST 迁移到 GraphQL 时的使用差异。这包括 Moesif 跟踪 GraphQL 操作的能力，例如 GraphQL 突变，并基于特定字段进行过滤，以便您可以看到哪些正在使用以及它们是如何使用的。

您还可以使用 Moesif 为您的团队创建警报，并根据使用情况自动向用户发送电子邮件。这有助于以完全自动化的方式实现入职、特性采用和客户成功。

正在考虑 GraphQL 或者已经在你最新的项目中使用 GraphQL？立即注册了解 Moesif 的 GraphQL 监控功能，尽可能轻松、安全、成功地过渡到企业 GraphQL。

Node.js 中的 GraphQL 堆栈:工具、库和框架的解释和比较

原文：https://www.moesif.com/blog/technical/graphql/GraphQL-Stack-Nodejs-Tools-Libraries-Frameworks-Explained-and-Compared/

介绍

GraphQL 通常被视为 RESTful API 的替代品。虽然创建 GraphQL APIs 有明显的优势，但负面影响和转换成本可能会阻止许多组织从 RESTful 迁移。有很多文章描述了 GraphQL 的优点和缺点。关键的优点是 GraphQL 让客户端确定它想要的数据，同时避免了对服务器的多次请求。

GraphQL 是脸书提出的标准。实现 GraphQL API 的方法有很多，但是工具、库和框架的选择数量多得令人应接不暇。有许多很好的教程以一种自以为是的方式开始使用 GraphQL。这篇文章并不打算成为一套预选工具的入门指南，而是探索在新 GraphQL API 的设计和规划阶段将会出现的不同选项。

堆叠的层

在我们深入研究不同的选项之前，让我们来看一下使用 graphQL 系统建立生产环境的要素。

• 第一层是 HTTP 服务器，用于处理 GraphQL 服务器的传入 HTTP 请求。
• 第二层通常是核心层，是查询处理，它需要几个子部分:
  • 模式定义，静态时完成。
  • 解析和解析查询，即确定对每个查询采取什么动作或方法。
  • 产生和合计输出。
• 第三，您最终需要将其连接到数据库，即如何将 GraphQL 模式绑定到您的数据库模式。
• 第四，您需要全面考虑安全模型，并设置正确的授权和身份验证方案。

在客户端，有几个主要元素:

• 帮助您构建请求和处理查询返回值的工具和库。
• 工具和库如何通过将查询绑定到 UI 的组件来将数据注入到 UI 中。

让我们探索每一层。

构建和定义模式的工具

GraphQL 模式本身是语言不可知的，它是一种 DSL(领域特定语言),在教程中有很好的记录。这个 DSL 有很多方面，包括继承、静态类型、参数、操作符等等。所以学习它并有效地使用它可能需要一些时间。

GraphQL 查询通常如下所示:

type  Person  {  name:  String!  age:  Int!  posts:  [Post!]!  } 

graphql.js官方图书馆是来自Graphql.org

您可以自己编写 DSL，加载它并让它被buildSchema函数解释。

var { buildSchema } = require('graphql');

var schema = buildSchema(
  `
  type Person {
    name: String!
    age: Int!
    posts: [Post!]!
  }
  `
); 

graphql.js的 buildSchema 不是唯一的解析器，还有几个，比如 Apollo 的 graphql-tools 。graphql-tools 的好处是它有助于使调制更容易。

GraphQL 工具使您能够用 javascript 创建 GraphQL 模式的字符串表示，您可以在这里阅读和了解它，并解析它以便它可以被其他工具使用。

如果您喜欢以编程方式构建模式，有 Javascript 库可以帮助您完成。

import {
  graphql,
  GraphQLSchema,
  GraphQLObjectType,
  GraphQLString
} from 'graphql';

var schema = new GraphQLSchema({
  query: new GraphQLObjectType({
    name: 'RootQueryType',
    fields: {
      hello: {
        type: GraphQLString,
        resolve() {
          return 'world';
        }
      }
    }
  })
}); 

如果您已经有了一个现有的项目，通常您可能已经定义了一个模式，比如 Mongoose 模式。有人构建工具来从您现有的模式生成 GraphQL 模式。有些相对较新，如mongose-schema-to-graph QL，而graffitti-mongose已经过时。挑战在于，通常情况下，GraphQL 模式实际上比典型的 mongoose 模式更具表达性，因此，如果您进行直接移植，有时您可能无法充分利用 GraphQL 的特性。尽管如此，尝试将任何现有产品移植到 GraphQL 中仍然是一项艰巨任务。

图书馆	方法	利弊
graphql.js 与 graphql-tools	编写架构	语言不可知
graphql.js	通过编程编写架构	在创建模式时更容易模块化和防止错误
mongose-schema-to-graph QL . js	从现有架构生成架构	自动生成的模式不够灵活，因为 GraphQL DSL 比 Mongo 模式定义更具表现力。

注意我个人认为使用GraphQLSchema、GraphQLString函数“以编程方式”生成您的模式似乎是不必要的，因为 GraphQL DSL 本身是非常干净的、声明性的和独立于语言的。没有理由再增加一层复杂性。此外，甚至尝试根据另一个数据库模式自动生成模式也是不必要的。如果您决定采用 GraphQL 作为您的应用程序的主干，那么仔细考虑所有事情并仔细设计模式是值得的，这是您整个应用程序的核心。

下决心者

解析器是一组对应于模式的数据元素的函数。在查询被验证之后，解析器在查询被遍历时被触发。解析器按照模式的规定完成所需的数据或变化(即更新数据库中的数据)。

因为解析器只是函数，所以除了与数据库交互之外，它们还可以执行任何操作。解析器函数通常如下所示:

Query:  {  human(obj,  args,  context)  {  return  context.db.loadHumanByID(args.id).then(  userData  =>  new  Human(userData)  )  }  } 

解析器是您需要编写的大部分代码，包括任何需要的业务逻辑。打个比方，这些是 RESTful APIs 的控制器。

没有任何框架可以取代您自己的业务逻辑代码，您必须自己编写这些代码，但是如果大部分数据字段都直接解析为数据库字段，那么可能会有许多可以编写脚本的样板代码。

注意旋变器可以是同步或异步的。Node.js 的伟大之处在于它已经为非阻塞 IO 而设计，利用这一点很重要。任何网络调用(比如对另一个 API 的调用或单独的数据库获取)都应该放在异步解析器中。

连接到数据层

对于许多常见的数据库，如 PostgresSQL 和 MongoDB，有可用的驱动程序和库使查询更容易，帮助您管理模式、迁移等。

您不一定需要使用为 GraphQL 设计的数据库驱动程序。但是，如前所述，有一些工具可以帮助您基于数据库模式生成 GraphQL 模式。您的应用程序需求可能需要比生成器所能创建的更多的自定义模式。而没有复杂关系的非常简单的 CRUD 应用程序可以受益于自动模式生成。

Prisma 走反路线。它允许您在 GraphQL 中创建模式，然后在您打算使用的数据库中生成相应的模式。它提供了一套工具，用于生成到数据库的链接，连接到这些数据库，并提供标准的预装代码，如分页。

Dataloader 实用程序可用作应用程序数据提取层的一部分，通过批处理和缓存，为各种远程数据源(如数据库或 web 服务)提供简化且一致的 API。同样，尽管 facebook 说它是通用的，但它主要用于 GraphQL 应用程序。

连接到 HTTP 服务器

通常，除了简单地连接到 HTTP 服务之外，引擎实际上解析查询，并决定调用哪个解析器。它几乎相当于一个路由器，但它做得更多，通常引擎也处理这些事情:

1. 正在验证查询。
2. 正在解析。
3. 路由和触发解析器。
4. 放回解析器的结果。

其中最简单的可能是express-graphql，尽管顾名思义它是用于“express.js”的，但它实际上支持任何基于节点的 https 服务器，这些服务器支持next风格的中间件。

使用它非常简单:

app.use('/graphql', graphqlHTTP({
  schema: schema,
  rootValue: root,
  graphiql: true,
})); 

其中rootValue是解析器的入口点。

基本上，您可以添加已经在使用的任何类型的快速中间件，比如身份验证或授权。

然而，有几个其他的引擎或框架提供了更多的特性。

阿波罗服务器由流星背后的公司提供。Apollo Server 有一个更简单的接口，并且只支持一种传递查询的方式。Apollo Server 支持更多的 https 服务器(Express、Connect、哈比神、Koa、Restify ),并为每个服务器创建了单独的库。它是阿波罗(即流星)提供的工具套件的重要组成部分。它还排除了【GraphiQl】服务器，该服务器更多的是一个开发工具，而不是生产所需的。

Graph Cool 也是 GraphQL 的开源后端框架，非常强调无服务器技术/架构。因为它是一个框架，它不仅仅是设置 HTTP 服务器。在文章的最后，我将总结考虑到堆栈多层的主要框架的选择。

GraphQL 中的身份验证和安全性

所以您创建了一个 GraphQL API，但是现在您需要考虑几个安全问题，尤其是如果它可以从互联网访问的话。

对于传统的 REST API，我们编写了一篇深入的文章，这里涵盖了设置的一些关键考虑事项，GraphQL 也需要一些相同的考虑事项。关键区别在于，对于 RESTful API，您可以在路由级别设置安全性要求，但是对于 GraphQL API，它是在/graphql的单个端点，因此为了安全性，您需要与 GraphQL 引擎更紧密地耦合。

安全性的另一个考虑是 GraphQL 在构建查询时更加灵活，这使得某些人更有可能构建如此复杂的查询，以至于他们可以意外或恶意地 DDoS 您的服务，或者导致占用服务器资源的无限循环。

在客户端进行查询

构建获取数据的查询与 JSON 非常相似。例如，要获取一个 id 为 1000 的人，并选择(项目)、姓名和身高字段，可以编写如下的 GrapQL 查询:

{  human(id:  "1000")  {  name  height  }  } 

这里有大量关于查询的教程。

有生成和构建查询的工具，因此您不必依赖 javascript 字符串。查询生成器 Graphql 查询生成器

由于向服务器发送查询只是简单的任何 HTTP 请求，您可以使用任何流行的 https 客户端，如 SuperAgent 或 Fetch 或 Axios 或 Request 。

虽然您可以手动发出查询请求，但由于在大多数用例中，查询的结果将显示给最终用户，即呈现在 UI 中。由于有许多前端 UI 框架，有许多选择来帮助将查询绑定到 UI，这些库可以消除手动执行查询的需要，还提供关键功能，如缓存数据和订阅数据更改。

注意graph QL 的一个伟大之处是订阅模式，它可以让用户界面体验比让客户端不断获取数据要好得多。然而，这对于像聊天这样的应用来说是有意义的，但是并不是在所有的场景中都有意义。例如，如果用户想看到一个数据表，如果数据不断地重新呈现，这可能会很烦人。您可以让用户触发数据的重新加载。

客户端:将查询绑定到 UI。

React 、 Angular 、 Vue 、 Ember 大概是当今最白杨的前端框架了。如果您是从零开始一个项目，在选择 GraphQL 客户端工具之前，先决定使用哪个 UI 框架可能是值得的。虽然根据 Github stars 的说法，react 目前似乎主导着市场份额。

Apollo 客户端为每个框架提供绑定器，也为 Android 和 iOS 提供绑定器。

Relay 虽然设计的非常通用，理论上可以用于任何 UI 框架，但是基本上是由创建 React 的同一个团队支持的。因此，这些库和工具与 react 紧密相关。

这两种技术还有更深入的比较，我将快速比较这两种技术。

技术	服务器端要求	UI 框架兼容性	查询模式	订阅支持	贮藏
继电器	需要额外配置。这些是可用的工具。架构的每个节点都需要一个唯一的 id。	理论上任何框架，但在实践中反应	更具声明性，例如，对于每个组件，您描述您需要的数据，库将为您构造查询	极好的支持。	内置的。保证本地存储与服务器处于一致状态
阿波罗	兼容任何 GraphQL 服务器。	支持主要的 UI 框架。	直接构建查询。	需要额外的库。	缓存在大多数情况下都工作得很好，但是您可能需要手动执行 updateQueries

总之，如果 Apollo 客户端看起来更容易学习和开始，但从长远来看，Relay 是一个更复杂的系统，如果您的项目可能会变得非常大和复杂，也许值得投资。

样板或框架

GraphQL 的设计并不固执己见，但具有讽刺意味的是，大多数框架和样板文件都有点固执己见。

鉴于构建基于 GraphQL 的应用程序的技术堆栈的每一层都有如此多的技术选择，尤其是对于全新的应用程序，您可能会考虑所有决策都是在哪里做出的，您可以快速启动并运行，只有在绝对必要时才替换掉 swap out 技术。这就是框架和样板文件的用武之地。

• 阿波罗已经被提到过几次了。它本质上是一个完整的堆栈，将服务器和客户机之间的代码分开，你可以使用任何一个，而不必绑定到另一端(当然，如果你使用它们的整个堆栈，会更容易)。
• GraphCool 专注于服务器端。它试图坚持开放标准，包括基于 JWT 的认证、订阅等功能，甚至包括 Docker 之类的东西。
• 甘松也专注于服务器端，它开箱即可兼容中继，并且还支持 ES7。
• 火神是全栈的，但重点是以流星为基础。选择 Meteor 本身是一个需要仔细考虑的重大决定，因为有很多优点和缺点。

样板文件和框架之间的界限有时会变得更窄，但是通常样板文件会为您做出更多的决定。

• 节点 GraphQL 服务器是相当小的样板文件。
• nodejs api starter 是厨房水槽自带的样板文件，包括数据库(PostgreSQL)和 Docker。所以这是最广泛的，但对初学者来说可能是好的开始。
• graphql-yoga 是另一个样板文件，主要基于 Apollo 栈，比如 express-apollo、subscriptions-transport-ws。

注意虽然选择一个框架似乎可以让决策变得容易，但有时你会因为不需要的东西而变得臃肿。你总是可以从一个最小的栈开始，然后随着你了解更多的东西而增加。

摘要

选择 GraphQL 本身作为新应用程序的主干可能是一项艰巨的任务，但是在您决定使用 GraphQL 之后，它的缺点是这是一种非固执己见的技术，我们必须做出如此多的库和工具选择。有时候感觉像是决策瘫痪。即使你通过采用样板文件或框架来避免做出大量决策，了解所有的考虑因素也是值得的。

尽管任何技术都没有灵丹妙药，但 GraphQL 也存在一些问题，比如它变得更加难以调试，尤其是当你有一个开放的公共 API 时，你不知道你的 API 将使用哪种查询模式。对生产 API 调用的分析变得更加重要。

Moesif 相信 GraphQL 会一直存在，因此我们很高兴在我们的高级 API 分析平台

上推出原生 GraphQL 支持了解更多信息

GraphQL 和 RESTAPI 哪个对 API 的可观察性更好

原文：https://www.moesif.com/blog/graphql/api-development/GraphQL-Versus-RESTAPI-Which-is-Better-for-API-Observability/

API 可观察性

API 提供者需要观察他们的 API，以获得关于它们在实践中是否被使用以及如何被使用的有意义的数据。API 可观察性是一种监视形式，它被动地将 API 流量记录到可观察性服务中。与传统的 API 监控不同，利用 API 可观察性，您可以:

监控交互以改善开发人员体验了解客户如何使用您的 API 对您的 API 进行故障排除

观察 REST API 得到了很好的理解和支持，但并不是每个 API 都是 REST API。特别是，当涉及到可观察性时，GraphQL APIs 的行为非常不同。让我们深入了解这意味着什么，以及如何利用它。

GraphQL APIs 提供了优势，但是挑战了可观察性

许多组织通过监控用户访问的端点、记录错误消息和测量端点请求的延迟来实现 API 的可观察性。这种策略对于 REST APIs 来说很好，但是对于 GraphQL APIs 的可观察性来说还不够。

API 消费者喜欢 GraphQL，因为它足够灵活，可以在单个请求中查询来自多个来源的数据，并处理复杂的状态和缓存管理，这为开发人员带来了很好的体验。

GraphQL 的好处不仅仅在于 API 消费者。使用 GraphQL，API 提供者可以在不影响现有查询的情况下更新他们的 API。使用 GraphQL 提供数据也是平台无关的，因此 API 提供者可以选择最适合他们的数据提供者，包括将多个数据资源捆绑到一个查询中。支持 GraphQL 对于致力于构建优秀开发人员体验的 API 提供者来说非常重要，在这种体验中，查询是高效、强大和灵活的。

GraphQL 的灵活性对于 API 提供者和 API 消费者来说都是一个重要的好处，但是这种灵活性也意味着您需要一种不同的方法来观察 GraphQL APIs。让我们更深入地看看 API 可观察性在 GraphQL 上下文中提出的挑战，以及如何处理它们，以便您的组织可以观察您的 GraphQL API。

在实践中观察 GraphQL

为了从 REST API 访问数据，开发人员分别调用多个端点，将客户机需要的所有数据拼凑在一起。对于复杂的应用程序，GraphQL 方法更有吸引力，因为对不同数据源的请求都发生在一个查询中。这意味着开发人员只需要在使用 GraphQL 时请求他们需要的数据，而 REST 查询结构不允许这种级别的可定制查询。例如，一个显示产品信息的购物应用程序，谁在卖它，以及交付需要多长时间，将由如下三个独立的 REST API 调用组成:f GET/category//product info GET/seller//GET/delivery//

需要多次 GET 调用来接收加载产品页面所需的所有数据。从产品端点调用数据，该端点返回包括销售者 id 在内的信息。有了卖家 id，应用程序向卖家端点发出数据调用，以获取卖家的信息，包括位置 id。最后，使用 location-id 调用交付端点，以便页面知道该产品的交付需要多长时间。每个响应都依赖于之前 API 调用的信息，这种方法经常获取过多或过少的数据。只从多个来源获取所需信息的 GraphQL 调用可以通过一个查询来完成:

{
  category{
    name
    product(product-id){
      name
      productInfo{
        size
        price
        seller-id
      }
      seller(seller-id){
        name
        location-id
        delivery(location-id){
          name
        }
      }
    }
  }
} 

虽然 GraphQL 方法的单个查询的灵活性对于开发人员来说很大，但当使用 GraphQL 监控数据查询时，这就带来了挑战。如果在使用 REST API 的事务中出现部分失败，或者如果一个端点未能返回数据，HTTP 请求将返回一个失败状态响应。当调用不成功时，API 提供者和 API 使用者都会收到 HTTP 500 或 400 错误，而对于成功的端点调用，则会收到成功的 HTTP 200。我们购物示例中的 REST API 故障如下所示:

HTTP/1.1 400 Unprocessable Entity
{
  "error": 
    {
      "code": "400",
      "message": "Product ID does not exist"
    }
} 

使用 GraphQL，即使 API 调用没有返回任何查询数据，部分故障也会成功解决并返回 HTTP 200。成功的 HTTP 响应是查询到达服务器的结果。如果查询调用了不存在的数据或者消费者无权访问的数据，HTTP 响应代码不会向您提供这些信息。这使得处理错误更加困难，因为诊断错误需要更多的努力。API 消费者可以检查 errors 对象的响应对象，这将显示哪个端点遇到了错误以及导致错误的原因。下面是我们的 GraphQL 购物应用程序查询示例中部分失败的情况:

{
  "errors": [
    { "path": [ "product" ],
      "locations": [ { "line": 3, "column": 12 } ],
      "extensions": {
        "message": "Object not found",
        "type": 2
      }
    }
  ]
} 

API 消费者能够通过检查客户端的 GraphQL 错误对象来诊断错误，如下所示。不幸的是，在服务器端，如果您不检查每个调用，您可能不会发现这些错误。对于 API 提供者来说，要解决这个问题，他们需要监控他们的 API 返回的 GraphQL 有效负载，这样他们就可以像使用他们的 API 的开发人员一样检查错误对象。监视 API 有效负载还有一个额外的好处，那就是让您知道开发人员是如何使用您的 API 的，哪些查询是最常见的，哪些查询具有最低的延迟，以及 API 使用者是否成功地完成了查询。

通过观察学习

监控 GraphQL 有效负载的另一个好处是，您可以记录指标，这样您就可以根据开发人员访问 API 的方式做出长期决策。日志可以告诉你哪些 GraphQL 查询是成功的，谁是你最忠实的用户，哪些查询是首次用户做的，哪些查询经常被捆绑在一起，等等。这可以为您组织的客户成功战略提供信息，这将允许您编写更有效的文档，找到在 API 调用方面有困难的用户，并为使用您的 API 的开发人员提供更主动的支持。有了详细的日志，您可以详细了解您的 API。过滤查询是一种从 GraphQL 日志中聚集信息的强大技术。

将 GraphQL 查询聚合到您的 API 中，然后按类别(如字段名和参数值)对它们进行过滤，这将为您提供关于对您的 GraphQL API 进行的大多数查询的可操作信息。这将告诉您 API 的哪些部分为您的客户创造了最大的价值，因此您知道在编写文档时应该关注什么，应该向开发人员提出哪些问题，以及哪些附加功能可能会为您的用户创造价值。如果您的组织同时拥有 GraphQL 和 REST APIs，那么过滤您的查询将允许您直接比较开发人员如何使用您的不同 API。

我们已经介绍了您的组织应该如何实现 GraphQL API 可观察性，以及它对于一个专注于促进客户成功的组织有多么重要。虽然 REST API 可观察性实现起来更直观，并且有更多现有的 REST API 分析工具，但 GraphQL 可观察性比 REST API 可观察性有一些独特的优势。

GraphQL API 可观察性的优势

GraphQL 查询准确地指出了需要什么信息。REST API 消费者经常欠挖或过挖数据，因为他们不能选择他们需要的具体数据。GraphQL 查询只调用消费者需要的数据，这些数据会准确地告诉您哪些数据正在为您的消费者创造价值。使用 REST API analytics，很难确定多个连续的 API 端点调用是来自消费者的单个事务的一部分，还是它们是不相关的事件。GraphQL analytics 将单个交易所需的所有调用捆绑到单个查询中，因此您可以更好地了解消费者如何使用您的 API。

GraphQL API analytics 可以在产品开发中为您提供优于 REST API analytics 的优势，并且它们可以使您的组织更容易关注客户成功。如果您的组织了解首次用户在遇到挑战时是如何试图查询您的 API 的，那么您的客户支持可以在解决您的客户遇到的问题方面发挥更积极的作用，从而提供更详细和更有建设性的支持。如果一个客户因为调用一个不再存在的 REST 端点而无法查询您的 API，您的组织可能不会注意到这个失败，您的客户支持也无法联系到这个客户。与 GraphQL API 调用形成对比，在 graph QL API 调用中，查询指向单个端点。如果客户试图查询不再存在的数据，您的监控将记录这一失败，并且您的客户支持可以直接联系用户，以帮助您的客户进行成功的 API 调用。

这些年来，GraphQL 变得非常流行，越来越多的团队选择使用 GraphQL APIs。作为一个 API 提供者，观察您的 GraphQL API 可能具有挑战性。绝大多数 API 分析工具都是为了支持 REST APIs 而构建的，而 GraphQL 通常是事后才想到的。Moesif 与众不同，旨在观察 GraphQL 和 REST APIs，以便您的组织能够促进客户成功并为您的客户创造价值。Moesif 提供了产品内置的 GraphQL 可观察性的所有优点。当您实现 GraphQL API 时，您不需要放弃强大的分析工具！

使用 Python、Flask 和 MongoDB 创建 RESTful API 指南

原文：https://www.moesif.com/blog/technical/restful/Guide-to-Creating-RESTful-APIs-using-Python-Flask-and-MongoDB/

RESTful APIs 简介

在 HTTP 协议上使用 JSON 的 RESTful APIs 是目前最流行的创建 web APIs 的方法。它们使开发人员能够从资源的角度考虑对这些资源的操作，如 CRUD(创建、读取、更新、删除)。然而，还有一些即将出现的 API，比如越来越受许多应用程序欢迎的 GraphQL。

在本教程中，我们将使用 Python 和 Flask 框架构建一个 RESTful API 来创建、读取、更新和删除 Mongo 数据库中的文档(包含用户信息)。

入门指南

以下是我们构建 API 所需的工具:

• Python 3.7
• 邮递员下载这里
• Mongo 数据库文档
• Robo 3T 下载此处

创建您的本地环境

注意:在使用 Python 时，我们建议使用虚拟环境来保持项目的所有依赖项与其他项目的隔离。

conda create -n restfulapi python=3.7 anaconda # Create the environment
source activate restfulapi # Activate the environment 

安装依赖项

pip install -r requirements.txt 

启动 MongoDB 服务器

如果您使用的是 MacOS，您可以使用brew来启动服务器。

brew services start mongodb 

MongoDB 中的收藏

集合类似于传统关系数据库中的表。我们将创建一个用户集合来存储用户详细信息，类似于 SQL 中的用户表。

创建用户

我们将创建一个端点POST /api/v1/users，它接收一个 JSON 对象，该对象由用户详细信息组成，如name、email、phone作为请求体中的 JSON。我们还可以设计端点来接受一组用户。

@app.route("/api/v1/users", methods=['POST'])
def create_user():
    """
       Function to create new users.
       """
    try:
        # Create new users
        try:
            body = ast.literal_eval(json.dumps(request.get_json()))
        except:
            # Bad request as request body is not available
            # Add message for debugging purpose
            return "", 400

        record_created = collection.insert(body)

        # Prepare the response
        if isinstance(record_created, list):
            # Return list of Id of the newly created item
            return jsonify([str(v) for v in record_created]), 201
        else:
            # Return Id of the newly created item
            return jsonify(str(record_created)), 201
    except:
        # Error while trying to create the resource
        # Add message for debugging purpose
        return "", 500 

单个用户返回实体 id，因此前端可以引用新创建的项目。另一方面，用户数组返回实体 id 数组。

读取用户

为了获取我们刚刚创建的用户列表，我们将设计一个端点GET /api/v1/users并将搜索标准作为查询字符串参数传递。

@app.route("/api/v1/users", methods=['GET'])
def fetch_users():
    """
       Function to fetch the users.
       """
    try:
        # Call the function to get the query params
        query_params = helper_module.parse_query_params(request.query_string)
        # Check if dictionary is not empty
        if query_params:

            # Try to convert the value to int
            query = {k: int(v) if isinstance(v, str) and v.isdigit() else v for k, v in query_params.items()}

            # Fetch all the record(s)
            records_fetched = collection.find(query)

            # Check if the records are found
            if records_fetched.count() > 0:
                # Prepare the response
                return dumps(records_fetched)
            else:
                # No records are found
                return "", 404

        # If dictionary is empty
        else:
            # Return all the records as query string parameters are not available
            if collection.find().count() > 0:
                # Prepare response if the users are found
                return dumps(collection.find())
            else:
                # Return empty array if no users are found
                return jsonify([])
    except:
        # Error while trying to fetch the resource
        # Add message for debugging purpose
        return "", 500 

如果提供了搜索条件，我们将返回用户详细信息，否则我们将尝试返回所有文档(如果存在),否则我们将返回一个空数组。

更新用户

现在，我们将设计一个端点POST /api/v1/users/<user_id>来更新用户详细信息。

@app.route("/api/v1/users/<user_id>", methods=['POST'])
def update_user(user_id):
    """
       Function to update the user.
       """
    try:
        # Get the value which needs to be updated
        try:
            body = ast.literal_eval(json.dumps(request.get_json()))
        except:
            # Bad request as the request body is not available
            # Add message for debugging purpose
            return "", 400

        # Updating the user
        records_updated = collection.update_one({"id": int(user_id)}, body)

        # Check if resource is updated
        if records_updated.modified_count > 0:
            # Prepare the response as resource is updated successfully
            return "", 200
        else:
            # Bad request as the resource is not available to update
            # Add message for debugging purpose
            return "", 404
    except:
        # Error while trying to update the resource
        # Add message for debugging purpose
        return "", 500 

例如，我们想用匹配的1来更新文档。

删除用户

最后，我们将设计一个端点DELETE /api/v1/users/<user_id>来从数据库中删除用户。

@app.route("/api/v1/users/<user_id>", methods=['DELETE'])
def remove_user(user_id):
    """
       Function to remove the user.
       """
    try:
        # Delete the user
        delete_user = collection.delete_one({"id": int(user_id)})

        if delete_user.deleted_count > 0 :
            # Prepare the response
            return "", 204
        else:
            # Resource Not found
            return "", 404
    except:
        # Error while trying to delete the resource
        # Add message for debugging purpose
        return "", 500 

我们将指定删除文档的匹配条件。例如，我们想要删除具有id匹配1的文档

处理找不到页面的请求

我们建议用给用户的信息性消息来处理找不到页面的请求。

@app.errorhandler(404)
def page_not_found(e):
    """Send message to the user with notFound 404 status."""
    # Message to the user
    message = {
        "err":
            {
                "msg": "This route is currently not supported. Please refer API documentation."
            }
    }
    # Making the message looks good
    resp = jsonify(message)
    # Sending OK response
    resp.status_code = 404
    # Returning the object
    return resp 

如果您想摆弄数据，也可以使用 Robo 3T mongo shell。

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

在下一篇博客中，我们将学习如何授权和认证我们的 API。如果你对使用 Python 开始使用 GraphQL 感到好奇，请参考这个博客。同时，如果您有任何问题，请联系 Moesif 团队

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

了解更多

消费者应用货币化指南:衡量货币化功能的影响

原文：https://www.moesif.com/blog/product-management/mobile-apps/Guidelines-To-Monetize-Consumer-Apps-Measuring-Monetization-Feature-Impact/

介绍

多年来，我开发了许多游戏和应用程序，研究如何将免费增值应用程序货币化，因此我撰写了这篇文章，总结了一些我们用来评估货币化功能潜在影响的指南。这篇文章还根据我过去工作过并接触过的一些应用和游戏的数据，探讨了指导方针背后的原因。虽然基于手机游戏，但我相信这些准则可以应用到很多手机 app 上。

货币化的三种方式

免费增值应用的盈利方式有三种:

• 目标(加速或阻碍目标)。
• 自我表达
• 广告(ad 的复数)

方法的比较

与目标相关的特征> =与自我表达相关的特征~=广告。

与目标相关的特性影响最大。对于一般人群，与自我表达相关的特性与广告相当或略好。

自我表达功能可以更好地为女性和年轻人赚钱。通常，如果一款游戏可以从广告中获得 0.01 美元的 DARPU(每用户日平均收入)，那么与自我表达相关的功能可以获得 0.01 美元或 0.02 美元的 DAPRU。然而，自我表现的 DAPRU 通常不会比来自广告的收入贡献多太多。最大的 DARPU 归因仍然来自与目标相关的特征。进球收入的上限通常与游戏的类型有关。对于像 match-3 游戏这样的休闲游戏，目标驱动的收入低于硬核游戏。此外，游戏中的大多数目标都是人为目标，所以真实目标可能比人为目标更容易赚钱。建立人为的目标需要用户的“认同”,通常这并不能保证，也不容易。

基于目标的功能

目标的重要性和相关性

更重要和更常见的目标是，更高的货币化潜力。

更多的共同目标意味着目标被更多的人分享。例如，在一个约会应用程序中，如果一些人真的多才多艺，他们就不需要过滤特定的类型或个性。然而，每个人都想检查更多的比赛。检查更多匹配的门将比几个特定的过滤器更重要，并且与更大的人群相关。

浇口硬度与 DARPU 和保持力

另一方面，门越硬，达尔普越高。然而，你可能会疏远用户，导致用户保留率下降。虽然这是一种权衡，但令人惊讶的是，你可以取得平衡，让你增加 DARPU 而不损失保留或损失非常少的保留。如果这些门被认为是有趣的、具有挑战性的或激发好奇心的，在某些情况下，它们实际上可以增加记忆。门的硬度应通过实验来测试。

总收入等于 DAU *达尔普，而 DAU 是留存和安装的函数。所以收入可以归结为一个二次函数。最终，二次函数有一个最大值。每种情况都不同，可能需要几次尝试才能收敛到最大值。使用软门，并使水平灵活调整和实验，以找到最大值。

自我表达特征

• 表达越明显，货币化定制功能就越能吸引注意力。如果有更多的人看到它，就会有更多的人愿意为此付费。

• 比男性更吸引女性和小孩

接近饱和

如果一种方法已经饱和，继续在该领域增加功能将不会带来额外的收入改善。

在一个特定的过去的游戏中，我们出售帮助击败一个水平的工具(能量)。我们卖出了一款工具，它带来了很大一部分收入。然后，我们决定添加更多的工具来帮助击败一个水平。首先，一对夫妇可以帮助。然而，在某个时候增加更多对收入没有帮助。相反，这很伤人，因为用户可能会被选择淹没。

功能蚕食

太多的功能集中在一个目标上会导致自相残杀。

蚕食意味着两个功能可能独立地对贡献收入同样有益。但是，如果两个特性一起实现，那么这两个特性就会相互竞争。你不一定有两倍的收入。

如果唯一的货币化是高级订阅服务，同样的自相残杀问题也适用。如果我们增加了足够多的价值(或足够多的门槛)，额外增值服务的回报将会递减，从而导致更低的付费订阅转化率。在这种情况下，我们可能会考虑增加额外的层级或更直接的应用内购买。自我表达相关的商品可能最适合应用内购买。

结束想法

• 最终，这些指导方针可能只是一个“猜测”即使有最好的功能想法/机制。特性是如何实现的，在给定的环境下，如何表现，如何交流，如何定价等等，都将有助于特性的成功。
• 考虑到所有潜在的影响和成本，而不仅仅是与收入相关的影响，实现特定功能仍然是一个商业决策。

Moesif 如何帮助您改善平台的开发者体验

原文：https://www.moesif.com/blog/developer-marketing/api-analytics/How-Can-Moesif-Help-You-Improve-Your-Platforms-Developer-Experience/

一个好的开发者体验可以成就或者毁灭你的产品。包括我在内的开发人员对他们用来构建和监控项目的工具非常挑剔。有了大量可用的开发工具，选择挑剔比以往任何时候都容易。

产品体验的伟大之处在于，通过适当的跟踪和分析，你可以慢慢地做出有影响力的小改变。这些小的改变可以迅速地将你的产品的可用性和开发者体验变得更好。

这就是 Moesif 可以提供帮助的地方，从有效地收集指标到帮助您理解它们。Moesif 是一个分析工具，可以从您的 API 调用和前端收集指标，以准确跟踪您的整个客户旅程。然后，当你做出改变时，Moesif 还会帮助你跟踪结果，以确保你朝着正确的方向前进。让我们来看看 Moesif 可以帮助您改善开发人员体验的几个方面。

用户和公司跟踪

Moesif 平台的一个构建模块是将应用程序中发生的每个事件与用户和/或公司相关联的能力。这允许进行一定程度的详细报告和分析，这是您无法从无法与特定用户旅程相关联的指标中获得的。有助于衡量开发者体验的两个关键分析是漏斗和保持。让我们看看每个特性是如何工作的，以及如何使用它来改善开发人员的体验。

烟囱

漏斗本质上是应用程序中特定流程的逐步分解。例如，您可能正在查看您的注册流程，并尝试对其进行优化。

通过这种分析，您可以看到用户完成每一步需要多长时间，以及有多少百分比的用户真正完成了这一步。这很重要，因为它允许您建立一个基线，并了解用户在哪里被挂起。然后，当你做出改变时，你可以检查以确保整个漏斗的转化率在提高。至少，您应该检查以确保您的“改进”不会给用户带来更多的问题。

保留

从你的平台中获取价值并享受其体验的用户往往会被留住。保持力分析可以帮助你确定客户何时会对你的产品失去兴趣。同样，这可以让您创建一个基线，将开发人员体验的改善或恶化与用户保持联系起来。

发信号

积极主动地吸引用户也是改善平台开发人员体验的好方法。有时候，开发者体验不仅仅是拥有最漂亮的用户界面或入门，还可以归结为当你陷入困境时公司如何帮助你。

对产品的 UI 或物理体验的改进可能需要一段时间来改变，这就是提醒可以派上用场的地方。警报可用于通知客户成功团队、工程团队或任何其他关注客户体验的团队有关用户可能遇到的问题。团队可以做两件事:

• 在客户放弃产品之前，主动联系客户，帮助他们解决问题
• 将反馈发送到产品团队的反馈循环中，以帮助改善未来的体验

Moesif 中有两种类型的警报:静态和动态。让我们来看看两者。

静态警报

如果您心中有一个特定的阈值，例如，如果用户在 1 小时内遇到超过 5 个 401 -未授权错误，您可以使用静态警报。这是一个静态标准，您将使用静态发生次数作为阈值。

动态警报

如果您不确定希望用作警报阈值的确切发生次数，动态警报可能是最佳选择。动态警报允许您设置阈值，例如当用户遇到与正常数量相比的 401 错误高峰时发出警报。动态警报允许您监视趋势和峰值，而无需为阈值输入具体的数字。

这两种警告风格都可以用来改善开发人员在产品中的体验。虽然与产品没有直接关系，但产品背后的团队乐于助人、知识渊博且积极主动，会是一个重要的优势。

行为邮件

如果你不能处理大量的高接触电子邮件支持，或者只是想通过自动化来优化它，行为电子邮件是一条出路。Moesif 允许你设置由应用程序中的事件触发的行为邮件流。例如，如果用户收到大量的 500 内部服务器错误响应，那么您可能希望向他们发送一封电子邮件，概述原因和可能的修复方法。这减轻了支持团队的负担，也允许采取即时和主动的行动。

你也可以使用行为电子邮件来引导开发人员找到可以帮助他们使用特性或 API 的资源。当开发人员使用你的产品时，这有助于提高他们的生产力和效率。通过引导他们找到正确的文档，您可以帮助用户更快地进入他们使用您的 API 的第一个“Hello World”时刻，或者帮助他们探索您的 API 或工具中更高级的特性。

计费仪表

自助服务是改善产品开发人员体验的好方法。许多开发人员不喜欢通过繁琐的程序或销售电话来访问和使用产品。在开发者和你的产品之间设置一个强制性的“与销售人员交谈”的障碍，你可能会失去客户。相反，允许用户注册、选择计划、添加信用卡或开使用发票可以成为吸引新用户的游戏规则改变者。

Moesif 的计费表可以帮助解决这个问题。计费仪表功能允许您快速构建一个货币化模型，并将使用情况发送给计费提供商，如 Stripe 或 Recurly。注册、计费和开发票的操作都可以自动化，为开发人员提供一个无缝的流程。

自助 API 使用

虽然使用计费表可能有许多目的，但利用计费表的最大好处是它使公司能够快速创建自助消费模型。开发人员不需要通过销售来开始，他们可以简单地注册并使用该平台。大多数开发人员工具都支持自助式模型，因此可以自下而上地采用。因为这是一种规范，所以这也是您的平台所期望的。

如果你有 API 或者你的产品的另一部分，你可以简单地建立一个收费标准，让 Moesif 计算使用量并为开发者创建一张发票。你也可以支持预付费计费，开发者可以购买积分，并在使用服务时“烧掉”。为 API 使用提供自助服务是提高开发人员利用您的平台的便利性的一个好方法。

包扎

积极的开发人员体验根植于良好的 DX、良好的文档和始终如一的目标，即在您的产品中改进开发人员的旅程。糟糕的开发者体验不仅会让开发者离开你的产品，如果口碑成为产品采用的因素，还会阻止其他软件工程师尝试它。这就是为什么跟踪度量标准并使用战术变化来改善开发人员的体验，对于任何创建了开发团队使用的工具或服务的公司来说都是必须的。

Moesif 不仅是跟踪开发人员体验的最佳工具之一，也是直接改进开发人员体验的最佳工具之一。如前所述，使用 Moesif 的用户和公司跟踪、提醒、行为电子邮件和计费表都是增加你对开发者的产品的好方法。通过使用 Moesif 跟踪和改善开发人员的体验，您应该可以在整个产品中看到更好的激活和保持。为了亲自体验 Moesif，现在就注册，开始跟踪和改进您平台内的开发者体验。

Moesif 如何帮助你理解 API 的用法？

原文：https://www.moesif.com/blog/product-management/api-analytics/How-Can-Moesif-Help-You-Understand-API-Usage/

你想发展你的业务吗？为您的客户创造更多价值？好吧，理解 API 的使用应该是你的首要任务，就在跟踪 API 使用和 API 监控的能力之后。

通过使用 Moesif 了解客户的 API 使用情况，您可以获得许多不同的见解，例如

• 你最受欢迎的 API
• 哪些 API 错误最多
• 个人用户和公司如何使用你的 API
• 还有更多…

了解这些关键见解有助于做出明智的业务和工程决策。有了 Moesif，有许多不同的方法可以对 API 分析进行切片和切块，以揭示 API 使用的多个角度。不仅如此，您还可以使用某些功能来采取行动，以提高保留率，并在减少错误的同时提高用户的使用率。

让我们看看 Moesif 中的一些特性，它们有助于理解和改进 API 的使用。

图表

探索不同指标报告的文档可以在这里找到

能够可视化 API 的使用是为数据带来上下文并使其更易理解的一个好方法。Moesif 的核心焦点是提供易于配置的图表，使用户能够真正深入细节。这是通过对数据应用过滤器以获得您想要的精确输出来实现的。例如，您可能希望看到一个时间序列图表，它显示了过去 2 周所有 API 的错误趋势。您可能希望进一步挖掘，查看特定公司的用户在过去 12 小时内尝试访问某个端点时发生的 401 个错误。能够准确地拨入你所需要的是 Moesif 最擅长的。

虽然有很多不同的图表样式，但是让我们回顾一下两种最流行的样式，它们有助于理解 API 的用法。

实时事件日志

现场活动日志是查看和深入 Moesif 中每个活动的好方法。通过单击每个事件，您可以探索关于请求和响应的所有细节。这比查看纯文本 API 日志要高效得多。

如果您设置并启用了用户和公司跟踪，您还可以轻松地深入查看附加到事件的用户和公司资料。为了展示如何使用实时事件日志的快速示例，让我们过滤一些演示数据来识别在/购买 路线上发生的不成功 API 调用。

您可以在这里看到，我们可以很容易地看到哪些调用出错，甚至可以检查或生成一个示例 API 请求来重放请求，以便进行故障排除或测试。

使用实时事件日志来了解 API 使用指标的好处是可以看到每个事件并与之交互。这是一个很好的方式来解决问题，并看到需要在最细粒度的水平上探索的趋势。

时间序列

为了观察一段时间内的趋势，时间序列图是最好的可视化方式。有了时间序列，你将决定你想要跟踪哪些事件，然后让 Moesif 显示一段时间内的趋势。例如，我们希望查看发生不成功 API 调用的前 5 名端点，并观察这一趋势。下面是一个可能的例子。

时序图可以让你更容易地看到趋势，而实时事件日志可以让你深入每个单独的 API 调用。这两个图表对于理解如何使用 API 以及详细研究每个调用都非常有用。

仪表盘

仪表板文档可在这里找到

既然您已经找到了一些图表，可以帮助您深入了解组织内的 API 指标，那么让我们将它们集中到一个地方。仪表板允许您将所有喜爱的图表集中在一个位置，以便于查看和管理。如果您想在一个地方查看 API 指标的多个方面，仪表板是实现这一点的好方法。

默认仪表板

当您第一次创建您的 Moesif 帐户时，您的 Moesif 实例将被填充一些现成的仪表板。这些仪表板涵盖了大多数企业的核心领域，并预先填充了可能对每个领域都有帮助的工作区。这些领域包括:

• 产品
• 工程
• 安全性
• 客户成功
• 销售
• 营销

例如，在默认出现的产品仪表板中，我们可以看到包含的工作区标题。

这些可以作为一个很好的起点，您可以根据您喜欢的图表和报告添加更多的工作区切片，或者您可以编辑每个切片以更好地适应您的特定用例。

自定义仪表板

如果 Moesif 默认包含的仪表板不是您所需要的，或者您只是想从头开始创建一些东西，也可以创建自定义仪表板。自定义仪表板是一种很好的方式，可以创建简化的方式来访问您最喜爱的图表和报告，这些图表和报告更符合您的确切需求。关于创建仪表板的细节，包括自定义仪表板，请查看我们的文档。

用户和公司跟踪

用户和公司跟踪功能的文档可在这里找到

Moesif 与其他分析平台的主要区别在于 Moesif 能够将每个事件与用户和/或公司联系起来。这开启了许多深度分析用例，这些用例在查看大型数据集时是不可能的，因为大型数据集只能匿名查看事件。

用户和公司跟踪最常用的两个功能是漏斗和留存分析。两者都可以回答客户如何使用产品，你的入职效果如何，以及用户是否会离开你的产品。让我们仔细看看这两个特性。

烟囱

漏斗允许 Moesif 用户看到他们转换漏斗中的每一步是如何工作的。对于大多数企业来说，这可以给出非常重要的提示，说明应该改进什么，以及最新的改进是如何改进或阻碍转换过程的。

一个简单的例子是让我们看看探索用户登录的三步漏斗。我们将看到一个漏斗，其中:

• 用户登录一次
• 用户第二次登录
• 用户在第二次登录后会再登录 3 次

这样做的目的是让我们看到我们的客户是如何回到这个平台的。漏斗看起来像这样:

保留

理解 API 使用的另一个关键部分是了解用户是如何被保留的。让用户开始使用你的 API 是战斗的一部分，对公司更大的价值是保持用户流量进入 API。

使用 Moesif，与仅跟踪客户是否拥有有效订阅的订阅保持不同，Moesif 可用于调查产品保持。这更准确，因为它跟踪用户是否回来并积极使用你的产品。为了计算用户的保持率，Moesif 需要一个初始事件和一个返回事件。如果我们有一个允许用户结帐的 API，我们可以让初始和返回事件等于他们调用 /purchase API 的时间。

本质上，这种类型的保留分析将概述用户正在进行持续购买，我们将重复购买的用户视为活跃/保留客户。在 Moesif 中，上面的每周保留分析如下所示。

我们可能会更进一步，观察使用我们平台的不同细分市场或群体的留存率。这方面的一个例子可能是查看企业客户与非企业客户在保留率上的差异。将它添加到我们的报告中会是这样的:

在漏斗和留存分析中，您还可以挖掘特定的用户群，例如按用户或公司查看留存趋势。这可以帮助您了解个人层面的 API 使用情况，并了解各种用户和公司如何使用该平台，以及他们是否会返回该平台。

警报

报警和监控文件可在这里找到

当某些事情发生在你的客户身上或你的产品中时，得到通知是很重要的。依靠仪表板和持续的手动轮询来发现问题是非常低效和不可靠的。通过 alerts，您可以将 Moesif 配置为通过电子邮件、SMS、Slack、PagerDuty 或其他自定义渠道向您发出警报，以便在达到特定标准时通知您。

在理解 API 使用方面，您可能想知道 API 何时接收到异常高或异常低的流量。Moesif 可以通过使用两种不同类型的警报来实现这一点。

静态警报

静态警报允许您配置警报，以便在达到静态阈值时发送通知。例如，当特定的 API 端点每小时接收超过 1，000 个调用时，就会发出警报。一旦端点接收到该数量的流量，就会向配置的任何通道发送通知。在 Moesif 中，这是它的样子:

动态警报

如果您不确切知道您想要设置为警报阈值的静态数量，您可以使用动态警报。动态警报的设置类似于上面的静态警报设置，除了您将类型指定为动态警报，然后设置诸如突然峰值灵敏度、异常变化灵敏度和趋向更高灵敏度等因素的灵敏度。

当动态警报启用时，Moesif 将查看趋势和峰值，以提醒用户其客户的 API 使用中的异常。与静态阈值相比，这可能是监控 API 使用情况的更好方法。

治理规则

治理规则的文档可以在这里找到

大多数时候，创建报告和监控 API 是必不可少的，但是能够以自动化的方式使用这些见解会非常强大，并增强这些功能。这意味着理解 API 的用法只是战斗的一部分。能够使用这些见解来管理对 API 的访问是理解 API 使用和主动使用数据的下一个层次。有了 Moesif 的治理规则特性，您就可以做到这一点。

阻止不必要的行为和使用

治理规则特性可用于检测不需要的行为或条件何时发生，并阻止用户使用 API。有两种类型的治理规则可以应用:阻塞和非阻塞。非阻塞规则仍然允许请求通过上游 API，但是允许响应主体、响应状态代码和响应头被覆盖。对于阻塞规则，请求不会被上游 API 接收，而是在插件/网关或 SDK 级别被阻塞，被覆盖的响应将被发送回调用 API 的用户。

这可能有用的一个例子是在 API 货币化的环境中。在 Moesif 中，我们可以创建一个治理规则，阻止有过期发票的用户访问货币化的 API。用户还会收到一个响应，告诉他们有一张过期的发票，并向调用者返回一个 429 - Payment Required 状态代码。

不是每个 SDK 或插件都支持治理规则。请检查你的插件的文档，看看它是否支持治理规则。

治理规则是一种很好的方式，可以利用 API 使用的度量标准，并自动化治理，使 API 更加安全和用户友好。

试试吧！

Moesif 充满了大量的特性来增强你的 API 业务和理解 API 和产品的使用。我们已经介绍了一些有助于理解 API 用法的关键特性，并展示了一些 Moesif 中每个特性的例子。Moesif 平台使您的整个组织，从工程师到 API 产品经理，能够更深入地理解 API 的使用。此外，该平台还允许您使用这些见解，通过治理规则，甚至通过其他功能，如行为电子邮件或计量计费，自动采取行动。登录或今天就注册开始 Moesif！

客户成功团队应如何监控账户健康和 API 使用情况

原文：https://www.moesif.com/blog/customer-success/monitoring/How-Customer-Success-Teams-Should-Monitor-Account-Health-and-API-Usage/

为开发者优先或 API 优先的企业引领客户成功与传统的企业软件截然不同。最好的 API 产品被设计成自助式和无人干预的，这意味着一旦实现完成，客户很少需要登录 web 门户。如果您是 Stripe 或 Twilio 客户，您上次登录他们的门户网站是什么时候？希望不是最近，否则这可能意味着一个问题或议题。另一方面，传统的企业解决方案可能会将客户活动席位的增加或减少视为扩张或流失的早期信号。

API 优先业务的客户成功是什么

API 优先的企业有两种不同的“产品体验”，客户成功需要考虑这两种体验。首先，注册和登录您的门户网站时会有网络体验。然后，还有与 API 平台集成和交互的 API 体验。两者都是“入职体验”的一部分，应该有可衡量的 KPI。然而，API 是驱动长期价值的因素。客户增加了许多席位或团队成员，但从未与平台整合，可能会很快流失(如果已经付费)。

下面是传统企业平台和 API 平台的一些比较。虽然我们使用术语“席位”，但您可以用任何定价单位来代替，如“许可证”、“CPU”或“物理位置”。

收入增长的领先指标

传统企业软件	API 平台/开发者平台
活动席位/已用许可证数量的增加	有价值的 API 调用增加
部署到多个地点或更多部门	部署到生产或更多应用

客户流失的领先指标

传统企业软件	API 平台/开发者平台
许多座位的拆除	有价值的 API 调用大量减少
大量非活动席位与活动席位	大量低价值的 API 调用与有价值的 API 调用

入职期间的问题

传统企业软件	API 平台/开发者平台
一个或少量座椅被激活	没有进行 API 调用或进行了少量 API 调用
很多负面支持票	堆栈溢出/ Reddit 上的许多负面评论

糟糕的客户体验

传统企业软件	API 平台/开发者平台
许多应用程序崩溃或用户界面异常	API 上 400 或 500 个错误的批次
页面加载缓慢	高延迟 API 调用
UI 需要多次点击才能完成一项任务	API 设计需要许多 API 调用来完成一个事务

如何使用 Moesif 创建客户成功仪表板

您首先要做的是创建两种类型的仪表板:

1. 所有客户成功指标的“概览仪表板”,用于识别有问题的客户
2. 一个“每个客户仪表板”来放大单个客户的表现

仪表板概述

每个 Moesif 帐户都有一个预建的仪表板，使您能够获得以下六个客户成功报告:

| 图表名称 | 描述 |
| 停止发送流量的新用户 | 显示最近注册但最近没有发送任何 API 调用的所有用户，这可能表明客户流失 |
| 第一次 API 呼叫的大客户 | 了解今天激活了哪些大客户 |
| 按用户列出的有错误的顶级 API | 监视那些在 API 中遇到很多错误并且可能需要帮助的用户 |
| 使用 API 最多的公司 | 了解谁是您的 VIP 客户很重要，这样您就可以优先考虑支持 |
| 新用户保持率 | 如果新用户保持率开始下降，这可能意味着严重的产品或客户体验问题 |
| 使用 SDK 的用户保持率 | 产品和客户成功团队应该跟踪有问题的集成，例如错误的 SDK |

这些指标提供了一个很好的起点，但是您可以修改或添加特定于您的 API 业务的仪表板。

每个帐户仪表板

每个客户的控制面板有助于您了解客户的表现、他们遇到的问题，并提供您是否应该联系他们的背景信息。因为许多 API 企业有成千上万的客户，为每个帐户手动创建一个仪表板将是一项繁琐的工作。相反，我们可以构建一个主仪表板，然后使用 Moesif 的过滤器覆盖特性在客户之间切换。

第一步。创建主仪表板

在 Moesif 中创建一个新的仪表板，名称为“单一帐户视图”。然后，创建一个针对单个客户的新图表。例如，要显示单个帐户的 API 使用情况报告，请单击“事件”->“时间序列”。添加感兴趣的过滤器和指标，如下所示。

确保您的图表具有针对单个帐户的筛选器，例如通过在公司域上添加筛选器。值是什么并不重要，因为它是一个占位符值。在这种情况下，我们选择Asana.com作为占位符值。

继续添加其他图表和指标，直到您的“单一帐户视图”仪表板完成，如下所示:这显示了与Asana.com相关的所有指标

第二步。在客户之间切换

现在我们已经构建了主控制面板，导航到它，以便我们可以在帐户之间切换。
点击仪表板右上角的覆盖过滤器按钮。这将打开一个弹出窗口，选择要覆盖的过滤器，如下所示:

我们可以添加过滤器company.Company Domain并输入不同于第 1 步的公司值，如dropbox.com，然后单击应用

尽管最初的仪表板在Asana.com上被过滤，但这将被dropbox.com覆盖，如下所示:

在每个单幅图块的右上角，将有一个蓝色的漏斗图标。此图标表示过滤器覆盖已成功应用于图表。

如何在帐户的 API 使用发生变化时获得提醒

既然我们已经创建了一些显示帐户运行状况的仪表板，那么当其中一个指标异常时收到警报将会很有帮助，这样客户成功可以更主动地联系客户。

为此，我们可以利用 Moesif 的监控和警报功能。

第一步。创建新的时间序列报告

可以将监视器添加到 Moesif 中的任何时间序列图中。进入“事件”->“时间序列”开始创建一个新的报告。在这种情况下，我们希望在特定帐户的 API 流量大幅下降时得到提醒，这可能意味着他们即将流失。

我们应该确保我们正在跟踪中有价值的 API 调用的减少，这样我们就可以添加一个过滤器来只监控response.Status Code为200 OK的调用。毕竟，减少 500 个错误是一件好事，并不意味着流失。

我们还想按上面蓝框所示的company.Company Domain分组。这确保了我们分别跟踪每家公司。对于指标，我们只需选择Event Count。稍后，我们可以为平均延迟等其他指标创建额外的警报规则。

第二步。创建警报规则

单击橙色的警报按钮，这将打开创建警报规则弹出框，如下图蓝色框所示。

因为我们是按公司分组的，所以 Moesif 将单独跟踪 eah 时间序列(即每个公司)。

因为每个公司的 API 使用情况都大不相同，所以利用异常检测的动态警报比静态警报更合适。

对于方向，选择“减少”，因为我们只想在流量减少时得到提醒，而不是增加。稍后，我们可以针对某个帐户的 API 流量增加创建一个单独的警报。

结束语

许多工具不是为 API 业务设计的，或者只关注基础设施的健康。如果您关心客户的成功，拥有正确的报告和警报是至关重要的。Moesif 是 API 产品和客户成功团队的头号分析解决方案，可以获得自助式 API 指标，而不会因高昂的实施和维护成本而负担过重。

客户成功如何改变您的 SaaS 业务

原文：https://www.moesif.com/blog/customer-success/monitoring/How-Customer-Success-Transforms-Your-SaaS-Business/

专注于客户成功可能是您的 SaaS 业务进展顺利或实现惊人增长之间的区别。客户的成功越来越被视为软件即服务(SaaS)业务增长的基础。如果您的企业在增长方面没有取得预期的结果，或许是时候重新评估您对客户关系的看法以及快乐客户的重要性了。

什么是客户成功？

对于 SaaS 企业来说，客户成功是发展的基础。为什么？客户成功就是支持现有客户实现他们的目标。这是客户成功专业人士努力实现的核心目标。

客户成功不仅仅是客户支持或服务。它是公司和客户之间建立的一种非交易关系。就结构而言，客户成功介于企业的销售和支持职能之间。它以互补的方式与这两种功能相互作用和重叠。

强大的客户成功计划支持:

• 登机时
• 激活
• 综合
• 订阅续订
• 订阅升级
• 客户保留
• 客户支持

客户成功是成长的基础

如果做得好并符合行业最佳实践，客户成功管理(CSM)可以帮助任何企业减少客户流失，并获得更好的声誉、更大的经常性收入、更满意的客户等。这是任何想要最大化增长机会的现代 SaaS 企业的一个基本组成部分。

为什么客户成功对 SaaS 如此重要？

客户成功对任何企业都很重要，尤其是对 SaaS 的企业。从前，一家企业出售一种产品。客户可能会在客户支持的帮助下实现产品，这样交互就基本完成了。不再是了。

今天的 SaaS 客户希望在首次购买订阅计划之前、期间和之后引领他们的购买之旅。今天的 SaaS 客户是一个自我引导的买家。这意味着传统的外向销售方式不再适用。消费者宁愿自己发现和检查产品，也不愿收到不请自来的电子邮件。这种模式被称为产品导向型增长，或 PLG。

产品导向的增长是 SaaS 的新冠军

输入客户成功。通过与现有客户建立有机的关系，客户成功在公司和客户之间创造了一个新的沟通渠道。这意味着一种直接与自我导向型买家沟通的方式。

这就是客户成功成为 SaaS 商业模式如此重要的因素的原因。客户成功经理，数据驱动的客户成功，以及他们的团队可以显著增加客户继续使用他们服务的可能性，甚至升级他们的计划。他们在 SaaS 运营中充当客户的代言人。这样做涉及与客户的一系列接触点，既包括在客户旅程中的设定阶段，也包括对沿途异常事件的响应。

关系是新的优势

在 SaaS 企业中，客户成功管理可以确保客户感觉被倾听。它可以推动产品变革。它可以最大化每个客户的价值，不仅是在你获得他们的时候，而是在他们的整个生命周期中。对于 SaaS 的产品来说，这可能是一个完整的生命周期。这在客户价值和客户终身价值实现方面的潜力是巨大的。

客户成功对 SaaS 很重要的另一个原因是，满意的客户有可能成为推荐人。有谁比那些已经在愉快地使用你的产品并从中获得最大价值的人更适合为你的企业招募新客户呢？

客户成功与客户支持有何不同？

客户成功和客户支持的关键区别在于，客户成功是主动的，而非交易性的。你的客户成功团队应该在每个阶段都比客户的需求领先一步，预测你的产品如何支持客户做得更好，达到他们想要的结果。一系列客户成功指标可以支持您的团队做到这一点，以便确定客户将从互动中受益的设定点，以及最大化每个客户的成长和成功的个性化机会。

另一方面，客户支持是一种被动的服务。当客户伸出援手时，它会迅速做出反应并提供帮助。

让客户成功成为您 SaaS 业务的重中之重

对于任何业务功能，你越早实现它，它就越容易成为你运营的基础部分。这就是为什么将客户成功作为您 saas 业务的早期优先事项非常重要，为什么客户成功是 SaaS 的优先事项。这样做意味着您可以将所需的人员和工具部署到位，以确保您的客户成功努力产生最大的成果。

客户入职期间的支持

您的客户成功团队将支持每一位新客户发展成为长期的忠诚客户。客户入职流程是这一旅程的第一步。第一印象很重要，所以入职是你给客户留下深刻印象的机会，让他们知道你的产品是多么易于使用，你的团队是多么乐于助人。

正确入门意味着支持客户以最适合其业务和期望结果的方式正确设置您的产品。这意味着在产品激活阶段提供技术指导(适合个别客户的需求)。这也意味着支持客户在您的产品和他们现有的基础设施之间的任何集成。毕竟，当你的 SaaS 产品是新来者时，你需要确保它能很好地与他人合作。

整合期间及之后的支持

一旦客户加入，就该支持他们充分利用你的产品了。您是否知道许多 SaaS 客户从未完成整合？[INCLUDE: fact]通过确保客户能够将您的 SaaS 产品恰当地整合到他们的产品中，这是客户成功鼓励回头客的地方。

关键是了解客户的业务。在客户入职和激活阶段，您已经收集了大量关于客户喜欢如何操作的信息，因此，使用这些信息来提供个性化的方法以实现客户成功。这将他们的业务增长转化为与你的 SaaS 公司的合作经验，结果是双方都受益。

你对客户的业务了解得越多，你就越能有效地突出自己产品中的功能，让他们从中受益。你就越有可能预见到他们可能遇到的任何障碍。使用客户数据来识别这些需求和潜在问题，可以让您处于一个强有力的位置，支持客户从您的产品中实现最大价值。这是一个通过积极主动的客户服务方法赢得忠诚、满意的客户的好方法，这种方法已经成为你业务的核心部分。

被照顾的顾客就是被保留的顾客

通过在您的 SaaS 业务中采用这种客户参与方法，您在提高保留率和(降低客户流失率)方面做了很多工作[https://www . moesif . com/blog/Customer-success/monitoring/How-to-Define-Measure-Analyze-and-Predict-Customer-Churn/？UTM _ campaign = Int-site & UTM _ source = blog & UTM _ medium = body-CTA & UTM _ content = cs-transforms-SaaS]{:target = " _ blank " }。客户参与降低流失率。如果任由客户使用自己的设备，他们不太可能充分利用您的产品，也不太可能跟上您的最新功能发布以及这些功能可能带来的好处。但是，有了您的客户成功团队，每位客户都可以持续从您的 SaaS 产品中获得真正的价值，因此，到时候更有可能续订。

围绕客户成功，公司面临哪些挑战？

客户的成功，就像任何业务职能一样，需要工作、思考和专业知识。这样做需要克服一系列挑战。

将数据作为客户成功的核心

数据在帮助任何客户成功经理实现最佳业绩方面发挥着核心作用。使用正确的客户成功指标可以标记出客户成功团队与客户互动的最有效时间。

让客户成功数据驱动是这些挑战中的第一个——这也是 Moesif 的切入点。通过提供一系列客户成功指标的可见性、moesif 以及可以触发客户参与互动的警报，该平台支持企业抓住每一个机会提升客户体验。

毕竟数据不会说谎。在像关系管理这样主观的领域中，衡量你所能衡量的标准是必要的。值得注意的是，有些指标比其他指标更有用。

SaaS 积分很难——这就是为什么你需要测量它

一个这样的度量是“第一个 Hello World 的时间”(TTFHW)。这是客户从注册到完全集成所需的时间。他们越快到达那里，就越有可能对你的产品满意。

当您知道 TTFHW 流程可以并且应该花费多长时间时，就很容易识别客户何时陷入困境。Moesif 可以通过自动警报向您的客户成功团队标记这一点，以便他们能够主动介入，找出问题所在，并支持客户继续前进。

监控所有客户的 TTFHW 还可以帮助您发现趋势。例如，如果您的 TTFHW 在增加，您可能需要让您的产品和工程团队知道，因为他们的更改可能会使客户入职变得更加复杂，从而影响用户旅程。

这种数据驱动的方法还可以在客户努力使用新功能时提醒您，识别成功差距，标记使用量减少的情况(以及有流失风险的客户)，并识别追加销售和交叉销售的机会。同时确保客户感受到合作方式的支持。

监控您的客户成功努力的有效性

另一个挑战是监控客户成功努力的影响。这种类型的监控高度依赖于您的 SaaS 产品的性质。然而，使用用户漏斗将您的入职旅程分段，以及在客户遇到错误时设置警报，可以帮助您主动管理客户问题。关于衡量正在进行的工作，通过 API 调用量等指标记录与您平台的互动，可以揭示客户是否重视他们与您的体验。

您还可以通过 Moesif 等工具监控一系列客户成功指标，以获得整个业务范围的使用统计数据和趋势。这进一步将客户成功的角色嵌入到您的业务中。

在 SaaS 实现客户成功的 4 个策略

您可以实施各种策略来确保您的客户成功努力的成功。以下 4 个在 SaaS 实现客户成功的策略可以帮助你做到这一点，但是还有很多其他的客户成功策略选择，所以一定要实施对你的商业模式最有意义的策略。

识别努力整合的客户

上面的例子，Moesif 标记可能有安装和集成问题的客户，是有先见之明的客户成功管理战略的一部分。这一切都是为了在客户意识到他们能从与你的团队的互动中获益多少之前，发现问题并与他们取得联系。

有先见之明的客户支持方法的理念是，在客户对你的产品感到失望之前，你应该主动接触他们。你不要等到他们尝试了十次后就卡住了。取而代之的是，在他们还没有达到愤怒的程度之前，你就在那里打电话或提供聊天或电子邮件支持。无论他们遇到什么问题，你都能顺利地支持他们，让他们对你的产品和团队感到满意。

让好客户成为伟大的客户

另一个优秀的 SaaS 客户成功方法是个性化您的追加销售和交叉销售活动。由于许多软件销售现在依赖于买方主导的旅程，您的客户成功人员有特权获得您的客户的关注。因此，客户成功经理通常是追加销售某些服务的最佳人选。

这依赖于对每个客户需求的理解，以及您的产品支持他们实现预期结果的方式。这并不是说仅仅因为你开发了一个你认为很棒的新功能，就强行推销。相反，它是关于采取一种深思熟虑的方法来让你的新功能如何让你的客户受益，并接触那些可以从中获得真正价值的人。

这种个性化的客户成功战略符合一系列条件。这向您的客户表明，您关心他们的个人业务需求，并且您了解他们的难点和目标。这意味着您可以通过追加销售来提高客户保持率和经常性收入，而不是通过硬销售策略来降低它们。

通过电子邮件吸引客户

主动赢得客户的第三个策略是建立一个成功的生命周期电子邮件计划。这是 Moesif 可以通过与您的 CRM 集成来支持您的另一项任务。目标是向您的客户发送及时的、适合阶段的电子邮件，旨在最大化他们从您的 SaaS 产品中获得的价值。

忘掉每月一次的所有客户电子邮件，这些邮件都是通用的产品和功能推荐。它们不会对大多数顾客有所帮助，而且会因为不相关而激怒一些顾客。相反，您可以跟踪客户对您的产品的行为，并使用该数据在客户旅程的理想时间发送电子邮件，提供相关的、真正有用的功能和使用建议。

像这样的客户成功战略也带来了额外的好处。事实上，它们是数据驱动和自动化的，这意味着它们可以大规模实施。因此，无论您的客户获取战略有多成功，您仍然可以在每个客户的旅程中的正确时间接触他们，以最大化您交叉销售或追加销售的机会，并最大化他们从您的服务中获得的价值。

把顾客变成朋友

另一个关键的客户成功策略——也许是最传统的——是与你的客户交谈。他们可以告诉你他们的成功是什么样子的。他们可以告诉你什么对他们很有效，他们喜欢你产品的什么，以及他们不喜欢的。

一个完善的客户反馈流程可以大大提高您的整体客户满意度。但是要注意——象征性地寻求客户反馈可能会适得其反。毕竟，你的客户正在花时间分享他们对你的产品的看法。他们需要看到你感谢他们投入的时间，并且你正在用他们提供的数据做一些事情。

这就是在你的企业中倡导顾客的原因。客户成功团队，建立一个优秀的客户成功团队可以向产品和工程团队反馈客户面临的棘手问题以及您如何帮助解决这些问题。它可能像更改默认设置一样简单，也可能像添加一个全新的功能一样复杂。但是有了正确的反馈环，你可以向你的客户展示你的关心，支持更大的客户成功，并减少客户流失的可能性。

想知道在 SaaS 公司是什么成就了伟大的客户成功运营吗？

在 SaaS 公司创建一个伟大的客户成功运营是关于早期实施的——关于将对客户成功的真诚承诺作为一个核心商业原则。

还需要找到合适的工具和合适的人。正确的工具意味着您可以充分深入地监控您的客户成功指标，以采取有预见性的行动，并提供个性化的、适合不同阶段的客户成功体验。与此同时，合适的人将意味着你的客户与你的企业的每一次互动都会让他们感到积极。当你有一个态度正确的团队时，即使是一个遇到问题的客户也会感到满意。

我需要雇用客户成功团队或经理吗？

如果你经营的是 SaaS 商业模式，你想让你的经常性收入最大化，那么是的——只要你能负担得起。这样做当然会增加你的支出，但是有效的客户成功专家可以通过降低你的客户流失率和增加你的客户续订甚至升级他们的订阅的可能性来迅速收回他们自己的成本。他们还可以提高你的公司声誉，通过创造更快乐的客户来提升你的净推广分数。

建立一个客户成功团队时，知道从哪里开始是雇佣合适的人的关键，所以在准备你的工作规格和面试问题之前，一定要做足功课。考虑个性以及技能和知识，并确保你的招聘过程足以识别那些将有助于你和你的客户的业务长期成功的人。

建立客户成功团队时要记住的另一件事是，这不是一个孤立运作的团队。如果你的客户成功功能处于孤立状态，与你的其他业务功能隔绝，它将不会非常有效。鉴于客户成功是客户支持、产品和工程团队工作的桥梁，您需要一个适当的结构来鼓励这些团队之间的积极互动和协作。

建立客户成功团队从哪里开始

如果你准备开始建立一个客户成功团队，是时候考虑你需要的技能了。是的，如果你是一家 SaaS 企业，你可能需要有技术头脑的人，但你的客户成功管理方法的成功将依赖于更多。你需要一个关心客户体验的团队，相信客户成功的作用和价值，并且具有外交手腕、积极性和同理心，充当客户和你的产品和工程团队之间的桥梁。

客户成功经理在 SaaS 做什么？

客户成功经理负责 SaaS 业务中客户成功职能的日常运作和交付。在人事方面，他们负责管理团队。在运营方面，客户成功经理，建立客户成功团队的步骤，负责确保团队实现其目标。

客户成功经理通常向首席客户官或客户成功副总裁(取决于组织的规模)报告，他们负责企业客户成功计划的整体绩效。客户成功经理的职责是监督该客户成功计划的日常运作和实现，为客户成功制定计划。

在您的公司中发展客户成功倡导者

你的客户成功项目的优势很大程度上取决于你雇佣的客户成功倡导者的质量。客户成功倡导者是与您的客户一对一合作的团队成员。他们的职责包括建立强大的客户关系，提供技术援助和见解，并在您的业务中代表客户进行宣传。通过这种方式，他们将确保客户为您的产品实现最大价值，从而提高您的客户保持率和更新率。由于利率是你的 SaaS 业务的命脉，很容易理解这个角色的巨大价值。

您的客户成功经理需要与每位客户成功倡导者密切合作，以确保他们得到全力支持。这应包括适当的指导和训练，以确保提供的所有支持符合您的业务价值观和实践。

来自客户成功倡导者的反馈在与您的客户支持、产品和工程团队建立联系方面非常宝贵。这些互动越有效，以最好地支持现有客户的方式发展你的产品和业务的空间就越大。这样做不仅可以降低你的客户流失率，还可以提高你获得新客户的潜力，因为你的产品开发将保持与目标受众不断变化的需求相关。哪个 SaaS 企业能够忽视这种潜在的好处呢？

最后的想法

客户成功不是你的 SaaS 企业在未来某一天应该考虑的“拥有就好”的功能。这是现代 SaaS 模式的一个重要组成部分，它可以将一家普通企业转变为一家鹤立鸡群的企业——当然是在做得好的时候。

从基于客户成功指标推动见解和行动的正确工具，到您雇用的人员的质量和您实施的客户成功战略，您有潜力快速扩展您的 SaaS 业务。始终将对客户成功的承诺放在运营和方法的核心位置。因为客户的成功是每一家 SaaS 企业赖以发展和生存的经常性收入的基础。

如何加速 API 与行为邮件和开发人员细分的集成

原文：https://www.moesif.com/blog/technical/behavioral-emails/How-To-Accelerate-API-Integration-with-Behavioral-Emails-and-Developer-Segmentation/

行为电子邮件是以用户为中心的平台集成的基石——给开发者的电子邮件在基于他们如何使用你的平台时最有效。毫不奇怪，将你的客户划分为具有相似行为或态度的群体的概念是市场营销中公认的最佳实践。

MarketSherpa 的调查发现，最有效的营销策略之一是根据客户的行为发送电子邮件。B2C 世界中常见的例子包括，服务已注册但注册未完成的通知，表单提交后收到抵押品，购物车被放弃后邀请结帐。

对于 API 平台公司来说，行为电子邮件也是一种非常有效的沟通方式，可以帮助开发人员加速 API 集成和尝试新产品功能，同时让他们了解订阅和平台问题。

目录

• 为什么 API 优先公司会使用行为电子邮件
• 加速 API 集成的步骤
  • 1。按工作类别细分
  • 2。欢迎邮件
  • 3。基于使用的电子邮件
• 试用未使用的 API 产品特性
• 及时了解订阅和平台问题

为什么在 API 优先的公司中使用行为电子邮件

行为电子邮件是根据客户的行动或行为自动发送给客户的有针对性的消息。通过触发你的客户如何与你的网站或产品互动，你能够发送内容与他们正在做的事情实际一致的电子邮件，因此更有可能引起共鸣。

在 API 平台公司中，触发行为通常围绕 API 产品参数，如事件计数、端点利用率、状态码等。我们自己的客户已经研究过围绕某些动作和用户类型发送不同的消息。例如:

ShipEngine，一个航运物流 API 平台，查看 的出货量使用量和的每月出货量，发送定制的自动订阅计划邮件。

Radar 是一个位置基础设施 API 平台，当客户创建他们的第一个地理围栏时，或者当他们进行第一次位置自动完成 API 调用时，它会发送交易电子邮件。

在 Moesif 中，我们已经从静态的试用注册活动转向定制的自动化电子邮件。通过关注客户在入职过程中的表现，我们将基于客户的营销 (ABM)推向了新的高度。通过将角色或行业定位与我们产品的参与度相结合，我们看到了客户整合度的显著提高。

加速 API 集成的步骤

提高 API 集成率可以通过向受众提供相关内容来实现，而最简单的方法就是将您的客户划分为具有相似特征的群体。针对每个群体，针对该群体的行为特征，创建一个电子邮件活动，或工作流序列。

1.按工作类别细分

注册后，新用户应该选择一个角色。对于 API 平台公司，典型的工作职能包括:产品、工程、营销、客户成功、开发者关系、销售、支持和高管。

2.欢迎电子邮件

将角色作为第一标准，发送一封欢迎电子邮件，重点关注对受众最重要的关键问题。例如，API 平台公司的开发人员最关心的是如何快速将健壮的产品推向市场。因此，缩短调试时间和防止新问题出现将会产生良好的反响。下面是一个例子，我们在这方面取得了很大的成功。请注意，单一行动号召(CTA)会将收件人带到针对其专业领域定制的登录页面。

相反，产品经理希望推动平台的采用，因此他们的关键信息更多地是做出明智的决策来刺激参与。在我们的博客文章每个 API 产品公司都应该使用的五大行为邮件中，我们详细介绍了 API 优先公司最重要的邮件。

3.基于使用的电子邮件

在有针对性的欢迎邮件之后，是时候进一步细分了，但这次使用的是行为标准，而不是人口统计标准。因为我们对推动 API 集成最感兴趣，所以我们关注与客户在集成漏斗中的位置相关的消息:顶部、中部或底部。根据 API 调用的数量，我们将客户分成三组:

API 事件数/天	阶段	描述
0 个事件	顶端	尚未集成
0	中间	仅集成在沙盒中(小于自由计划)
事件超过 1，000	底部	集成到生产中(大于自由计划)

通过与我们的 MarTech 工具 HubSpot 的集成，我们将使用的事件计数 API 参数(客户调用 API 的次数)从 Moesif 分析工具传递给 CRM。然后，根据 API 事件的数量，我们将客户登记到三个定制工作流之一:

序列#1:预集成

如果试用用户没有通过 API 发送任何流量，我们知道他们没有成功集成，所以重点应该更多地放在教育和集成的难易程度上(即，出色的开发人员体验)。我们的目标是让他们第一次参加 Hello World 也叫 Time to First Hello World 。为了做到这一点，我们分享关于开发者中心问题的有用文章、信息图表和电子书，并穿插来自开发者关系团队的温和的轻推/提供帮助。通过让开发人员的交流不要太虚假，他们会看到他们从你的公司以及最终从你的 API 中获得的价值。尽可能找到共同点来建立相互尊重也是一个好主意，比如上面邮件中的评论:“我们的创始人本身就是 API 工程师。他们自己也在缓慢的手动日志搜索中苦苦挣扎。”为此，我们吃自己的狗粮，并为过去 7 天内注册但尚未发送任何 API 调用的用户建立行为群组:

我们发现 3:1 的节奏相当成功——对于每三条有见地的内容，我们都会提供帮助。任何更频繁的“询问”都会导致开放率下降。

在我们的整合漏斗顶端运作良好的示例宣传材料包括:

• 您应该跟踪的 15 个 API 指标信息图，
• 如何掌握采用和保留指标电子书，或者
• 预览我们的自助服务演示应用。

还有一个不太强势的例子:

序列#2:沙盒集成

开发人员已经注册并提出了他们的第一个 API 请求，但是有些事情阻碍了他们将应用程序投入生产。不要只关注开发者的体验，现在是时候展示他们从你的 API 中获得的价值，并帮助他们消除任何障碍。从最初签约到推广到生产的时间有时被称为第一个工作应用程序的时间或第一个付费应用程序的时间。

说明价值的最佳方式是通过案例研究和高级特性。展示您的 API 平台如何满足其他客户的需求，并解决他们的棘手问题。通过联系其他真实世界的例子，开发人员将有希望看到他们也能从你的解决方案中得到帮助。

尽管你主要是和开发者打交道，但是在企业销售中有很多不同的利益相关者。您需要经常处理决策者、法律和安全审查、其他项目优先级以及功能和性能测试。提供宣传材料和工具，帮助开发人员解决集成问题，同时确保他们在以下方面放心:

• 安全性和合规性，
• GDPR/CCPA 支持，
• 支持基础设施的可扩展性和成本降低。

最后，帮助开发人员验证他们的集成。通过使用基于他们在过去几天中进行的 API 事务数量的触发器来自动发送此电子邮件。

顺序#3:生产整合

既然客户已经投入生产，那么就利用您的 API 平台的所有功能来推动转换。定期让他们了解您的最新功能发布、比较指南和投资回报分析。现在是时候通过指出他们可以期待的附加价值和他们可以实现的补充结果来进一步激活用户了。如果他们仍然没有转变为付费，这些序列旨在通过发现是什么利益相关者阻碍了他们来解决这些问题。否则，考虑到它们的 API 使用水平，这些序列非常适合推动向上销售。

尝试未使用的 API 产品功能

与上面的生产集成阶段密切相关，但真正适用于转换漏斗的任何阶段的是让客户了解新的/未使用的 API 平台特性的愿望。最好的方法是根据客户活动自动发送电子邮件。

在我们上一节关于加速 API 集成的步骤中，我们使用 API 调用量作为触发事件，但是我们可以使用一个更加微妙的指标。尤其是在较大的公司中，关注点将集中在端点利用率和流量模式分析等方面，相应的电子邮件如下:

“您使用过这个特殊的端点吗？让我们带您开始使用它的新功能集。”随着新组件的集成和使用，以及客户经历整个生命周期，您可以通过重复该过程来引入更多的端点。

“我们注意到您在 7 天前停止发送流量。我们能为您提供端点 X 的帮助吗？”这是一种无需手动操作就能让客户了解信息的好方法:

电子邮件营销自动化工具非常擅长发送常规的大规模营销电子邮件，如时事通讯、新闻公告等。当你想根据五个不同的动作发送一封电子邮件，每个动作完成五次，这在任何 MarTech 平台上几乎是不可能的。对于这些行为驱动的客户电子邮件，真正需要的是像 Moesif 这样的定制平台，它被设计为基于 API 平台本身内部的特定指标发送电子邮件。

Moesif 的行为电子邮件和工作流功能是定制的，可以在您的产品中使用多个触发器轻松配置和设置交易电子邮件。同样，基于以用户为中心的事件的电子邮件工作流可以使用我们简单的图形界面来实例化。

随时了解订阅和平台问题

客户希望了解其平台投资的进展情况，但订阅和维护通知可能会非常昂贵，而且耗费时间。Moesif 的行为电子邮件功能使支持、CSM 和工程团队无需人工操作即可扩展客户拓展工作。

现在，可以在 Moesif API 分析工具中自动配置和发送通知，而不是由某人发送电子邮件通知客户的 API 调用限制已超过其配额:

对于自助式 API 平台，您现在能够经济地扩展涵盖许多常见订阅问题的开发人员外展电子邮件，包括:订阅使用、费率限制和大小合适的计划电子邮件等。

此外，配置 Moesif 将维护问题发送给所有客户，甚至是您的客户的子集，这也很简单。例如，在某些情况下，您可能只想通知可能受到平台漏洞影响的特定客户群，而不想向整个客户群发送电子邮件。现在，您可以使用我们的行为电子邮件功能。

如何加速 API 产品收入

原文：https://www.moesif.com/blog/api-monetization/api-strategy/How-To-Accelerate-API-Product-Revenue/

API 可以对你的业务产生巨大的影响，创造价值并带来新的收入流。但是他们并不总是以你一开始可能想象的方式去做。这意味着，当谈到 API 货币化时，it 可以为意外情况做好准备。

为 API 货币化奠定基础

如果你刚刚开始涉足 API，或者你有一个收入停滞不前的现有产品，是时候启动一个项目让事情重新运转起来了。分析是这个过程的开始。您可以使用分析来深入了解人们如何使用您的 API，利用这些知识，提取流行的功能、API 术语中的端点，并将其货币化。

以这种方式使用分析可以使您通过从现有产品中分离出端点，从 API 中产生另一条业务收入线。这是一种将你产品的单个元素货币化的方式，而不是仅仅关注产品整体。

货币化在行动

看到理论付诸实践总是有帮助的，所以让我们快速看一下 NexHealth 的 API 货币化例子。NexHealth 最初是一个 SaaS 平台，为医生和牙医办公室提供在线患者调度和双向通信。为了做到这一点，该公司与许多不同的数据库接口。

当 NexHealth 的客户看到这些互联数据库所提供的潜力时——即与任何包含医疗记录的数据库轻松接口的能力——他们对这种可能性感到非常兴奋。因此，NexHealth 推出了一个从现有产品中剥离出来的 API。新的 API 使客户能够与所有这些数据库进行交互，Moesif 帮助 NexHealth 将 API 接口货币化。

NexHealth 的成功源于其愿意剥离其原始产品的单一功能，根据市场需求灵活和扩展，从而最大限度地加速其原料药的货币化。到 2022 年 4 月，NexHealth 的 C 轮融资让该公司获得了 1.25 亿美元。在撰写本文时，其估值为 10 亿美元。

“从长远来看，API 将是收入的一个更大驱动因素，因为我们有一个更大的销售市场。不仅仅是医生，还有病人。这将是消费者，这将是实验室和药房的人…任何需要访问医疗保健数据的人。这将是我们的市场；这将是巨大的。”NexHealth 首席技术官瓦利德·阿西夫

专注于 API 货币化

有不同的方法可以让 API 货币化。免费增值模式、订阅、现收现付和收入分成模式都可以提高你的底线。使用你的 API 来增加你网站的流量或者激励第三方采用你的产品也可以帮助你充实你的金库，尽管不那么直接。

所有这些的关键是货币化思维。毕竟，如果你的产品卖不出去，那你造出来又有什么用呢？专注于盈利就是将API 作为产品提供以增加收入——优化你的业务，让你的 API 产生最大可能的影响。之后，问题是深入了解人们是如何使用这些 API 的，以及如何最好地从中获利。

这种对 API 及其所能提供的东西的关注——被称为 API 经济——并不新鲜。多年来，老牌全球巨头一直采用他的方法。例如，杰夫·贝索斯早在 2002 年就在亚马逊发布了 API 指令，要求所有的功能都必须以 API 的形式设计和公开。自那以后，亚马逊的表现相当不错。

API 可以实现大量的商业模式和数字体验。但是，不仅仅是 Meta、Google 之类的公司能够通过将 API 放在他们战略的核心位置来实现伟大的事情。任何一家拥有 API 的公司，无论在世界的哪个角落，都有可能通过开发独立的特性来最大化其 API 程序的价值。

最大化 API 价值

根据麦肯锡的分析，在 API 程序中有三个主要的价值来源:

• 简化后端
• 个性化优惠
• 创新和参与的生态系统

简化后端允许轻松的 API 集成、任务自动化和加快上市速度。与此同时，个性化服务可以通过精心设计的数据汇总和报告来提高客户参与度。创新和参与的生态系统可以支持客户体验的改善以及新产品和服务的创造。

采用这种方法意味着您在开发新特性和加速新 API 产品的收入方面处于最佳位置。接受 API 第一的思想是这一点的核心。商业分析公司 SAS 的首席 API 架构师 Jeannie Hawrysz解释道:

“所有的 API 在设计时都应该考虑到有一天它们会被外部化，所以产品经理的商业理念必须回答这样一个问题:‘这个 API 适合我的目标受众吗？’"

以这种方式将 API 放在第一位，以加速从中获得收入，这对于各种形式和规模的公司都是可能的。更老、更成熟的企业可能不得不处理相互竞争的优先级，但这并不一定会阻碍 API 收入的加速，只要公司的心态坚定地专注于 API。霍利斯继续说道:

“专注于全新的、有潜力的、尚未被证实的事物，尤其是在一家有 40 多年历史的公司中，这自然会与其他业务重点相竞争。随着时间的推移，我们拥有的许多其他优先事项已经在赚钱了。而且，在它成为现实之前，我们理论上认为 API 会赚钱。尽管如此，潮流确实在改变。我们已经从我们的领域中获得了许多用例。我们一直与该领域的领导者保持联系。他们一直在寻求高价值、易于使用的 API。”

寻找合适的合作伙伴

正如 NexHealth 出色地展示的那样，当涉及到 API 货币化和推出新功能以增加收入时，与正确的合作伙伴合作至关重要。NexHealth 最初从其 API 客户那里获得的经常性收入不到 10%。展望未来，预计大部分收入将来自其新的 API 产品，而分析在推动这一增长方面将发挥关键作用。首席技术官瓦利德·阿西夫简洁地总结了与合适的合作伙伴合作实现这一目标的重要性:

“在 Moesif 之前，我们不知道谁在使用我们的平台，谁没有。在 Moesif 到位之前，我们甚至无法向客户收费。”

也不仅仅是外部合作伙伴可以提供帮助。SAS 的 Jeannie Hawrysz 强调了在企业内部寻找盟友的重要性:

“在业务方面，特别是如果你刚开始组建一个项目，寻找盟友……对 API 顶礼膜拜是一回事，我们在内部称自己为 API 很重要’，但当其他团队，特别是面向客户的团队开始支持我们时，事情才真正开始加速。”

API 收入加速的另一个很好的例子是 Okra。由于其开放金融应用编程接口(Open Finance API ),这家非洲企业正在快速扩张，该应用编程接口支持整个非洲大陆数千家企业的金融服务应用。该公司正在努力将 10 亿非洲人与全球经济联系起来，使用 API 帮助企业加快入职速度、评估风险、验证交易、检查消费模式，并为客户构建个性化的金融服务解决方案。

Moesif 的 API 分析正在支持 Okra 可视化其客户群中正在大规模发生的事情。通过与 Moesif 合作，Okra 已经能够将其支持票据减少 80%以上，并将客户从注册到生产部署的时间减少 2 倍以上。结果呢？更快的 API 创收。

在全球范围内，数字经济正在快速发展。那些准备重新审视现有产品，并准备以新的方式扩展其某些功能的公司，可能就是那些将企业从高原推向独角兽领域的公司。

如何将 Moesif API 分析和监控添加到 Kong 入口控制器

原文：https://www.moesif.com/blog/technical/kong/kubernetes/How-to-Add-Moesif-API-Analytics-and-Monitoring-to-Kong-Ingress-Controller/

Kong 是一个流行的开源 API 网关，可以帮助你管理你的 API。有了 Kong，即使您有多个微服务，您也可以从一个集中的位置处理身份验证、速率限制、数据转换等事务。Kong 的核心是 NGINX，这是最流行的 HTTP 服务器之一。由于是开源的，Kong 很容易在内部部署，通常只需要几分钟，除了 Postgres 或 Cassandra 商店之外，不需要安装许多组件。

Kong Ingress Controller 在 Kubernetes 集群中实现认证、转换和其他功能，无需停机。Kong Gateway 将 Kubernetes 集群与跨任何环境或平台运行的服务连接起来。通过与 Kubernetes 入口控制器集成，Kong 与 Kubernetes 的生命周期直接相关。随着应用程序的部署和新服务的创建，Kong 将自动对自身进行实时配置，以便为这些服务提供流量。Kong 和 Kong Ingress 控制器拥有完整的管理层和 API、目标和上游的实时配置，以及使用 Postgres 或 Cassandra 的持久、可扩展的状态存储，可确保每个 Kong 实例同步时没有延迟或停机时间。

Moesif 为 Kong 提供了一个插件，只需几分钟就可以开始使用 API observability ，这样您就可以专注于提供客户喜欢的功能，而不是处理构建自己的数据基础设施的维护成本。借助 Moesif，您可以了解 API 的使用方式和用户，确定哪些用户遇到了集成问题，并监控需要优化的终端。在本文中，我们将讨论 Moesif 给你的见解，以及如何将其与 Kong Ingress 控制器集成。然后，我们将讨论如何使用 Moesif 和 Kong 来最好地利用 API 可观测性。

概观

Moesif Kong plugin 是一个代理，它收集指标并发送给 Moesif 收集网络。这使您能够全面了解 API 的使用情况，即使是跨不同的 Kong 实例和数据中心区域。Moesif 为工程团队提供了深刻的见解，以了解如何使用他们的 API，并快速解决复杂的问题。因为 Moesif 还跟踪谁在调用你的 API 以及它们是如何被访问的，所以产品驱动的团队可以了解整个客户之旅以及在哪里投入更多的资源。借助 API 可观察性，具有前瞻性思维的工程领导者可以通过对激活漏斗、保留报告等进行自助式分析，增强面向客户的团队的能力。Moesif 还分析您的 API 有效负载，以便进行故障排除和业务洞察，这样您就能够了解特定有效负载键的使用情况，等等。

设置 Kong 入口控制器

请注意只有在没有设置和运行入口控制器的情况下，才需要执行此步骤。如果您已经运行了 ingress 控制器，请参考如何在现有 kong ingress 控制器运行的情况下加载 moesif 插件的步骤。

我们将执行以下步骤来部署入口控制器并加载 Moesif 插件。

使用 Moesif 插件代码创建配置映射:

您将需要克隆 kong-moesif-plugin 并导航到kong/plugins目录以使用

kubectl create configmap kong-plugin-moesif --from-file=moesif -n kong 

请确保在与将要安装 Kong 的名称空间相同的名称空间中创建它。

创建名称空间

如果已经创建了想要使用的名称空间，那么可以跳过这一步。但是请确保使用安装了 Kong 的同一个空间。

{  "apiVersion":  "v1",  "kind":  "Namespace",  "metadata":  {  "name":  "kong",  "labels":  {  "name":  "kong"  }  }  } 

使用创建命名空间

kubectl apply -f namespace.json 

添加孔图表

您需要添加 kong 图表，并通过 Helm 更新回购。

# Add kong chart 
helm repo add kong https://charts.konghq.com

# Update helm repo
helm repo update 

部署 Kubernetes 入口控制器并加载 Moesif 插件:

使用 Helm，您可以通过将以下值添加到您的values.yaml文件来加载 Moesif 插件:

# values.yaml
plugins:
  configMaps:
  - name: kong-plugin-moesif
    pluginName: moesif 

设置 Kubernetes 入口控制器并使用 Helm chart 加载 Moesif 插件非常简单:

helm install kong kong/kong --namespace kong --set ingressController.installCRDs=false --values values.yaml 

设置环境变量

您将使用可访问 Kong 的 IP 地址设置一个环境变量。这将用于实际向 Kubernetes 集群发送请求。您将为 kong-proxy 创建一个隧道并获取 url。

如果您在 Amazon Elastic Kubernetes 服务(EKS)上部署 Kong Ingress，您将需要使用

export PROXY_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].hostname}" service -n kong kong-proxy) 

请注意如果您的kong-proxy服务被不同地命名，您必须相应地更改命令。

请注意如果您通过不同的方法部署 Kong Ingress，请参考文档关于如何设置环境变量。

您可以回显环境变量，使用-

echo $PROXY_IP
# http://192.168.99.100:32728 

测试与孔的连接

这里假设PROXY_IP环境变量被设置为包含指向 Kong 的 IP 地址或 URL。如果您还没有这样做，请按照其中一个部署指南来配置这个环境变量。

如果一切都设置正确，那么向 Kong 发出请求应该会返回 HTTP 404 Not Found。

curl -i $PROXY_IP
HTTP/1.1 404 Not Found
Date: Fri, 21 Jun 2019 17:01:07 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Content-Length: 48
Server: kong/1.1.2

{"message":"no Route matched with those values"} 

这是意料之中的，因为孔还不知道如何代理请求。请注意如果你正在使用 minikube，确保 LoadBalancer 类型的服务通过minikube tunnel命令公开。它必须在单独的终端窗口中运行，以保持负载平衡器运行。终端中的 Ctrl-C 可用于终止进程，此时将清理网络路由。

接下来，我们将全局启用 Moesif 插件。

在现有 Kong 入口控制器运行的情况下加载 Moesif 插件

请注意只有在没有执行上一步的情况下，才需要执行这一步。当你已经运行了 Kong Ingress 控制器并且想要启用 Moesif 插件时，你应该执行这个步骤。

本节假设您已经运行了 kong ingress 控制器，并希望加载 Moesif 插件。这也假设你已经有舵孔图可用，如果没有请添加舵孔图。

使用 Moesif 插件代码创建配置映射:

您将需要克隆 kong-moesif-plugin 并导航到kong/plugins目录以使用

kubectl create configmap kong-plugin-moesif --from-file=moesif -n kong 

请确保在与将要安装 Kong 的名称空间相同的名称空间中创建它。

部署 Kubernetes 入口控制器并加载 Moesif 插件:

使用 Helm，您可以通过将以下值添加到您的values.yaml文件来加载 Moesif 插件:

# values.yaml
plugins:
  configMaps:
  - name: kong-plugin-moesif
    pluginName: moesif 

展开部署

您需要使用 Moesif 插件修补 kong 入口控制器部署，并部署部署。

helm upgrade kong kong/kong --namespace kong --values values.yaml 

接下来，我们将全局启用 Moesif 插件。

全局启用 Moesif 插件

请注意无论您执行了上述哪个步骤，您都需要执行该步骤。这是一个关键的部分，它将在全球范围内启用 Moesif 插件，并开始向 Moesif 记录数据。

要设置 KongClusterPlugin 资源，您需要 Moesif 应用程序 Id。您可以通过注册一个免费的 Moesif 帐户来获得一个，然后在入职时选择 Kong。Moesif 建议对所有的 Kong 实例和数据中心区域使用单一的应用程序 Id。这确保了无论物理拓扑如何，您都有一个 API 使用数据的统一视图。使用 Moesif 的高基数、高维度分析引擎，您仍然可以根据任意数量的属性进行分解。

Moesif 仍然建议为每个环境创建单独的应用程序 id，如生产、试运行和开发，以保持数据隔离。

创建一个global-plugin.yaml文件

apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
  name: moesif
  annotations:
    kubernetes.io/ingress.class: kong
  labels:
    global: "true"
config:
  application_id: Your Moesif Application Id
  debug: false
plugin: moesif 

然后全局应用插件。

kubectl  apply -f global-plugin.yaml 

请注意将标签 global 设置为“true”将在 Kong 中全局应用插件，这意味着它将为通过 Kong 代理的每个请求执行。

请确保在与安装 Kong 的名称空间相同的名称空间中创建。如果您的名称空间与kong不同，您应该相应地更改这个命令。

查看 Moesif 插件的运行情况

此时，如果您已经配置了 Kong 资源(服务),那么通过 Kong 代理的所有 api 调用都将记录在 Moesif 中。您不必执行接下来的步骤，因为这只是一个为想要创建示例服务的人创建服务/资源的示例。

建立回声服务

设置一个 echo-service 应用程序，演示如何使用 Kubernetes 入口控制器:

kubectl apply -f https://bit.ly/echo-service -n kong 

请注意，echo-service文件没有被更改，它正在监听端口80。

请确保在与安装 Kong 的名称空间相同的名称空间中创建。如果您的名称空间与kong不同，您应该相应地更改这个命令。

创建一个使用 Moesif 插件的新入口资源

您可以对入口或服务资源进行注释，以指示 Kong 何时执行插件。您可以在全局范围内、在服务资源上或为特定用户配置插件。这将创建一个入口规则来代理先前创建的 echo 服务器。

echo "
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: demo-example-com
  annotations:
    kubernetes.io/ingress.class: kong
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /bar
        backend:
          serviceName: echo
          servicePort: 80
"  |  kubectl  apply  -f  -  -n  kong 

请注意因为在我们之前创建的echo-service中，端口80是暴露的，所以servicePort被设置为80。如果您在不同的端口公开了服务，请相应地更改servicePort。

请确保在与安装 Kong 的名称空间相同的名称空间中创建。如果您的名称空间与kong不同，您应该相应地更改这个命令。

发送请求

一旦安装了 Moesif 插件，您的 API 流量应该会出现在 Moesif 的实时事件流中。您可以向使用配置的资源发送流量

curl -i -H "Host: example.com" $PROXY_IP/bar/sample 

如果一切设置正确，您将看到 200 响应。下面是示例响应的样子-

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Date: Wed, 17 Nov 2021 21:31:04 GMT
Server: echoserver
X-Moesif-Transaction-Id: f8a8660e-1843-4844-89a7-67fbf2ac15ae
X-Kong-Upstream-Latency: 1
X-Kong-Proxy-Latency: 0
Via: kong/2.5.1

Hostname: echo-5fc5b5bc84-5s772

Pod Information:
	node name:	ip-192-148-47-105.us-west-2.compute.internal
	pod name:	echo-5fc5b5bc84-5s772
	pod namespace:	kong
	pod IP:	192.118.36.8

Server values:
	server_version=nginx: 1.12.2 - lua: 10010

Request Information:
	client_address=192.368.25.12
	method=GET
	real path=/bar/sample
	query=
	request_version=1.1
	request_scheme=http
	request_uri=http://example.com:8080/bar/sample

Request Headers:
	accept=*/*
	connection=keep-alive
	host=example.com
	user-agent=curl/7.68.0
	x-forwarded-for=192.178.50.41
	x-forwarded-host=example.com
	x-forwarded-path=/bar/sample
	x-forwarded-port=80
	x-forwarded-proto=http
	x-moesif-transaction-id=f8a8660e-1843-4844-89a7-67fbf2ac15ae
	x-real-ip=192.178.50.41

Request Body:
	-no body in request- 

如何使用 API 可观察性

工程度量

您可能感兴趣的第一件事是工程度量，比如我的 API 性能如何。这种类型的指标可以通过进入 Moesif 中的事件->-时间序列视图获得。然后，您可以选择第 90 个百分位数的延迟作为要绘制的指标。然后，您可以按 URI 路由分组，以了解哪些端点的性能最差。在这里，您可以通过 API 属性(如 route、verb)以及 HTTP 头和主体字段来过滤流量。

处理敏感数据

如果您的应用程序包含敏感数据，如医疗保健或财务数据，您可以通过以下两种方式之一实现数据合规性:

1.零知识安全

客户端加密具有低维护 SaaS 的优势，同时仍然让您能够控制您的数据。因为在发送给 Moesif 之前，您在内部对数据进行控制和加密，所以 Moesif 实际上无法访问您的数据。这只需要在您的基础设施中运行一个名为安全代理的小型设备，即可动态处理数据的加密/解密。

2.数据屏蔽

如果不想客户端加密，也可以直接使用插件屏蔽数据。这通过config.request_body_masks和config.response_body_masks配置选项来处理。例如，您可以屏蔽有效负载中可能出现的名为密码的字段。此外，如果您想一起删除日志请求和响应主体，您可以将config.disable_capture_request_body或config.disable_capture_response_body配置选项设置为true。

结束语

通过这种方式，Moesif 插件将捕获 API 请求和响应，并记录到 Moesif，以便通过 Kong 和处理应用程序周围所有其他服务的 Kong，实现深入的 API 可观察性和对 API 流量的实时监控。

如何用 Moesif 为 Postman 自动创建 API 测试

原文：https://www.moesif.com/blog/technical/api-testing/How-to-Automate-Creating-API-Tests-for-Postman-with-Moesif/

在创建 API 时，我们都有自己喜欢的工具。这里的主要玩家之一是邮差。一个图形化的 HTTP API 客户端，允许我们构造、发送和保存对我们选择的 API 的请求。

Moesif API Analytics 甚至允许我们从用户收集的真实请求中生成邮递员集合。

保存和管理请求

保存请求并在集合和文件夹中管理它们的能力是测试自动化的基础，因为对于每个请求、文件夹和集合，我们还可以保存两个脚本。Postman 在请求发生前后执行这些脚本。

这些集合可以导出为 JSON 文件，并通过一个名为 Newman 的 CLI 工具运行。这个导出允许我们将所有的请求版本化，用一个友好的 UI 工具为它们编写测试，然后将它们集成到我们的 CI/CD 管道中。

为了将测试脚本与 Postman 请求集成，我们必须首先创建一个新的集合。对于一个简单的 API，我们可以对整个 API 使用一个集合。

要创建集合，我们必须执行以下步骤:

1. 点击左侧工具条中的收藏标签
2. 点击收藏选项卡内的新收藏
3. 输入新集合的名称，如“我的 API”
4. 点击创建

有了保存请求的集合，我们现在可以定义这些请求。

要创建请求，我们必须遵循以下步骤:

1. 右键单击新集合
2. 选择添加请求
3. 输入请求名称
4. 点击保存到我的 API

新的请求显示在我们创建的新集合下的左侧栏中。它不会有任何目标网址，所以目前无法发送。

如果我们点击请求，我们可以输入请求 URL 。让我们输入example.com，点击发送！。

Postman 向example.com服务器发送一个GET HTTP 请求，然后服务器用一个 HTML 页面进行响应。

如果我们现在单击 Save ，我们的请求将在我们之前创建的集合中更新。

集成测试和请求

现在我们已经保存了我们的请求，我们可以在每次启动 Postman 时加载它，然后再做一次。

我们甚至可以通过点击左侧工具条中收藏右下角的 … 并选择导出来导出它所在的收藏。该导出创建一个 JSON 文件；我们可以与其他开发人员共享，并将它放入版本控制中。

我们要做的下一件事是向我们的请求添加脚本。

有两种类型的脚本:

1. 预请求脚本，在发送请求之前执行
2. 测试，在收到响应后执行

如果我们选择我们的请求，我们可以在输入目标 URL 的文本字段下方看到预请求脚本和测试选项卡。

让我们通过选择 Test 选项卡并将以下代码粘贴到文本区域来添加一个测试脚本:

pm.test("response is ok", () => {
  pm.response.to.have.status(200);
}); 

当我们点击右上角的发送时，代码在 Postman 收到响应后执行。在这个测试中，我们简单地检查响应是否有一个200状态。

我们可以在点击发送后看到这个测试的结果；我们只需要向下滚动；在文本区域下，我们用来输入测试。在测试结果(1/1) 标签中。

当我们点击 Save 时，除了我们的请求之外，我们的测试也被保存在我们的集合中。如果我们稍后导出它，它可以作为一个字符串在我们的集合 JSON 中找到。

写作测试

在文本区的右边，我们可以找到代码片段和 Postman 脚本文档的链接。这些代码片段也适用于预请求脚本；它们可以用来动态地生成我们请求的一部分，比如头或参数。

让我们在一个代码片段的帮助下编写一个稍微复杂一点的测试！

为此，我们首先删除我们的测试代码，然后单击文本区域右侧的代码片段。

选择响应体:包含字符串

这会生成以下代码:

JavaScript pm . test(" Body matches string "，function(){ pm . expect(pm . response . text())). to . include(" string _ you _ want _ to _ search ")；});

This snippet extracts the text of our response and tries to find a specific string in it.

To find an actual string in our response from `example.com`, we need to scroll down and select the **Body** tab.

Here we see the HTML that got delivered. We can select a part of it and use it in our test instead of the `"string_you_want_to_search"` placeholder.

Let's select **This domain is for use in illustrative examples in documents.** and update our test, so it looks like the following:

```javascript
const expectedText = "This domain is for use in illustrative examples in documents.";
pm.test("Body matches string", function () {
  pm.expect(pm.response.text()).to.include(expectedText);
}); 
```py

如果我们再次点击**发送**，我们可以在**测试结果**下看到我们的测试工作正常。

## 导出测试

下一步是导出我们的测试，这样我们就可以在 CI/CD 管道中使用它。为此，我们需要导出我们的集合，其中包括我们的测试。

通过点击左侧栏中我们收藏的省略号( **…** )并从上下文菜单中选择 **Export** 来导出收藏。

在对话框中，我们选择**收藏 v2.1** ，因为邮递员建议我们这样做，然后点击**导出**。

导出格式有点粗糙，但易于阅读。这些测试是带有 JavaScript 的 JSON 字符串，因此它们可以用编辑器来操作，但是使用 Postman 至少给了我们一些 IDE 特性。

## 通过 Newman CLI 运行测试

现在我们已经以 JSON 格式导出了我们的集合，我们可以使用这个导出的文件在命令行中运行我们的测试。

名为 [newman](https://github.com/postmanlabs/newman) 的 CLI 工具用于在命令行中运行 Postman 集合。

当我们用`run`命令执行它并提供我们导出的集合文件的路径时，它试图发送我们定义的所有请求并执行测试脚本。

对于我们的 **My API** 集合，可能是这样的:

$ npx newman run My\ API.postman_collection.json

如果 NPM 不可用，也可以在全球范围内安装纽曼。

## 使用 Moesif 创建邮递员集合

Moesif 允许我们从真实的用户请求中[生成邮递员集合](https://www.moesif.com/docs/api-analytics/run-in-postman/)。这允许我们用真实数据在本地调试我们的 API！我们也可以稍后在我们的测试套件中集成请求，在我们的 CI/CD 管道中与 newman 一起运行它，因此我们可以确保过去导致问题的请求不是任何回归错误的一部分。

要使用 Moesif 创建集合，我们必须遵循以下步骤:

1.  登录 Moesif
2.  点击顶部的 **API 分析**选项卡
3.  选择我们希望包含在集合中的请求
4.  点击**运行邮递员**
5.  点击**下载邮差合集**

然后可以将生成的集合导入到 Postman UI 应用程序中，然后添加测试或修改请求，以便它们可以与 Newman CLI 工具一起使用。

## 结论

Postman 是一个非常通用的工具，可以帮助我们构建和测试我们的 API。如果我们导出我们的集合并为它们编写测试，Postman 与 Newman 一起会变得更加强大。

我们可以用友好的用户界面编写测试，将它们导出到 JSON，这样它就可以和我们的 API 代码一起存储。导出允许轻松的版本控制和与 CI/CD 管道的集成。

Moesif 通过允许我们为 Postman 导出从真实用户请求生成的请求集合，降低了创建这些测试的工作量，因此我们可以通过用真实数据替换假设来强化我们的测试套件。

当新开发人员检查我们的代码时，他们可以简单地启动 Postman 并运行一些带有相应测试的请求来完成他们的工作，因此它甚至有助于入职。

# 如何避免虚荣心的 API 指标，并最好地衡量开发者平台的开发者成功

> 原文：<https://www.moesif.com/blog/engineering/api-monitoring/How-to-Avoid-Vanity-API-Metrics-and-Best-Measure-Developer-Success-for-Developer-Platforms/>

在多年为许多公司提供建议和咨询的过程中，从种子阶段的初创公司到独角兽和公共实体，我观察到许多团队和企业在定义成功指标时都忽略了这一点。

有趣的是，开发者平台更有可能是这种情况。我经常听到“看看在我们的平台上创建了多少 API 键/开发时间/{Marklar}！”因为我会问“你有多少活跃的开发人员？”或者“您的合作伙伴应用的采用率是多少？”我会触动你的神经。

在 API 世界中，虚荣度量可以像在任何其他产品领域一样被加入。我已经记不清有多少次公司向我吹嘘他们的系统进行了多少次 API 调用，认为这是他们的主要指标——我注意到他们的 API 设计效率低下，夸大了指标。通常，当我的客户项目成功时，API 调用的数量会减少，因为我们设计的 API 使我们的合作伙伴和服务器上的集成更容易。

这种判断错误有时来自与公司目标不一致的高级业务 KPI。
其他人来自正确的公司目标，当他们走向平台计划时，失去了一致性。
有可能公司专注于增长或留住人才，但高管们认为这可以通过“更多合作伙伴”来实现在这种情况下，当管理一个开发者平台时，你必须准备好批评，说“不”，并保持关注*你的客户和开发者社区的健康*。

在不止一个场合，我被要求为一个应用程序市场建立一个合作伙伴生态系统，发布指定数量的应用程序。“当然，”我会说。“我认识一个合作伙伴，他正在创建一个面向*消费者的、与收入*整合无关的项目，所以我将引入大量这样的合作伙伴，我们很容易找到他们。或者……让我们调整一下我们的衡量标准”。

然后，我会确保我们确实在根据公司目标设定价值。怎么会？

1.  理解并重申公司的目标。
2.  了解合作伙伴支持哪些价值点和功能差距。
3.  设定 KPI，重点是获得这些合作伙伴并使他们成功。

当被要求或被诱惑引入 X 数量的合作伙伴集成时，最好调整计划，以确保您只包括真正产生价值的合作伙伴。平台的目标是获取新客户吗？那么只计算那些为我们带来新客户的可靠渠道合作伙伴吗？你是在努力提高销量吗？然后，只计算为我们带来明确收入的合作伙伴。目标是提高保留率吗？然后，只计算支持现有客户的合作伙伴，以及我们的售后团队可以确认支持许可证续订的合作伙伴。

虚荣心指标很容易产生，我们都明白它们会产生负面后果。然而，我们很容易发现虚荣心指标，也许更多的是 API 而不是 UI 相关的指标。只有应用数据并严格评估您平台的优先级和您公司的目标，您才能确保您平台在正确的道路上发展。像 [Moesif API Analytics](https://www.moesif.com/solutions/track-api-program) 这样的工具可以帮助您通过快速安装 SDK 开始测量正确的 API 指标。

# 如何通过投资正确的工具成为有效的工程经理

> 原文：<https://www.moesif.com/blog/financial/procurement/How-To-Be-An-Outstanding-Engineering-Manager-By-Investing-In-The-Right-Tools/>

在与各种各样的软件工程团队合作后，我们 Moesif 对什么样的特质能让工程师走上领导岗位并成为杰出的经理，而不是那些很难升职的人有了独特的看法。获得高级职称和责任不是一件容易的事。毕竟，无论公司规模大小，软件工程师的数量都远远多于高管。那么，你如何脱颖而出，获得这个令人敬畏的副总裁或高管职位呢？要理解是什么造就了一个伟大的领导者，最好从推动晋升的人的角度来理解。

## 领导的心态

工程学自然会对一系列问题或挑战进行逻辑推理。无论是构建和扩展新的数据平台，还是如何获得领导头衔。工程师喜欢根据性能或缺陷率等指标对系统进行“分级”。这甚至可以体现在精心组织的大规模测试活动中，比如我们熟悉的*黑客马拉松*。然而，首席执行官或首席技术官可能并不关心你能以多快的速度编写一个优步的克隆体或挂接一些 API。即使是教科书中常见的软技能也不那么重要。虽然拥有出色的沟通和演讲技巧很方便，但许多高管害怕走上舞台展示一些吸引眼球的东西。那是什么呢？成为一名伟大的工程领导者并不真的与软技能或分数有关，而是与找到将资本投入工作并创造商业投资回报的方法的心态有关。每个公司(除非你是非盈利的)都是为了赚钱。这意味着你创造的工作必须为这个行业创造积极的投资回报。如果你为企业创造了负面的投资回报，比如没有交付你的工作，那么这是一条快速的被解雇的道路。然而，企业一直在通过培训、职业指导和其他活动雇佣和投资初级工程师。这是因为即使该雇佣的短期投资回报率可能是负的，但长期投资回报率预计会超过任何初始投资成本。优秀的工程师已经很好地理解了这个概念，并将努力创造更多的价值，这些价值可以表现为“证明自己”。假设您的经理让您构建一个内部 API 分析工具，这样您就可以了解客户的使用情况。一种天真的方法是声称你可以在一天内完成，然后花整个周末的时间编写一个临时的解决方案，这个解决方案可以工作，但是扩展和维护的成本很高。当然，你编码得很快，但是这能以最有效的方式实现业务目标吗？这种思维方式会让自己更像一个“代码猴子”，而不是工程领导者。事实上，当走极端时，友好的竞争和“升级”可能会变得不友好，并产生办公室政治。

## 有效利用资本

杰出的领导者可以证明他们有能力有效地利用资本来完成工作。

### 资本

这里的资本可以是人力资本、技术资本、金融资本或其他可用资源。根据定义，企业是资本的分配和使用，以创造更多的资本，通常是以增加现金储备、员工人数或专利组合的形式。

### 杠杆作用

杠杆使企业领导人能够利用企业中所有可用的资本来创造最大的成果，这是没有任何资源也做不到的。一个人不可能在一夜之间建立一个搜索引擎，但是伟大的领导者可以带领一个 100 人的工程组织完成很多事情。例如，工程领导者可以利用人力资本(即工程师)来创造技术资本(可销售的产品或服务)。然后，企业领导人可以利用该产品创造金融资本(即收入)。在每个阶段，都会创造更多的价值。在这种情况下，财务资本(收入)必须高于初始投资(工程工资)。它越大，对你老板的结果越好。

那些能够证明自己不断创造正投资回报的经理会被分配到更多的资本，这可以被视为增加你的责任和能力，以放大你的业务成果。

### 效率

一个好的领导者不仅利用资本来创造积极的商业收入，他们还能有效地利用资本来获得最大的投资乘数。缺乏经验的经理对效率的理解很差，这可能导致员工最终做“繁忙的工作”,无法实现业务成果的最大化。

消耗工程时间等商业资本的成本大于内在价值。经理需要考虑机会成本，这意味着你应该有效地利用资本。

如果你能够产生正回报，但它们是个位数(即回报相对于投入的资本来说很小)，那么你对资本的使用是低效的，可能会被用在其他方面。

## 为什么有经验的经理购买软件

工程和商业领袖通常投资于 API 分析和监控等企业软件，以做出回报最大化的最佳决策。这是因为这样的工具可以让你的员工更有效率，使你有更大的杠杆作用。

然而，一个人采购软件和工具的方法会因他或她的领导经验而大相径庭，这就引起了关于*构建还是购买*的争论。决定是投入工程资源来构建内部解决方案，还是投入财务资源从第三方供应商处购买交钥匙解决方案可能会令人望而生畏。缺乏经验的管理者通常拒绝购买软件，并会努力构建内部解决方案，而有经验的领导者通常倾向于从外部供应商那里购买。

缺乏经验的经理想要建立通常有三个动机:

1.  这位缺乏经验的经理认为，创造一些东西会提升他/她在公司的“形象”。
2.  这位经验不足的经理从未接触过采购和财务总监，所以不知道从哪里开始。
3.  这位没有经验的经理认为采购是公司的浪费。

然而，有经验的经理几乎总是更喜欢从第三方采购，他们更了解内部建设的真正成本和风险，而不是选择第三方可以获得的优势。当您购买企业软件时，您也在利用供应商多年来的研发投资来构建一个更好的产品。一个典型的 SaaS 供应商可能有数亿美元的年收入和多年的专业知识，他们可以利用这些来进一步开发他们的产品。投入数亿美元的人力资本来构建与第三方供应商同等水平的功能和性能是一个糟糕的商业决策。这意味着内部构建几乎总是不如第三方解决方案，或者是有缺陷的。

### 了解短期和长期业务成本

假设你做了一个建立的决定，那么你可以在短期和长期内对业务产生负面影响，这会让你的老板质疑你的决策。

从短期来看，除了包括以下多种机会成本之外，内部开发还会使企业因工程工资而花费大量资金:

*   当你的竞争对手获得市场份额时，你不能使用这个工具，直到它完成。
*   您的工程师正忙于构建和维护这个工具，而不是创收功能。
*   增加了公司的风险，即工具不工作或有问题。

从长期来看，随着员工转向其他项目或离开公司，维护成本和技术债务会增加。根据 SAP 的数据，78%的本土企业应用在首次使用后就被抛弃了。由于缺乏工程资源，在初始交付之后，功能请求和错误修复仍然没有解决。

### 利用供应商的优势

通过购买软件，您还能够利用供应商的可用优势和资源。大多数供应商都有成千上万的客户，他们利用这些客户来学习和创造更具创新性的解决方案，从而击败竞争对手。然后，您就可以利用这些创新，同时将成本分摊给许多不同的公司。没有一个客户必须承担全部 R&D 成本。即使像云计算这样的成本也在许多客户之间分摊，使他们的平台更具弹性，更好地应对需求高峰。然而，即使没有员工访问基础设施，您的内部构建也会一直运行。

## 这里没有发明综合症(NIHS)

这种租赁有一个名称，叫做“非此发明综合症”(NIHS)。由于不愿意从不同的角度采纳新的想法或产品，拥有大量非创新文化的公司抑制了增长并缺乏创新。经历过构建后果的有经验的经理通常最热衷于购买已经测试过的东西。把你的情绪和自我放在一边，根据数据和整体商业感觉做出决定是获得下一次晋升的最可靠的方法。

## 让你的老板看起来像个明星

考虑产量最大化的另一种方式是站在老板的角度考虑。他或她还希望利用你和你的团队产生的成果来执行他或她自己的议程。这可能意味着争取更多的收入来赞助他们的项目或获得晋升。你的工作对业务目标的影响越大，你的老板在首席执行官或董事会的眼中就越好。这就是俗语*让你的老板看起来像明星*的真正含义。毕竟，首席执行官或部门主管是*也是*根据收入和客户成功等业务目标进行评估的。

# 如何最好地监控 GraphQL APIs

> 原文：<https://www.moesif.com/blog/technical/monitoring/How-to-Best-Monitor-GraphQL-APIs/>

自 2015 年发布以来，GraphQL 已经成为 REST 的第**种选择。它给前端开发人员带来了他们渴望已久的灵活性。**

向后端开发人员乞求单一目的端点的日子已经过去了。现在，一个查询可以定义所有需要的数据并一次性请求，至少在理论上大大减少了延迟。

有了 REST，事情就完全简单了——尤其是监控。后端团队可以查看每个端点的测量结果，并立即了解正在发生的情况。

有了 GraphQL，情况就不一样了。通常只有一个端点，因此测量每个端点没有太大帮助。那么，有哪些新的地方可以接入系统呢？

在本文中，我们研究如何监控 GraphQL！

## GraphQL 架构

为了了解**我们系统中的**有趣点在哪里，让我们看看潜在的架构。

一个简单的 GraphQL 系统主要由三部分组成:

1.  定义所有数据类型的模式
2.  一个 GraphQL 引擎，它使用模式将查询的每个部分路由到解析器
3.  一个或多个解析器，它们是由 GraphQL 引擎调用的函数

GraphQL 后端从解析模式开始，这为服务器提供了关于哪个解析器处理哪个类型的知识。

当我们向 GraphQL 端点发送查询时，它会被引擎解析，对于查询中请求的每个类型，引擎都会调用我们的解析器来满足请求。

正如我们所想象的，这种方法只有在用于简单查询时才能提供出色的性能。

有时，查询的各个部分可以在我们的数据源中相互连接(数据源意味着类似数据库或第三方 API 的东西)。例如，我们正在加载一个用户帐户及其地址。它们在 GraphQL 模式中可能是两种类型，但在数据源中仅仅是一个记录。如果我们一次请求两个，我们不会期望服务器向数据源发出两个请求。

为了解决这个问题，人们开始使用一种叫做**数据加载器**的模式。

数据加载器是 GraphQL API 中的另一层，位于解析器和数据源之间。

在简单的设置中，解析器将在更复杂的迭代中直接访问数据源，解析器将告诉数据加载器它们需要什么，这个加载器将为它们访问数据源。

为什么这有帮助？

数据加载器可以等待，直到所有解析器都被调用，并合并对数据源的访问。

有人想加载用户帐户和地址吗？这只是对数据源的一个请求！

这个想法是，解析器只知道它的需求，数据加载器知道所有解析器想要什么，并且可以优化访问。

## 监控图表 QL

正如我们所看到的，根据我们的架构，我们可以在多个地方监控我们的 GraphQL API。

1.  **HTTP 端点**

*   对于所有访问我们 API 的流量

1.  **GraphQL 查询**

*   对于每个特定的查询

1.  **图 QL 解析器或数据加载器**

*   对于对数据源的每次访问

1.  **追踪**

*   在每个查询之后，它们会影响解析器和数据加载器

## 1.HTTP 端点

HTTP 端点就是我们监控的 REST API。在 GraphQL 世界中，通常只有一个，所以这个级别的监控只能给我们提供关于 API 整体状态的信息。

这还不错。至少它给了我们一个起点。如果一切正常，低延迟、低错误率、无客户投诉、一切都是绿色的，那么我们只需查看这些指标就可以节省时间和金钱。

如果有什么不对劲，我们需要深入挖掘。

## 2.GraphQL 查询

下一个明显的步骤是查看每个查询，这对于具有静态使用模式的 API 来说已经足够好了。

如果我们只对自己的客户使用我们的 API，通常很明显查询不会经常改变，但是如果我们的 API 适用于具有不同需求的不同客户，事情就不再那么简单了。

突然之间，我们可能会有数百个(稍微)不同的查询，它们都因为这样或那样的原因而运行缓慢。

解决这个问题的一个方法是检查最常见的查询，并尝试综合监控它们。这意味着我们定义一堆查询和变量组合，并从测试客户端运行它们，当我们推出新版本时，测试客户端会检查它们需要多长时间。通过这种方式，我们可以降低更新造成显著性能退化的风险。[持久化查询](https://blog.apollographql.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5)可以对此有所帮助。它们是缓存最常用查询的一种方式。

如果事情超出了我们的能力，我们需要采取另一个步骤。

## 3.解析器和数据加载器

监控发生了什么的最佳地点通常是橡胶接触路面的地方。如果我们看看后端访问数据源的地方，我们可以更好地把握现实。

我们使用的数据源类型仅仅是访问模式的错误吗？我们需要不同类型的数据库吗？

我们的数据源类型可以吗，但是我们应该提高对它们的要求？如果我们还没有使用数据加载器,我们还需要这样的东西吗？

我们是否向太慢的外部 API 发送请求？我们能在离后端更近的地方复制这些数据吗？

现在，当我们看到在我们的后端检索数据的内容和方式时，所有这些问题都可以问了。

这里我们还看到了数据加载器的另一个好处。解析器只允许我们监视一个解析器做什么；数据加载器允许我们看到所有解析器在一个请求中做了什么，另外还允许我们在发现问题后解决解析器间的问题。

## 4.跟踪整个堆栈

这是监控的最高纪律。当查询传入时，用 tracing-ID 标记查询，当查询被转换为解析器、数据加载器甚至数据源时，传递这个 ID。这允许我们在记录计时和错误时使用 tracing-ID，因此我们可以在以后合并它们以获得更大的视图。

这里的想法如下:

虽然测量一个查询可能会给我们一些关于解析所需时间的数据，但是实际的数据加载是在解析器和/或数据加载器中完成的，而不是在解析查询时完成的。

在加载数据时，我们不再使用查询，因为 GraphQL 的核心思想之一是将查询从实际的数据加载中分离出来，但是当有人发送查询时，看到后台发生的事情仍然很有趣。

## 结论

了解 GraphQL API 的后端是如何构建的，可以让我们更好地了解在哪里监控这样的系统。

与 REST APIs 相比，事情确实变得有些麻烦，但是 GraphQL API 中并没有什么神奇的事情发生，它只是我们可以为了不同的目的(比如监控)而挂接的代码。

如果我们在生产系统中获得可见性，关于缓存和错误处理的问题也会变得更加清楚。

# 如何使用 Moesif API 分析插件最好地监控 Kong 性能和 API 使用情况

> 原文：<https://www.moesif.com/blog/technical/kong/How-to-Best-Monitor-Kong-Performance-and-API-Usage-with-the-Moesif-API-Analytics-Plugin/>

对于任何寻找可靠和可伸缩的 API 提供方式的团队来说，Kong 是一个非常值得推荐的 API 网关。与 Apigee 和 Mulesoft 等更传统的玩家相比，Kong 遵循开放核心模式，高度模块化。

为了最好地优化您的 API 性能，并了解需要进行哪些更改来收回您的投资，建议建立像 Moesif 这样的 API 可观察性和监控系统。传统的监控会回答*已知的未知问题*如每分钟*请求*或状态如*红色、黄色、绿色*，您需要提前知道要探测和测量什么，如增加性能计数器。[另一方面，API 可观察性](/blog/api-engineering/api-observability/What-is-API-Observability/)是一种趋势，使业务和工程团队能够回答*未知的未知*。这些随意的问题源于快速解决复杂的工程和业务挑战的需求。

因为 Moesif 是一个完全托管的 SaaS，所以您的财务需求远低于构建和维护您自己的数据基础设施。不要因为你的内部分析用户因为 Grafana 和 Kibana 的缩放问题而无法访问他们的数据，或者因为你的 Elasticsearch shards 是红色的，就深夜打电话叫醒他们。

Moesif 已经发布了一个 [Kong 插件](https://docs.konghq.com/hub/moesif/kong-plugin-moesif/),使你能够增加 API 的可观察性，并从一个中心点，也就是你的 API 网关监控你的 API，而不会对你的 API 增加任何性能损失。接下来的问题是，你*应该*监控的关键事情是什么？

## 工程度量

首先想到的 API 指标是功能和性能指标。与许多 API 网关和代理服务器一样，Kong 是为高吞吐量 API 设计的，可以扩展到每分钟极高的请求数，但大多数性能问题是由于应用程序速度慢，而不是您的 Kong 基础设施。除非您能够完全控制 API 消费者如何查询您的 API，否则您将会遇到模糊的查询，这会给您的数据存储和处理带来额外的压力。一小群 API 消费者执行过多的全扫描或大型连接会降低 API 基础设施的速度。

### 平均延迟可能具有欺骗性

您可能认为平均延迟是您应该跟踪的第一件事，但是平均 API 延迟是骗人的。持续的高平均延迟可能没问题。每小时或蓝月亮熄灭时变化的延迟可能对您的客户不利。跟踪 90%的延迟，然后按终端或客户进一步细分。像 Moesif for Kong 这样的现代 API 分析解决方案使您能够将 API 调用绑定到单个用户，然后用客户统计数据丰富这些用户

![Kong 90th Percentile Latency By Endpoint](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/d96d3ab1e126ac2bbc018c39928d9b4e.png)

您应该能够根据任意数量的 API 调用参数(比如端点、特定的查询参数，甚至是主体字段)来划分 90%的延迟。

### 监控实际应用程序错误

一旦你掌握了 Kong 的第 90 个百分位数的延迟，是时候看看错误率的趋势了。错误可能意味着许多不同的事情。根据 Kong 和 Moesif 的报告，只要 HTTP 状态大于 400，就可能发生错误。

![Kong 400 and 500 errors](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/79d28b97ab1269b53f269d0094c1cf4d.png)

要在 Moesif 中监控或创建关于 Kong 指标的警报，您可以单击顶部的*警报*按钮。这将打开一个窗口，您可以在其中配置发送警报的位置，并确认您希望在警报中包含的任何过滤器和分组依据。

![Setting up alert rules to monitor Kong](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/8fcb902f604a4e8c5d02ea994fbcfb75.png)

一旦创建了警报规则，您可以稍后在*警报规则*下查看它。请记住，有许多错误情况更多的是用户错误或糟糕的体验，而不是真正的错误。例如，API 消费者可能不完全理解 API 过滤和分页是如何工作的，导致他们总是得到空的搜索结果。在这些情况下，您应该利用正文过滤器来设置可能暗示不良体验的警报规则，例如重复响应但没有结果。

### 检查 API 调用

实时事件流显示 API 调用进入 Kong 实例的过程。与典型的基础设施指标不同，API 调用自然有大量的字段，每个字段都有大量不同的值。像 Moesif 这样专为 API 设计的分析解决方案是为 API 流量的高基数、高维度分析而设计的。这意味着您可以通过任何 HTTP 头或主体字段来过滤和创建复杂的聚合，这大大减少了手动搜索和 SQL 查询所花费的时间。即使对于位于不同数据中心的 Kong 实例，您也可以获得统一视图的好处。

![Kong API log](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/5f4790b5fdb4afe34ae64eb9c7d3590a.png)

## 产品和业务指标

工程团队不是唯一需要访问 API 度量的人。无论是产品销售还是客户成功，企业的每个部分都应该利用对客户 API 使用的可见性。像 Moesif 和 Kong 这样的现代 API 分析解决方案使您能够将 API 调用与个人用户(或公司)联系起来，然后用人口统计信息丰富这些用户。这使您能够通过了解谁在调用什么来最大化您的 API 和 Kong 投资的商业价值。这有时被称为用户行为 API 分析或以用户为中心的 API 分析。

### 跟踪按客户细分的 API 使用情况

任何 API 优先的团队首先应该关注的是他们的 API 流量分布。设计为事务性的 API 自然是传递价值的媒介，每个 API 调用都是一个可度量的价值单位。例如，位置 API 可能会让用户付费来提取位置数据。他们执行的位置查询(即 API 调用)越多，用户从使用您的 API 中获得的收益就越多。如果你向你的 API 消费者收费，希望他们支付的最多。像 Twilio 这样的公司就利用了这一点，他们向客户收取每次 API 调用的费用。💰

![Kong API usage by customer](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/70f3c4c339103b2dff80f7640060bc18.png)

### 将独特用户归因于获取渠道

一旦你很好的理解了谁是你的顶级 API 用户，你应该开始看看他们来自哪里。如果你把你的 API 当成一个产品，那么产品营销和发展团队需要知道在哪里投入更多的营销资金。要跟踪这一点，您还应该安装 Moesif browser SDK，它可以自动收集网络行为和归属信息，并将它与您的 Kong 指标联系起来。Moesif Kong 集成将根据 [Kong 消费者 id 和消费者用户名](https://docs.konghq.com/hub/kong-inc/key-auth/#upstream-headers)自动跟踪唯一用户。

![Kong API usage by acquisition channels](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/ba6f436ed4a538f7e9b5f8bf04e7b220.png)

### 了解您的采用漏斗

如果不显示采用，大多数 API 程序将无法获得继续运行所需的资源。一个伟大的 API 应该有一个高效和有效的伟大的采用和成长故事。然而，API 是一个难以置信的硬推销。大多数开发人员对对外销售和付费营销并不敏感，然而 API 的采用有很高的障碍，因为开发人员需要集成它。这意味着你应该虔诚地追踪你的收养漏斗。Moesif 建议跟踪两个关键指标:

#### 第一个你好世界的时间到了

也称为首次 API 调用时间，首次 Hello World 时间(TTFHW)是 API-first 公司追踪的黄金指标。首次 Hello World 的时间是新开发人员注册并进行第一次 API 调用以使他们能够从您的 API 中获得至少一些价值所需的时间。从商业的角度来看，有些人可能会认为这一次是有价值的。在他们的第一次 API 调用之前，你的开发者用户从你的 API 程序中得到的很少，这对于那些第一次进行 API 调用的开发者来说是很神奇的。

![Kong Time to First Hello World Funnel](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/e0215ba8b7bbde959d979aa579f75b06.png)

TTFHW 不是你应该关注的唯一指标，还有第二个指标是第一个工作应用程序的时间，或者有时是第一个付费应用程序的时间。这个定义因产品和 API 而异，但非常类似于一个活跃用户。在上面的图表中，我们显示了从他们迈出第一步到他们第一个 Hello World 的时间，看起来是 6 小时 5 分钟。然后，我们可以跟踪从他们的 Hello World 到他们的工作应用程序的时间，我们将其定义为超过 100 个对`/api/:id/payment`的 API 调用

#### 汇率

就像我们可以跟踪转化的时间一样，我们也应该跟踪转化率本身。较高的转换率自然会带来较高的收入。与我们跟踪 TTFHW 类似，您应该跟踪客户旅程中每一步的转化率。然后，您可以像我们之前一样，按人口统计数据进行细分，例如按收购渠道。

![Kong API adoption funnel by acquisition channels](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/ba6f436ed4a538f7e9b5f8bf04e7b220.png)

## 结束语

使用合适的工具来监控 Kong 不仅对于理解性能，而且对于获得 API 采用和使用的业务可见性都是至关重要的。有了 [Kong integration](https://docs.konghq.com/hub/moesif/kong-plugin-moesif/) ，这种度量标准的收集就可以大规模地自动处理。这使您能够建立更好的 API 产品策略，并更好地支持您的客户。

# 如何构建开发者喜爱的杀手级 API 程序

> 原文：<https://www.moesif.com/blog/technical/api-platform/How-to-Build-a-Killer-API-Program-That-Developers-Love/>

[//www.slideshare.net/slideshow/embed_code/key/NWq2SCeDOcSglL](//www.slideshare.net/slideshow/embed_code/key/NWq2SCeDOcSglL)

**[How to build a killer api program developers love](//www.slideshare.net/DerricGilling/how-to-build-a-killer-api-program-developers-love "How to build a killer api program developers love")** from **[Derric Gilling](https://www.slideshare.net/DerricGilling)**

注意，这是我在 [API 世界大会](https://apiworld2019aidevworld2019.sched.com/speaker/derric_gilling.76hia4k)上展示的幻灯片。

# 如何更快地为开发人员提供个性化的开发体验

> 原文：<https://www.moesif.com/blog/product-management/onboarding/How-To-Build-A-Personalized-Developer-Experience-To-Onboard-Developers-Faster/>

鉴于 Box、Atlassian 和 Salesforce 的成功，各公司正以前所未有的速度推出新的开发者平台，以将自己定位为市场领导者，并将其影响力扩展到核心产品之外。这些公司有数以千计的第三方开发人员连接到他们的 API，以扩展产品功能，并为平台公司和第三方开发人员创造额外的收入渠道。

然而，为了吸引和留住这些开发人员，必须在开发人员入职时投入更多的心思。对于初级开发人员来说，它应该是尽可能无缝的，而对于有价值的传播者来说，它应该在关键时刻提供高级功能。

## 运行开发人员平台的关键问题

### 入职流失

TTFHW (Time To First Hello World)是衡量开发者平台成功与否的最重要的指标。TTFHW 是从初始注册到在一个创造价值的 API 上进行第一次 API 交易所花费的时间。TTFHW，是开发人员版本的第一个时间值。

众所周知，开发人员对不能满足其需求的产品的关注有限，因此平台公司应该大力投资，尽可能降低这一指标。如果开发人员没有获得或看到集成新 API 的价值，他们将永远不会将该应用程序部署到生产中，最终*流失*。

### 未充分利用的功能

即使当开发人员第一次调用 API 时，平台也可能没有被充分利用。大型 API 可以有成百上千个不同的特性和端点，但是开发人员可能只从选定的几个特性开始。这取决于平台公司展示可以为双方带来额外价值的附加特性和功能。

### 开发者体验差

您的经验应该使新开发人员能够快速找到信息，而无需联系支持人员。此外，当开发人员被阻止时，他或她应该能够访问必要的信息，以便尽快解除阻止。关键是要跟踪你的 API 和入职体验的哪些设计问题最令人沮丧。

## 为什么是个性化体验？

由实际使用数据驱动的个性化入职和产品体验可以使新开发人员更快地融入，更快地解决障碍，并作为成功的合作伙伴留住他们。个性化体验可以实现三个目标:

### 1.更快地搭载开发人员

在接下来的几天或几周内，当开发人员使用您的平台时，您可以逐渐地让他们参与进来，而不是在一个单独的入门步骤中让开发人员过载许多集成选项和操作。如果你还没有，头脑风暴一下什么是向新收购的开发者展示价值所需的最小集成。此外，在开发人员可以遵循的成功完成入职培训的各种途径上绘制一个决策树。

您的第三方开发人员不需要集成所有功能，甚至不需要集成适合生产或高流量的功能。然而，一旦开发人员完成了第一步，您就可以检测到这一点，然后再提出开发人员应该采取的下一步行动。这需要一个系统来跟踪你的*入职漏斗*中每个开发人员的进度。

### 2.有效地传达相关的变化和功能

如果有两件事情是所有开发人员都讨厌的，那就是:

1.  太少或不相关的沟通
2.  醒来后发现他们的代码被第三方破坏了，第三方决定改变或废弃一个 API

因此，你需要传达你的平台的变化，同时确保你的沟通是切题的和相关的。开发人员每天会收到数百封电子邮件，从招聘人员到生产警报和票务系统。你的每月简讯不足以传达变化，然而增加简讯的频率只会让事情变得更糟。

个性化的应用内交流是在正确的时间接触到正确受众的有效方式。对于个性化沟通，您应该做到以下几点:

1.  当端点的特定版本将失效时，向使用不赞成使用的版本的开发人员发出通知，指定对不赞成使用的端点进行了多少次调用。您还应该包含一个链接，指向为他们现有版本量身定制的迁移计划*。*
2.  当添加额外的功能时，例如对他们已经在使用的端点进行额外的过滤和数据操作，让他们知道该功能的存在以及如何利用它。
3.  当端点出现性能问题(如延迟峰值)时，让受影响的开发人员了解正在发生的问题以及解决方案的任何更新。当然，你不应该向你的 entre 开发者社区发送垃圾邮件，因为他们可能并没有受到这个问题的影响。
4.  由于开发人员使用过时的 SDK 或集成，当他们的实现可以改进以获得更高的安全性、更高的性能或其他更改时，通知他们。
5.  向未能进入入职漏斗下一步的开发人员提供额外的反馈和提示。这可以通过应用内指南、工具提示和有针对性的滴滴邮件来实现。

### 3.分析成功的开发人员群体

一旦你的平台已经运行了几个月，你就有了一些数据来执行开发者群体分析，看看你的开发者留存率是如何随时间变化的。随着开发人员体验的改善，您的保留曲线变得更好了吗？因为 API 被各种不同的环境、编程语言和业务用例所消费，所以按照其他特征(比如使用的 SDK)来划分你的群组是很重要的。例如，通过按 SDK 或使用的语言分解您的每周或每月保留，您可以确定是否有特定的 SDK 可能需要在可靠性、易于集成或附加文档方面进行一些改进。您应该努力使您的保留曲线不会因开发人员的特性(如编程语言、国家或使用的云提供商)而异。

此外，您应该覆盖 API 变更和这些群组中出现的问题。最近的一次中断是否严重影响了开发人员的保留率？

最后，如果您正在 A/B 测试您的 onboarding 体验，您应该基于 onboarding 变体或第一个 API 调用来比较您的开发人员群组。TTFHW 很小的开发者会坚持更久吗？

## 如何构建个性化的开发者体验

在当今拥有成百上千个开发者平台和 SaaS 公司的环境中，花精力优化你的漏斗中部，包括开发者入职，是至关重要的。新产品经理犯的一个常见错误是过度优化收购和增长，而没有考虑一艘漏水的船如何严重影响你的业务底线。然而，创造个性化的体验需要正确的数据和服务。

如果您企业的核心竞争力不是产品分析，您可以探索能够实现个性化入职和应用内体验的最佳解决方案。分析领导者 [Moesif](https://www.moesif.com) 和 [Pendo](https://www.pendo.io) 正在合作，为产品团队提供完整的解决方案，以构建个性化的开发人员体验，而无需构建成本高昂、无法扩展的一次性解决方案。

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

## 我们为什么与 Pendo 合作？

我们很高兴与 [Pendo](https://www.pendo.io) 合作，将这种以开发者为中心的体验带入生活。Pendo 为客户提供产品体验平台，提高产品采用率，集中用户反馈，并使产品团队能够衡量和改善他们的产品体验。从第一次讨论开始，Pendo 和 Moesif 就意识到我们的愿景是一致的，即公司需要将他们的 API 作为一个产品来对待，以释放额外的增长，并成为产品体验领域的市场领导者。

这种集成将结合两种工具的优点，使数据驱动的产品团队有更多的方法根据使用数据而不是直觉来分析和与他们的开发人员交流。Pendo 平台负责人 Chad Burnette 表示:“Moesif 和 Pendo 之间的集成为 API 驱动的企业提供了两种平台的优势”。*“这是一个我过去花费了无数工程资源来解决的问题。现在，市场上有了一种简单且可扩展的方法来检测 API，然后使用这些数据直接向开发人员传达信息，以简化入门工作并推动更广泛的采用。当你建立你的开发者社区时，这是完美的。”*

## 组件

有四个核心组件使您能够提供个性化的开发人员体验:

#### 1.API 使用数据的收集

您应该有一个可以收集 API 使用数据并将其归因于个人开发者帐户的系统。这种归属可以通过 API 密钥、用户 id 或其他可识别的信息来完成。这可以通过像 [Moesif](https://www.moesif.com) 这样的 API analytics SDK 自动完成。您希望从 API 中收集的关键指标包括:

*   使用的休息路线或特征
*   使用的 API 或端点的版本
*   电话打了多长时间
*   使用的用户代理或 SDK
*   它的地理来源

#### 2.UI 交互的集合

除了收集 API 数据，您还需要来自 UI(如 web 应用程序)的使用数据。这可以直接从您的浏览器 javascript 代码中完成，也可以通过 web analytics SDK(如 [Pendo](https://www.pendo.io) )自动完成。您至少应该收集以下内容:

*   当用户注册时
*   入职流程中的页面或步骤。
*   使用的浏览器或设备
*   当用户退出入职培训时

#### 3.分析系统来组合和分割这些数据

如果您正在构建一个内部系统，您将需要一种方法来为每个开发人员将您的 web 历史与您的 API 历史结合起来。通过这种方式，您可以对您的第三方社区执行更高级的细分和群组分析。您将在该分析服务中需要的特定功能:

*   能够将开发人员分成不同的小组，并执行保留分析
*   一种根据 API 或网站上过去的操作进行过滤或分组的方法
*   从 CRM 或用户数据库同步用户属性，包括收入或 LTV 等信息
*   导入属性信息，如推荐和数字营销的 UTM 参数。

#### 4.支持应用内消息和通知的 UI 元素

一旦有了可以收集和分析这些数据的系统，就需要创建各种 UI 元素，比如可以从这些用户数据中驱动的横幅、弹出模式和通知。对此至关重要的是在正确的时间驱动它，同时在 A/B 测试此消息传递时提供灵活性。通过 A/B 测试，您可以衡量每个入职流程的有效性并进行改进。

## 结束语

创造令人惊奇的好的开发者体验需要把你的平台当成一个产品。这意味着你需要跟踪、测量、分析、测试和重复。一旦你能够遵循这个过程，你就拥有了提高 API 保持度和推动更高的 API 采用度的工具。

# 如何选择最好的 Javascript 数据可视化库

> 原文：<https://www.moesif.com/blog/technical/visualization/How-to-Choose-the-Best-Javascript-Data-Visualization-Library/>

任何以数据为中心的应用程序都需要 UI/仪表板的数据可视化。对于基于 web 的应用程序，这些库几乎总是 Javascript。获得正确的图表和可视化可能很难，但幸运的是，我们有各种 Javascript 库可供选择，如 D3.js、Chart.js 和 Google Charts。然而，对于每个库来说，都有大量的利弊选择。本指南可以帮助您选择库以及一些最佳实践。

## 要考虑的因素

### 浏览器和设备兼容性

这可能是最重要的因素之一。虽然库支持哪些浏览器和版本是值得考虑的，但是如果你试图支持非常旧版本的浏览器，它可能会使你不能利用最新的特性。你可以看看浏览器的市场份额来决定分界线在哪里。

如果您的应用程序将在网络之外和移动网络上使用，请检查图表是否可以响应，并确保它在移动浏览器上看起来不错。

### UI 框架兼容性

现代的 web 应用前端通常是使用主流的 UI 框架之一来开发的，比如 [Ember](https://www.emberjs.com) 、 [React](https://reactjs.org) 、 [Vue](https://vuejs.org) 或者 [Angular](https://angular.io) 。

取决于您正在使用的框架，您可能希望确保该库能够很好地与它兼容。大多数图表库是框架不可知的。通常，每个主要框架都有包装器。然而，每个框架都有一些奇怪的地方值得验证，因为一些库假设代码只在客户端环境中执行。随着越来越多的现代框架现在支持服务器端渲染，可能需要特殊的技巧来确保只有客户端的库不会加载到服务器端。

### 各种图表类型

有一些图表库只关注一两种类型的图表，比如时间线系列或方向图，但大多数库试图在它所拥有的图表集中包含所有内容。最好的比较是在维基百科上。

如果一个库没有您需要的所有图表类型，使用两个或三个图表库也无妨，但是如果它们是同一个应用程序的一部分，您可能需要使它们在视觉上风格一致。

### 文件大小

Javascript 库需要作为应用程序的一部分下载到客户端。为了获得良好的用户体验，您希望尽可能减小 Javascript 的大小。

所以图书馆的总规模很重要。有几种方法可以缓解这种情况。

1.  您可以尝试明智地进行代码拆分，或者将每个库的加载延迟到需要的时候。Webpack 和其他工具通常是处理这个问题的简单方法。
2.  如果您只需要一种或两种类型的图表，加载一个支持许多图表的大型库可能没有意义。
3.  有些库提供了仅加载所需图表类型的选项。
4.  如果你正在使用`import`，有时你可以加载你需要的特定组件，而不是整个库。

### 表演

如果您计划一次渲染大型数据集，那么性能就很重要。您可以尝试进行基准测试，但是为大型数据集设计的库通常会将性能作为它们的主要特性。

### 风格和定制

对于美学来说，这是一个关于它有多漂亮的更主观的判断。在这篇文章中，我分享了我的一些个人观点。

有些库支持动画，而有些不支持，动画的质量也各不相同。虽然如果你选择使用动画，一定要适度添加，因为它会很分散注意力。

关于视觉效果最重要的方面可能是定制，也就是说，你在多大程度上可以控制风格，以适应你的应用程序的主题和风格。

### 价格、许可和支持

一些最全面的图表库也需要付费许可，通常他们提供免费试用或免费用于非商业用途。就我看到的少数几家而言，价格似乎相当。

对于免费库，它们从免费使用到在 MIT 或 Apache 许可下完全开源都有。它们都不提供任何保证。

付费产品的一个好处是它们会提供支持，但是对于免费库，你很可能会依赖于社区。如果社区足够大(可以看看 Github 上收到的明星数量)，通常会有很多人愿意帮忙。大社区的一大好处是图书馆不太可能被遗弃。

## 流行的免费图书馆

Wikipedia 提供了一个非常好的所有 Javascript 图表库的特性对照表。在这里，我将只进入一些最受欢迎的。

### [Chartjs](http://www.chartjs.org/)

![screenshot of chartjs](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/bb3c533b0175a4af41eb65f80f1844ec.png)

这是最受欢迎的之一。它受麻省理工学院的许可，这是限制最少的许可之一。

图表类型的范围不是很大，只有 8 种，但是它们非常容易使用。

视觉上，它看起来非常漂亮，外观简约而扁平，开箱即用。与其他产品相比，定制有些受限。默认动画做得非常好。它也是有求必应。

它有一个非常大的社区，所以有很多像 React 这样的主要框架的包装器。

它占地面积小，非常适合入门。但是它只是为客户端使用而设计的，所以如果你使用服务器端渲染，你必须确保不要在服务器端使用它。

### [谷歌图表](https://developers.google.com/chart/)

![screenshot of google charts](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/a425088904c3fe8d751812c71a7222ef.png)

在免费的可视化库中，Google Charts 提供了最大的图表类型集之一。除了典型的折线图、条形图和饼图之外，它还提供了许多不常用的图表，如蜡烛图、日历图、地理图、组织图和树形图。

尽管 Google Charts 是免费的，但它不是开源的，它遵循 [Google API 使用条款](https://developers.google.com/terms/)。有谷歌做后盾，它不太可能被抛弃。

从视觉上看，与 Chartjs 相比，它没有开箱时那种干净简约的外观。但是可以自定义。定制参数的数量因图表类型而异，但是有很多不同的东西可以使用。尽管它不是开箱即用的，但您可以编写代码来调整图形的大小，以便在调整窗口或容器大小时检测事件。

不像其他库，不支持`npm`或`bower`安装，令人失望。相反，它需要通过来自 CDN 的`script`标签包含一个加载器脚本。与其他一些库不同，您使用加载器动态地加载包含您需要的图表类型的包，然后在完成的加载回调:`onLoadCallback`中呈现您的图形。

这有时会使该库使用起来有些笨拙，尤其是如果您有其他要用于渲染的触发器。幸运的是，还有 react 的[包装器。](https://github.com/RakanNimer/react-google-charts/tree/master/src/components)

### D3.js

![screenshot of d3js](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/7d1f0ba8a777368be3b2228b3a9b4cd6.png)

D3.js 是 Javascript 中数据可视化的黄金标准，它通常是其他库的基础。在 BSD 许可下，它是开源和免费的。

它以陡峭的学习曲线而闻名，并且没有从基础库中提供图表。但是有一个巨大的用户社区，他们互相支持并回答问题，我个人觉得这个库使用起来非常简单有趣。

有一些构建在上面的库，如 [react-d3](http://www.reactd3.org/) 和 C3js，它们提供了与 chartjs 几乎相同的一组现成的图表类型，例如:折线图、条形图、面积图、散点图、饼图。

如果您对可视化有特殊需求，比如新的或独特类型的图表，D3 可能是正确的解决方案。还是那句话，除非万不得已，不要多此一举，先查查有没有另一个满足你需求的库先。

## 付费商业图书馆

这些库通常为个人使用提供免费试用或免费许可，但商业使用需要付费。如果除了希望从社区获得答案之外，你还需要支持，他们可能是不错的选择。市场领导者似乎是 [Highchart](https://www.highcharts.com) 、 [Fusionchart](https://www.fusioncharts.com/) 、[am chart](https://www.amcharts.com/)和 [Anychart](https://www.anychart.com/) 。它们都提供了大量的图表类型，具有大量的定制、集成选项和流行的框架支持。去看看吧。

## 特定框架的可视化库

大多数库不依赖于其他 UI 框架。大多数被设计成呈现一个`div`标签。由于有很多框架，如 JQuery、Ember、Angular 或 React，所以有人为这些库创建了包装器(如前面提到的 react-chartjs 和 react google charts)。然而，有些包装器使用起来很笨拙，有些没有保持最新，最终会增加一层依赖性。

然而，有一些图表库是专门为流行的前端框架设计的，如果你已经在使用这个框架，并且它们有你需要的图表类型，那么它们可能更容易使用。

*   [Flot](http://www.flotcharts.org/) 是 jQuery 特有的。
*   [Ember Charts](http://opensource.addepar.com/ember-charts/) 是建立在 D3.js 之上的 emberjs 框架。
*   [n3 图表](https://n3-charts.github.io/line-chart/#/home)，同样构建在 D3.js 之上，但是是为 Angular 框架构建的。
*   [胜利](http://formidable.com/open-source/victory)是专门为 react 设计的。
*   React-Vis 也是专门为 React 设计的，它来自优步团队。

## 特定的单一图表类型聚焦库。

有一些免费的库专注于一种类型的图表，这种图表做得非常好，我想说出来。

*   [Sigmajs](http://sigmajs.org/) 创建漂亮的图形，即表示节点和网络。
*   Springy.js 专门研究力的方向图，它提供了一个非常“有弹性”的动画。
*   [思慕雪图表](http://smoothiecharts.org/)专注于显示流数据。

## 结论

Javascript 可视化库中的选择数量多得令人不知所措，但这反映了数据可视化对于 web 应用程序的重要性。我们兴奋地看到所有主要的图书馆都在不断改进。

这篇文章并不详尽，所以如果你对选择库时应该考虑的因素和你真正喜欢的库有其他想法，请在下面的评论中告诉我。

# 如何为您的平台选择正确的 API 网关:Kong、Tyk、Apigee 和备选方案的比较

> 原文：<https://www.moesif.com/blog/technical/api-gateways/How-to-Choose-The-Right-API-Gateway-For-Your-Platform-Comparison-Of-Kong-Tyk-Apigee-And-Alternatives/>

## 为什么选择 API 网关？

API 是许多大大小小应用的驱动力。无论你是发布一个公共 API 还是建立一个新的集成市场，API 正在成为做生意的方式。就像 web 时代有 HTTP 服务器为生产中的网站提供服务一样，API 也有 API 网关来为生产中的 API 提供服务。人们可以利用 API 网关来帮助向您的客户和合作伙伴交付考虑到高可用性的 API。它们是一种代理服务器，位于您的 API 之前，执行身份验证、速率限制、将公共可访问的端点路由到适当的微服务、跨多个内部服务的负载平衡等功能。

## 历史背景

### 企业集成中间件

从历史上看，对 API 网关的需求源于集成挑战。在 REST 和 GraphQL APIs 之前，公司正在构建由结构化或非结构化数据组成的基于 SOAP 和 XML 的 API。API 网关可以提供统一的接口，并将多个遗留应用程序链接在一起。在这种用例中，API 网关可以采用遗留的 SOAP 服务，将数据转换应用到 API，例如从 SOAP 转换到 REST 以及从 [JSON](https://www.json.org/) 转换到 [XML](https://www.w3.org/XML/) 。这些类型转换通常不是自动的。例如，[RESTful API 的核心原则](/blog/api-guide/getting-started-with-apis/#core-principles-of-restful-api)与 SOAP 非常不同，因此它不像将 XML 转换成 JSON 那么简单。

### 打破巨石

[微服务架构](/blog/api-guide/the-next-api-platform-serverless-and-blockchain/#microservices)是构建和部署独立服务以组成更大应用的策略。微服务与整体架构的利弊超出了本文的范围。从高层次来看，微服务架构正在成为构建 API 的方式。它使多个独立的团队能够在一个大的应用程序上工作，而不用互相监督或处理长时间的部署。

除了微服务，还有更小的计算单元，如纳米服务和无服务器计算。由于管理成百上千个服务的复杂性以及向客户提供统一接口或合同的要求，API 网关正在成为使用微服务和无服务器计算的架构中的常见位置。

## API 网关的优势

无论您使用的是微服务还是无服务器计算，或者您的 API 是内部使用还是公开访问，使用 API 网关都有很多好处:

*   **解耦**:如果您无法控制的客户端与许多独立的服务直接通信，重命名或移动这些服务可能会很困难，因为客户端与底层架构和组织相耦合。API 网关使您能够基于路径、主机名、报头和其他关键信息进行路由，从而使您能够将面向公众的 API 端点从底层微服务架构中分离出来。
*   **减少往返行程**:某些 API 端点可能需要跨多个服务连接数据。API 网关可以执行这种聚合，这样客户端就不需要复杂的调用链，并减少往返次数。
*   **安全性** : API 网关提供了一个集中的代理服务器来管理速率限制、僵尸检测、认证、CORS 等。许多 API 网关允许建立一个数据存储库(如 Redis)来存储会话信息。
*   **横切关注点**:日志记录、缓存和其他横切关注点可以在一个集中的设备中处理，而不是部署到每个微服务上。事实上，Moesif 为许多 API 网关(如 Kong 和 Tyk)提供了[插件](https://www.moesif.com/extensions/data-ingestion)，因此您无需安装任何 SDK 就可以获得现代客户和 API 分析。

![API-Gateway-with-Microservices](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/af6d8b11715148c9ea8cd451cdc8f9b7.png)

### API 平台的其他优势

除了上面列出的好处，为客户和合作伙伴构建可公开访问的 API 的公司还有其他好处。这种 API 平台由 Stripe 或 Twilio 等 API first 公司以及 Github 或 Twitter 等开发平台公司构建。如今，随着客户和合作伙伴要求更多的定制和集成，B2B 公司向平台转型变得越来越重要。

使用 API 网关的其他好处包括:

*   为开发人员管理 API 密钥，包括提供一致的授权和认证方式
*   基于配额或使用量的速率限制和计费。
*   为客户和合作伙伴提供开发人员门户，以创建 API 令牌、弃用令牌等。

> *什么是 Moesif？ [Moesif](https://www.moesif.com/) 是最先进的 API 分析平台，被成千上万的平台用来了解你最忠实的客户在用你的 API 做什么，他们如何访问它们，以及从哪里访问。Moesif 有流行 API 网关的插件，比如[孔](https://docs.konghq.com/hub/moesif/kong-plugin-moesif/)、 [Tyk](https://tyk.io/docs/configure/tyk-pump-configuration/#moesif-config) 和 [more](https://www.moesif.com/docs/server-integration/) 。*

## 要比较的变量

### 部署复杂性

它是单节点设备还是网关需要运行多种类型的节点来启动和设置数据库？一些网关需要多种类型的数据库。

### 开源与专有

当您想用附加功能扩展网关时会发生什么？有插件吗？如果是，插件是开源的吗？

### 内部部署与云托管

内部部署会增加额外的时间来规划部署和维护。然而，云托管解决方案可能会由于额外的跳跃而增加一点延迟，并且如果供应商倒闭，可能会降低您的服务的可用性。

### 特征

一些网关更像是为服务 API 而修改的基本 HTTP 服务器。而另一些包含了整个包，包括开发人员门户、安全性等等。如果网关包含这样的特性，那么像开发者门户这样的特性是否具有良好的用户体验和设计，或者使您能够调整设计以满足您的需求。

### 社区

开发人员是否在网关之上构建了额外的功能？就像 Apache Tomcat 和 NGINX 拥有庞大的开源追随者一样。一些 API 网关有大型开发人员社区来构建脚本，回答堆栈溢出等问题。

### 价格

如果你是一家小公司，他们有好的免费版本或开源版本吗？然而，如果你是一家老牌企业，这家公司有你需要的支持吗？

## API 网关领域的主要参与者

### 孔（姓）

Kong 是一个基于 NGINX 的开源 API 网关。)这是一个非常流行的开源 HTTP 代理服务器。尽管 Kong 是开源的， [KongHQ](https://www.konghq.com) 为大型企业提供维护和支持许可。虽然开源版本拥有基本功能，但某些功能，如管理 UI、安全性和开发人员门户，只能通过企业许可证获得。

部署:Kong 的最大优势之一是它广泛的安装选项，有预先制作的容器，如 Docker 和 range，这样您可以快速运行部署。NGINX 是仅次于 Apache 和 IIS 的最流行的 HTTP 服务器，即使在高请求速率下也有很高的性能。NGINX 有一个巨大的 Lua 脚本和扩展社区，所以在寻找一些定制时，你不会被落在后面。就部署而言，孔的复杂性适中。它确实需要运行 Cassandra 或 Postgres。一些插件，比如限速插件，需要额外的数据存储，比如 Redis。然而，生产部署并不像 Apigee 那样复杂。

功能完整性:Kong 开箱即用提供了 API 管理的许多预期功能，如创建 API 密钥、路由到多个微服务等。它没有很多转换层(主要是基于 HTTP 的转换，没有 SOAP 或 to XML)。然而，如果您没有很多遗留应用程序，您可能不需要额外的数据转换层。尽管它有速率限制，但它没有计费集成。可以通过 CLI 或 curl 命令对 REST API 执行管理任务，这使得管理更容易集成到您现有的 devops 行动手册中。

Kong 提出了 [*服务*](https://docs.konghq.com/1.0.x/admin-api/#service-object) 、 [*路由*](https://docs.konghq.com/1.0.x/admin-api/#route-object) 和 [*消费者*](https://docs.konghq.com/1.0.x/auth/#consumers) 的概念，在处理组成您的 API 的数百个微服务和调用您的 API 的不同类型的消费者时提供了很大的灵活性。这使得插件和转换能够被附加到一个特定的路径，甚至是一个单独的消费者。

Kong 有一个大型的社区社区开发插件，他们在 2018 年[推出了](https://konghq.com/blog/welcome-to-the-new-kong-hub/) [Kong Hub](https://docs.konghq.com/hub/) ，并且它已经有几十个插件。 [Moesif 是那里的一个插件](https://docs.konghq.com/hub/moesif/kong-plugin-moesif/)。

Kong 是我们极力推荐的 API 网关之一。如果你不需要遗留的包袱，想要一个流行的开源 API 网关，那么 Kong 是绝对不会错的。它是现代的，旨在管理现代微服务，而不仅仅是给传统的 monoliths 增加一个转换门面，并且有一个快速增长的插件社区，从 Moesif 这样的 API 分析到缓存层和验证 JWT (JSON Web Tokens)。

### Tyk.io

和 Kong 一样，Tyk 也是[开源](https://github.com/TykTechnologies/tyk)，但是是在 MPL 许可下，比 Kong 的 Apache 2.0 许可宽松一些。同时，Tyk 的企业用户使用与社区用户完全相同的网关。您不必为某些企业功能支付额外费用。Tyk 不依赖于额外的插件和 Lua 脚本，它更像是一个包含了 API 网关的*电池。像 OIDC、OAuth2、无记名令牌、基本认证、相互 TLS、HMAC 这样的认证方案都是开箱即用的，不需要插件。它还支持 XML- > JSON、JSON- > XML、JSON 模式验证。*

Tyk 建立在 GoLang 之上，作为一种系统语言，它是为高吞吐量和并行性而设计的。背后的公司， [Tyk.io](https://tyk.io/) 提供云托管版本和专业支持许可。与 Kong/NGINX 的 Lua 不同，有些人可能会发现 Golang 更现代，也更容易编程。除了 Golang，Tyk 还有解释器来运行其他语言的插件，比如 Javascript 和 Lua。请记住，与可以部署在与您的内部服务相同的 VNET 上的内部版本不同，云版本需要将您的一些服务直接公开到互联网上。

部署:Tyk 提供云托管 SaaS 解决方案或内部部署。您可以在 Heroku 或 AWS 上部署实例。他们的网站提供了关于如何使用 T1 的教程。开源版本的部署相对简单，只需要 Redis，而 Kong 需要运行 Cassandra 或 Postgres 集群。

Tyk 具有密钥管理、配额、速率限制、API 版本、访问控制等功能，但没有集成的计费功能。Tyk 有一个 REST API 和一个 web 仪表板来完成管理任务。虽然他们有一个扩展列表，但是 Tyk 没有像 Kong 那样大的社区或者插件中心。然而，他们确实保持他们的网关设计良好，并试图保持精简。

### 养蜂场

[Apigee](https://apigee.com/) 是本文中列出的最古老的 API 网关。它成立于 2004 年，2016 年被谷歌收购。它不是开源的，构建在 enterprise Java 之上。它们最初是作为 XML/SOA 应用程序开始的，但后来转向了 API 管理领域。Apigee 旨在将遗留的 monoliths 转换成可供第三方使用的 API。他们不太关注微服务和内部 API。

因为 Apigee 具有复杂的多节点架构，所以相对于开源 API 网关，部署的复杂性要高得多。Apigee Edge 要求在本地运行至少 9 个节点，包括运行 Cassandra、Zookeeper 和 Postgres，这迫使部署由一个集中的基础架构团队进行规划，该团队花费数月时间来规划部署。

虽然大多数 Apigee 客户使用内部版本，但在加入谷歌后，他们引入了云托管解决方案。然而，它更接近 IaaS，必须部署到特定的谷歌云数据中心，而不是纯粹的 SaaS。与其他托管版本一样，托管代理版本会增加延迟，并需要保护您自己的服务。

> 当使用托管 API 网关时，除非它与您的上游服务在同一个数据中心，否则会增加一点延迟。

与其他 API 不同的是，Apigee 支持[端到端集成计费](https://apigee.com/api-management/#/product/monetize-apis)来直接货币化你的 API。管理门户构建在 Drupal 之上。取决于你的观点，Apigee 要么看起来功能臃肿，要么就是完整的解决方案。同时，由于是专有的，它没有一个大的开发者社区贡献插件或扩展。

### 亚马逊 AWS API 网关

[亚马逊 AWS](https://aws.amazon.com/) ，作为最大的云厂商，也有 [AWS API 网关](https://aws.amazon.com/api-gateway/)。这是唯一的云选项。如果您已经在使用 AWS Lambda 或 EC2，您可以在与上游服务相同的数据中心区域部署 AWS API gateway，这样增加的延迟就不是问题。AWS API Gateway 是完全受管的，只需在 AWS 门户中点击几下就可以部署。

当与 AWS Lambda 结合使用时，AWS API Gateway 为[无服务器](/blog/engineering/serverless/A-Primer-On-Serverless-Computing-AWS-Lambda-vs-Google-Cloud-Functions-vs-Azure-Functions/)API 提供了一个很好的解决方案。无服务器就像类固醇上的微服务，需要对 API 端点进行完美的管理，以将传入的 API 调用路由到适当的无服务器函数。

除了 AWS Lambda，AWS API Gateway 还有最好的一键式解决方案，可以将传入的 API 调用路由到其他 AWS 服务，如 Amazon Kinesis 和 Amazon DynamoDB。此外，您可以使用现有的 IAM 基础设施为 API 提供身份验证，而不会产生太多开销。

论相貌，它比得上孔。然而，AWS API Gateway 并没有一个大型的开发人员社区来编写扩展或插件。使用 AWS API Gateway 的最大问题之一是供应商锁定。

### 其他人

上面的列表并不详尽，下面是一些其他列表的快速总结:

*   Azure API Gateway 与 AWS 的产品非常相似。当然，如果你使用的是微软 Azure，并且对 Azure 功能有很好的支持，那就更适合了。

*   [Express API Gateway](https://www.express-gateway.io/) 是由 [LunchBadger](https://www.lunchbadger.com/about-us/) 打造的新入口，它是完全开源的，基于非常流行的 [Node.js](https://nodejs.org/en/) [Express 框架](https://expressjs.com/)。他们的设计理念是保持它的最小化和声明性。如果您正在 Node.js 上构建大量核心基础设施，并且熟悉 express 中间件，那么值得一看。

*   [KrakenD](https://www.krakend.io/) 也是 GoLang 内置的开源产品。我们还没用过这个。如果你有任何反馈，请告诉我。

## 摘要

下面以表格形式简要总结了调查结果:

| 制品 | 孔（姓） | Tyk.io | 养蜂场 | AWS 网关 | Azure 网关 | 快速网关 |
| --- | --- | --- | --- | --- | --- | --- |
| 部署复杂性 | 单一节点 | 单一节点 | 许多具有不同角色的节点 | 云供应商平台即服务 | 云供应商平台即服务 | 灵活的 |
| 需要数据存储 | 卡珊德拉还是波斯特格里斯 | 雷迪斯 | 卡珊德拉、动物园管理员和波斯特格里斯 | 云供应商平台即服务 | 云供应商平台即服务 | 雷迪斯 |
| 开放源码 | 是的，Apache 2.0 | 是的，MPL | 不 | 不 | 不 | 是的，Apache 2.0 |
| 核心技术 | ngix/月球 | GoLang | Java 语言(一种计算机语言，尤用于创建网站) | 不公开 | 不公开 | Node.js 快递 |
| 在内部 | 是 | 是 | 是 | 不 | 钼 | 是 |
| 社区/扩展 | 大的 | 中等 | 不 | 不 | 不 | 小的 |
| 授权/API 密钥 | 是 | 是 | 是 | 是 | 是 | 是 |
| 限速 | 是 | 是 | 是 | 是 | 是 | 是 |
| 数据转换 | 超文本传送协议 | 超文本传送协议 | 是 | 不 | 不 | 不 |
| 集成计费 | 不 | 不 | 是 | 不 | 不 | 不 |

随着更多的公司部署更精细的 mciroservice 和无服务器架构，API 网关的使用只会增加。此外，在看到 Twilio、Salesforce 和 Stripe 等公司的早期成功后，越来越多的公司开始推出自己的开发人员计划。我们非常期待看到 API 经济和开发者平台是如何发展的，并且很乐意为此做出贡献。

# 如何在 Moesif 中定制您的个人资料视图体验

> 原文：<https://www.moesif.com/blog/api-product-management/api-analytics/How-To-Customize-Your-Profile-View-Experience-In-Moesif/>

在 Moesif，我们做了大量工作来改善特定用户和公司的观看细节和趋势。这包括我们最近增加的添加[个人资料仪表板](https://www.moesif.com/blog/api-product-management/api-analytics/Introducing-Profile-Dashboards/?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_term=profile-dash-custom)，以将个人和可重复使用的图表添加到用户和公司个人资料中

现在，我们增加了更多的功能，允许用户自定义每个用户和公司的个人资料视图。这使得显示与您的组织相关的所有数据并隐藏不相关的数据变得更加容易。

## 什么变了？

旧的纵断面图屏幕是静态的，无法自定义。尽管大部分数据是有用的，但它可能与使用 Moesif 的每个组织的需求不相关。以前，纵断面图如下所示:

![Old profile view](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/7b47d6f8cf3daaf0e37b31987aaedd8a.png)

现在，我们已经添加了一个新的外观和功能，使个人资料视图更加可用和完全可定制。当你点击一个用户或公司的个人资料，你会在屏幕上方看到下面的个人资料视图。

![New profile view](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/84bdf44404c9c17cb3890a1a1cb4bbb6.png)

## 如何自定义纵断面图

在纵断面图中自定义字段非常容易。编辑纵断面图后，无论何时打开纵断面图，都可以将其保存并应用于纵断面图。用户和公司个人资料视图都可以独立编辑。这有助于进一步的自定义，因为您可能希望在公司简档中看到某些特定字段，而在用户简档中可能不希望看到这些字段，反之亦然。

*[使用 Moesif 为对您的 API 最重要的指标创建自定义仪表板。](https://www.moesif.com/features/api-dashboards?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_term=profile-dash-custom)T3】*

### 添加和编辑字段

要编辑哪些字段出现在配置文件视图中，只需点击窗格右上角的**更多操作**，然后选择**自定义配置文件的布局**。

![edit profile button](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/edc7d6ec048b60fde4dac0120d4bfc08.png)

选择后，屏幕将变为可编辑状态。

![editable preview](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/95042dd7ac2e84626a2a64e77652823f.png)

要向列中添加新字段，只需点击每列顶部的 **+** 按钮。

![Add field to profile](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/7b3585eeaae6d79b5bbfbef611ab4ed0.png)

从这里，选择您要添加的字段。然后，该字段将被添加到选定的列中。您还可以通过单击并拖动新字段和现有字段到所需位置来重新定位它们。

![move field in profile](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/87a45f1da6c6296a907b0f32416cbcf6.png)

> 您需要确保单击并按住左边的条目来移动字段。

要保存您的更改，请点击屏幕右上角的**保存**按钮。

![save profile changes](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/38901c3c9f3125c48ebf29555061afde.png)

### 添加列

要添加新列，请滚动到已创建列的末尾，并点击 **+** 按钮。

![add column to profile](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/21366ba5e7caade7fd518e0369438e25.png)

然后，选择要添加到新列中的第一个字段。比如我会选择**初始 Utm 介质**。选择后，将创建新列。

*[用 Moesif 组织你的 API 日志和指标。](https://www.moesif.com/features/api-logs?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_term=profile-dash-custom)T3】*

![column added to profile](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/79c23ca3a63a5658c9b906e77dbe9777.png)

要编辑用于该列的图标，您可以单击当前图标。然后，您将看到可用的图标库。

![select icon for new column](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/03ecb23865148c8768f5dfc30a2e8ea5.png)

单击您想要使用的图标，它将被分配到该列。

要保存您的更改，请点击屏幕右上角的**保存**按钮。

![save profile](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/38901c3c9f3125c48ebf29555061afde.png)

## 你自己试试吧

使您的组织能够轻松查看 Moesif 中每个用户和公司的最重要的详细信息。使用 profile view 中最新的自定义功能，帮助您的销售、客户成功和其他团队快速访问最重要的数据。要查看这一最新功能，请[登录](https://www.moesif.com/wrap?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_term=profile-dash-custom)或[立即创建](https://www.moesif.com/signup?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_term=profile-dash-custom)您的 Moesif 账户。

# 如何调试无响应的 Elasticsearch 集群

> 原文：<https://www.moesif.com/blog/technical/elasticsearch/How-to-Debug-an-Unresponsive-Elasticsearch-Cluster/>

Elasticsearch 是一个开源搜索引擎和分析商店，被各种应用程序使用，从电子商务商店的搜索到使用 ELK stack 的内部日志管理工具(简称“Elasticsearch，Logstash，Kibana”)。作为一个分布式数据库，您的数据被分割成“碎片”,然后分配给一个或多个服务器。

由于这种分片，对 Elasticsearch 集群的读或写请求需要在多个节点之间进行协调，因为在单个服务器上没有数据的“全局视图”。虽然这使得 Elasticsearch 高度可伸缩，但这也使得它的设置和调优比 MongoDB 或 PostgresSQL 等其他流行数据库复杂得多，这些数据库*可以*在单个服务器上运行。

当可靠性问题出现时，如果您的弹性搜索设置有问题或不稳定，救火可能会很有压力。您的事故可能会影响客户，从而对收入和您的商业声誉产生负面影响。快速补救措施很重要，但在事故或停电期间花费大量时间在线研究解决方案对大多数工程师来说并不奢侈。本指南旨在为工程师运行的常见问题提供一份备忘单，这些问题可能会导致 Elasticsearch 出现问题，以及需要查找的内容。

作为一个通用工具，Elasticsearch 有数千种不同的配置，这使它能够适应各种不同的工作负载。即使在线发布，适用于一家公司的数据模型或配置可能并不适合您的公司。没有灵丹妙药可以让 Elasticsearch 规模化，需要勤奋的性能测试和反复试验。

## 无响应的弹性搜索集群问题

集群稳定性问题是最难调试的问题之一，尤其是在您的数据量或代码库没有任何变化的情况下。

### 检查集群状态的大小

#### 它有什么作用:

*   [Elasticsearch 集群状态](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html)跟踪我们集群的全局状态，是控制流量和集群的核心。集群状态包括集群中节点的元数据、碎片的状态以及它们如何映射到节点、索引映射(即模式)等等。
*   集群状态通常不会经常改变。但是，某些操作(如向索引映射添加新字段)会触发更新。
*   因为集群更新会广播到集群中的所有节点，所以它应该很小(< 100MB)。
*   大型集群状态会很快使集群变得不稳定。发生这种情况的常见方式是通过[映射爆炸](https://www.elastic.co/blog/found-crash-elasticsearch#mapping-explosion)(一个索引中有太多的键)或太多的索引。

#### 寻找什么:

*   使用下面的命令下载集群状态，并查看返回的 JSON 的大小。

    ```py
    curl -XGET 'http://localhost:9200/_cluster/state' 
    ```

*   特别是，查看哪些索引在集群状态中有最多的字段，这可能是导致稳定性问题的违规索引。如果集群状态较大且不断增加。您还可以查看单个索引或与如下索引模式进行匹配:

    ```py
    curl -XGET 'http://localhost:9200/_cluster/state/_all/my_index-*' 
    ```

*   您还可以使用以下命令查看违规索引的映射:

    ```py
    curl -XGET 'http://localhost:9200/my_index/_mapping' 
    ```

#### 如何修复:

*   看看数据是如何被索引的。当高基数标识符被用作 JSON 键时，通常会出现映射爆炸。每次看到类似“4”和“5”的新键时，群集状态都会更新。例如，下面的 JSON 将很快导致 Elasticsearch 的稳定性问题，因为每个键都被添加到全局状态。

    ```py
     {  "1":  {  "status":  "ACTIVE"  },  "2":  {  "status":  "ACTIVE"  },  "3":  {  "status":  "DISABLED"  }  } 
    ```

    T4】
*   为了解决这个问题，将你的数据扁平化，使之对弹性搜索友好:

    ```py
    {  [  {  "id":  "1",  "status":  "ACTIVE"  },  {  "id":  "2",  "status":  "ACTIVE"  },  {  "id":  "3",  "status":  "DISABLED"  }  ]  } 
    ```

### 检查弹性搜索任务队列

#### 它有什么作用:

*   当对 elasticsearch(索引操作、查询操作等)发出请求时，它首先被插入到任务队列中，直到一个工作线程可以拾取它。
*   一旦工作池有一个空闲线程，它将从任务队列中选取一个任务并处理它。
*   这些操作通常由您通过 HTTP 请求在`:9200`和`:9300`端口上完成，但是它们也可以在内部处理索引的维护任务
*   在给定时间，可能有数百或数千个正在进行的操作，但应该非常快地完成(如微秒或毫秒)。

#### 寻找什么:

*   运行下面的命令，查找长时间(如几分钟或几小时)停滞运行的[任务](https://www.elastic.co/guide/en/elasticsearch/reference/current/tasks.html)。
*   这意味着某些东西正在使集群饥饿，阻止它向前发展。
*   对于某些长时间运行的任务来说，比如移动一个索引需要很长时间，这是可以接受的。然而，普通的查询和索引操作应该很快。

    ```py
    curl -XGET 'http://localhost:9200/_cat/tasks?detailed' 
    ```

*   使用`?detailed`参数，您可以获得关于目标索引和查询的更多信息。
*   寻找任务总是排在列表首位的模式。是同一个指数吗？是同一个节点吗？
*   如果是这样，可能是该索引的数据有问题，或者是节点过载。

#### 如何修复:

*   如果请求量高于正常水平，那么就寻找优化请求的方法(比如使用批量 API 或更高效的查询/写入)
*   如果数量没有变化，并且看起来是随机的，这意味着有其他东西正在降低集群的速度。任务备份只是一个更大问题的征兆。
*   如果你不知道请求来自哪里，给你的 Elasticsearch 客户端添加 [`X-Opaque-Id`](https://www.elastic.co/guide/en/elasticsearch/reference/current/tasks.html#_identifying_running_tasks) 头来识别哪个客户端触发了查询。

### 检查弹性搜索待定任务

#### 它有什么作用:

*   [未决任务](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-pending.html)是对集群状态的未决更新，例如创建新索引或更新其映射。
*   与前面的任务队列不同，挂起的更新需要多步握手来将更新广播到群集中的所有节点，这可能需要一些时间。
*   在给定的时间内，飞行中的任务应该几乎为零。请记住，快照恢复等昂贵的操作可能会导致这种情况暂时加剧。

#### 寻找什么:

*   运行命令并确保没有或很少任务在运行。

    ```py
    curl curl curl -XGET 'http://localhost:9200/_cat/pending_tasks' 
    ```

*   如果它看起来是一个持续的集群更新流，并且很快完成，那么看看是什么触发了它们。是映射爆炸还是创建了太多指数？
*   如果只是几个，但是它们似乎卡住了，那么查看主节点的日志和指标，看看是否有任何问题。例如，主节点是否遇到内存或网络问题，以至于无法处理集群更新？

### 热线程

#### 它有什么作用:

*   hot threads API 是一个有价值的内置分析器，可以告诉你 Elasticseach 在哪里花费的时间最多。
*   这可以提供一些见解，如 Elasticsearch 是否在索引刷新或执行昂贵的查询上花费了太多时间。

#### 寻找什么:

*   调用[热线程 API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-hot-threads.html) 。为了提高精度，建议使用`?snapshots`参数

    ```py
    curl -XGET 'http://localhost:9200/_nodes/hot_threads?snapshots=1000' 
    ```

    捕捉多个快照
*   这将返回拍摄快照时看到的堆栈跟踪。
*   在许多不同的快照中寻找相同的堆栈。例如，您可能会看到文本`5/10 snapshots sharing following 20 elements`。这意味着一个线程在 5 个快照期间花费时间在代码的那个区域。
*   你还应该看看 CPU 的百分比。如果一个代码区域同时具有高快照共享和高 CPU %,这就是一个热门代码路径。
*   通过查看代码模块，分解 Elasticseach 在做什么。
*   如果您看到等待或暂留状态，这通常是正常的。

#### 如何修复:

*   如果在索引刷新上花费了大量的 CPU 时间，那么请尝试增加刷新间隔，使其超过默认的 1 秒。
*   如果您看到大量缓存，可能您的默认缓存设置不是最佳的，并导致严重的未命中。

## 内存问题

### 检查弹性搜索堆/垃圾收集

#### 它有什么作用:

*   作为一个 JVM 进程，堆是存储大量弹性搜索数据结构的内存区域，需要垃圾收集周期来修剪旧对象。
*   对于典型的生产设置，Elasticsearch 在启动时使用`mlockall`锁定所有内存并禁用交换。如果你不想做，现在就做。
*   如果某个节点的堆一直在 85%或 90%以上，这意味着我们即将用尽内存。

#### 寻找什么:

*   在 Elasticsearch 日志中搜索`collecting in the last`。如果这些都存在，这意味着 Elasticsearch 在垃圾收集上花费了更高的开销(占用了其他生产任务的时间)。
*   只要 Elasticsearch 没有将大部分 CPU 周期花费在垃圾收集上(计算花费在收集上的时间相对于所提供的总时间的百分比),偶尔这样做是可以的
*   一个 100%时间都花在垃圾收集上的节点停滞不前，无法继续前进。
*   看似有网络问题(如超时)的节点实际上可能是由于内存问题。这是因为在垃圾收集周期中，节点无法响应传入的请求。

#### 如何修复:

*   最简单的方法是添加更多的节点来增加集群可用的堆。然而，Elasticsearch 需要时间来将碎片重新平衡到空节点。
*   如果只有一小部分节点具有高堆使用率，您可能需要更好地平衡您的客户。例如，如果您的碎片大小变化很大，或者具有不同的查询/索引带宽，那么您可能向同一组节点分配了太多的热碎片。要移动碎片，使用[重新路由 API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html) 。只要调整[碎片感知灵敏度](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#shard-allocation-awareness)确保它不会被移回来。

    ```py
    curl -XPOST -H "Content-Type: application/json" localhost:9200/_cluster/reroute -d '
    {
    "commands": [
        {
          "move": {
            "index": "test", "shard": 0,
            "from_node": "node1", "to_node": "node2"
          }
        }
      ]
    }' 
    ```

*   如果您向 Elasticsearch 发送大量请求，请尝试减少批量大小，使每批小于 100MB。虽然较大的批处理有助于减少网络开销，但它们需要分配更多的内存来缓冲请求，这些内存在请求完成和下一个 GC 周期之前无法释放。

### 检查弹性搜索旧的记忆压力

#### 它有什么作用:

*   旧内存池包含经历了多个垃圾收集周期的对象，并且是长期存在的对象。
*   如果[老内存](https://www.elastic.co/blog/found-understanding-memory-pressure-indicator)超过 75%，你可能要关注一下了。当填充超过 85%时，会发生更多的 GC 循环，但是对象不能被清除。

#### 寻找什么:

*   看旧池已用/旧池最大。如果这一比例超过 85%，那就令人担忧了

#### 如何修复:

*   您是否急切地加载大量现场数据。这些在内存中驻留很长时间。
*   您是否正在执行许多长期运行的分析任务？某些任务应该卸载到为 map/reduce 操作设计的分布式计算框架，如 Apache Spark。

### 检查弹性搜索字段数据大小

#### 它有什么作用:

*   FieldData 用于计算字段的聚合，如`terms`聚合
*   通常，在第一次对字段执行聚合之前，字段的数据不会加载到内存中。
*   然而，如果设置了`eager_load_ordinals`，这也可以在索引刷新时预先计算。

#### 寻找什么:

*   查看一个索引或所有索引字段数据大小，如下所示:

    ```py
    curl -XGET 'http://localhost:9200/index_1/_stats/fielddata' 
    ```

*   如果我们对错误类型的数据使用索引，那么索引可能会有非常大的字段数据结构。您是否正在对基数非常高的字段(如 UUID 或跟踪 ID)执行聚合？Fielddata 不适合非常高基数的字段，因为它们会创建大量的 fielddata 结构。
*   您是否有许多设置了`eager_load_ordinals`的字段或向 fielddata 缓存分配了大量数据。这导致 fielddata 在刷新时间而不是查询时间生成。虽然它可以加速聚合，但如果您在索引刷新时计算许多字段的字段数据，并且从不在查询中使用它，那么它就不是最佳选择。

#### 如何修复:

*   对您的查询或映射进行调整，不要在非常高的基数键上进行聚合。
*   审核您的映射以减少将`eager_load_ordinals`设置为 true 的数量。

## 弹性搜索网络问题

### 节点向左或节点断开

#### 它有什么作用:

*   如果一个节点不响应请求，它最终将从集群中删除。
*   这允许将碎片复制到其他节点，以满足复制因子并确保高可用性，即使某个节点被删除。

#### 寻找什么:

*   查看主节点日志。即使有多个主节点，您也应该查看当前选出的主节点。您可以使用 nodes API 或类似于 Cerebro 的工具来完成这项工作。
*   查看是否有一致的节点超时或有问题。例如，您可以通过在主节点的日志中查找短语`pending nodes`来查看哪些节点仍在等待集群更新。
*   如果您看到同一个节点不断被添加，然后又被删除，这可能意味着该节点过载或无响应。
*   如果您无法从主节点访问该节点，这可能意味着存在网络问题。您也可能遇到网卡或 CPU 带宽限制

#### 如何修复:

*   将设置`transport.compression`设置为 true 进行测试。这将压缩节点之间的流量(例如从接收节点到数据节点),以 CPU 带宽为代价减少网络带宽。
*   注意:早期版本称此设置为`transport.tcp.compression`
*   如果您也有内存问题，请尝试增加内存。由于在垃圾收集上花费了大量时间，节点可能会变得无响应。

## 主节点问题不足

#### 它有什么作用:

*   主节点和其他节点需要相互发现以形成集群。
*   在第一次启动时，你必须提供一组静态的主节点，这样你就不会有 T2 裂脑问题。
*   只要主节点存在，其他节点就会自动发现集群。

#### 寻找什么:

*   [启用跟踪记录](https://www.elastic.co/blog/elasticsearch-logging-secrets)以查看与发现相关的活动。

    ```py
    curl -XPUT -H "Content-Type: application/json" localhost:9200/_cluster/_settings -d '
    {
      "transient": {"logger.discovery.zen":"TRACE"}
    }' 
    ```

*   查看配置，如`minimum_master_nodes`(如果比 6.x 版本旧)。
*   查看您的初始主节点列表中的所有主节点是否可以相互 ping 通。
*   审核自己是否有*法定人数*，应该是`number of master nodes / 2 +1`。如果少于法定数量，将不会更新群集状态以保护数据完整性。

#### 如何修复:

*   有时，网络或 DNS 问题会导致无法到达原始主节点。
*   检查当前至少有`number of master nodes / 2 +1`个主节点在运行。

## 碎片分配错误

### 黄色或红色状态的弹性搜索(未分配的碎片)

#### 它有什么作用:

*   当节点重新启动或群集恢复开始时，碎片不会立即可用。
*   恢复受到限制，以确保群集不会不堪重负。
*   黄色状态表示主索引已分配，但辅助(副本)碎片尚未分配。虽然黄色索引既可读又可写，但可用性会降低。当集群复制碎片时，黄色状态通常是可以自我修复的。
*   红色索引表示主碎片未被分配。这可能是暂时的，例如在快照恢复操作期间，但也可能意味着重大问题，例如丢失数据。

#### 寻找什么:

*   了解分配停止的原因

    ```py
    curl -XGET 'http://localhost:9200/_cluster/allocation/explain'

    curl -XGET 'http://localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' 
    ```

*   获取红色指数列表，以了解哪些指数导致了红色状态。只要至少有一个索引是红色的，集群状态就会是红色的。

    ```py
    curl -XGET 'http:localhost:9200/_cat/indices' | grep red 
    ```

*   有关单个索引的更多详细信息，您可以查看违规索引的恢复状态

    ```py
    curl -XGET 'http:localhost:9200/index_1/_recovery' 
    ```

#### 如何修复:

*   如果您看到 max_retries 超时(可能是集群在分配期间很忙)，您可以临时增加断路器阈值(默认值为 5)。一旦数字高于断路器，Elasticsearch 将开始初始化未分配的碎片。

    ```py
    curl -XPUT -H "Content-Type: application/json" localhost:9200/index1,index2/_settings -d '
    {
      "index.allocation.max_retries": 7
    }' 
    ```

## 弹性搜索磁盘问题

### 索引是只读的

#### 它有什么作用:

*   Elasticsearch 有三个影响碎片分配的[基于磁盘的水印](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#disk-based-shard-allocation)。`cluster.routing.allocation.disk.watermark.low`水印防止新碎片被分配给磁盘已满的节点。默认情况下，这是所用磁盘的 85%。
*   `cluster.routing.allocation.disk.watermark.high`水印将迫使集群开始将碎片从该节点转移到其他节点。默认情况下，这是 90%。这将开始移动数据，直到低于高水位线。如果 Elasticsearch 磁盘超过泛滥阶段水位线`cluster.routing.allocation.disk.watermark.flood_stage`，则说明磁盘已满，在磁盘空间耗尽之前，移动速度可能不够快。到达时，索引被置于只读状态，以避免数据损坏。

#### 寻找什么:

*   查看每个节点的磁盘空间
*   查看如下消息的节点日志:

    ```py
    high disk watermark [90%] exceeded on XXXXXXXX free: 5.9gb[9.5%], shards will be relocated away from this node 
    ```

*   一旦到达洪水阶段，您会看到如下日志:

    ```py
    flood stage disk watermark [95%] exceeded on XXXXXXXX free: 1.6gb[2.6%], all indices on this node will be marked read-only 
    ```

*   一旦发生这种情况，该节点上的索引就是只读的。
*   要进行确认，请查看哪些索引的`read_only_allow_delete`设置为真。

    ```py
    curl -XGET 'http://localhost:9200/_all/_settings?pretty' | grep read_only 
    ```

#### 如何修复:

*   首先，清理磁盘空间，比如删除本地日志或 tmp 文件。
*   要删除此只读块，请执行以下命令:

    ```py
    curl -XPUT -H "Content-Type: application/json" localhost:9200/_all/_settings -d '
    {
      "index.blocks.read_only_allow_delete": null
    }' 
    ```

## 结论

对稳定性和性能问题进行故障排除具有挑战性。找到根本原因的最佳方法是使用假设的科学方法，并证明其正确或不正确。使用这些工具和 Elasticsearch 管理 API，您可以深入了解 Elasticsearch 的表现和问题所在。

# 如何定义、衡量、分析和预测客户流失

> 原文：<https://www.moesif.com/blog/customer-success/monitoring/How-to-Define-Measure-Analyze-and-Predict-Customer-Churn/>

获得一个新客户比留住一个现有客户的成本更高。至于究竟要高出多少，分析不一，但大约在 5X 的 25 倍左右。因此，定义、衡量和分析客户流失，然后预测并主动减少客户流失，可以为您的企业节省资金。一大笔钱。以下是方法。

[![The cost of acquiring a customer is up to 25 times more expensive than retaining one](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/fef11cf4a43b6868e5827f2f9cd63535.png)](https://www.moesif.com/solutions/customer-success?utm_campaign=Int-site&utm_source=blog&utm_medium=image-cta&utm_content=define-measure-predict-customer-churn) 获得一个客户的成本是留住一个客户的 25 倍

## 客户流失是最重要的指标

如果你想从客户身上获得最大价值，你需要留住他们。这样做是您客户成功战略的核心部分。这意味着你需要了解你的客户流失率。

### 客户成功中的流失是什么？

客户流失率是客户停止使用你的产品或服务的比率。它通常表示为固定时间段内的比率，例如每月 2%的流失率或每季度 6%的流失率。

这种收入流失对你的企业来说代价很高。你投入了大量的时间和精力，却最终失去了客户。

让你的客户满意并长期使用你的产品是降低客户流失率的关键。这使得你在获得这些客户时的初始投资最大化。

### 用户流失率如何影响其他指标？

那么，为什么用户或客户流失是[最重要的指标](https://www.moesif.com/blog/customer-success/monitoring/Customer-Health-Metrics-Help-CSM-Teams-Reduce-Churn-and-Accelerate-Upsell-in-API-Platform-Companies?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_content=define-measure-predict-customer-churn)？为了了解你的客户流失率，你需要监控你的客户在做什么。当用户努力集成或使用你的产品和 API 时，你也需要提醒。您为实现这一目标而制定的一系列指标将由减少客户流失的需求驱动。

为了了解您的客户流失率，您需要测量和分析:

*   API 调用和保持的数量
*   错误事件
*   群组和产品保留

理想情况下，所有这些都应该有自动警报，以便如果客户下降到某个水平以下，就会发出通知。

### 客户流失的两个主要原因是什么？

客户流失的原因有很多。也许你的营销吸引了错误类型的顾客，所以你的产品不能满足他们的需求。也许你的产品很棒，但是你的客户支持很糟糕。或者可能支持是正确的，但是你的产品有问题。价格也很关键——如果你的价格比你产品的感知价值高，你的客户会很快盯上竞争对手。

虽然客户流失的两个主要原因是你的业务和产品所特有的，但它们将集中在以下几个方面:客户契合度、产品特性、客户支持效率、可靠性或定价。这就是为什么深入研究客户流失如此重要。

### 为什么流失在 SaaS 和 API 中特别重要？

SaaS 和 API 业务依赖于来自用户的定期收入。如果 SaaS 的流失率越来越高，公司将很快陷入困境。因此，使用客户流失率作为关键指标来监控客户成功，对于企业的财务健康至关重要。

## 我可以使用什么工具来跟踪客户流失？

跟踪客户流失是为了充分利用您的数据。它可以向您展示哪些痛点导致了客户流失，提供对客户保留问题的见解，使您能够采取及时、果断的行动。

那么，我可以用什么工具来跟踪客户流失呢？有各种各样的工具可以帮助你追踪你的流失率。它们为您提供了解客户流失程度所需的数据可见性。然后，就看你如何利用这些数据并付诸行动了。

Moesif 是这种工具的一个很好的例子。它提供:

*   全方位了解您客户的账户健康状况
*   跨大量数据点的全面流失分析
*   警报自动化
*   易用性

这些元素中的每一个都在流失分析和减少中扮演着重要的角色。借助 360°可见性，您可以直观地了解每个客户的情况，并发现趋势，表明客户何时适合扩张或面临流失风险。分析大量的数据点可以做到这一点。它们包括:

*   新帐户登录
*   每日登录
*   日常使用
*   每日 API 增长率
*   特征利用
*   最活跃的用户
*   API 错误日志
*   MRR 增长

拥有广泛的指标是全面客户流失分析的基础。显微镜下的特定指标将取决于您的业务。对于特别有帮助的分析，寻找允许您定制您报告的指标的工具。确保内置自动警报，这样您就不会错过任何客户面临流失风险的警告信号。

在整个过程中，无论是定制报告还是深入研究不同的指标，您的流失分析工具越简单，您就能越快地支持您的客户坚持使用您的服务。

### 谁对客户流失负责？

制定减少客户流失的策略并不是你企业中某一个人的事。事实上，如果你真的想实施一些方法来[阻止客户流失](https://www.superoffice.com/blog/reduce-customer-churn)并保持你的客户群的健康，一系列的团队都需要参与进来。

当然，为了实现你选择的减少客户流失的工具，你需要你的工程师和其他技术人员。他们还可以帮助确保监控正确的指标，与您的核心运营团队合作，确保分析正确的数据。

然后，您将需要客户成功团队的意见，以帮助了解数据显示的客户痛点，并建议更好地支持这些客户的策略。毫无疑问，其中一些修正也需要您的技术团队的大量投入。

您的财务团队也需要参与讨论任何旨在减少客户流失的支出，并分析这样做的潜在财务收益。

这样一个跨多个团队的大范围流失分析项目，也需要管理层的监督，以确保它符合公司的长期方向。简而言之，减少客户流失和提高客户保持率是团队的共同努力。

## 通过有针对性的主动保留减少客户流失

失去顾客并想知道原因的日子已经一去不复返了。至少，如果你有合适的工具来分析你的流失率背后的原因，那些日子已经一去不复返了。有了合适的平台，您可以采取有针对性的主动方法来留住客户。

[![Track retention and keep your focus on minimizing churn](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/4d7cb70b847b6ed274cfc78ece2476ad.png)](https://www.moesif.com/solutions/customer-success?utm_campaign=Int-site&utm_source=blog&utm_medium=image-cta&utm_content=define-measure-predict-customer-churn#understand-customer-health) 追踪留存率，把注意力放在最大限度减少流失上

### 什么是客户流失和保留？

我们根据客户离开你的服务的比率来考虑客户流失。与之抗衡的是客户保持，这是所有关于防止客户停止使用。

客户保留是任何旨在阻止客户流失的战略的核心。它是关于长期吸引你的客户，并确保他们对你的产品和支持感到满意。

### 如何通过主动参与提高客户保持率并减少客户流失

以提醒您的工程、客户成功和销售团队潜在客户流失的方式监控每一位客户，意味着您可以接触到每一位面临客户流失风险的客户。例如，有了 Moesif，你可以通过电子邮件、短信、Slack、PagerDuty 或定制的 webhook 发送警报——无论哪种方式最适合你的业务。然后你的团队就可以开始行动了。

客户越来越少使用你的产品/服务可能有很多原因，从缩减他们的运营规模到你甚至没有意识到的集成问题。借助使用动态警报的主动[保留策略](https://techsee.me/blog/technology-based-solutions-to-enhance-customer-retention-strategies)，您可以快速识别客户使用量的下降，找出原因并支持客户克服这一问题。根据您的业务模式和需求，您可以为关键客户或每个客户设置提醒。

令人高兴的是，积极主动的客户参与方式有助于建立信任——这对长期保持客户关系至关重要。假设客户对您的 API 的使用下降了 2 倍。如果动态提醒标记了这一点，意味着您可以在客户需要的时候提供相关的咨询，您不仅会支持他们解决问题，还会建立信任和欣赏。这都是帮助防止流失的一部分。

### 最重要的客户保持策略是什么？

有许多策略可以通过[有针对性的主动保留](https://www.moesif.com/blog/customer-success/monitoring/6-ways-moesif-API-alerts-can-help-your-engineering-customer-success-and-sales-teams?utm_campaign=Int-site&utm_source=blog&utm_medium=body-cta&utm_content=define-measure-predict-customer-churn)来减少客户流失。它们的核心是一个简单的任务——让客户成功。这将减少流失。

让你的客户满意并留住他们的策略围绕着创造积极的互动(从入职到克服障碍)，建立对你的公司和产品的信任，以及传递价值感。正确掌握这些基本原则，你就能大大降低客户流失率。

这些顶级目标中的每一个都可以分解为各种以客户保持为中心的任务。它们可以是简单的事情，如发送一份新闻稿，提供解决常见产品集成问题的技巧，也可以是更加个性化的事情，提供独特的客户体验。同样，您的业务将决定您的特定需求和战略，但如果您将客户满意度作为核心，然后添加一个主动的方法来减少客户流失，您可能会看到积极的结果。

## 查看客户成功指标并获得洞察力

所有这些主动参与的基础是查看正确指标的能力。这使您能够识别哪些客户面临流失风险，并调查客户对您的服务参与度下降背后的原因。因此，监控客户成功也与正确的衡量标准有关，这也许并不奇怪。

客户成功与客户流失有着内在联系。如果你不支持你的客户取得成功，他们就会流失。如果你的产品提供的客户体验很糟糕，他们就会流失。如果你的客户服务很差呢？没错，更多的流失。因此，您需要一个稳健且经过深思熟虑的客户成功战略，以及一个客户成功管理团队，提供客户可能希望得到的所有知识和关怀。并且了解不同的客户希望获得不同水平和风格的客户服务。

有了这些要素，就该考虑您的客户成功指标了。Moesif 的方法是让您能够监控完整的端到端客户体验。这不仅能让您了解您的总体客户健康评分，还能识别客户行为的任何变化。最终可能导致客户流失的变化。

### 你如何确定客户是否会流失？

使用 Moesif，确定客户是否会流失的第一步是了解正常行为是什么样的。毕竟，如果你不知道规范是什么，你就不能标出与规范的偏差。要做到这一点，您需要持续监控功能和性能问题，以构建一幅正常对您的业务和客户意味着什么的画面。

然后是实时用户监控(RUM)的时候了。这不仅仅是关于基础设施指标，而是关于与采用、参与和保留相关的关键客户标准。Moesif 的高级异常检测算法处理所有这些数据，以发现与标准的偏差——可能表明客户将流失的行为模式。它发现了客户行为中的“未知的未知”，这意味着是时候让您的客户服务团队进行调查并可能提供额外的支持了。

有了[客户成功代理](https://www.custify.com/how-to-create-a-customer-success-journey-map)来调查您的客户成功指标中的异常情况，您可以采取主动的、几乎是有预见性的方法来更好地支持您的用户。在某些情况下，您甚至可以在客户意识到问题之前就发现问题。这可以给客户体验带来意想不到的快乐，特别是当您的客户成功代理向用户指出这一点并提供一个易于实施的简单解决方案时。

您可以引入动态警报来标记客户流失的迹象。定期查看关于您最重要的客户的报告也是一个好主意，这样您就可以监控*他们的*客户成功指标的总体方向。这种对客户健康评分的主动方法可以确定哪些客户最有可能流失，并使您能够在他们流失之前采取措施。您可以利用从您的客户成功指标中收集的见解来确定问题并实施解决方案，所有这些都可以降低您的流失率，并最终确保您从最初获得该客户的投资中实现最大价值。

## 通过定义、测量、分析并最终预测来停止流失

当你的顾客不高兴时，顾客就会流失。理解你的客户为什么在搅动是释放你阻止他们这样做的能力的关键。这就是为什么定义、衡量、分析和预测客户流失非常重要。除非你主动这样做，否则你很可能会让你的企业损失惨重。以至于你的客户流失率可能是最重要的指标。

幸运的是，有了合适的工具，您可以跟踪客户流失率，获得洞察力并采取措施降低流失率，从而为您的底线带来相关的好处。

# 如何为高容量 API 设计 API 分析数据收集

> 原文：<https://www.moesif.com/blog/technical/scaling-analytics/How-to-Design-API-Analytics-Data-Collection-for-High-Volume-APIs/>

对于任何希望深入了解其 API 和平台使用情况的平台公司来说，API 分析平台都是关键。产品所有者、增长团队、开发者关系等可以利用这些见解，根据您平台业务的原始健康状况而非直觉做出更多战略决策。然而，许多 API 平台每天都有非常高的 API 调用量。当设计一个分析系统时，这种容量带来了一系列独特的挑战，该分析系统在扩展时不会削弱他们的平台，也不会在查看云供应商的账单时感到震惊。这篇文章深入探讨了我们如何设计 Moesif 的 API 分析平台来处理每天有数十亿次 API 调用的公司的一些内部工作。

## 代理/SDK

面向规模的设计从一个设计良好的代理开始，该代理从各种应用程序收集指标并发送到您的分析平台。由于代理或 SDK 嵌入在您的应用程序中，如果您的分析服务过载，设计不佳的代理或 SDK 可能会削弱您的核心服务。为了防止这种情况，您的代理应该有自动故障保险和终止开关。

首先，代理应该从您的核心应用程序代码中异步收集任何指标，并且应该位于带外，这样，即使您的分析服务长时间关闭，您的应用程序可用性也不会受到影响。确保处理指标数据中的任何错误都得到处理，并且不会传播回应用程序本身。因为您将异步收集指标，所以您将希望利用本地队列。这可以在内存或磁盘中完成，具体取决于所需的数据一致性。但是请记住，任何需要在本地分配的资源(比如队列所需的内存或磁盘)都需要受到约束。否则，如果您的分析服务长时间停机，队列可能会继续无限制地增长，最终导致进程耗尽内存并崩溃。解决这个问题的一种方法是通过固定队列大小和丢弃旧事件。

在网络断开期间丢弃旧事件意味着您牺牲了一致性来换取可用性，这是 Brewer 的 CAP 定理的一个关键支柱，在讨论分布式数据存储时通常会引用，但在这里也适用。排队还使您能够批量处理事件，从而减少网络开销。

更多信息，请阅读[为 API 构建 SDK 的最佳实践](/blog/technical/sdks/Best-Practices-for-Building-SDKs-for-APIs/)

## 抽样

如果您的 API 一天要处理数十亿个 API 调用，即使有排队和批处理，您也可能很快超过计算和存储需求。运行这样一个系统的计算成本很容易达到每年数十万或数百万美元。减少这种压力的一种方法是通过智能采样算法。虽然持续选择随机百分比的事件进行记录而不是丢弃的基本算法可能在短期内有效，但这可能会严重降低您的分析系统的有用性。这是因为大多数产品在客户使用时都呈现出幂律曲线。你的前 20%的顾客会创造你 80%的流量。这也意味着你有一个发送很少流量的长尾客户。大量抽样的客户最初发送的数据很少，这可能会对您的客户旅程产生扭曲的看法。

减少这一问题的一种方法是实施更智能的采样方案。一种方法是基于每个用户或每个 API 键进行采样。例如，前 20%客户的任何用户将具有 10%的抽样率，而其余客户将具有 100%的抽样率(即捕获所有活动)。这意味着您需要一种机制来将采样率传播到您的代理。

## 收集网络

无论您的分析服务是只能从您自己的基础架构访问，还是可以从内部网访问，您都应该有一个在其中一个收集节点关闭时能够处理故障转移的系统。一个设计良好的网络将利用全球多个数据中心之间基于 DNS 的负载平衡，如 AWS Route 53 或具有相对较短 TTL 的 Azure Traffic Manager。在每个数据中心内，您可以利用代理服务器(如 HAProxy、NGINX、AWS ELB)在您的收集器节点之间分配流量。我们 Moesif 的大量用户使用 HAProxy 在每个数据中心内进行负载平衡，使用 Azure 的流量管理器在不同的数据中心之间进行负载平衡。你的收集器逻辑应该很轻。它的工作应该只是认证，一些轻量级的输入验证，并尽快保存到磁盘上。这就是像卡夫卡这样的解决方案非常有用的地方。

## 汇总

即使您进行了采样，您也可能会发现您的存储成本在不断增加，并且查询会花费非常长的时间。像 Elasticsearch 和 Cassandra 这样的现代数据库可以通过其分布式架构保存数百 TB 的数据，但是当您试图对这些大规模数据集执行聚合时，您会遇到越来越长的查询(或者更糟:内存不足错误)。此外，存储需求持续增长。说到分析，您可以选择存储数据的分辨率。这可以是它们出现时的原始事件，也可以是在特定时段(如每分钟或每小时)发生的所有活动的汇总*故事*。汇总指标可以显著降低存储需求，但会牺牲指标分辨率。许多分析系统都有分层汇总策略。例如，过去 7 天的所有数据都存储到事件分辨率或每隔 5 秒存储一次。7 天前的旧数据可以汇总到每小时的时间间隔内。而即使是比一年前更冷的*数据也可能会以每天为间隔进行汇总。您不太可能查看精确到时间戳的事件*

## 度量估计

有时你不需要精确的计数，可以在一定的误差范围内生活。让我们以计算每周活跃 API 键为例。假设您有一个有序的 API 日志，其中包含请求时间戳和用于访问 API 的 API 键。一种简单的方法是创建一个按周索引的映射，然后为每个*桶*创建一个包含每个桶的唯一键的集合。这种方法的一个问题是，如果您有大量唯一的 API 键(也称为高基数)，您可能会很快耗尽内存。一种不同的方法是利用概率数据结构来推断或估计集合的唯一性，而不是直接计数。概率数据结构的例子包括 [HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog) 和 [Bloom Filters](https://en.wikipedia.org/wiki/Bloom_filter) 毕竟，你可能会对上周是否有 100 或 10，000 个 API 键活跃感兴趣，但是如果你的分析系统报告 101 个而不是 100 个，你的决策也不会有所不同。对于这种情况，我们可以利用 HyperLogLog，它通过估计 API 键通过哈希算法哈希在一起时前导零的数量来估计唯一值的数量。准确性取决于为存储散列值所需的位向量分配了多少位。许多用于分析的现代数据库，如 Druid 和 Elasticsearch，都内置了 HyperLogLog，但能否确保您的数据能够利用它们取决于您。

# 如何在您的 SaaS 应用中显示客户调用 API 的次数与计划限制

> 原文：<https://www.moesif.com/blog/engineering/api-analytics/How-to-Display-the-Number-of-API-Calls-a-Customer-Made-vs-Plan-Limits-in-your-SaaS-app/>

我们 Moesif 努力为我们的客户提供最先进的监控和分析，以充分利用他们的 API。其中一个工具是我们的管理 API。

Moesif 管理 API 允许我们的客户检索我们存储的关于他们的 API 的数据。有了这个 API，他们可以检查发生了多少请求或者谁做了最多的请求。

B2B 客户经常问我们一个最紧迫的问题:

**“在过去 30 天内，一个用户调用了多少次 API？”**

在本文中，我们将学习如何使用管理 API 来回答这个问题。

## 什么

我们将使用 cURL 和 Node.js。此外，Moesif 的免费用户不能使用管理 API，因此需要付费订阅。

管理 API 不支持 CORS，所以不可能从浏览器直接使用它。

## 获取管理 API 的令牌

首先，我们需要检索一个管理 API 令牌。该密钥必须通过每个请求旁边的`Authorization`报头发送。

为此，我们需要访问 Moesif 网站上的管理 API 页面。

![Moesif Menu](https://github.com/OpenDocCN/geekdoc-devops-zh/raw/master/moesif-blog/img/3d0eeaa8d9ec7b5bfa19a317ef066bc9.png)

在该页面上，我们必须选择一个范围，然后单击*生成令牌*。

在我们的 API 调用中，我们只需要选择`read:events`范围。

## 使用带有 cURL 的令牌

测试一切是否正常的最简单的方法是，复制我们点击*生成令牌*后出现在我们的令牌下方的例子。

```py
curl -X GET https://api.moesif.com/v1 \
  -H 'Accept: application/json' \
  -H 'Authorization:Bearer <API_TOKEN>' 

这个请求将显示类似这样的内容:

{  "name":  "Moesif Management API",  "region":  "eastus"  } 

现在，让我们修改 cURL 请求，使它响应我们想要的答案:在过去的 30 天里，一个用户进行了多少次 API 调用？

curl -X POST 'https://api.moesif.com/search/~/count/events?from=-720h&to=now' \
  -H 'Content-Type: application/json' \
  -H 'Authorization:Bearer <API_TOKEN>' \
  -d '{"post_filter":{"bool":{"should":{"term":{"user_id.raw":"<USER_ID>"}}}}}' 

这里发生了什么事？

我们将向管理 API 的/search/~/count/events端点发送一个POST请求，并使用查询参数from和to来指定我们希望包含在结果中的时间段。720h除以24h得到我们想要的 30 天。

我们需要设置正确的Content-Type并将我们的API_TOKEN包含在Authorization头中。

此外，我们需要发送一个 JSON 对象作为查询。这是因为管理 API 使用弹性搜索 SDL 来执行搜索和过滤。

我们定义的查询只获取具有该特定 ID 的用户的呼叫。

响应看起来像这样:

{  "_shards":  {  "total":  1,  "successful":  1,  "skipped":  0,  "failed":  0  },  "hits":  {  "hits":  [],  "total":  5,  "max_score":  0  },  "took":  1,  "timed_out":  false  } 

我们可以看到我们的搜索有total数量的hits，这类似于我们的总 API 调用。

将令牌与 Node.js 一起使用

要设置一个简单的服务器作为我们的客户机和管理 API 之间的代理，我们可以使用 Node.js。

const http = require("http");
const https = require("https");

const API_TOKEN = "<API_TOKEN>";
const USER_ID = "<USER_ID>";

const quotaOneMillionCalls = 1000000;

const handleRequest = (request, response) => {
  const requestOptions = {
    method: "POST",
    headers: {
      Authorization: `Bearer ${API_TOKEN}`,
      "Content-Type": "application/json"
    }
  };

  const query = JSON.stringify({
    post_filter: {
      bool: {
        should: {
          term: { "user_id.raw": USER_ID }
        }
      }
    }
  });

  https
    .request(
      "https://api.moesif.com/search/~/count/events?from=-720h&to=now",
      requestOptions,
      moesifResponse => {
        let data = "";
        moesifResponse
          .on("data", chunk => (data += chunk))
          .on("end", () => {
            const apiCalls = JSON.parse(data).hits.total;
            const usage = apiCalls / (quotaOneMillionCalls / 100);
            response.end(
              `User ${USER_ID} made ${apiCalls} API calls. That is ${usage}% of their quota.`
            );
          });
      }
    )
    .end(query);
};

http.createServer(handleRequest).listen(8888); 

在这个例子中，我们使用 Node.js 的'http模块启动一个 HTTP 服务器，并使用它的https模块向管理 API 发出请求。

我们的 HTTP 服务器用描述在过去 30 天内发生了多少请求的文本来响应它接收的所有请求。

结论

通过它的管理 API，Moesif 提供了一个强大的工具来从你的 API 中获取重要的指标。

Elasticsearch DSL 使它非常灵活，因为它只是另一个 HTTP API ，它可以快速地与您想要的任何分析工具集成。

使用 API 分析推动关于您的 Web3 应用的有价值的见解

原文：https://www.moesif.com/blog/product-management/api-analytics/How-To-Drive-Valuable-Insights-From-API-Analytics-For-Web3/

关于你的 Web3 应用，你的 API 数据告诉你什么？通过从应用的 API 交易和通话记录中提取相关信息，您可以在客户发现问题之前发现并主动捕捉问题。让您的客户满意并减少流失-让您的客户成功团队高效运作。

Moesif 提供专门针对 Web3 应用和开发者平台的 API 分析。只需通过我们的 API 网关合作伙伴或快速安装的 SDK 连接 Moesif，您的团队现在就可以开始分析通过该 API 进行的调用。Moesif 的可定制仪表板允许跟踪和提醒您与标准的偏差。这种行为的全局视图可以为 Web3 工具和应用提供实时 API 分析，为您提供增强的业务视图。

从交易数据中获得洞察力

Web3 的采用正在增加。2015 年至 2022 年间，区块链的采用率与 1991 年至 1998 年间互联网的采用率增长速度相同。如果这种趋势继续下去，那么到 2027 年，Web3 用户将达到 10 亿。

对于早期的 Web3 采用者来说，有大量的机会，来自交易数据的洞察力可以帮助识别这些机会。Moesif 通过提升来自加密公司和其他 web 3/区块链采用者的交易数据来帮助实现这一点，以可视化数据并产生洞察力。

交易数据可以包含哪些信息？

如果您有合适的工具，交易数据可以提供丰富的信息。您的数据可以揭示转化率、受欢迎的端点和 API 负载异常的见解。它甚至可以帮助识别欺诈事件。正如彭博指出的，与领先的提供商合作可以揭示你的数据中的故事。然后，您可以利用数据揭示的优势，进一步发展您的业务，改进您的产品并赢得更多客户。

通过您的分析收集的可操作的见解可以帮助您更有效地运营业务，并增强您的客户体验。来自 Web3 应用程序的交易数据的洞察可以释放隐藏的业务增长潜力，就像分析 Web2 API 有效负载一样。

交易数据存储在哪里？

区块链交易数据由不同的区块链以不同的方式存储。由于支持区块链的开放数据结构，它们不适合存储大量数据。这就是为什么许多 dApps 提供分散存储。区块链本身作为分散的应用程序，存储在世界各地的“节点”中。

例如，比特币使用未用完的交易输出数据库来存储比特币交易的零钱。同时，以太坊区块链使用 trie(数字树)数据结构，包括状态尝试、存储尝试、事务尝试和接收尝试。

重要的交易 KPI

人们是否有效地使用你的服务？如果没有，你就面临着他们走向竞争对手的风险。测量您的事务的关键性能指标(KPI)可以提供大量的洞察力。这意味着您需要花一些时间来确定哪些是重要的事务 KPI。

在这一点上，Web2 和 Web3 之间的差异非常明显。Web3 的分散性质意味着许多对 Web2 至关重要的关键绩效指标对 Web3 可能没有意义。

对于支付处理，您应该衡量哪些 KPI？

说到支付处理，让你的财务指标井然有序是关键——这是每个成功企业都需要跟踪的事情。Web3 支付使用安全的分类账来处理资金流动，这是一种分散金融的形式。处理支付时往往没有与大数据、中央银行和 Web2 相关的个人数据要求和费用。

无论是财务 KPI 还是开发者 KPI ，管理顾问彼得·德鲁克(Peter Drucker)指出，“如果你不能衡量它，你就不能管理它。”这是决定衡量哪个 KPI 的基石。无论是客户满意度、客户保持率、客户获取率，还是您正在挖掘的终身价值，正确的 KPI 都将开启详细的洞察力。

对于 Web3 支付处理，相关指标包括交易 KPI、安全 KPI 和对账 KPI。事务性 KPI 可能包括诸如挖掘者数量、事务数量或散列率之类的度量。同时，安全 KPI 可以包括欺诈检测/警报的数量或防止的数据泄露的数量。在对账方面，您可以测量按时对账、过期对账项目的数量或自动对账的百分比等指标。

留住用户和获得新用户一样重要，所以监控你的转化率是你的 Web3 API 分析的基础部分。无论是作为衡量客户满意度还是运营效率的一种手段，你的用户行为都可以用来为你的产品决策提供信息。

KPI 如何融入您的工程路线图以确保客户成功？

您构建工程路线图的方式是从运营效率到客户成功的基础。毕竟，如果你没有掌握好基本原则，你能提供的成功客户服务就只有这么多了。然而，如果你的成绩一落千丈，你的净推广分数可能会一飞冲天。

尽早考虑 KPI 会有所帮助。哪些交易 KPI 对您很重要？只有知道了这一点，你才能确保你有能力跟踪和监控你的 Web3 产品的正确元素。

因此，当您对主要主题进行优先级排序时，以及当您集成项目管理、数据分析和其他工具时，都需要考虑将 KPI 融入您的工程路线图。您首先需要确定想要跟踪的 KPI，然后为 Web3 实施正确的数据分析来实现这一点。

Moesif 检测到的 KPI 如何帮助你了解用户数据的偏差？

Moesif 为 Web3 开发者平台提供 API 分析。我们通过确保 Web3 工具/服务提供商保留他们的客户并遵守治理规则来服务 Web3 社区。

其中包括使用 KPI 来识别用户数据中的任何偏差。我们通过让您能够创建控制面板来做到这一点，工作区代表不同的指标。您可以分析每个工作区，查看每个指标的历史性能。数据的图形化特性意味着任何偏差都会很快显现出来，从而允许快速采取行动来解决业务和产品问题。

您还可以设置预警规则，以便在指标超过特定阈值时通知您。这将立即标记任何超出您设置的阈值的偏差，并通过我们的 Slack integration 或内置的行为电子邮件工具立即传达偏差。

通过实时用户监控发展您的产品

通过正确的产品分析来加强你的 Web3 业务，你可以通过实时用户监控来发展你的产品。监控真实用户数据远比合成监控更有效，因为它深入到您交付的真实用户体验中，并标记任何性能问题。这意味着您可以对您的产品、战略和交付模式进行更改，以提供增强的客户体验。这可能会导致加速增长，因为所做的决策是由真实的用户数据支持的。

分析如何加速增长？

分析通过帮助你了解人们如何使用你的产品以及他们在哪里遇到困难来加速增长。您可以了解他们面临的挑战，确定导致客户流失的模式，并了解当他们冲击您的付费服务时会发生什么。

通过更深入地了解[消费者行为]](https://online . Ben . edu/programs/MBA/resources/evaluating-consumer-behavior-to-boost-your-business){:target = " _ blank " rel = " noope ner " }您可以找到更好地为客户服务的方法，并支持他们改变行为，使他们和您的企业都受益。您可以确定消除产品缺陷的需求，并找到新的方法来增强用户体验。从本质上来说，分析意味着您可以将日志数据转换为可操作的信息，用于提升您的产品。

RUM 与合成数据

实时用户监控(RUM)意味着使用真实用户监控来分析您产品的性能，并支持加速增长。它使用日志来提供基于数据的客户反馈和对用户实际行为的洞察。

许多公司让你使用合成数据来测试你的产品，但那些虚假的端点和虚假的分析无法告诉你，当你的服务的真正用户面临挑战或遇到付费墙时，他们实际上会做什么。这意味着用合成数据进行测试只能到此为止。这是一种对用户可能会做什么的理论方法，而不是基于现实情况的反馈。

这就是为什么通过实时用户监控，你的产品有更大的发展空间。RUM 提供了合成数据无法提供的价值。它提供了对您的业务在任何给定时刻和持续发生的事情的见解。

例如，如果转化为付费客户的开发人员数量低于预期，您可以使用 RUM 来发现他们的痛点。然后，您可以解决这些棘手问题，并通过真实的用户监控来见证您的更改所带来的影响。

与其他形式的客户反馈一起，这为您提供了优化产品的强大能力，以提供出色的用户体验，支持长期用户忠诚度和持续的产品发展。这正是 Moesif 提供实时用户监控的原因；因为这样做能让你更好地发展你的产品和业务。

如果你准备好为 Web3 进行 API 分析，Moesif 可以提供帮助。我们可以为您的区块链技术业务提供有洞察力的数据分析和可操作的信息，从而推动业务增长。请联系我们，了解我们对 Web3 初创公司的更多支持。

如何在开发人员门户中嵌入 API 调试仪表板

原文：https://www.moesif.com/blog/technical/dashboards/How-To-Embed-an-API-Debug-Dashboard-in-your-Developer-Portal/

您已经创建了仪表板和报告。也许你也和你的同事合作过。现在，您希望您的客户能够像您的内部团队成员一样了解您的 API。通过在您的开发人员门户中嵌入 API 日志，您可以为您的客户提供简单的入门体验和简单的调试工具，使他们能够尽快集成您的 API，而不会出现问题。

什么是 Moesif 工作区？

Moesif 平台有公共工作区的概念。这些是在 Moesif 平台中创建的仪表板，就像您为内部团队成员创建的仪表板一样。最大的区别是公共工作空间有自动约束来保护您的数据。数据可以通过像客户的用户 id 或账户 id 这样的字段来沙箱化。此外，访问公共工作区的用户不需要登录 Moesif。相反，他们可以使用工作区访问令牌或共享链接来访问数据。

Moesif 支持多种工作空间类型，包括 API 事件日志、分段、时间序列、热图等。

创建模板

Moesif 提供模板来构建强大的图表，并将这些图表嵌入到面向客户的门户中。可以使用动态字段创建模板，以约束要与客户共享的数据。您可以通过登录并点击Share按钮并选择Embed Template来从您的 API 数据创建一个模板。

嵌入工作区模板需要两个步骤。首先，一个端点生成具有正确限制的 URL。然后，使用 URL 将图表嵌入面向客户的门户。

创建工作区 URL

使用管理 API 键和动态字段生成工作区 URL 的请求。

curl -X POST -H 'Authorization: <Authorization Token>' -H 'Content-Type: application/json' -i 'https://api.moesif.com/v1/portal/~/workspaces/<workspace_id>/access_token
  -d '{
  "template": {
    "values": {
      "user_id": "{YOUR_DYNAMIC_VALUE}"
    }
  }
}' 

带有工作区 URL 和工作区访问令牌的响应。

{
  access_token: '{WORKSPACE_ACCESS_TOKEN}',
  url: 'https://www.moesif.com/public/{WORKSPACE_ACCESS_TOKEN}/ws/<workspace_id>?embed=true'
} 

注意:您可以根据您需要的过滤器修改请求体，以限制共享的数据。

嵌入工作区

您可以将工作区嵌入到用户期望看到它们的门户或网站中。Embed 适用于任何支持使用 iFrame 嵌入内容的门户或网站。您可以通过使用上一步中生成的 iframe 来显示工作区。数据访问将限于先前设置的动态值。

<iframe
  id="preview-frame"
  src="https://www.moesif.com/public/{WORKSPACE_ACCESS_TOKEN}/ws/<workspace_id>?embed=true"
  name="preview-frame"
  frameborder="0"
  noresize="noresize">
</iframe> 

对贴有白色标签的工作区感兴趣，请联系 Moesif 团队了解更多信息。

如何在记录 3scale API 网关的 API 调用时获取客户和应用上下文

原文：https://www.moesif.com/blog/technical/3scale/How-to-Get-Customer-and-Application-Context-When-Logging-API-Calls-for-3scale-API-Gateway/

由于 API 处理大量各种类型的数据，对于任何数据提供者来说，关键问题是如何具体保护这些数据。一种身份验证方法，使开发人员能够构建满足其所有需求的应用程序，确定谁可以访问 API 以保护敏感数据并确保请求不被篡改。身份验证是指实体证明一个身份。简而言之，认证是验证你就是你所声称的那个人的行为。如果没有身份验证，就没有简单的方法将请求与特定的用户数据相关联，也没有方法保护恶意用户的请求，恶意用户可能会删除其他用户的数据。身份验证不应该是事后才想到的，而是构建在 API 的结构中。

身份验证模式

根据我们的 API，我们可能需要使用不同的身份验证模式来发布访问 API 的凭证。这些范围可以从 API 密钥到定制配置。

3Scale 支持以下身份验证模式:

标准 API 密钥

一种身份验证模型，其中单个随机字符串或哈希充当标识符和秘密令牌。每个具有 API 权限的应用程序都有一个唯一的字符串。默认情况下，关键参数的名称为user_key。在对 3scale 进行授权调用之前，我们可以使用相同的标签或选择另一个标签。

应用程序标识符和密钥对

一种身份验证模型，其中不可变的标识符-应用程序 Id (App_Id)和可变的密钥字符串-应用程序密钥(App_Keys)被分成两个令牌。App_Id是常数，可能是也可能不是秘密。每个应用程序可以有 1-n 个应用程序密钥，其中每个密钥直接与App_Id相关联，并且应该被视为秘密。

在 3Scale 中，每个服务可以使用不同的身份验证模式，但每个服务只能使用一种模式。在身份验证部分，我们可以选择所需的身份验证模式。

应用程序上下文

3Scale 提供了一个管理 API 端点来获取与每个用户相关的应用程序上下文。应用上下文包含与单个用户相关的关于他们与 3 种规模 API(如first_traffic_at、first_daily_traffic_at)的交互的细节，以及其他个人可识别信息数据，如- user_id、user_account_id、service_id、plan信息和其他细节。有了对这些细节的访问，将请求与特定用户关联起来就很容易了。

根据我们使用的身份验证方法，我们调用管理端点来获取应用程序上下文。在使用标准 API keys 身份验证方法时，我们通过调用这个端点来获取应用程序上下文

curl -v -X GET "https://#{domain}/admin/api/applications.xml?access_token=#{ADMIN_ACCESS_TOKEN}&user_key=#{user_key}" 

在使用应用程序标识符和密钥对身份验证方法时，我们通过调用这个端点来获取应用程序上下文

curl -v -X GET "https://#{domain}/admin/api/applications.xml?access_token=#{ADMIN_ACCESS_TOKEN}&app_id=#{app_id}&app_key=#{app_key}" 

设置具有 3 个刻度的 Moesif API 分析

Moesif 在 Luarocks 中提供了一个插件，用于捕获 API 请求和响应，并记录到 Moesif，以便通过 3Scale 轻松检查和实时调试您的 API 流量。该插件在本地捕获指标并对其进行排队，这使得该插件能够将指标数据发送到 Moesif 收集网络的带外，而不会影响您的应用程序。

建议通过 Luarocks 安装 Moesif:

luarocks install --server=http://luarocks.org/manifests/moesif lua-resty-moesif 

身份验证凭据位置

3Scale 为最终用户在调用 API 时通过HTTP_Headers或作为query_parameters传递身份验证凭据提供了灵活性。Moesif 将在头和查询参数中查找凭证，并获取特定用户的应用程序上下文。Moesif 提供了一个配置选项来设置字段名称，该名称与配置 API 认证设置时使用的名称相同。默认情况下，3Scale 使用user_key作为标准 API 密钥，使用app_id和app_key作为 App_Id 和 App_Key 对认证方法。

识别用户和公司(账户)

管理端点将应用程序上下文作为 XML 实体返回。Moesif 提供了一个配置选项来设置 3Scale 应用程序 XML 实体的字段名，该实体将用于标识用户和公司(帐户)。默认情况下，用户和公司字段名为id和user_account_id，但其他有效的示例包括user_key和service_id。

-- Function to parse 3Scale XML entity
-- @param `user_id_name` The 3scale field name from 3scale's application XML entity used to identify the user. Default `id`.
-- @param `company_id_name` The 3scale field name from 3scale's application XML entity used to identify the company (account). Default `user_account_id`.
-- @param `debug`  A flag to print logs
function parseXML(user_id_name, company_id_name, debug)
    -- config_response is the response from an api call to fetch application context which is a XML entity 
    local response_body = config_response:match("(%<.*>)")
    if response_body ~= nil then 
        local xobject = xml.eval(response_body)
        local xapplication = xobject:find("application")
        if xapplication ~= nil then
            local xtable = {}
            for k, v in pairs(xapplication) do
                if v ~= nil and type(v) == "table" then 
                    xtable[v:tag()] = k
                end
            end

            local key = xapplication[xtable[user_id_name]]
            if key ~= nil then 
                if debug then
                    ngx.log(ngx.DEBUG, "Successfully fetched the userId ")
                end
                -- Set the UserId
                local user_id = key[1]
            else 
                if debug then
                    ngx.log(ngx.DEBUG, "The user_id_name provided by the user does not exist ")
                end
            end
            local companyKey = xapplication[xtable[company_id_name]]
            if companyKey ~= nil then 
                if debug then
                    ngx.log(ngx.DEBUG, "[moesif] Successfully fetched the companyId (accountId) ")
                end
                -- Set the CompanyId (AccountId)
                local company_id = companyKey[1]
            else 
                if debug then
                    ngx.log(ngx.DEBUG, "[moesif] The company_id_name provided by the user does not exist ")
                end
            end
        else
            if debug then
                ngx.log(ngx.DEBUG, "Application tag does not exist ")
            end
        end
    else
        if debug then
            ngx.log(ngx.DEBUG, "Xml response body does not exist ")
        end
    end
end 

结论

通过这种方式，插件可以将每个事件或行为与单个客户联系起来，并且可以通过一起查看多个事件来发现行为趋势，以确定产品问题，例如用户为什么停止使用你的 API，或者他们最常使用的功能或端点。

如何指导客户使用 Moesif 自动集成 API

原文：https://www.moesif.com/blog/developer-marketing/behavioral-emails/How-to-Guide-Customers-on-API-Integration-Automatically-With-Moesif/

你有一个开发人员正在采用的 API 程序；客户已经注册，但有些还没有集成；在那些已经整合的公司中，有一些很早就陷入困境，没有了声音；理想情况下，您希望帮助这两组客户通过开发人员漏斗。

Moesif 可以充当开发人员的催化剂，在他们遇到挫折并放弃之前主动通知他们集成问题。确保他们有良好的体验-尽快解除对客户的封锁。

用例

吸引顾客尝试你的产品通常只是成功的一半。在开发者漏斗中有许多阶段将这些线索转化为付费客户并最终转化为传播者。

你可能已经有客户注册了你的 API 产品，但是没有更进一步。如果他们从未尝试过你的产品，那么所有让他们进入漏斗顶端的销售和营销努力都是徒劳的。为了激励他们行动起来，在注册 7 天后给他们发一封自动邮件，提醒他们还没有融入。并将他们放入一个 drip campaign ，这将向他们发送关于产品特性和常见开发者问题的有用信息。你可以挽救沉没成本，并通过一些明智的推动来扭转这些客户。

类似地，当开发人员第一次集成您的 API 时，他们很可能会遇到您的产品无法工作或者没有数据显示的时候。这通常是由于不正确的实现或客户端错误。如果什么都不做，挫折感会增加，客户可能会流失。

积极主动地让您的客户在他们的平台上更加成功，并降低他们离开的可能性。通过监控 HTTP 状态代码错误，当开发人员的实现收到太多 4xx 客户端错误时，向他们发送电子邮件，让他们知道错误的性质，以便他们可以轻松地找到解决失败调用的方法。

掌握客户 API 集成的行动手册

自动化重复过程是整个产品设计的一个关键属性。通过将有效载荷的可观察性与行为电子邮件相结合，Moesif 能够让您在许多功能、性能和产品问题的复杂工作流程中更加高效。

本演示行动手册重点关注您的客户在集成过程中可能遇到的问题，通过向您展示如何处理注册 7 天后仍未激活并在集成过程中收到过多 4xx 错误的用户，来具体说明 Moesif 的功能。

其他行动手册侧重于保护您的 API 免受攻击和故意滥用以及配额和计费问题的自动通知。这三部行动手册仅仅触及了我们平台的皮毛；一旦你掌握了创建自己的群组、指定触发事件和设计行为邮件的诀窍，你就会想知道在 Moesif 之前你都做了些什么。

配料清单

我们将使用 Moesif 的分析工具来构建这个应用程序。如果你还没有创建账户，你可以免费注册。

行动手册创建的步骤

行动手册包括工作流、sop 和文化价值观，它们共同形成了一个一致的反应—行动。不管你想达到什么目的，Moesif 行动手册包含两个关键要素:团队规范和电子邮件创建。

群组规范

Moesif 将用户和公司定义为不同的实体，这些实体可以被分组到共享相似标准的群组中。不同的群组包括共享类似领域的群组，例如:订阅计划、端点使用、请求代码等。正如之前的教程中所解释的那样，通过对用户/公司人口统计数据和行为进行过滤，可以创建群组。

要创建新的用户群组，请转到 Moesif 工具的用户>用户查找部分，并从下拉菜单中选择与和执行事件匹配的用户字段，如下所示。事件过滤器和用户/公司字段的完整列表可以在我们的用户分析面板中找到。

注册后 7 天未激活

如果客户在注册后的一段时间内(比如 7 天)还没有集成您的 API，那么提醒他们会很有帮助。通常，客户成功或解决方案工程部门将手动跟进这些客户和潜在客户，以确保他们成功完成试用或 POC。这可能会带来巨大的负担，并占用客户在教育或寻找其他机会等其他领域取得成功的时间。借助 Moesif，客户激活和指导可以实现自动化和规模化。

要创建一批注册账户后 7 天仍未激活的客户，请转到用户>用户查找部分:

• 从匹配的用户设置过滤器:
  • Created is before 7 Days Ago、&、Created is after 4 Weeks Ago
• 从执行的事件设置过滤器:
  • Event Type is API Call(2)
  • 时间段为At Most 0 times in Last 4 weeks，如下图。

积分有太多 4xx 错误

如果集成有太多 4xx 错误，这可能意味着客户做错了什么，可能需要解决方案工程师或支持人员的帮助。您可以让客户知道他们的实施有异常多的客户端(4xx)错误，这意味着可能需要进一步调查，而不是对每个客户都了如指掌。您的电子邮件应该提供一些关于可疑问题的自助资源，或者安排与解决方案工程师通话的方法。

根据您的内部工作流程，您可以使用 Moesif 的抄送或密件抄送直接自动抄送给负责该客户的解决方案工程师。

要创建在过去 7 天内收到过多 4xx 错误的群组，请转到用户>用户查找，并从已执行事件中选择过滤器:response.Status Code是400 Bad Request (0)、404 Not Found (0)或405 Method Not Allowed (0)，然后将时间段设置为At Least 1000 times in Last 7 Days，如下所示。

一旦设置了过滤器，Moesif 将查看所有当前和历史数据，并将所有符合过滤器标准的用户/公司组合在一起。我们还将监控用户/公司是否继续属于该群体，而无需任何人工干预。

然后，该群组可用于填充行为电子邮件中的收件人列表。

电子邮件创建

你可以使用拖放式所见即所得编辑器在 Moesif 中设计 HTML 邮件。要创建行为电子邮件，请转到 Moesif 工具的警报和治理>行为电子邮件部分。

第一步是添加一个新的+模板，其中模板包括电子邮件设计以及其他相关信息，例如哪些群组应该接收电子邮件。关于创建电子邮件模板的完整文档在可用，但可以说，电子邮件创建非常简单，一旦完成，可以使用测试按钮来验证电子邮件。

注册后 7 天未激活

只需将预定义的群组添加到行为电子邮件的收件人列表中，为那些进步停滞的人提供帮助:

每当新注册的客户没有在 7 天内整合，他们将自动被添加到队列中，并发送一封有用的电子邮件。

新集成有太多 4xx 错误

同样，只需将这一群客户添加到一封行为电子邮件中，警告他们他们的实施会收到大量 4xx 错误代码:

只要在过去 7 天内积分超过 1，000 4xx，特定客户将自动添加到队列中，并且将向这些客户发送警告电子邮件。

外卖食品

对于一个 API 优先的公司来说，减少成功集成和驱动价值所需的时间是非常重要的。借助我们的 SaaS 平台，我们努力让我们的客户尽可能高效。通过有效负载可观察性和行为电子邮件的结合，我们创建了自动化的警告流程，有助于推动您的客户进行集成，从而节省您的时间和资源。

如何通过使用 Moesif with Hubspot 或 Salesforce 向开发人员发送客户生命周期电子邮件来改善开发人员体验

原文：https://www.moesif.com/blog/technical/developer-journey/How-to-Improve-Developer-Experience-by-Guiding-Developers-With-Customer-Lifecycle-Emails-using-Moesif-and-Hubspot-or-Salesforce/

让你的公司成功取决于你的客户能够支持你的产品，并从中获得价值。当你使用集客营销来获得客户时，电子邮件不一定要被归为二等公民。我们认为电子邮件是 B2B 公司与其客户之间最强大的沟通渠道之一。

如果你专注于开发人员，那么你应该认真考虑部署生命周期电子邮件作为产品体验的一个关键组成部分。当您遵循自助服务模式时尤其如此，因为支持扩展的唯一方式是尽可能多地自动化流程。在内部，我们利用自己的 API 分析工具，与 HubSpot CRM 集成，作为催化剂推动开发人员通过采用漏斗。

跟踪用户/网站行为，然后利用这些数据推动你的滴滴推广活动——鼓励你的开发者完成整合，尝试你的所有功能

构建成功的生命周期电子邮件计划的步骤

通过发送及时和适合阶段的电子邮件，而不是只发送漏斗顶部的电子邮件，你将能够大规模地建立长期的客户关系。这篇博客文章向你展示了我们在 Moesif 是如何做的，并且反过来把我们的客户群扩大到了成千上万的开发者:

第一步。将您的 CRM 与 Moesif 集成

Moesif 与 Salesforce 和 HubSpot 集成，因此您可以将 API 参数直接导入 CRM 工具。设置集成时要记住的事项:

• Moesif 中的用户对应于 HubSpot 中的联系人和 Salesforce 中的帐户，
• Moesif 中的公司对应于 HubSpot 中的公司和 Salesforce 中的帐户，
• 任何字段都可以从 Moesif 映射到 HubSpot 或 Salesforce 对象

在我们的内部实现中，我们将 Moesif 的 API 分析平台中的许多字段映射到 HubSpot 对象。示例字段包括以下内容:

田	描述
电子邮件	注册时，客户提供他们的电子邮件
作用	在注册过程中，客户提供他们的角色
计划	客户订阅的计划
首次注册日期	当客户首次集成您的平台时
首次 API 调用日期	当他们发出第一个 API 调用时

Moesif 支持将任何字段映射到 HubSpot 对象，包括客户第一次与您的平台集成的时间，他们的第一次 API 调用，以及他们使用了多少 API。

第二步。根据原则对电子邮件进行分类

不要给每个人都发同样的邮件，往好了说这是浪费时间，往坏了说这是在积极破坏你的客户关系。按角色对您的客户进行细分，然后将信息与他们的特定专业相匹配。许多 API 平台公司主要销售给开发者，但是产品经理、CSM、开发者关系和高管都可能是潜在的买家，或者至少在购买决策中是重要的。

第三步。设置电子邮件工作流程

电子邮件工作流是一系列基于用户/网站行为触发的自动化电子邮件。通过从几十个触发器、条件和操作中进行选择，您可以在正确的时间向正确的客户发送正确的电子邮件。利用这些点滴电子邮件活动，你可以将潜在客户培养置于自动驾驶状态，并无限扩大你的入职规模。

就像电影行业在 20 世纪 30 年代制定的营销规则 7(他们发现，在你购买产品之前，你需要“听到”广告商的信息至少 7 次)，电子邮件工作流程可以很容易地让你的客户记住你。

最佳实践要求在你的公报中提供真正的价值，而不仅仅是反复要求交易。我们发现，2-3 个目标内容的节奏，然后提供帮助或推广，大约是正确的平衡。

第四步。发送基于时间的电子邮件

在自助服务采用中，您的客户应该已经在注册过程中输入了他们的角色。我们竭尽全力为每一类客户创建不同的工作流程:开发人员、产品经理、客户成功专家、开发人员关系、执行人员等。

注册后，每位新客户都会收到一封有针对性的欢迎电子邮件，向他们介绍最适合其专业的产品功能。例如，开发人员的信息是花更少的时间调试，花更多的时间开发，而产品经理则是推动更高的采用率和参与度。同样，电子邮件的行动号召按钮(标题为“工程师解决方案”或“产品经理解决方案”)，重定向到我们网站的不同部分。

经过一段时间后，我们发现 3-5 天的间隔效果很好，序列中的下一封电子邮件将被发送。同样，内容是针对客户的领域的，开发人员会收到技术文章和操作指南，而产品团队会收到业务电子书和案例研究。温和的提醒电子邮件穿插在增值内容之间，例如提供帮助集成或咨询以充分利用您的 API 计划。

客户和他的公司保持在这些序列中，直到我们的平台被集成并且 API 调用开始。一旦进行了第一次 API 调用，我们就转移到基于行为的电子邮件中的其他工作流。

第五步。发送基于行为的电子邮件

基于 API 指标的基于行为的电子邮件才是真正神奇的地方。通过向您的客户传达符合他们在生命周期谱中特定位置的信息，您可以使互动更加切中要点，更有可能提供帮助，也更有可能赢得客户的好感。

我们发现以下基于行为、以 API 为中心的电子邮件是一个很好的起点:

API 度量	电子邮件主题
进行第一次 API 调用	恭喜你被安排好了
接近计划定额	计划警告
超计划定额	计划升级
超过 400/500 错误流或 SLA	检查集成的错误警告
使用过时或易受攻击的 SDK	升级警告
中断供应	全球断电警告

显然，您可以将时间和中断驱动的触发器结合起来，如下所示:

API 度量	电子邮件主题
前 7 天没有 API 调用	文档和行动手册的集成帮助
在过去 Z 小时内，端点 Y 上出现超过 X 个错误	检查端点 Y 的错误警告
过去 24 小时内超过 100 个 API 调用	CSM 通知

将 Moesif 与您的 CRM 相结合，提高入职效率

电子邮件是你的产品和品牌的核心部分。通过将您的 CRM 与 Moseif 的 API 分析平台相结合，您可以利用 API 使用数据并创建高度个性化的客户生命周期电子邮件。组合解决方案可以成为真正的催化剂，吸引开发人员并加速他们通过采用漏斗。

如何集成 Moesif 和 Recurly 以轻松实现 API 货币化

原文：https://www.moesif.com/blog/developer-platforms/recurly/How-To-Integrate-Moesif-And-Recurly-To-Easily-Monetize-Your-APIs/

构建优秀的应用程序和 API 并不是一件容易的事情。更难的是，试图利用他们赚钱并创造一个可持续发展的业务。作为我们帮助公司创造更好产品的使命的一部分，我们决定投入大量精力帮助企业更容易赚钱。我们的无代码计费方法是一种简单而优雅的方式，可以非常快速地获得向客户收取使用费的能力。简单的货币化是我们从你的 API 中获取收入的最新功能的前提。我们的最新功能可以在 Moesif 的 计费表 屏幕下找到。

为什么要使用计费表？

计量产品的使用情况，并对使用情况收费，是技术产品货币化的最常见方式之一。统计使用情况，将指标发送给计费提供商，然后让计费提供商收取资金。

对于那些已经为其产品实施了基于使用量的计费方案的人来说，您知道这个过程可能相当复杂。它包括收集大量数据，将这些数据放在正确的位置，收集所欠的资金，如果发票没有支付，则进行治理，以便用户不再能够访问该服务。创建这样的计费系统需要大量的编码、集成、测试和支持工作。

Moesif 通过收集大量可以计费的指标，然后自动按用户和/或公司进行汇总，让您轻松做到这一点。有了 Moesif，您需要准确计费的所有数据都已经存在，这也是我们认为创建计费表功能非常有意义的原因。我们也已经为您完成了在 Moesif 和 Recurly 之间创建集成的工作。这意味着只需几次点击，你就可以向客户收取使用费。根据复杂程度，您将在几分钟而不是几天甚至几周内拥有计费能力。

如何在 Moesif 中创建和使用计费表

一旦你把你的 API 和 Moesif 集成在一起，赚钱就非常简单了。在你与 Moesif 整合之后，有几个步骤可以让你知道什么时候可以获得收入。这些步骤包括:

• 在递归中设置计划和附加模块
• 将 Moesif webhook 添加到递归
• 将递归 API 细节插入 Moesif
• 在 Moesif 中配置计费参数
• 激活计费仪表

所有这些步骤都非常直观，只需几分钟。

在递归中设置计划和附加模块

货币化的第一步是在 Recurly 中实际设置一些计划，以便对使用进行计费。要在递归中设置计划，您需要使用左侧菜单点击配置，然后点击计划。

一旦你进入计划屏幕，你可以点击屏幕右上角的新计划来创建一个新计划。

计划可以包含您需要的任何配置，但是您必须确保至少创建了一个附加组件。附加组件必须配置为:

• 在计费周期结束时向客户收费
• 费用基于单位价格

在递归计划中对此进行配置，如下所示:

一旦您的计划配置完毕，点击屏幕底部的创建计划。

在这一点上，我们现在有一个计划，我们可以与 Moesif 集成，并开始按使用计费。

在 Moesif 中递归配置

一旦您的计划和附加组件被创建，是时候开始递归地集成 Moesif 了。进入计费表页面，点击屏幕右上角的编辑计费提供商下拉菜单，在 Moesif 中开始递归配置。

这将打开递归配置屏幕，引导您完成集成。在这个屏幕上，您可以获得递归插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到递归

集成的第一步是在 Recurly 中将 Moesif webhook 添加到配置中。添加此功能允许 Recurly 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 recurry，从 recurry 的左侧菜单中选择集成，然后选择 Webhooks 。

这将把你带到 Webhooks 页面，在这里你可以查看现有的 Webhooks 并添加新的 webhooks。要添加新的 webhook，我们将点击屏幕右上角的配置按钮。

在下一个屏幕上，您需要点击屏幕右上角的新端点按钮。

从这里，我们将把我们的 Moesif API 端点 URL 插入到端点 URL 字段中，并将我们的 Moesif 应用程序 ID 添加到 HTTP AUTH 用户名字段中。

在 HTTP 认证密码字段中不应输入任何内容。

这些细节都可以在前面提到的 Moesif 中的递归配置页面上找到。

将递归 API 细节插入 Moesif

为了让 Moesif 在 Recurly 中将使用量添加到订阅中，我们需要将 Recurly API 细节添加到 Moesif 中。这是在 Moesif 的递归配置屏幕中完成的，这个屏幕与我们之前使用的屏幕相同。

目前，Moesif 只支持递归 API 的 v3，因此值是默认的，并且对于递归 API 版本字段是不可编辑的。

对于 Recurly API 键字段，您需要从 Recurly 检索 API 键以将其插入。为此，在左侧菜单中点击集成，并选择 API 证书。然后，您将能够在屏幕上的默认 API 密钥字段中看到您的 API 的私有密钥。

从 Recurly 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Recurly API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，您在 Moesif 中的递归集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。缺省值对于大多数目的来说应该可以，但是如果您确实需要定制它，它将允许您指定如何将递归的订阅和帐户字段映射到 Moesif 中的公司 ID 和用户 ID 。

在 Moesif 中配置计费参数

一旦添加了与 Recurly 的集成，您就可以在 Moesif 中配置您的计费参数。如果您还没有这样做，您将需要创建一个新的计费表。要做到这一点，在 Moesif 中，您需要像开始递归集成时一样，单击左侧菜单中的计费表链接。

一旦你进入计费表屏幕，你将点击 +添加计费表按钮开始创建一个新的计费表。

在添加计费计数器屏幕上，您将添加:

• 计费仪表名称
• 账单提供商信息
• 添加过滤器以指定要计费的事件

在下面的例子中，我设置了一个名为“我的计费计划”的计费计划，它使用 Recurly 作为我的计费提供者。我还决定对任何响应为 200 OK 的 API 调用计费。

输入详细信息后，您将在屏幕底部看到过滤器输出的可视化表示。虽然计费只会发生在未来，但您将能够从历史上看到您的过滤器如何处理现有数据。这有助于确保，尤其是对于更复杂的过滤，您已经按照您需要的方式配置好了一切。

激活计费仪表

我们货币化的最后一步是保存和激活计费表。要做到这一点，我们只需要确保在配置页面的顶部打开计费表。

最后，我们需要点击屏幕顶部的创建。

点击 Create 按钮后，在弹出的模式中会提示您确认计费表的创建。

需要注意的是，一旦创建了计费表，过滤标准和计费提供商的详细信息都不能更改。只有名称可以更改，计费表的状态可以打开和关闭。这是出于合规和审计的目的。计费仪表也不能删除，但如果不再使用，可以存档。

我们现在应该看到我们的新计费表出现在计费表主页上。

现在，我们已经成功创建了一个计费表，它将开始向 Recurly 发送使用数据。这种集成可以在几分钟内完成，不需要任何代码。如需了解更多信息，您也可以查看我们的文档。

你自己试试吧！

如果你有一个 API，或者你的产品的任何其他部分，你想赚钱，Moesif 可以帮助你。正如上面的步骤中所提到的，这是一种从你的产品中获得收入的简单而快速的方法。如果您已经在货币化您的产品，并在寻找一个更简单的解决方案，我们的计费功能是简化您的设置和降低您现有货币化工作的支持成本的好方法。

Moesif 还提供了许多与我们的计费功能捆绑得很好的其他出色功能，包括漏斗指标和留存分析、自动化用户行为电子邮件、定制指标仪表板和治理功能。立即注册开始使用账单和更多功能。

如何集成 Moesif 和 Stripe，轻松实现 API 货币化

原文：https://www.moesif.com/blog/developer-platforms/stripe/How-To-Integrate-Moesif-And-Stripe-To-Easily-Monetize-Your-APIs/

一旦你决定将你的应用或应用编程接口货币化，你就开始寻找一个简单而强大的付费解决方案。在 Moesif，我们知道计费解决方案实际上很难实施。让你的产品从“0 到货币化”并不总是一条直截了当的道路，即使它应该是。我们的无代码计费方法是一种简单而优雅的方式，可以非常快速地获得向客户收取使用费的能力。简单的货币化是我们从您的应用和 API 中创收的最新功能的前提。我们的最新功能可以在 Moesif 的计费表屏幕下找到。

为什么要使用计费表？

计量产品的使用情况，并对使用情况收费，是技术产品货币化的最常见方式之一。要做到这一点，您需要监控使用统计数据，将指标发送给账单提供商，然后让账单提供商收集资金。

对于那些已经为其产品实施了基于使用的计费解决方案的人来说，您知道这个过程可能相当复杂。它包括收集大量数据，将这些数据放在正确的位置，收集所欠的资金，如果发票没有支付，则进行治理，以便用户不再能够访问该服务。创建这样的计费系统需要大量的编码、集成、测试和支持工作。

Moesif 通过收集大量可以计费的指标，然后自动按用户和/或公司进行汇总，让您轻松做到这一点。有了 Moesif，您需要准确计费的所有数据都已经存在，这也是我们认为创建计费表功能非常有意义的原因。我们还为您完成了在 Moesif 和 Stripe 之间创建集成的工作。这意味着只需几次点击，你就可以向客户收取使用费。根据复杂程度，您将在几分钟而不是几天甚至几周内拥有计费能力。

如何在 Moesif 中创建和使用计费表

一旦你把你的 API 和 Moesif 集成在一起，赚钱就非常简单了。在你与 Moesif 整合之后，有几个步骤可以帮助你获得收入。这些步骤包括:

* Setting up products and prices in Stripe
* Adding the Moesif webhook to Stripe
* Plugging the Stripe API details into Moesif
* Configuring the billing parameters in Moesif
* Activating the billing meter 

所有这些步骤都非常直观，只需几分钟。

在 Stripe 中设置产品和价格

货币化的第一步是在 Stripe 中实际设置一些产品，以便按使用量计费。要在 Stripe 中设置产品，您需要点击标题菜单中的产品。

一旦你进入产品屏幕，你可以点击屏幕右上角的 +添加产品来创建一个新产品。

产品可以包含您需要的任何配置，但是您必须确保至少创建一个价格条目。价格必须配置为:

• 循环的
• 计费周期应为月
• 使用是计量的
• 按时间段内使用价值总和计量的使用费用
• 建议添加一个价格描述

产品的配置示例如下所示:

产品配置完成后，点击屏幕右上角的保存产品。

现在，我们有了一个可以和 Moesif 一起使用的产品，并开始为使用计费。

在 Moesif 中配置条带

一旦你的产品和价格确定下来，是时候开始整合 Stripe 和 Moesif 了。要开始在 Moesif 中配置 Stripe，请转到计费表页面，并点击屏幕右上角的编辑计费提供商下拉菜单。

这将打开条带配置屏幕，引导您完成集成。在这个屏幕上，您可以获得将 Stripe 插入 Moesif 所需的所有信息。配置的每个步骤都包含在模式中。

将 Moesif webhook 添加到条带

集成的第一步是将 Moesif webhook 添加到 Stripe 的配置中。添加此功能允许 Stripe 向 Moesif 发送订阅更新。

要将 Moesif webhook 添加到 Stripe，从右上角点击开发者，然后在左侧菜单中点击 Webhooks 。这将把你带到网页挂钩页面，在那里你可以查看现有的网页挂钩并添加新的。要添加新的 webhook，我们将单击屏幕底部的添加端点按钮。

从这里，我们将插入我们的 Moesif API 端点 URL，并配置要监听的事件。您需要将 Moesif Webhook URL 复制到端点 URL 字段，然后点击 +选择事件按钮。

这些细节都可以在前面提到的 Moesif 中的条带配置页面上找到。

您应该选择客户下的选项进行选择所有客户事件。之后，点击屏幕底部的添加事件按钮。

此后，您将返回到添加端点详细信息的原始屏幕。滚动到屏幕底部，单击添加端点将端点保存到条带。

将条带 API 细节插入 Moesif

为了让 Moesif 向 Stripe 中的订阅添加使用量，我们需要向 Moesif 中添加 Stripe API 细节。这是在 Moesif 的条带配置屏幕中完成的，与我们之前使用的屏幕相同。

目前，Moesif 仅支持条带 API 的版本 2020-08-27 ，因此字段默认为条带 API 版本字段。

对于 Stripe API 密钥字段，您需要从 Stripe 中检索 API 密钥以将其插入。从开发者界面，与我们在上一步中使用的界面相同，您将点击 API 键。然后，您将能够在屏幕上的秘密密钥或生成的受限密钥字段中看到您的 API 的私有密钥。两个键都可以用。

从 Stripe 复制密钥后，您将把这个密钥粘贴到 Moesif 中的 Stripe API 密钥字段。完成后，回到 Moesif，你可以向下滚动到屏幕底部，点击保存保存配置。

至此，Moesif 中的条带集成已经完成，您可以开始使用它了。

或者，您也可以在 Moesif 中定制客户 ID 源。缺省值对于大多数目的来说应该可以，但是如果您确实需要定制它，它将允许您指定如何将条带订阅和客户对象映射到 Moesif 中的公司 ID 和用户 ID 。

在 Moesif 中配置计费参数

添加与 Stripe 的集成后，您可以在 Moesif 中配置您的计费参数。如果您还没有这样做，您将需要创建一个新的计费表。为此，在 Moesif 中，您需要像开始条带集成时一样，单击左侧菜单中的计费表链接。

一旦你进入计费表屏幕，你将点击 +添加计费表按钮开始创建一个新的计费表。

在添加计费计数器屏幕上，您将添加:

• 计费仪表名称
• 账单提供商信息
• 添加过滤器以指定要计费的事件

在下面的示例中，我设置了一个名为 My Billing Plan 的计费计划，该计划使用 Stripe 作为我的计费提供商。我还决定对任何响应为 200 OK 的 API 调用计费。

输入详细信息后，您将在屏幕底部看到过滤器输出的可视化表示。虽然计费只会发生在未来，但您将能够从历史上看到您的过滤器如何处理现有数据。这有助于确保，尤其是对于更复杂的过滤，您已经按照您需要的方式配置好了一切。

激活计费仪表

我们货币化的最后一步是保存和激活计费表。要做到这一点，我们只需要确保在配置页面的顶部打开计费表。

最后，我们需要点击屏幕顶部的创建。

点击 Create 按钮后，在弹出的模式中会提示您确认计费表的创建。

需要注意的是，一旦创建了计费表，过滤标准和计费提供商的详细信息都不能更改。只有名称可以更改，计费表的状态可以打开和关闭。这是出于合规和审计的目的。计费仪表也不能删除，但如果不再使用，可以存档。

我们现在应该看到我们的新计费表出现在计费表主页上。

现在，我们已经成功创建了一个计费表，它将开始向条带发送使用数据。这种集成可以在几分钟内完成，不需要任何代码。如需了解更多信息，您也可以查看我们的文档。

你自己试试吧！

如果你有一个 API，或者你的产品的任何其他部分，你想赚钱，Moesif 可以帮助你。正如上面的步骤中所提到的，这是一种从你的产品中获得收入的简单而快速的方法。如果您已经在货币化您的产品，并在寻找一个更简单的解决方案，我们的计费功能是简化您的设置和降低您现有货币化工作的支持成本的好方法。

Moesif 还提供了许多与我们的计费功能捆绑得很好的其他出色功能，包括漏斗指标和留存分析、自动化用户行为电子邮件、定制指标仪表板和治理功能。立即注册开始使用账单和更多功能。

如何推出新的自助式开发人员平台

原文：https://www.moesif.com/blog/developer-platforms/self-service/How-to-Launch-a-Developer-Platform-Self-Service/

如今，企业软件公司的销售方式与十年前大不相同。以前，大多数软件都是收缩包装的，需要大量的工作来分发和实现，并且销售给必须在整个部门或组织中部署它的主管。购买过程涉及很长的销售周期，通常包括试点、成本效益分析、采购和法律审查。

如今，企业公司正在构建开发者平台，个人开发者可以注册 SaaS 服务，集成 SDK，并在几分钟内开始通过信用卡支付。从 Stripe 和 Twilio 这样的支付和电信到 Algolia 这样的电子商务搜索，现在都可以通过 API 和 SDK 交付。随着 SaaS 的崛起，企业公司正在颠覆新的行业，从最新一代专注于移动和 web 2.0 的公司，如脸书、AirBnB 和优步的走向市场剧本中吸取一页。这意味着广告、入职体验和自助服务比现场销售或内部销售更重要。然而，这种转变并不容易。本文列出了一些必需的关键元素。

自助入职

任何开发者平台或自助式 SaaS 都必须从他们的入职流程开始。上一代企业公司可以简单地依赖“日程演示”或“联系我们”表单，而开发人员平台现在必须支持从注册到通过无接触或低接触模式支付实施费用的一切。因为许多企业软件产品需要工程专业知识来设置，并且比注册网飞更复杂，所以应该把重点放在你的入职流程上。您需要收集一些信息，如公司名称和人员的角色。这使得体验能够个性化——不管这个人是开发人员还是非开发人员。无论是安装 SDK 还是使用第三方工具进行身份验证，您都需要清楚地定义实现的后续步骤。

衡量入职成功

首次 Hello World 的时间(TTFHW)，或有时称为首次 API 调用的时间，是跟踪您的入职效率的关键指标。具体来说，TTFHW 是开发人员注册您的服务并进行第一次 API 调用所需的时间。有些产品的 TTFHW 可能很短，只有几分钟，但如果需要认真调查，其他产品可能需要几周甚至几个月。留意那些表现出比其他人更好的 TTFHW 的用户群。比如哪个营销渠道最有效，他们在用什么整合等等。他们的第一个 API 调用可能像来自 Postman 或来自他们的产品代码的测试一样简单。欲了解更多信息，请阅读开发者关系项目的最佳实践，以衡量 API 平台的成功

减少入职摩擦

为了减少摩擦，将入职流程保持在三步或更少。即使您的平台有很大的表面积或很大的集成组件，也要尽快确定向开发人员展示价值所需的最小集成是什么。这意味着设置自定义规则或配置应用程序设置等不太重要的步骤不应在入职期间显示。例如，在 Moesif，我们只提示我们的新客户集成中间件 SDK，以获得对其 API 的即时可见性。Moesif 有额外的 SDK 来丰富用户配置文件的人口统计信息，如计划配额或公司名称，但我们不会在入职期间提示用户安装这些软件。相反，我们通过进度清单和点滴邮件来推动我们的用户。当用户重定向到未设置的产品区域时，我们会显示相关的辅助 onboarding 页面。这种做法有时被称为渐进入职。

自助定价

自助服务应该意味着无接触或低接触销售，并且几乎总是包括免费等级或有限期限的试用。如果您团队中的某个人必须通过电话来演示产品或提供新帐户，并涉及工程实施，那么自助服务将非常难以实现。相反，只需公开分享您的企业定价，因为获取成本将远远超过客户的终身价值。同样，自助服务对于高初始合同价值也不理想。虽然最初是自助服务的客户可以随着时间的推移增加其使用量，并成熟到更昂贵的计划，但他们最初可能不愿意为更高的计划付费。不要仅仅为了降低销售和支持成本而推出自助式开发平台。相反，将自助服务视为打开对传统销售来说过于昂贵的新市场(如小型企业)的一种方式，或者减少需求挖掘所需的工作(如在拥有大量用户基础并可通过口碑营销推动的市场)。

定价方式

虽然一些公司可以获得更高的费率，但大多数自助服务模式在价格点低于 1000 美元/月，甚至低于 500 美元/月时表现最佳。理想情况下，您需要针对不同客户群和规模的多个价位。这可以通过基于使用情况、座位数量、多个层或捆绑包、附加组件或上述方式的组合来实现。只选择一种定价模式，以防止客户决策疲劳。将分层计划与基于使用和席位的计划混在一起会让客户感到困惑。

定价什么

为了适应客户的需求，许多 API first 公司将某种基于使用的定价与价值标准联系起来。这可以是交易量(如短信发送量)、月活跃用户数、美元交易量等。如果不同的客户关注不同的价值指标，为了占领整个市场，您可能需要不止一个指标。

登录 API auth 0 就是一个明显的例子。除了公司规模，他们还有两类客户:B2C 和 B2B。B2C 拥有非常高的月活跃用户数。如果 Auth0 在其较低层级仅提供 100 或 1，000 MAU，则可能显得极其昂贵；我们已经看到 1,000 MAU 的仅限邀请的测试版应用，甚至还没有推出；7000+MAU 可能更适合他们的免费计划。

许多 B2B 公司的年运营率可能在 10 美元到 100 美元之间，但从未突破 7，000 MAU。为了获取这一端的价值，Auth0 决定在他们的 B2B 计划中打包某些高价值的功能，如企业登录支持和基于角色的高级访问控制。有关定价的更多信息，请参见SaaS 定价策略剖析

数据驱动的定价

一旦决定了自助服务平台的包装和定位，您仍然需要确定实际限制。免费层每月有 10，000 个 API 事务，还是每月有 100 万个 API 事务？确定这些金额的最佳方法是首先根据您的客户资料确定价格点，例如免费、每月 100 美元和每月 500 美元。然后，根据用户的使用数据，使用您选择的工具对用户进行聚类。一个简单快速的视觉扫视甚至脚本化的 k-means 也可以。你能在某些组中找到一个局部极大值吗？你可能会发现这样的趋势，大多数少于 10 名员工的公司使用 X。为了做到这一点，您需要跟踪每个客户的使用数据，并能够通过 API 分析工具(如 Moesif 或 API 平台的替代分析工具)轻松实现可视化。

自助服务支持

第三方开发人员讨厌仅仅为了解决支持问题而发电子邮件或打电话给某人。此外，解决方案工程师、顾问和工程师作为一线支持非常昂贵。如果开发人员在网上找不到他们的答案，他们应该是可用的。这意味着您需要在文档、教程、GitHub 示例和其他自助资源上投入精力。使开发人员能够研究和解决他们自己的问题，而不是依赖昂贵的第一层支持人员。阅读设计良好的静态 REST 文档了解如何组织各种资源的概述。

如何记录 AWS Lambda Go 函数的 API 调用

原文：https://www.moesif.com/blog/aws-lambda/go/How-to-Log-API-Calls-for-AWS-Lambda-Go-functions/

AWS Lambda 是一种无服务器计算服务，它运行您的代码来响应事件，并自动为您管理底层计算资源。Amazon API Gateway 是一个托管服务，它允许开发人员定义 REST API 的 HTTP 端点，并将这些端点与相应的后端业务逻辑连接起来。API Gateway 位于 API 的后端服务和 API 用户之间，处理对 API 端点的 HTTP 请求、任何认证需求，并将它们路由到正确的后端。在无服务器环境中，我们对底层基础设施的控制较少，日志记录是构建后端的重要部分，对于无服务器 API 也是如此。通过跟踪 API 请求，不仅可以了解 API 的执行情况以及哪里需要优化，还可以了解 API 的使用情况以及哪些功能使用得最多。

在本指南中，我们将向您展示如何在几分钟内设置 Moesif API analytics，以使用 API Gateway 作为触发器来跟踪托管在 AWS Lambda 上的 API。

创建 AWS Lambda 函数处理程序

在我们用 go 编写的 lambda 函数中，我们需要包含 aws-lambda-go 包，它实现了 Go 的 lambda 编程模型。此外，我们需要实现 handler 函数和 main()函数。

下面是一个示例类和 Lambda 函数，它接收 Amazon API Gateway 事件记录数据作为输入，并以 200 状态、标题和与请求相同的正文作为响应。

package main

import (
	"github.com/aws/aws-lambda-go/lambda"
	"github.com/aws/aws-lambda-go/events"
	"context"
)

func handleRequest(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {

	return events.APIGatewayProxyResponse{
		Body:       request.Body,
		StatusCode: 200,
		Headers: map[string] string {
			"RspHeader1":     "RspHeaderValue1",
			"Content-Type":   "application/json",
			"Content-Length": "1000",
		},
	   }, nil
}

func main() {
	lambda.Start(handleRequest)
} 

我们需要按照请求发生的顺序维护请求的历史。每个日志条目包含关于请求的信息，包括客户端 IP 地址、请求日期/时间、请求路径、HTTP 代码、提供的字节、用户代理等。使用 Moesif AWS Lambda 中间件 for Go ，我们将记录所有 API 调用并发送给 Moesif。

我们将为我们的函数定义配置选项。更多详情，请参考 Moesif 配置选项。

func MoesifOptions() map[string]interface{} {
	var moesifOptions = map[string]interface{} {
		"Log_Body": true,
	}
	return moesifOptions
} 

现在，我们将把Moesif Middleware添加到我们的 lambda 函数中。

func main() {
	lambda.Start(moesifawslambda.MoesifLogger(HandleLambdaEvent, MoesifOptions()))
} 

集成之后，我们将看到所有的 API 调用都被捕获并发送给 Moesif。

安全记录数据

认证请求包含凭证，响应包含安全令牌，在日志中记录凭证和令牌是不安全的。有了 Moesif，我们可以安全地提取我们需要的信息，同时保持安全性，不需要对我们的代码库进行大量的修改。使用Mask_Event_Model配置选项，我们可以屏蔽请求/响应头字段或请求/响应体，以保持认证信息的机密性。此外，如果我们想删除 Moesif 的日志请求和响应主体，我们可以将配置选项Log_Body设置为false。我们还可以捕获所有从我们的应用程序到第三方(如 Stripe、Github 或我们自己的内部 API)的传出 API 调用。

要了解如何使用您的 API，请捕获 API 请求和响应，并记录到 Moesif，以便通过 AWS Lambda 对您的 API 流量进行分析和实时调试。关于如何集成 Moesif 的更多细节，您可以从 GitHub 中克隆并运行这个示例应用程序。

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

如何记录来自 Envoy 代理的 API 流量并使用 Moesif 监控指标

原文：https://www.moesif.com/blog/technical/envoy/How-to-Log-API-Traffic-from-Envoy-Proxy-and-Monitor-Metrics-with-Moesif/

Envoy 是为微服务和面向服务的架构设计的高性能 C++分布式代理，也是为大规模服务网格设计的可扩展通信总线和“通用数据平面”。Envoy 与每个应用程序一起运行，并通过以平台无关的方式提供通用功能来抽象网络。当基础设施中的所有服务流量都通过 Envoy mesh 流动时，除了在单一位置添加底层功能之外，还可以轻松地集中可观察性、安全性等交叉问题。Envoy 支持静态配置模型，还允许通过 gRPC/proto buf API 进行配置，从而简化大规模管理。Envoy 还提供了各种过滤器来增加对 gRPC、速率限制、阴影、金丝雀路由和 API 可观察性的支持。

API 可观察性是一种新趋势，它是传统监控的发展，使业务和工程团队能够回答任意问题。传统的监控可以回答已知的未知数，如每分钟错误或状态，如红色、黄绿色，因为监控通过探测已知的指标来工作，因此您将添加性能计数器或其他工具来监控该指标。另一方面，API 可观察性使你能够回答未知的未知，这些未知来自复杂的工程和商业挑战。

Moesif 为 Envoy 提供了一个插件，只需几分钟就可以开始使用 API observability，这样您就可以专注于提供客户喜欢的功能，而不是处理构建自己的数据基础设施的维护成本。在本文中，我们将讨论 Moesif 为您提供的见解，以及如何将其集成到您的 Envoy 代理中。然后，我们将讨论如何使用 Moesif 和 Envoy 来最好地利用 API 的可观察性。

特使背景

如果您是一名微服务实践者，在为您的组织的 API 产品组合迁移到分布式架构时，担心联网和可观察性问题，那么您最有可能的解决方案是在您的技术堆栈中包含一个服务代理平台。在当今以云为中心的世界中，业务逻辑通常分布在微服务中。每个服务都有依赖于该服务的其他消费者，无论是其他团队、合作伙伴，甚至是产生收入的客户。虽然其中大多数是 RESTful APIs，但它们也可以是 SOAP、gRPC、GraphQL、Thrift 或其他协议。“(从技术上讲，gRPC 仍然使用 http/2，但不像我们典型的 JSON/RESTful API)。管理和观察 L7 对于任何云应用都至关重要，因为应用语义和弹性的很大一部分都依赖于 L7 流量。

在可用的代理中，HAProxy、NGINX 和 Envoy 是可靠的、经过验证的代理，Envoy 是最新的一个。虽然 HAProxy 是一个非常可靠、快速且经过验证的代理，但人们对微服务可用的最小功能集存在担忧。NGINX 最初是作为一个 web 服务器设计的，随着时间的推移，已经发展到支持其他用例，如代理服务器和 API 网关。NGINX 是一个高性能的 web 服务器，支持无中断重新加载，但是 NGINX 开源有很多限制，包括有限的可观察性和健康检查。Envoy 完全是为微服务而设计的，具有无中断重新加载(称为热重启)、可观察性、弹性和高级负载平衡等功能。Envoy 还采用分布式架构，将最终一致性作为核心设计原则，并为配置提供动态 API。

如何设置 Envoy API 监控

使用 Moesif Envoy 过滤器，您的 API 流量将被记录到 Moesif 中，以进行分析和报告。Moesif 为工程团队提供了深刻的见解，以了解如何使用他们的 API，并快速解决复杂的问题。因为 Moesif 还跟踪谁在调用你的 API 以及它们是如何被访问的，所以产品驱动的团队可以了解整个客户之旅以及在哪里投入更多的资源。借助 API 可观察性，具有前瞻性思维的工程领导者可以通过对激活漏斗、保留报告等进行自助式分析，增强面向客户的团队的能力。Moesif 还分析您的 API 有效负载，以便进行故障排除和业务洞察，这样您就能够了解特定有效负载键的使用情况，等等。

Envoy 公开了各种 API，允许您动态配置代理。通过配置一个允许 Envoy 在可配置地址监听网络流量的Listener，您可以启用通过代理的流量，并使用几个Filters增强数据流。HTTP 级过滤器的 API 允许过滤器在不了解底层协议的情况下运行。

Moesif 使用 HTTP Lua 过滤器来捕获 API 请求/响应，以便进行 API 分析和监控。当 Envoy 在配置中加载脚本时，它会查找脚本定义的两个全局函数:envoy_on_request和envoy_on_response。在请求路径中，Envoy 将运行envoy_on_request向请求 API 传递句柄，而在响应路径中，Envoy 将运行envoy_on_response向响应 API 传递句柄。

对于每个请求，当调用envoy_on_request函数时，Moesif 捕获请求方法、头和主体信息，当调用envoy_on_response函数时，moes if 捕获响应状态代码、头和主体信息。它将该事件添加到队列中，并定期刷新队列以将事件发送到 Moesif。Moesif 确保即使在高流量期间也不会通过批处理事件增加延迟。

添加 Moesif Envoy 插件

要为特使添加 Moesif 插件，您需要您的 Moesif 应用程序 Id。你可以通过注册一个免费的 Moesif 账户来获得一个，然后在入职时选择 Envoy。Moesif 建议对所有 Envoy 代理实例和数据中心区域使用单一的应用程序 Id。这确保了无论物理拓扑如何，您都有一个 API 使用数据的统一视图。使用 Moesif 的高基数、高维度分析引擎，您仍然可以根据任意数量的属性进行分解。

Moesif 仍然建议为每个环境创建单独的应用程序 id，如生产、试运行和开发，以保持数据隔离。

envoy.yaml文件应该是这样的:

 http_filters:
    - name: envoy.filters.http.lua
    typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
        inline_code: |
        local log = require("moesif.plugins.log")

        -- Moesif configs
        log.set_application_id("Your Moesif Application Id")

        function envoy_on_request(request_handle)
            -- Log Event Request to Moesif
            log.log_request(request_handle)
        end

        function envoy_on_response(response_handle)
            -- Log Event Response to Moesif
            log.log_response(response_handle)
        end 

一旦安装了 Moesif Envoy 插件，您的 API 流量应该会出现在 Moesif 的实时事件流中。

更多信息关于如何配置您的 Envoy 代理以捕获 Moesif 的流量和日志。

如何使用 API 可观察性

工程度量

您可能感兴趣的第一件事是工程度量，比如我的 API 性能如何。这种类型的指标可以通过进入 Moesif 中的事件->-时间序列视图获得。然后，您可以选择第 90 个百分位数的延迟作为要绘制的指标。然后，您可以按 URI 路由分组，以了解哪些端点的性能最差。在这里，您可以通过 API 属性(如 route、verb)以及 HTTP 头和主体字段来过滤流量。

业务指标

要将 API 调用与单个客户相关联，请使用set_user_id_header()或set_company_id_header()配置选项配置 Envoy。

一旦完成，你就可以通过 Moesif 的用户跟踪 SDK 存储额外的客户属性，如公司域名或用户电子邮件。这使得面向客户的团队能够清楚地了解谁在使用您的 API，以及他们是如何使用的。

Moesif 支持分析常见的有效载荷内容类型，包括 JSON 和 XML。例如，您可以按response.body.label对 API 调用进行分组，然后按Company Domain进行分组，如下图所示。这显示了哪些客户由于遇到缺货问题而收到了不好的体验，即使没有抛出 500 错误。

漏斗报告

客户可以在您的 API 之外(比如在您的 UI 中)采取各种各样的操作。为了跟踪这个，你可以添加 moesif-browser-js 来跟踪用户动作。用户动作是客户在你的 UI 中完成的目标，例如签到或购买计划。一旦完成，您就可以从 UI 到 API 跟踪您的端到端客户旅程。

在上面的报告中，我们创建了一个由三个步骤组成的漏斗分析。

1. 第一步是客户登录您的 web 应用程序。
2. 从第一步到第二步显示了通过您的平台进行首次支付交易的客户的减少。到达第二步所需的时间被称为“第一个 Hello World 的时间”或 TTFHW。
3. 从第二步到第三步，显示了最终进行 100 次以上支付交易的用户的百分比。这可能是你的“啊哈”时刻，或者当有人从你的 API 中获得全部价值的时候。

处理敏感数据

如果您的应用程序包含敏感数据，如医疗保健或财务数据，您可以通过以下两种方式之一实现数据合规性:

1.零知识安全

客户端加密具有低维护 SaaS 的优势，同时仍然让您能够控制您的数据。因为在发送给 Moesif 之前，您在内部对数据进行控制和加密，所以 Moesif 实际上无法访问您的数据。这只需要在您的基础设施中运行一个名为安全代理的小型设备，即可动态处理数据的加密/解密。

2.数据屏蔽

如果不想客户端加密，也可以直接使用插件屏蔽数据。这通过set_request_body_masks()和set_response_body_masks()配置选项来处理。例如，您可以屏蔽有效负载中可能出现的名为密码的字段。此外，如果您想一起删除日志请求和响应主体，您可以将set_disable_capture_request_body()或set_disable_capture_response_body()配置选项设置为false。

结束语

有了 Moesif Envoy 插件，您的工程和业务团队就拥有了深入的 API 可观察性，而无需花费高昂的成本来构建和维护您自己开发的工具。

要查看 Envoy 与 Moesif 的集成，您可以从 GitHub 中克隆并运行这个示例应用程序

如何在后新冠肺炎时代维护开发者关系

原文：https://www.moesif.com/blog/developer-relations/travel/How-To-Maintain-Developer-Relations-in-a-Post-COVID-19-World/

2020 年还没有过半，社会已经发生了根本性的变化。新冠肺炎疫情关闭了大多数商店，迫使许多人失业。当收入下降时，企业主会问自己:“哪部分员工对公司运营至关重要？”

对于向开发人员出售软件服务的公司，您可能会有这样的印象，即开发人员关系团队对公司至关重要。毕竟，如果你不能亲自与客户见面，你如何与他们互动？你如何发现他们需要什么？你如何改善对他们的服务？

最近，我听说一些 DevRel 专业人员被一家公司解雇了，他们的职位也被取消了。因此，让我们来谈谈在冠状病毒的时代，DevRel 发生了什么变化，以及 DevRel 如何，甚至是否仍然可以为您的客户增加价值，进而为您的公司增加价值。

虚荣与价值

DevRel 中一个众所周知的问题是对虚荣行为的关注。有规律的用户互动比有成千上万什么都不做的追随者要好得多。以我的经验来看，公司希望他们的追随者数量上升，因为这样看起来不错。

面对面的活动也是如此。让你的一个 DevRel 人员在美国的一个重要会议上发言，比让他们坐在德国的办公室里为你的客户制作内容要好得多。

我并不是说这些会议是浪费金钱，好的事情可以从中得到。但是，许多 DevRel 人做这份工作是因为他们喜欢旅行，喜欢在观众面前演讲——在这样的活动中更容易与潜在客户或投资者搭讪。但是最终，DevRel 是关于授权给使用你的服务的开发者，虽然它确实很酷，追随者和会议讨论不应该是第一优先。

关注开发者

那么，当不允许你的 DevRel 团队周游世界并亲自与客户交谈时，你的 DevRel 团队能做些什么呢？

它可以做它在冠状病毒危机之前可能已经做过的事情！

编写好的文档

好医生是每个公司都想要的超能力。不幸的是，大多数开发人员并不擅长写作，或者只是不喜欢写作。所以一个会编码的作家，可以把知识和技术结合在一起。

当开发人员选择一项服务时，文档常常是成败的关键。即使你的产品是最好的，如果没有人理解它，那么潜在客户会去别处。

创建教育内容

向你的观众展示你的关心。围绕你的产品为生态系统创造内容。如果你想卖给他们一个聊天机器人，教他们如何创建一个网站。如果您想向他们销售 API 监控，请告诉他们如何设计 API 以适应未来的变化。

教授核心技术，通过一篇博文或一段视频帮助他们解决反复出现的问题。他们可以在任何地方使用你的内容，不仅仅是在办公室，当他们无聊的时候也可以在隔离区使用。

倾听开发者的声音

观察人们在社交媒体上谈论什么。没有时间或金钱亲自拜访您的 DevRel 团队的人仍然可以有好的想法。留意你的服务嵌入的生态系统中会发生什么。没有人喜欢一个不知名的商业实体，无视客户，只做自己的事情。

您的 DevRel 团队可以监控互联网上的不同渠道，收集开发人员面临的意见、问题和想法，并将其带到公司的其他部门以改进您的服务。

管理社区

它还可以帮助您创建和管理自己的社区，尤其是在您的共享空间中目前还没有社区的情况下。在您自己的社区中，您的 DevRel 团队可能需要做更多的调整工作，但是您也有机会按照自己的意愿来构建它。

如果人们自由地来到你的网上社区谈论他们的工作，你不必在网上到处搜索来获得你需要的信息。

在冠状病毒肆虐的时候保持你的 DevRel 团队？

这要看你的情况了！

一个 DevRel 团队可以给你的公司带来很多价值，即使他们在受雇期间坐在他们的家庭办公室里。他们是你与顾客之间的纽带。他们让你的公司在你的空间里更有吸引力。当构建软件和服务时，你不希望盲目——把焦点放在错误的领域会很快变得昂贵。

如果资金紧张是因为人们更喜欢囤积卫生纸，而不是购买订阅你的服务，那么你很快将不得不面对这样一个事实:你不能再支付所有员工的工资了。让一个 DevRel 团队没有他们可以专注的产品，可能不是最明智的想法。

如何用 ApiRequest 发出 HTTP 请求并捕获响应？超正析象管(Image Orthicon)

原文：https://www.moesif.com/blog/technical/apirequest/How-To-Make-HTTP-Requests-and-Capture-Responses-with-ApiRequest.IO/

概述如何使用免费的 ApiRequest。IO 工具，用于为调试和测试生成和捕获 RESTful API 请求。您可以与其他人共享您的 API 工作空间，以获得关于 API 错误的帮助。

什么是 ApiRequest？木卫一？

这是一个由 Moesif 提供的基于浏览器的免费工具，用于帮助人们调试 API 错误:

• HTTP 客户端向公共或私有 REST API 发出一系列 HTTP 请求，甚至向本地主机发出请求。

• 请求/响应历史记录保存 30 天，以便您可以重新发送过去的请求。

• 该 URL 是可共享的，因此您可以在调试问题时与同事共享结果。任何拥有该链接的人都可以查看您的工作区。

如何发送单个请求

1. 转到 ApiRequest。IO 自动创建一个新的工作空间。

2. 在请求生成器中输入您想要调用的 API 的 URL。您还可以输入任何 HTTP 请求头和 URL 查询参数。如果像 POST 一样需要主体，您可以为请求主体输入 JSON 有效负载。

3. 点击发送一条，结果将保存在右面板的工作区历史下。

4. 工作区历史记录将在链接下保存 30 天。您可以与同事或开发人员社区分享帮助。您应该看到 HTTP 状态代码、HTTP 头和响应 JSON。

高级用法

请求构建器允许您创建一系列 API 调用，而不仅仅是一个。如果错误是在特定的请求顺序或时间安排中出现的，这将有所帮助。

纽扣	细节
添加请求	要在序列中添加第二个请求，只需点击添加请求按钮。将显示一个新的构建器表单，让您输入第二个 HTTP 请求。
删除请求	要删除序列中的请求，点击删除请求按钮。
延迟(毫秒)	这是从序列开始的偏移延迟。例如，假设顺序为
**-请求 1:延迟 0
-请求 2:延迟 125 毫秒
-请求 3:延迟 500 毫秒** 这意味着第三个请求将在第一个请求之后 500 毫秒发送。

最后，要启动序列，点击发送全部按钮。您也可以使用发送一个按钮单独发送序列中的特定步骤。

为什么创建 ApiRequest。木卫一？

Moesif 创建了 ApiRequest。IO 作为一个免费工具，可以帮助开发者更容易地调试 API。我们自己也支持 API，并多次收到关于特定 API 调用的帮助请求。我们厌倦了将 URL 和 JSON 有效载荷复制粘贴到电子邮件和 Slack 中，然后又不得不复制到 cURL 或 PostMan 中。

如何让你的 API 平台易于开发者采用

原文：https://www.moesif.com/blog/developer-platforms/developer-experience/How-to-make-Your-API-Platform-Easy-for-Developers-to-Adopt/

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

How to make your api platform easy for developers to adopt from Derric Gilling

注意，这是我在纽约 API Days Live 上展示的幻灯片。

如何在经济衰退期间向开发商推销你的 SaaS 平台

原文：https://www.moesif.com/blog/developer-marketing/recession/How-to-Market-Your-SaaS-Platform-to-Developers-During-a-Recession/

随着最近由于新冠肺炎事件导致的公开股票市场的低迷，衰退或萧条几乎是不可避免的。我们可能会看到零售、旅游、娱乐和其他行业的大规模倒闭。冠状病毒疾病的溢出效应以及随之而来的就地避难，可能会给初创企业带来严重后果。由于就地安置规则而关闭的小型实体企业将不再花钱在脸书或 Yelp 上推广他们的业务，也不会维持他们的 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 平台是困难的。通常营销和销售预算需要减少，企业更不愿意签订新合同，等等。通过关注你的采用漏斗，寻找廉价的增长渠道，如内容和合作伙伴关系，可以奏效。

如何用 API 分析和 UTM 参数衡量开发者获取

原文：https://www.moesif.com/blog/business/acquisition/How-to-Measure-Developer-Acquisition-with-API-Analytics-and-UTM-Parameters/

在建立企业时，衡量什么可行，什么不可行是至关重要的。对于 API 至上的公司来说尤其如此。他们需要知道:

• 他们的 API 是否稳定——他们的客户满意吗
• 有多少客户在使用他们的 APIs 这是一项可行的业务吗
• 使用了哪些 API 特性，如何使用它们——需要进行哪些产品增强
• 不一定直接映射到 API 的技术方面的标准，例如谁是他们的用户，他们是如何获得的

Moesif API Analytics 允许合并业务和技术视角，以便呈现操作环境的完整画面。我们的解决方案利用了一个漏斗，从客户与我们的登录页面的最早交互开始，通过集成和 TTFHH 过渡，以客户每天通过数十亿次 API 调用的稳定状态结束。

开发者归属

开发者归因是将使用我们服务的开发者归因于他们最初发现我们服务的渠道的行为。比如脸书广告、谷歌搜索结果、博客文章或推文。

通常，使用我们的 API 的开发人员正在旅途中。

1. 他们发现了我们的服务
2. 他们开始使用我们的服务
3. 他们停止使用我们的服务

这个旅程的第一步是最重要的一步，因为如果没有人知道我们的 API，它可能是人类有史以来创造的最好的东西，但没有人使用它。

这使得找出哪些营销努力导致了转化变得至关重要，在这种情况下，是注册，哪些没有。

在旅程的后续步骤中，了解开发人员通过哪种渠道找到我们也是至关重要的。

可能来自某个特定渠道的开发者很快就停止使用我们的 API 了。跟踪这些信息可以让我们检查这些渠道是否会给开发者带来错误的期望。

有了关于用户如何找到我们的知识，我们可以改变我们通过该渠道提供的信息，或者我们可以改进我们的 API 来满足这些期望。

许多因素决定了 API 业务的成败，而且并非所有因素都是技术性的。

Moesif 浏览器 SDK

大多数 Moesif SDKs 运行在后台。它们捕获我们的 API 接收的所有请求，以及我们从那里发送给第三方 API 的请求。

但是，要想全面了解用户的旅程，我们还需要某种方式来实现开发者归属，也就是搞清楚一个用户是怎么找到我们的。

针对这个问题， Moesif 提供了一个基于 JavaScript 的 SDK ，运行在浏览器中。

这有点像谷歌分析，但完全集成了我们的 API 分析的其余部分。

它自动捕获发送到我们的 API 和客户端第三方 API 的请求。所有后端不会注意到的事情。

活动数据

Moesif Browser SDK 的一个优点是，它还可以捕获发送这些请求的用户的信息。

这些识别信息包括用户或会话 id，也包括自定义数据，如电子邮件、姓名、年龄、性别、公司、位置等。

然而，它也捕捉活动数据，如推荐网站或 UTM 参数。

UTM 参数

UTM 代表顽童追踪模块，这是谷歌分析前身的名字。它是存储在查询字符串或 cookie 中的一组参数，告诉网站当前用户来自哪里，就像 referrer 一样，但也是一组经常用于营销活动的额外信息。

• utm_source喜欢推荐人
• 如果链接在应用程序、电子邮件或其他媒介中
• utm_campaign此链接属于哪个营销活动
• 使用了哪些搜索词来获得链接
• utm_content链接位于网站、电子邮件或应用程序的哪个位置

自动捕获

Moesif Browser SDK 会自动捕获这些值(如果有的话),并将用户或会话 ID 与之相关联。这允许我们找出哪个 API 请求属于哪个营销活动。

然后我们可以问这样的问题:

• 脸书广告公司的用户如何使用我们的 API？
• 是否有比其他营销渠道更能吸引长期用户的营销渠道？
• 来自 Google 的用户和来自 Twitter 的用户在 API 使用上有显著差异吗？
• 等等。

结论

使用一个统一的 API 监控和业务分析解决方案，有助于提出与 API 使用相关的高级营销问题。

在商业中，了解全局是至关重要的，而我们可能从来没有亲自见过我们的客户，这使得我们更难看到正在发生的事情。

针对这些问题使用不同的分析解决方案需要我们以某种方式将它们联系起来，但 Moesif API 分析套件及其服务和针对不同前端和后端的所有 SDK 有助于实现这一切。

如何将你的 API 货币化:选择你的 API 货币化栈

原文：https://www.moesif.com/blog/developer-platforms/api-analytics/How-To-Monetize-Your-APIs-Choosing-Your-API-Monetization-Stack/

您选择用来启动项目的技术决定了您的产品现在能做什么以及将来能做什么。找到合适的堆栈来构建是您可能面临的最大工程挑战之一。选择一个能让你构建产品并快速推向市场的堆栈是非常好的，除非同样的选择限制了未来产品的可伸缩性和特性。选择一个远远超出您当前和未来需求的堆栈，这可能会导致您在构建最初的项目时遇到困难。必须在您当前的需求和您的产品及未来客户的需求之间取得平衡。

当谈到从 API 中赚钱时，选择正确的堆栈可以帮助您快速启动和运行，并为您的业务及其客户提供灵活性。让我们看看几种方法来评估哪种栈最适合您的 API 货币化需求。

什么是 API 货币化？

一切都在 API 上运行，API 经济持续增长。你有你认为其他个人或公司可能想要使用的 API 产品吗？然后，基于使用的计费和 API 货币化是你可能会考虑的事情。当我们谈到 API 货币化时，我们正在考虑如何从我们的 API 中获得收入，无论是通过按用户收费、按 API 调用收费还是其他指标。如果你的商业模式不包括使用你的 API 资源来获得额外的收入，你可能会把钱留在桌子上。API 收入可能是一个非常快速的胜利，特别是如果你有公共 API，可以用于其他业务。

如何收费以及何时收费将取决于您的计费模式。你可以在 API 消费者使用你的 API 后，通过后付费模式向他们收费来赚钱。您也可以决定在预付费或现收现付的计费模式下，预先向 API 消费者收取费用。有许多不同的方法可以从现有的 API 和正在构建的 API 中赚钱。

一旦您决定使用您的 API 来产生更多的收入，您就必须构建一个解决方案来做到这一点。该解决方案可能会有几个移动部分，每个部分都将在您的 API 货币化堆栈中扮演至关重要的角色。

API 货币化栈看起来像什么？

最简单的形式是，API 货币化栈有两个组件:您的 API 和计费提供者。不幸的是，要使这些工作结合起来，实现起来变得相当困难。为了高效准确地完成这项工作，需要大量的定制和专业知识。

更实际的方法是将解决方案分成 3 个部分:您的 API、跟踪 API 使用的平台和计费提供者。让我们来看看这些组件的作用。

API

API 是用户的价值所在。这里，当我们谈论“API”时，我们指的是与 API 有关的一切，包括保护 API、速率限制、转换等。通常，API 设置的一部分可能包括某种类型的 API 管理层，如 API 代理或 API 网关。大多数现代企业都在使用 API 网关，如 Kong、Tyk、AWS Gateway 或许多其他替代产品。

API 分析(用于跟踪使用情况)

随着 API 的使用，您将希望收集关于该使用的指标。由于分析平台会查看每个 API 调用的 API 消耗指标，因此将其作为记录系统来跟踪使用情况并将其发送给计费提供商是有意义的。

账单提供商

计费提供商将接收每个客户的使用量，在计费周期内合计金额，开具发票，并收取欠款。

Moesif 是 API 分析的一部分，这大概是事情在高层次上的样子。

为您的 API 选择网关或代理

当选择 API 管理的网关或代理时，准确理解您将需要什么功能是很重要的。几乎市场上的每个网关都有一些独特之处，这可能会使它或多或少地适合您的使用情形。要真正深入了解网关与代理的争论，请查看我们整理的这个快速分类。

有一点是肯定的，使用 API 网关将使保护和管理 API 比不使用它容易得多。大多数网关都支持各种各样的授权和认证协议来控制 API 访问、用于生成和管理 API 密钥的工具、对速率限制和配额的强大支持，以及其他特性，例如将转换应用于请求和响应的能力。API 管理平台通常还提供一个开发者门户，这样 API 用户就可以很容易地看到哪些 API 是可用的，并可以访问它们。

尽管可以在没有 API 网关或代理的情况下管理 API，但是拥有一个 API 网关或代理意味着您可以建立一种更统一的方式来保护和管理 API。实质上允许您在单一控制台下管理所有与 API 相关的问题。从可扩展性和安全性的角度来看，没有比这更好的解决方案了。

流行的 API 管理工具包括 Kong、Tyk、AWS Gateway、Azure API Management 等等。每一个都有自己的优点和缺点，就像任何其他软件或基础设施一样。有关这些比较的更多信息，请查看[本文]https://www . moesif . com/blog/technical/API-gateways/How-to-Choose-The-Right-API-Gateway-For-Your-Platform-Comparison-Of-Kong-Tyk-API gee-And-Alternatives/？UTM _ campaign = Int-site & UTM _ source = blog & UTM _ medium = body-CTA & UTM _ content = how-to-money-your-stack){:target = " _ blank " }我们写信就是为了帮助您解决这个问题。

选择账单提供商

在选择计费提供商时，就像您将任何技术整合到您的堆栈中一样，您应该了解当前和未来的使用案例以及该技术如何支持它们。您应该评估您的产品路线图，并规划出每个解决方案的技术优势和劣势。这里的描绘出了一幅巨大的差异全景图。您还需要了解如何将计费提供商与您当前的解决方案相集成。不同的提供商有不同的集成方式，这可能会使他们或多或少地适合您的项目。另一个细节是确保计费提供商能够支持你的 API 货币化模型。

除了技术要求之外，在选择您的提供商时，还应该考虑一些其他的运营因素。这些因素强调如下。

费用

对于大多数公司来说，这将是比较技术能力之外的主要因素。如果两个计费平台在技术上都适用于您的项目，那么下一个重点将是成本。

一个平台的成本可以用许多不同的方法来计算。可以采用统一费率、百分比或两者混合的方式。您还需要考虑通过系统的流量，因为这也可能导致折扣，从而使某个提供商更具吸引力。

报告

该平台内置的报告工具可以帮助组织的业务部门轻松看到 API 货币化的结果。大多数平台都有最少量的报告，而其他平台则有非常详细的报告。如果你喜欢现成的报告而不是自己开发的，这应该是一个重要的因素。

客户支持

如果问题确实发生了，很高兴知道提供商可以提供快速支持来解决问题。您需要确保查看提供商提供的不同支持包、针对次要和主要问题的服务级别协议(SLA)以及一些客户评论，以了解现有用户对支持是否满意。

使用 Moesif 将它们整合在一起

在您的 API 和所选择的计费提供者之间架起一座桥梁，这就是 Moesif 的用武之地。Moesif 拥有独特的能力来跟踪使用情况，将其累加，然后将使用记录发送给计费提供商进行收费。这些都可以在 Moesif 中找到，开箱即用。

Moesif 允许全方位服务的 API 货币化。这意味着 Moesif 可以覆盖所有对创建强大的 API 货币化堆栈至关重要的缺口。这包括跟踪使用情况、阻止过期发票帐户的使用、让客户了解使用情况，以及提醒内部团队任何相关行为或可能的追加销售机会。

计费仪表

计费仪表是 Moesif 货币化解决方案的核心。计费表允许您描述您希望如何向用户收费，并指定该标准。这些标准可以是特定端点上的计费、请求的特定部分、响应代码、这三者的组合，或者任何其他设想的标准。

一旦计费仪表被设置，它将在预定的时间间隔向计费提供商报告这种使用情况。这可以在几分钟内完成，而且完全不需要编写代码。Moesif 中的计费表目前可以与 Stripe、Recurly 和 Chargebee 集成。随着我们对客户最喜欢的计费提供商的了解越来越多，这些集成选项将会继续增加。

管理

治理可以允许 Moesif 在发票过期时阻止调用，或者，如果您正在进行预付费设置，可以在 API 消费者帐户上的信用用完时阻止他们。同样，所有这些都可以在没有代码、没有工程支持的情况下完成，并且可以在几分钟内投入使用。

治理规则可以通过配置一个适合您的确切需求的过滤器并指定您想要覆盖响应的内容来设置。例如，如果用户用完了使用 API 的信用额度，或者有过期的发票，您可以返回 402 Payment Required 状态，以及更详细的 JSON 主体。

行为邮件

当用户进入下一个使用层级、接近费率限制或配额，或者信用额度用完时，自动发送电子邮件将变得非常方便。当然，在很多其他情况下，自动化电子邮件也能有所帮助。在 Moesif 中使用行为电子邮件的最大好处是，它可以让客户了解关键事件，同时减轻支持和销售团队的负担，而在过去，他们需要直接联系。

警报

除了行为电子邮件，根据公司或用户的行为向不同的内部团队发送通知也是有意义的。为此，我们可以使用 Moesif 来设置由特定标准触发的警报。这些警报可以通过电子邮件和短信发送，也可以通过 Slack、PagerDuty 或定制的 webhook 等替代方式发送。

对于货币化，这可能包括让销售团队知道用户已经准备好根据他们的数量或行为转向新的计划。这也可能意味着向您的财务或收款部门发送一个警报，让他们知道一个拖欠的客户正试图访问一个 API。

入门指南

将你的 API 货币化是一项复杂的工程，但并不困难。随着一个伟大的 API 战略和强大的 API 设计，通过使用声誉良好和成熟的技术让您快速进入市场，同时保持高质量，您可以快速推动您的 API 的收入。为您的货币化 API 选择正确的堆栈不仅对于今天的需求至关重要，而且对于确保您有信心扩展到明天也是如此。

无论您选择什么，使用 Moesif 作为 API 货币化策略的中心都可以节省时间和精力，同时为您的最新收入流提供可扩展性和稳定性。今天就通过注册来试试我们，开始你的 API 货币化之旅。

如何使用 Moesif 监控 3Scale API 网关日志

原文：https://www.moesif.com/blog/technical/3scale/How-to-Monitor-3Scale-Api-Logs-With-Moesif/

毫不奇怪，现代微服务架构中的应用程序通过使用各种 API(RESTful、GraphQL 等等)进行通信。API 网关在公开其 API 的应用程序和 API 的消费者之间提供认证、速率限制和访问控制，是 API 基础设施的基石。简单的体系结构将 API 相关功能捆绑在单个组件中，提供负载平衡、缓存和扩展能力，以确保高可用性。

Nginx 是一款高性能、高可伸缩、高可用的 web 服务器、反向代理服务器和 web 加速器(结合了 HTTP 负载平衡器、内容缓存等功能)。NGINX 有一个模块化的、事件驱动的、异步的、单线程的体系结构，在通用服务器硬件上和跨多处理器系统上具有极好的伸缩性。

3Scale 3scale API 管理平台基本上是一组模块化组件，可以部署在从托管在公共云中到内部部署的各种拓扑结构中，公司可以使用该产品来控制他们的 API，并将其置于他们可以使用 3Scale 平台实施的某种治理的控制之下。

设置具有 3 个刻度的 Moesif API 分析

Moesif 在 Luarocks 中有一个插件，可以让你了解 API 的使用情况并监控你的 API 流量。借助 Moesif，您可以了解 API 的使用方式和用户，确定哪些用户遇到了集成问题，并监控需要优化的终端。

建议通过 Luarocks 安装 Moesif:

luarocks install --server=http://luarocks.org/manifests/moesif lua-resty-moesif 

如何使用

lua_shared_dict moesif_conf 2m;

init_by_lua_block {
   local config = ngx.shared.moesif_conf;
   config:set("application_id", "Your Moesif Application Id")
   config:set("3scale_domain", "YOUR_ACCOUNT-admin.3scale.net")
   config:set("3scale_access_token", "Your 3scale Access Token")
}

lua_package_cpath ";;${prefix}?.so;${prefix}src/?.so;/usr/share/lua/5.1/lua/resty/moesif/?.so;/usr/share/lua/5.1/?.so;/usr/lib64/lua/5.1/?.so;/usr/lib/lua/5.1/?.so;/usr/local/openresty/luajit/share/lua/5.1/lua/resty?.so";
lua_package_path ";;${prefix}?.lua;${prefix}src/?.lua;/usr/share/lua/5.1/lua/resty/moesif/?.lua;/usr/share/lua/5.1/?.lua;/usr/lib64/lua/5.1/?.lua;/usr/lib/lua/5.1/?.lua;/usr/local/openresty/luajit/share/lua/5.1/lua/resty?.lua";

server {
  listen 80;
  resolver 8.8.8.8;

  # Customer identity variables that Moesif will read downstream
  # Set automatically from 3scale management API
  set $moesif_user_id nil;
  set $moesif_company_id nil;
  set $moesif_req_body nil;
  set $moesif_res_body nil;

  access_by_lua_file /usr/share/lua/5.1/lua/resty/moesif/read_req_body.lua;
  body_filter_by_lua_file /usr/share/lua/5.1/lua/resty/moesif/read_res_body.lua;
  log_by_lua_file /usr/share/lua/5.1/lua/resty/moesif/send_event_3Scale.lua;

  # Sample Hello World API
  location /api {
    add_header Content-Type "application/json";
    return 200 '{\r\n  \"message\": \"Hello World\",\r\n  \"completed\": true\r\n}';
  }
} 

Moesif 建议对 Nginx 中配置的所有服务和路由使用相同的 Moesif 应用程序 Id。但是，建议对每个隔离环境使用单独的 Moesif 应用程序 id，例如生产和开发环境。

洞察用户行为

API 分析围绕着用户(或者公司，如果你是 B2B 的话)如何体验你的应用。也被称为用户行为分析，每一个事件或行为都可以追溯到单个客户，并且可以通过一起查看多个事件来发现行为趋势。

通过关注以客户为中心的使用，我们可以发现产品问题，例如为什么用户停止使用您的 API，或者他们最常使用的功能或端点。

Moesif 自动从 3scale admin API 获取客户上下文。默认情况下，id字段用于从 3Scale 的应用程序 XML 实体中识别用户。我们可以用其他字段覆盖默认字段，包括user_account_id、service_id等等。Moesif 支持认证模式- API 密钥(user_key)和 App_ID 和 App_Key 对，以便您的客户对您的 API 进行认证，并将该事件链接到单个客户。

要查看 Moesif 的 3Scale 集成，您可以从 GitHub 中克隆并运行这个示例应用程序

结论

通过这种方式，该插件将捕获 API 请求和响应，并记录到 Moesif，以便通过 3Scale 轻松检查和实时调试您的 API 流量。

如何使用 Moesif 监控 Tyk API 网关的 API 指标

原文：https://www.moesif.com/blog/technical/tyk/How-to-Monitor-API-Metrics-for-Tyk-API-Gateway-with-Moesif/

在过去的几年里，API 网关变得越来越流行。通过将标准 API 相关功能捆绑到单个软件组件中，开发资源得以释放，系统架构得以简化。

Tyk 就是这样一个 API 网关。它是开源的，用 Go 编程语言编写。它具有一系列特性，比如身份验证、访问控制、配额和速率限制、API 版本控制等等。

Tyk 遵循一种轻量级、模块化的 API 网关软件方法，专注于访问控制。这使得为 Tyk API 网关构建 Moesif 插件变得很容易。

在本文中，我们将讨论 Moesif 给你的见解，以及如何将它集成到你的 Tyk 设置中。

使用 Tyk 设置 Moesif API 分析

Tyk 配备了一个分析泵，用于 Moesif API 分析。你所要做的就是在pump.conf中配置正确的分析泵，重新加载 Tyk，然后你就可以开始了。

Moesif 建议对所有 Tyk 网关实例和数据中心区域使用一个应用 ID。然而，生产、试运行和开发环境应该得到不同的 id。

pump.conf文件应该是这样的:

"pumps":  {  "moesif":  {  "name":  "moesif",  "meta":  {  "application_id":  "Your Moesif Application Id"  }  },  } 

Tyk 的 Moesif 分析泵是开源的。在 GitHub 上回顾一下。

Moesif API 分析如何增强 Tyk？

Tyk analytics pump 也提供了 Moesif 的大多数 SDK 特性。

服务和路由检测

Moesif 可以通过 REST 模板按路由过滤，这样 id 就可以作为通配符使用。

例如，GET /media/videos/:id会将所有GET请求匹配到一个视频，而与它们的 ID 无关。

地理分段

除了时间指标，Tyk 分析泵还将捕获 IP 数据，实现过滤和地理热图。下图显示了延迟超过 1 秒的位置。

用户会话

通过为 Tyk 配置身份验证，Moesif 分析泵将自动捕获相关凭据。根据会话信息，Moesif 能够生成 API 会话跟踪和用户配置文件，其中包含附加的详细信息，例如用户第一次看到的时间、用户最后一次看到的时间等。

有了 Moesif 浏览器软件开发工具包，甚至可以记录用户从第一次点击登陆页面到最后一次请求 API 的过程

您可能会发现添加用户人口统计信息(如姓名、电子邮件、电话等)非常有用。只要您拥有用户的 API 密钥/会话令牌，就可以使用任何 Moesif API 库来添加/更新用户配置文件元数据。

使用人口统计信息，Moesif 可以执行更高级的用户群组分析，例如允许您跟踪 30 天的活动保留。

保持率衡量的是一个群体中再次使用并保持活跃的用户的百分比。

传入和传出 API 调用

Moesif analytics pump 可用于跟踪您的 API 调用，以及向您的合作伙伴发出的 API 请求。这可用于了解和监控您合作伙伴的基础架构的运行情况，并让您尽早发现任何问题。只要有流量通过你的 Tyk 网关，Moesif 就能分析它。

摘要

moes if API Analyticsplus Tyk 是一个强大的软件包，有助于在整个 API 生命周期中最大限度地减少开发时间并降低维护成本。

Tyk 允许将所有常见的 API 特性捆绑到一个系统中，称为TykT2】API 网关。

随着 Moesif 的加入，可以分析以用户为中心的数据。通过结合 Moesif 的分析泵和浏览器 SDK ，所有用户交互都可以被保存(从第一次登录页面访问到最后一次发送请求)，记录并供进一步分析使用。

如何使用用于 AWS API 网关的 Moesif 插件监控 API 的使用和性能

原文：https://www.moesif.com/blog/technical/aws-api-gateway/How-to-Monitor-API-Usage-and-Performance-with-the-Moesif-Plugin-for-AWS-API-Gateway/

API 网关提供了一个中心点来管理和控制对 API 的访问，使客户和合作伙伴能够快速创建新的体验。亚马逊 API 网关拥有对各种计算资源的原生支持，如 AWS Lambda 或亚马逊弹性计算云(亚马逊 EC2) 。

API 可观察性

API 可观察性可以为您的业务和工程团队提供关于如何使用 API 的深刻见解。 API 可观察性被多个团队利用，包括:

• 产品团队了解 API 的使用和商业价值
• 监控和解决 API 问题的工程团队
• 安全团队检测和防范 API 威胁

Moesif API Analytics 是一个 API 可观察性解决方案，您可以利用它来更好地了解 API 的用法。有一个与亚马逊 API 网关的原生集成，这使得部署只是几个点击的问题，不需要任何代码更改或重启。作为基础设施其余部分的网关，API 网关也是为各种业务和工程团队提供 API 可观察性的自然场所。

解决方案概述和使用案例

该解决方案将 API 分析添加到 AWS API Gateway 托管的 API 中。它的工作原理是通过一个亚马逊 Kinesis 数据消防软管将结构化 API 访问日志从你的亚马逊 API 网关实例转发到 Moesif。使用附带的 CloudFormation 模板，只需点击几下鼠标即可完成解决方案的部署，并且不需要任何停机时间。完成后，您可以实现几个目标:

了解客户 API 的使用

API 分析的一个关键目标是了解谁在使用你的 API 以及他们如何使用它们。默认情况下，Moesif 通过用$context.authorizer.principalId或$context.identity.cognitoIdentityId解析请求上下文，将 API 调用绑定到用户标识符，这样您就可以理解用户行为。

一份重要的报告是了解哪些客户使用你的 API 最多。API 日志传统上不包括客户人口统计信息，但像 Moesif 这样的 API 分析系统可以自动加入其他包含客户属性的数据集，如用户电子邮件或公司域。用户可以使用相同的用户 id 通过客户端集成进行跟踪，如 moesif-browser-js 或 Segment 。然后我们可以调出一个使用情况报告，按公司显示 API 流量。

API 问题疑难解答

有了高基数、高维度的 API 可观察性，您可以按照任意数量的字段(包括 HTTP 头或响应时间)来划分 API 日志。这使得无需手动日志搜索即可快速解决问题。API 的一个核心工程指标是延迟百分比，比如第 90 个百分比。最佳实践是查看平均值的 90%延迟。这种做法有助于发现可能被低平均值掩盖的较大延迟差异。您的 API 用户正在寻找持续的低延迟，而不是最低的平均延迟，因为峰值可能会对他们自己的服务造成严重破坏。

为此，转到事件- >时间序列并选择 P90 延迟指标。最好也了解按路线或服务细分的情况。为此，通过“请求 URI 添加一个组 Moesif 将自动合并路线，这样/items/1和/items/2将在 UI 中显示为/items/:id;

查找 API 安全威胁

随着您将越来越多的 API 暴露给客户、合作伙伴和单页面应用程序使用，您的安全风险也随之增加。浏览器指纹和验证码等传统机制不起作用，因此您需要利用高级用户行为分析来发现可疑用户。

一个常见的 API 安全威胁不是限制对你的专有数据的访问。然后，黑客可以通过分页攻击下载所有这些数据。一种检测客户滥用你的 API 的方法是查看每个客户下载的数据量。要创建这个指标，添加一个response . headers . content-Length的总和，然后按客户名称分组:

如何设置

该集成通过添加一个亚马逊 Kinesis 数据消防软管来工作，该软管从你的亚马逊 API 网关接收 API 访问日志，并将它们发送到 Moesif。API 网关日志有两种类型的日志: API 访问日志和 CloudWatch 执行日志。虽然执行日志是非结构化的，但人类可读，API 访问日志是结构化的，更容易被机器解析。此外，日志包含用户身份，这使得它们非常适合像 Moesif 这样的用户行为分析工具。

1.发射云编队栈

使用 Moesif 的 Amazon Web Services cloud formation 模板自动创建 Kinesis 数据消防软管，并将其配置为向 Moesif 发送 API 访问日志。若要开始，请单击下面的“启动堆栈”按钮。

T2】

这将在 AWS 控制台中打开快速创建堆栈。您需要在参数部分输入您真实的 Moesif 应用程序 Id。您可以在 AWS Marketplace 上登录您的 Moesif 帐户，找到您的应用程序 Id。

2.启用 API 网关访问日志记录

您需要在 Amazon API Gateway 中启用 API 访问日志，并将其发送到步骤 1 中的 Kinesis Data Firehose。

• 转到 AWS 控制台中的 AWS API 网关实例。
• 在左侧菜单中选择阶段，然后选择日志/跟踪选项卡
• 打开启用访问记录。
• 在访问日志目的地 ARN 下添加步骤 1 中的消防软管 ARN。

3.添加 JSON 日志格式

现在您已经启用了访问日志，您需要添加下面的 JSON 日志格式，以便输出与 Moesif 兼容。Moesif 将安全地忽略任何多余的键。

{  "apiId":  "$context.apiId",  "requestId":  "$context.requestId",  "requestTime":  "$context.requestTime",  "protocol":  "$context.protocol",  "httpMethod":  "$context.httpMethod",  "resourcePath":  "$context.resourcePath",  "requestHostHeader":  "$context.domainName",  "requestUserAgentHeader":  "$context.identity.userAgent",  "ip":  "$context.identity.sourceIp",  "status":  "$context.status",  "responseLength":"$context.responseLength",  "durationMs":  "$context.responseLatency",  "caller":  "$context.identity.caller",  "user":  "$context.identity.user",  "principalId":  "$context.authorizer.principalId",  "cognitoIdentityId":  "$context.identity.cognitoIdentityId",  "userArn":  "$context.identity.userArn",  "apiKey":  "$context.identity.apiKey"  } 

4.成功！

API 网关集成完成后，您应该看到您的 API 日志出现在 Moesif 中。对您的 API 网关域进行一些调用，并看到它们实时显示在 Moesif 的事件日志中。您应该会看到捕获的状态代码、URL 和其他 HTTP 参数，如下图所示:

高级用户行为分析

您可以利用您的集成，而不仅仅是孤立地查看 API 调用，并将您的整个客户之旅缝合在一起。这种方法可以更容易地看到类似于关于“首次见面时间”和“价值实现时间”的漏斗报告

跟踪用户界面中的用户操作，如“登录”或“查看的文档”，并开始跟踪用户界面中的用户操作，如“登录或“查看的文档”。这使得按客户流量划分 API 使用变得更加容易。为此，将 moesif-browser-js 添加到您的 UI 中，并调用 track 方法:

moesif.track('Clicked Sign Up', {
  button_label: 'Get Started',
  sign_up_method: 'Google SSO'
}); 

一旦完成，你应该做的第一件事是生成一个漏斗报告。在下面的报告中，我们创建了一个由三个步骤组成的漏斗分析。

1. 第一步是客户登录您的 web 应用程序(用户操作)。
2. 第二步是通过 API 的单次支付交易。因此，从步骤 1 移动到步骤 2 显示了注册到第一次 API 调用的转换率。
3. 第三步是超过 100 笔支付交易。对于本例，我们认为这是展示客户价值的“啊哈”时刻。从第 2 步到第 3 步，显示了进行 API 调用的客户的减少，这些客户实际上看到了真正的价值。

结论

拥有正确的 API 可观察性解决方案可以为您的团队提供正确的可视性，从而做出明智的决策。虽然您可以使用自己的 API 网关、数据处理管道和数据仓库，但这会为您的工程团队带来巨大的时间消耗。使用完全托管的服务，如 Amazon API Gateway 和 Moesif API Analytics 可以帮助您扩展，而不会受到高维护成本或过时数据基础架构的阻碍。首先，你可以在 AWS Marketplace 上注册一个免费的 Moesif 账户。

如何用 Moesif 插件监控 Azure API 管理性能

原文：https://www.moesif.com/blog/technical/azure-api-management/How-to-Monitor-Azure-API-Management-Performance-with-the-Moesif-Plugin/

Azure API Management (APIM)是一个强大的平台，使您能够发布和扩展 API，同时确保它们是安全的。Azure APIM 的一个很棒的特性是你可以添加插件和转换到你的 API 中，而不需要任何代码改变或者重启。

这些功能是使用 XML 策略部署的，XML 策略是一组语句的集合。 Moesif API Observability 可以在几分钟内添加，使用 APIM 的 XML 策略，可以轻松查看 API 调用，甚至是那些被拒绝且从未到达底层服务的调用。

什么是 Azure APIM 的 Moesif API 可观察性？

API 可观察性使工程和业务能够深入理解他们的 API 是如何使用的，并在客户发电子邮件支持和淹没您的团队之前识别出需要修复的内容。传统的 API 监控通常会探测端点的典型“红、黄、绿”状态，与此不同，API 可观察性使领导者能够观察 API 发生的任何行为。一些例子包括:

• 产品负责人了解 API 的用法和关注点
• 工程领导随时了解 API 问题并进行故障排除
• 安全研究人员调查 API 威胁并加以防范

这个解决方案是如何工作的

为了使 API 可观察性工作，监控代理需要被动地将 API 流量记录到可观察性服务中。这可以是基于 Azure Synapse Analytics 等数据仓库的定制构建，也可以是 Moesif 等交钥匙解决方案。像 Azure APIM 这样的 API 网关提供了一个集中 API 日志的自然点。否则，每个服务都需要有自己的 SDK。

这个解决方案是使用一个 Azure 资源管理器模板部署的，它会自动向您的 Azure 订阅添加一些组件:

成分	目的
API 管理记录器	从 API 管理实例中捕获 API 日志，并将它们插入到 EventHub 中
Azure EventHub	缓冲原始 API 日志，直到可以使用为止
Azure WebApp	运行 ApimEventProcessor 应用程序，该应用程序从 EventHub 中读取日志，并将日志批量发送到 Moesif

下图显示了如何在 Azure 订阅中部署该解决方案。

一旦 Moesif 收到 API 日志，剩下的数据处理和分析就由该服务处理。

用例

了解客户 API 的使用

API analytics 的一个目标是了解谁在使用你的 API 以及他们如何使用它们。为了实现这一点，集成会自动将 API 调用关联到特定的用户配置文件。默认情况下，XML 策略还将从上下文中提取用户信息，如用户 Id、名字和电子邮件。用户对象，并保存为 Moesif 中用户配置文件的一部分。您可以随时使用 Moesif 的用户跟踪 API 添加其他用户属性](https://www . moes if . com/implementation/track-user-behaviors-with-http-API？平台=http-api)

一份重要的报告是了解哪些客户使用你的 API 最多。因为我们正在跟踪名称和电子邮件，所以我们可以在 Moesif 中打开一个报告，按公司名称显示每周 API 流量。

疑难解答问题

借助高基数、高维度的 API 可观察性，您可以根据任意数量的字段(如 URI 路由、HTTP 报头，甚至有效负载中的字段)来划分 API 日志，从而深入研究影响客户的问题。我们建议监控的一个这样的指标是第 90 百分位。与平均延迟不同，通过查看 90%的延迟，您可以更好地看到延迟的巨大变化，这对于客户来说通常比持续高延迟的 API 更糟糕。一个具有无缝随机延迟峰值的 API 可能会对他们自己的服务造成严重破坏。

为此，转到事件- >时间序列，然后选择指标 P90 延迟。你也可以按路线或服务来理解这一点。为此，通过“请求 URI 添加一个组 Moesif 合并路线，使/items/1和/items/2在用户界面中显示为/items/:id，这使您的分析更加容易。

研究威胁

随着您将越来越多的 API 暴露给客户、合作伙伴和单页面应用程序使用，您的安全风险也随之增加。浏览器指纹和验证码等传统机制不起作用，因此您需要利用高级用户行为分析来发现可疑用户。

一个常见的 API 安全威胁是没有针对数据抓取和故意滥用 API 的适当保护。API 提供了对你的数据的直接访问，黑客可以利用它来抓取数据。T2 检测客户滥用你的 API 的一种方法是查看每个用户访问的数据量。要创建这个指标，添加一个response . headers . content-Length的总和，然后按用户名分组:

如何用 Moesif API Observability 设置 Azure APIM

1.开始 Azure 资源部署

单击下面的按钮开始使用 Moesif Azure 资源模板进行自定义部署。

T2】

2.配置参数

在 Azure 模板部署面板中，设置以下属性:

• 将资源组设置为包含现有 Azure APIM 实例的同一个资源组。这将确保自动为您创建 APIM 记录器moesif-log-to-event-hub。

• 将 Moesif 应用 Id 设置为登录 Moesif 账户后显示的 Id。你可以在 Moesif 网站上免费创建一个

• 将现有 Api 管理名称设置为 Azure APIM 实例的名称。如果为空，您将需要手动创建 APIM 记录器。

完成后，点击底部的审核+创建按钮，完成模板创建向导。

偶尔，Azure 会报告由于新 DNS 设置传播缓慢而导致部署失败，即使一切都已成功部署。我们建议继续其余的过程。如果您在最后一步后仍有问题，查看故障排除。

3.添加 XML 策略

在 Azure 门户中，导航到您现有的 Azure API 管理实例。然后，将下面的 XML 策略添加到您希望启用 API 日志记录的所有产品或 API 中。

建议为所有 API 全局添加 XML 策略。然后，如果您想要创建选择性采样或抑制数据收集的规则，请使用 Moesif 动态采样。规则是基于特定的客户行为、正则表达式规则等动态启用的。

有关编辑 APIM 政策的更多信息，请访问 Azure docs

<policies>
    <inbound>
        <base />
        <set-variable name="moesif-message-id" value="@(Guid.NewGuid())" />
        <log-to-eventhub logger-id="moesif-log-to-event-hub" partition-id="0">@{
var body = context.Request.Body?.As<string>(true);
var MAX_BODY_EH = 145000;
var origBodyLen = (null != body) ? body.Length : 0;
if (MAX_BODY_EH < origBodyLen){ body = body.Remove(MAX_BODY_EH); }
var headers = context.Request.Headers
    .Where(h => h.Key != "Ocp-Apim-Subscription-Key")
    .Select(h => string.Format("{0}: {1}", h.Key, String.Join(", ", h.Value).Replace("\"", "\\\""))).ToArray<string>();
var jwtToken = context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt();
var userId = (context.User != null && context.User.Id != null) ? context.User.Id : (jwtToken != null && jwtToken.Subject != null ? jwtToken.Subject : string.Empty);
var cru = new JObject();
if (context.User != null) {
  cru.Add("Email", context.User.Email);
  cru.Add("Id", context.User.Id);
  cru.Add("FirstName", context.User.FirstName);
  cru.Add("LastName", context.User.LastName);}
var crus = System.Convert.ToBase64String(Encoding.UTF8.GetBytes(cru.ToString()));
var requestBody = (body != null ? System.Convert.ToBase64String(Encoding.UTF8.GetBytes(body)) : string.Empty);
return new JObject(
  new JProperty("event_type", "request"),
  new JProperty("message-id", context.Variables["moesif-message-id"]),
  new JProperty("method", context.Request.Method),
  new JProperty("ip_address", context.Request.IpAddress),
  new JProperty("uri", context.Request.OriginalUrl.ToString()),
  new JProperty("user_id", userId),
  new JProperty("contextRequestUser", crus),
  new JProperty("company_id", ""),
  new JProperty("request_headers", string.Join(";;", headers)),
  new JProperty("request_body", requestBody),
  new JProperty("contextTimestamp", context.Timestamp.ToString("o")),
  new JProperty("metadata", $@"")
  ).ToString();}</log-to-eventhub>
        <set-variable name="sent-moesif-request" value="@(true)" />
    </inbound>
    <backend>
        <forward-request follow-redirects="true" />
    </backend>
    <outbound>
        <base />
        <choose>
            <when condition="@(context.Variables.ContainsKey("sent-moesif-request") && !context.Variables.ContainsKey("sent-moesif-response"))">
                <log-to-eventhub logger-id="moesif-log-to-event-hub" partition-id="1">@{
var body = context.Response.Body?.As<string>(true);
var MAX_BODY_EH = 145000;
var origBodyLen = (null != body) ? body.Length : 0;
if (MAX_BODY_EH < origBodyLen){ body = body.Remove(MAX_BODY_EH);}
var headers = context.Response.Headers.Select(h => string.Format("{0}: {1}", h.Key, String.Join(", ", h.Value).Replace("\"", "\\\""))).ToArray<string>();
var responseBody = (body != null ? System.Convert.ToBase64String(Encoding.UTF8.GetBytes(body)) : string.Empty);
return new JObject(
  new JProperty("event_type", "response"),
  new JProperty("orig_body_len", origBodyLen),
  new JProperty("message-id", context.Variables["moesif-message-id"]),
  new JProperty("status_code", context.Response.StatusCode),
  new JProperty("response_headers", string.Join(";;", headers)),
  new JProperty("contextTimestamp", context.Timestamp.Add(context.Elapsed).ToString("o")),
  new JProperty("response_body", responseBody)
  ).ToString();}</log-to-eventhub>
                <set-variable name="sent-moesif-response" value="@(true)" />
            </when>
        </choose>
    </outbound>
    <on-error>
        <base />
        <choose>
            <when condition="@(context.Variables.ContainsKey("sent-moesif-request") && !context.Variables.ContainsKey("sent-moesif-response"))">
                <log-to-eventhub logger-id="moesif-log-to-event-hub" partition-id="1">@{
var body = context.Response.Body?.As<string>(true);
var MAX_BODY_EH = 145000;
var origBodyLen = (null != body) ? body.Length : 0;
if (MAX_BODY_EH < origBodyLen){ body = body.Remove(MAX_BODY_EH);}
var headers = context.Response.Headers.Select(h => string.Format("{0}: {1}", h.Key, String.Join(", ", h.Value).Replace("\"", "\\\""))).ToArray<string>();
var responseBody = (body != null ? System.Convert.ToBase64String(Encoding.UTF8.GetBytes(body)) : string.Empty);
return new JObject(
  new JProperty("event_type", "response"),
  new JProperty("orig_body_len", origBodyLen),
  new JProperty("message-id", context.Variables["moesif-message-id"]),
  new JProperty("status_code", context.Response.StatusCode),
  new JProperty("response_headers", string.Join(";;", headers)),
  new JProperty("contextTimestamp", context.Timestamp.Add(context.Elapsed).ToString("o")),
  new JProperty("response_body", responseBody)
  ).ToString();}</log-to-eventhub>
                <set-variable name="sent-moesif-response" value="@(true)" />
            </when>
        </choose>
    </on-error>
</policies> 

4.成功！

随着 Azure APIM 集成的完成，您应该会看到您的 API 日志出现在 Moesif 中。对您的 API 网关域进行一些调用，并看到它们实时显示在 Moesif 的事件日志中。您应该会看到捕获的状态代码、URL 和其他 HTTP 参数，如下图所示:

识别用户

使用字段user_id将 API 调用与用户相关联。默认的 XML 策略使用以下逻辑从context.User.Id或 JWT 令牌中提取这个信息:

var jwtToken = context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt();
var userId = (context.User != null && context.User.Id != null) ? context.User.Id : (jwtToken != null && jwtToken.Subject != null ? jwtToken.Subject : null); 

您可以通过更改这些代码行来修改 userId。

添加用户元数据

默认情况下，XML 策略还使用 XML 策略中的以下代码保存一些有用的用户属性，如电子邮件和名字:

if (context.User != null) {
  cru.Add("Email", context.User.Email);
  cru.Add("FirstName", context.User.FirstName);
  cru.Add("LastName", context.User.LastName);
}
var crus = System.Convert.ToBase64String(Encoding.UTF8.GetBytes(cru.ToString())); 

这些将与 Moesif 中与定义的userId匹配的用户配置文件一起保存。通过更改这些代码行，您可以从context.User中添加额外的字段来满足您的需求。

添加事件元数据

您也可以存储事件元数据。与用户元数据不同，事件元数据特定于每个 API 事务，可以包含 Moesif 尚未记录的有用信息，如跟踪 id 或环境变量。metadata字段应该是 JSON 编码的字符串。

采样请求

这种集成还支持动态采样。这使您能够根据用户行为有选择地对 API 调用进行采样，从而节省您的 Moesif 订阅成本。Moesif 仍然会推断原始的度量标准。

高级用户行为 API 分析

您可以利用您的集成，而不仅仅是孤立地查看 API 调用，并将您的整个客户之旅缝合在一起。这种方法可以更容易地看到类似于关于“首次见面时间”和“价值实现时间”的漏斗报告

跟踪用户界面中的用户操作，如“登录”或“查看的文档”，并开始跟踪用户界面中的用户操作，如“登录或“查看的文档”。这使得按客户流量划分 API 使用变得更加容易。为此，将 moesif-browser-js 添加到您的 UI 中，并调用 track 方法:

moesif.track('Clicked Sign Up', {
  button_label: 'Get Started',
  sign_up_method: 'Google SSO'
}); 

一旦完成，你应该做的第一件事是生成一个漏斗报告。在下面的报告中，我们创建了一个由三个步骤组成的漏斗分析。

1. 第一步是客户登录您的 web 应用程序(用户操作)。
2. 第二步是通过 API 的单次支付交易。因此，从步骤 1 移动到步骤 2 显示了注册到第一次 API 调用的转换率。
3. 第三步是超过 100 笔支付交易。对于本例，我们认为这是展示客户价值的“啊哈”时刻。从第 2 步到第 3 步，显示了进行 API 调用的客户的减少，这些客户实际上看到了真正的价值。

结论

API 的可观察性对于工程和商业领导者在关注什么和问题在哪里做出明智的决定是至关重要的。虽然您可以使用自己的 API 网关、数据处理管道和数据仓库，但这会为您的工程团队带来巨大的时间消耗。使用完全托管的服务，如 Azure API 管理 API 网关和 Moesif API 分析可以帮助您扩展，而不会受到传统基础架构的阻碍。

如何用 Moesif 监控 NGINX API 日志

原文：https://www.moesif.com/blog/technical/nginx/How-to-Monitor-Nginx-Api-Logs-With-Moesif/

随着 API 网关越来越受欢迎，API 网关在公开其 API 的应用程序和 API 的消费者之间提供认证、速率限制和访问控制，是 API 基础设施的基石。简单的架构将 API 相关功能捆绑在单个组件中，提供负载平衡、缓存和扩展能力，以确保高可用性。

Nginx 是一款高性能、高可伸缩、高可用的 web 服务器、反向代理服务器和 web 加速器(结合了 HTTP 负载平衡器、内容缓存等功能)。NGINX 有一个模块化的、事件驱动的、异步的、单线程的体系结构，在通用服务器硬件上和跨多处理器系统上具有极好的伸缩性。

OpenResty 是一个成熟的 web 应用服务器，它捆绑了标准的 NGINX 核心、大量第三方 NGINX 模块以及它们的大部分外部依赖项。它具有一系列功能，如负载平衡、内容缓存等。

概观

Moesif Nginx OpenResty 插件是一个代理，它捕获指标并发送给 Moesif 收集网络。这使您能够全面了解 API 的使用情况，甚至跨不同的实例和数据中心区域。该插件在本地捕获指标并对其进行排队，这使得该插件能够将指标数据发送到 Moesif 收集网络的带外，而不会影响您的应用程序。Moesif 建议对 Nginx 中配置的所有服务和路由使用相同的 Moesif 应用程序 Id。但是，建议对每个隔离环境使用单独的 Moesif 应用程序 id，例如生产和开发环境。

在本文中，我们将讨论 Moesif 给你的见解，以及如何将它集成到你的 Nginx OpenResty 设置中。

使用 Nginx OpenResty 设置 Moesif API 分析

Moesif 在 Luarocks 中有一个插件，可以让你了解 API 的使用情况并监控你的 API 流量。借助 Moesif，您可以了解 API 的使用方式和用户，确定哪些用户遇到了集成问题，并监控需要优化的终端。

建议通过 Luarocks 安装 Moesif:

luarocks install --server=http://luarocks.org/manifests/moesif lua-resty-moesif 

如何使用

编辑您的nginx.conf文件来配置 Moesif OpenResty 插件:如果需要，用正确的插件安装路径替换/usr/local/openresty/site/lualib。

lua_shared_dict moesif_conf 2m;

init_by_lua_block {
   local config = ngx.shared.moesif_conf;
   config:set("application_id", "Your Moesif Application Id")
}

lua_package_path "/usr/local/openresty/luajit/share/lua/5.1/lua/resty/moesif/?.lua;;";

server {
  listen 80;
  resolver 8.8.8.8;

  # Default values for Moesif variables
  set $user_id nil;
  set $company_id nil;

  # Optionally, identify the user and the company (account)
  # from a request or response header, query param, NGINX var, etc
  header_filter_by_lua_block  { 
    ngx.var.user_id = ngx.req.get_headers()["User-Id"]
    ngx.var.company_id = ngx.req.get_headers()["Company-Id"]
  }

  access_by_lua_file /usr/local/openresty/luajit/share/lua/5.1/resty/moesif/read_req_body.lua;
  body_filter_by_lua_file /usr/local/openresty/luajit/share/lua/5.1/resty/moesif/read_res_body.lua;
  log_by_lua_file /usr/local/openresty/luajit/share/lua/5.1/lua/resty/moesif/send_event.lua;

  # Sample Hello World API
  location /api {
    add_header Content-Type "application/json";
    return 200 '{\r\n  \"message\": \"Hello World\",\r\n  \"completed\": true\r\n}';
  }
} 

支持的功能

Moesif 丰富了数据，使其更有条理。例如，不是在GET /service_a/items/1 OR GET /service_a/items/2 OR GET /service_a/items/3上过滤，Moesif 将检测剩余的模板，包括在GET /service_a/items/:id上启用单个过滤器的任何参数和 id。

屏蔽敏感数据

如果您有隐私要求或在高度管制的行业中，Moesif 提供了在发送到 Moesif 之前删除 HTTP 头或正文中的任何敏感数据或跳过记录正文有效负载的能力。

要查看 Nginx OpenResty 与 Moesif 的集成，您可以从 GitHub 中克隆并运行这个示例应用程序

结论

通过这种方式，该插件将捕获 API 请求和响应，并记录到 Moesif，以便通过 Nginx 和 Nginx 处理应用程序周围的所有其他服务，轻松检查和实时调试您的 API 流量。

如何监控第三方 API 集成

原文：https://www.moesif.com/blog/monitoring/third-party/How-To-Monitor-Third-Partry-API-Integrations/

许多企业和 SaaS 公司依赖各种外部 API 集成来构建出色的客户体验。一些整合可能会将某些业务功能(如处理支付或搜索)外包给 Stripe 和 Algolia 等公司。您可能已经整合了其他合作伙伴，从而扩展了您的产品功能。例如，如果您想要向分析工具添加实时警报，您可能想要将 PagerDuty 和 Slack APIs 集成到您的应用程序中。

如果你像大多数公司一样，你会很快意识到你正在将数百个不同的供应商和合作伙伴集成到你的应用中。其中任何一个都可能存在影响客户体验的性能或功能问题。更糟糕的是，集成的可靠性可能不如您自己的 API 和后端那么明显。如果登录功能被破坏，你会有很多客户抱怨他们不能登录到你的网站。但是，如果您的 Slack 集成被破坏，那么只有那些将 Slack 添加到其帐户的客户会受到影响。最重要的是，由于集成是异步的，您的客户可能直到几天后才意识到集成被破坏了，因为他们已经有一段时间没有收到任何警报了。

你如何确保你的 API 集成是可靠的和高性能的？毕竟，如果你卖的是实时警报功能，你的警报最好是实时的，至少保证送达。从客户体验的角度来看，因为您的 Slack 或 PagerDuty 集成是不可接受的，所以丢弃警报。

监控什么

潜伏

具有极高延迟的特定 API 集成可能是您的集成即将失败的信号。也许您的分页方案不正确，或者供应商没有以最有效的方式为您的数据建立索引。

延迟最佳实践

平均延迟只能告诉你故事的一半。一个持续花费一秒钟完成的 API 通常比一个高方差的 API 要好。例如，如果一个 API 平均只需要 30 毫秒，但是 10 个 API 调用中有 1 个需要 5 秒，那么您的客户体验就有很大的差异。这使得追踪 bug 更加困难，在客户体验中更难处理。这就是为什么第 90 个和第 95 个百分点更值得关注。

可靠性

可靠性是一个需要监控的关键指标，尤其是因为您正在集成您无法控制的 API。API 调用失败的百分比是多少？为了跟踪可靠性，您应该对什么构成失败有一个严格的定义。

可靠性最佳实践

虽然任何具有 4xx 或 5xx 系列响应状态代码的 API 调用都可能被视为错误，但您可能会遇到这样的特定业务案例:API 似乎成功完成，但 API 调用仍应被视为失败。例如，如果一个数据 API 集成始终没有返回匹配项或内容，那么这个集成就会被认为是失败的，即使状态代码总是 200 OK 。另一个 API 可能会返回虚假或不完整的数据。数据验证对于衡量返回的数据是否正确和最新至关重要。

并非每个 API 提供商和集成合作伙伴都遵循建议的状态代码映射

有效性

虽然可靠性特定于错误和功能正确性，但可用性和正常运行时间是纯粹的基础设施指标——它们衡量服务中断的频率，即使是暂时的。可用性通常以每年正常运行时间的百分比或个 9 的数量来衡量。

可用性%	每年停机时间	每月停机时间	每周停机时间	每天停机时间
90%(“一九”)	36.53 天	73.05 小时	16.80 小时	2.40 小时
99%(“两个九”)	3.65 天	7.31 小时	1.68 小时	14.40 分钟
99.9%(“三个九”)	8.77 小时	43.83 分钟	10.08 分钟	1.44 分钟
99.99%(“四个九”)	52.60 分钟	4.38 分钟	1.01 分钟	8.64 秒
99.999%(“五个九”)	5.26 分钟	26.30 秒	6.05 秒	864.00 毫秒
99.9999%(“六个九”)	31.56 秒	2.63 秒	604.80 毫秒	86.40 毫秒
99.99999%(“七个九”)	3.16 秒	262.98 毫秒	60.48 毫秒	8.64 毫秒
99.999999%(“八个九”)	315.58 毫秒	26.30 毫秒	6.05 毫秒	864.00 微秒
99.9999999%(“九个九”)	31.56 毫秒	2.63 毫秒	604.80 微秒	86.40 微秒

使用

许多 API 提供商对 API 的使用进行定价。即使 API 是免费的，他们也很可能在 API 上实现了某种速率限制，以确保坏的参与者不会饿死好的客户端。这意味着跟踪您的每个集成合作伙伴的 API 使用情况是至关重要的，这样您就可以确定您当前的使用情况何时接近计划或速率限制。

使用最佳实践

建议将使用与您的最终用户联系起来，即使 API 集成在您的客户体验的下游。这有助于衡量特定集成的直接投资回报率并确定趋势。例如，假设你的产品是 CRM，你每月向 Clearbit 支付 199 美元来充实多达 2500 家公司。这是与客户的使用相关的直接成本。如果您有一个免费层，并且某个特定客户正在使用您的大部分 Clearbit 配额，那么您可能需要重新考虑您的定价策略。也许在这种情况下，Clearbit enrichment 应该只在付费层提供。

如何监控 API 集成

监控 API 集成似乎是控制这些问题的正确方法。然而，像 New Relic 和 AppDynamics 这样的传统应用程序性能监控(APM)工具更侧重于监控您自己的网站和基础设施的健康状况。这包括基础设施指标，如内存使用和每分钟请求数，以及应用程序级别的健康状况，如 appdex 分数和延迟。当然，如果您正在使用运行在其他人的基础设施中的 API，您不能仅仅要求您的第三方提供商安装您有权访问的 APM 代理。您将需要一种间接监控第三方 API 的方法，或者通过一些其他的工具方法。

监控传出 API 调用的挑战

为了监控第三方 API 调用，您需要一种机制来记录来自应用程序的传出 API 调用(在它们到达第三方之前)和响应。许多 APM 代理在进程级别捕获信息，这对于捕获 JVM 线程、配置文件或内存百分比等基础设施指标非常有用，但对于捕获特定于应用程序的上下文来说却很糟糕。第二个挑战是，您的应用程序中的传出调用通常分散在您自己的代码中和您在应用程序中使用的所有供应商的 SDK 中。每个第三方 SDK 都有自己的回调和逻辑来处理 API 通信。这使得很难通过横切关注点或集中式代理来捕获传出的 API 调用。因此，您可能决定不利用特定于供应商的 SDK，或者修改它们以拦截 API 流量。后者代表了大量繁忙的工作，很少有工程团队有时间去做。

真实用户 API 监控是现代科技公司推荐的做法。真实用户 API 监控查看真实的客户流量，而不是预定的探测。这使您能够捕捉到更深层次的集成问题，比如特定的访问模式，而健康证明不会捕捉到这些问题。

我们在 Moesif 是如何做到的

在 Moesif，我们建立了一个跟踪第三方 API 的 SaaS 解决方案。我们通过利用 monkey 修补和反射在通用编程语言的核心 HTTP 客户端库中注入跟踪代码来做到这一点。因为工具在应用程序本身中，所以有机会添加特定于业务的上下文，例如发起 API 调用的原始最终用户，以记录特定的响应头，从而提供对速率限制或其他软错误的洞察。我们可以做到这一点，因为大多数语言依赖于单个或少量的核心 HTTP 库。对于 Node.js，所有的 HTTP 通信都基于 http 或 https 模块。对于 Python，大多数高级客户端将利用 Python 请求库。

下面是 Node.js 用于检测传出 API 调用的中间件示例:

var express = require('express');
var app = express();
var moesifExpress = require('moesif-express');

// 2\. Set the options, the only required field is applicationId.
var moesifMiddleware = moesifExpress({
  applicationId: 'Your Moesif Application Id',
  logBody: true
});

// 3\. Start capturing outgoing API Calls to 3rd party services like Stripe
moesifMiddleware.startCaptureOutgoing(); 

startCaptureOutgoing()将通过用我们修改过的方法覆盖http和https对象上的每个方法来为 Node.js http和https模块打补丁，修改后的方法拦截传出的 API 调用。下面是我们如何为 Node.js 执行 monkey 补丁的例子，完整的 SDK 也可以在 GitHub 上获得。

function _patch(recorder, logger) {
  var originalGet = http.get;
  var originalHttpsGet = https.get;

  var originalRequest = http.request;
  var originalHttpsRequest = https.request;

  http.request = function(options, ...requestArgs) {
    var request = originalRequest.call(http, options, ...requestArgs);
    if (!request._mo_tracked) {
      request._mo_tracked = true;
      track(options, request, recorder, logger);
    }
    return request;
  };

  https.request = function(options, ...requestArgs) {
    var request = originalHttpsRequest.call(https, options, ...requestArgs);
    if (!request._mo_tracked) {
      request._mo_tracked = true;
      track(options, request, recorder, logger);
    }
    return request;
  };

  http.get = function(options, ...requestArgs) {
    var request = http.request.call(http, options, ...requestArgs);
    request.end();
    return request;
  };

  https.get = function(options, ...requestArgs) {
    var request = https.request.call(https, options, ...requestArgs);
    request.end();
    return request;
  };

  function _unpatch() {
    http.request = originalRequest;
    https.request = originalHttpsRequest;
    http.get = originalGet;
    https.get = originalHttpsGet;
  }

  return _unpatch;
} 

如何利用监控

仅仅设置仪表板和报告您的 API 集成只是故事的一半。您可以通过多种方式利用这些数据来改善客户体验:

1. 当指标超出界限或有异常行为时，设置警报。一个简单的方法是通过传呼机、Slack 或其他渠道。
2. 让合作伙伴对其 SLA 负责。当您一直遇到延迟问题，或单一供应商的失败时，让他们知道。如果您已经有一个完整的审计日志显示发生了什么，合作伙伴可能能够调整他们的基础设施，以更好地适应您的访问模式，甚至在他们未能履行合同义务时向您退款。
3. 避免停机，并确保您自己的团队能够响应合作伙伴的问题。这可能包括通过功能标志关闭功能，直到合作伙伴解决问题。

如何在带有 Moesif 的 EC2 上使用 Tyk API Gateway 监控 API 使用情况和性能

原文：https://www.moesif.com/blog/technical/tyk-api-gateway/How-to-Monitor-Usage-And-Performance-with-Tyk-API-Gateway-on-AWS-EC2-with-Moesif/

本文介绍了 API 可观测性，以及它在整个 APIOps 周期中的作用。然后，我们将通过一个例子来说明如何在亚马逊 EC2 上成功部署和利用 Tyk 网关和 Moesif API 可观察性。

什么是 API 可观测性？

API 可观察性是正确执行 APIOps 循环并确保为 API 用户构建有价值的东西的关键要素。如果你对 APIOps 周期不熟悉，看一看本指南中的，它提供了一个敏捷框架来快速构建面向业务和服务于客户需求的 API。

传统的监控侧重于跟踪已知的未知。这意味着你已经知道测量什么，比如每秒的请求或每秒的错误。虽然度量值可能事先不知道，但是您已经知道要测量或探测什么，比如一个计数器来跟踪桶中的请求。这使得可以报告系统的健康状况(如红色、黄色、绿色)，但对于解决工程或业务问题(通常需要询问任意问题)来说，这是一个糟糕的工具。

API 可观测性源于控制系统理论，通过推断状态和行为，从系统的输出尽可能多地观察系统的内部工作。有了一个复杂的分析工具来分析所有这些数据，您就能够回答任何关于您的 API 行为的任意问题，而不仅仅是一些可直接测量的预定义指标。

像 Moesif 这样的 API 可观察性解决方案旨在弥合监控特定预定义指标与产品或业务整体健康状况的一般可观察性之间的差距。关于 API 可观察性与监控的更多信息，参见这篇文章。

关于 Moesif 和 Tyk

像 Tyk 这样的 API 网关使您能够安心扩展和保护您的 API 组合。Tyk 的架构以 Go 编写，采用模块化即插即用方法，使您能够添加符合您要求的组件。Tyk 提供了许多现成的插件，这样您就可以开始运行了，身份验证、速率限制和跨源共享都已经处理好了。

Tyk 拥有许多分析后端的插件，无论是基于 ElasticSearch 等开源技术的 DIY 构建，还是像 Moesif API Observability 这样的托管服务。Moesif 是一个专为 API 产品设计的可观察性平台，并与 Tyk 紧密集成，以收集额外的上下文，如认证用户(AliasId 或 OAuthId ),这样您就能够深入了解客户使用指标，并了解他们在采用您的 API 时的不足之处。

使用 Moesif Tyk 插件，您的 API 日志将被发送到 Moesif，Moesif 将对这些日志进行分析，并提供使用情况的报告。Moesif 还处理有效载荷信息，这样您就能够了解特定 JSON 键的使用情况，等等。关于 Moesif 和 Tyk 如何合作的更多信息，请参见 Tyk + Moesif:完美的组合。

动态采样和治理

Tyk pump 的 Moesif 插件还支持 Moesif 的动态采样和治理特性。这使得基于 Moesif 中的用户行为规则或正则表达式规则对 API 流量进行采样变得容易，因此您可以节省 Moesif 订阅成本。Moesif 仍将外推原始指标以获得准确的报告。关于如何工作的更多信息，请参见 Moesif 基础设施指南。

如何在 AWS 上设置 Moesif 和 Tyk

如何在 EC2 上安装 Tyk 网关

在这个例子中，我们使用 EC2 上的 Marketplace AMI 安装 Tyk。根据您的要求，Tyk 有三种选择:

• PoC
• 【高可用性(双节点)
• 【自动缩放(3+节点)

对于本指南，我们将利用高可用性(2 节点)选项，但是如果您想要 3 个以上的节点，过程是类似的。不建议将 PoC 版本用于生产。

如果 AMI 不符合您的要求，您还可以使用 GitHub 上的 docker compose 文件在 亚马逊弹性容器服务 上设置 Tyk 和 Moesif。

1. 转到 AWS Marketplace 上的 Tyk 列表并点击右上角的黄色订阅按钮。这将启动 AMI 的设置过程。亚马逊正在处理你的请求，你需要等几分钟。一旦完成，点击黄色的继续配置右上方的。

1. 您需要确认交付方法是“Tyk Pro 高可用性 API 管理”，选择您的 AWS 区域，然后单击右上角的继续启动按钮。您需要确认一切，并选择底部的启动。

2. 在 CloudFormation create stack 面板上，您需要保留预先填充的设置，然后选择 Next。

1. 在 stack details 面板上，您需要填写所有参数，包括各种组件、子网和 SSH 密钥的管理员用户名和密码。如果您还没有这样做，您可能需要预先生成它。关于如何填写的完整细节，请参见 Tyk 网站上的视频。

2. 等待创建 CloudFormation 堆栈。这可能需要一些时间。

1. 一旦完成，你应该能够卷曲网关。

curl http://TYKElasticLoadBalancerALB-1234567879.us-east-1.elb.amazonaws.com/hello 

如何添加 Moesif 插件

既然您已经运行了 Tyk API 网关。您需要启用 Tyk Pump 中的 Moesif 插件，并添加您的 Moesif 应用程序 Id。

Tyk Pump 是一个异步组件，它将您的原始分析数据推送到 Moesif 进行分析。该插件完全支持 Moesif 的动态采样功能，让您轻松节省成本。

1. 注册一个免费 Moesif 账户。在 onboarding 安装页面上，单击 Tyk Gateway 调出设置说明和您的application\_id。

1. 现在您已经有了 Moesif 应用程序 id，SSH 到上一步中创建的 EC2 实例中。Tyk 泵应该已经启动并运行。

2. 在您的pump.conf中，您需要添加您在上一步中获得的 Moesif 应用程序 Id 和配置，这样您的配置看起来像这样:

"pumps":  {  "moesif":  {  "name":  "moesif",  "meta":  {  "application_id":  "Your Moesif Application Id"  }  },  } 

1. 如果您想要记录 HTTP 标题和正文，请确保在 tyk.conf 文件中启用了详细分析记录。

2. 使用正确的 Moesif 帐户配置 Tyk Pump 后，您现在应该重新启动 Tyk Pump 和 Tyk Gateway 实例。

sudo service tyk-gateway restart

sudo service tyk-pump restart 

1. 就是这样！点击几次 AWS ELB，这样 Moesif 就可以记录一些 API 流量。您应该看到 API 日志出现在您的 Moesif 仪表板中。

同时使用 Moesif 和 Tyk

现在您已经设置了 Moesif 和 Tyk，让我们来创建一些报告。

监控 API 性能

我想到的第一个问题是我的各种 API 如何执行。要调出该报告，您需要登录 Moesif，进入时间序列，然后选择 P90 延迟。这将显示通过 Moesif 跟踪的所有 API 的 90%延迟指标。

像 Moesif 这样的 API 可观测性系统的一个关键组成部分是以任何属性为中心，而不管基数。在这种情况下，让我们在Request.Route上通过添加一个组。这将通过 RESTful 路径分解我们的度量。由于 Moesif 是为 API 设计的，它会自动将 URI 标识符如/items/1和/items/2合并到一个更加分析友好的/items/:id。`

了解客户 API 的使用

APIOps 周期中的一个关键步骤是衡量业务和技术 KPI 以实现您的目标。这意味着要深入了解谁在使用你的 API，以及它们是如何被使用的。Moesif Tyk 插件将把一个 Tyk 令牌别名映射到 Moesif 中的一个用户 Id。这使得存储电子邮件、收入和其他客户统计数据等用户属性变得很容易。

安装 Moesif 用户跟踪

为此，在你的网站上安装 Moesif 的 browser-js SDK 。为您的 Tyk 泵配置使用相同的应用 id:

const moesif = require('moesif-browser-js');

moesif.init({
  applicationId: 'Your Moesif Application Id'
  // add other option here.
}); 

然后，我们可以识别用户，并在您获得这些信息后保存用户属性:

moesif.identifyUser('12345', {
  email: 'john@acmeinc.com',
  firstName: 'John',
  lastName: 'Doe',
  title: 'Software Engineer',
  salesInfo: {
      stage: 'Customer',
      lifetimeValue: 24000,
      accountOwner: 'mary@contoso.com',
  },
}); 

虽然是可选的，但您也可以通过moesif.track()方法跟踪用户操作，如“登录”和“查看文档”,以更好地了解您的客户之旅。

创建使用情况报告

现在您已经保存了客户统计数据，让我们调出一个报告，显示按用户电子邮件细分的使用情况排名靠前的客户。转到 Moesif 中事件下的相同时间序列视图。然后选择User.Email，我们将显示每个客户的 API 流量。因为我们想要查看长期趋势，所以将时间间隔更改为 7 天，这样您就会得到如下所示的报告:

总结想法

拥有正确的 API 分析堆栈可以为您的工程和业务团队提供正确的可视性，从而做出明智的决策。Moesif 和 Tyk 共同合作，提供了一个保护和发布 API 的交钥匙解决方案，同时只需做一些配置更改，就可以获得一个完整的 API 可观察性解决方案。像 Moesif 这样的托管 API 分析服务大大降低了定制解决方案的构建和维护成本，因此您可以专注于构建优秀的 API。

如何使用 moesif 正确弃用 api

原文：https://www.moesif.com/blog/api-product-management/deprecation/How-to-Properly-Deprecate-an-API-Using-Moesif/

与任何产品生命周期一样，API 架构师和 API 产品所有者的主要职责是决定何时终止或淘汰某个特性或产品。API 生命周期也不例外，但是需要仔细规划来执行弃用，以最小化对客户的影响。与更像黑盒的打包解决方案或模块不同，API 使您的客户能够构建可能需要数月集成工作和测试的定制功能。如果没有正确的评估或流程，您可能会过早地弃用某项关键服务，从而导致大量支持票。

本指南介绍了弃用和终结点的最佳实践，以及如何使用 Moesif API Analytics 轻松做到这一点。

为什么反对任何东西？

在一个预算无限的理想世界中，一个 API 产品被完美地设计来处理每一个客户用例，并且可以永远存在。然而，真实的产品受到不断变化的业务需求的约束和影响，因此需要不断发展以满足这些需求。因此，正常的业务过程是淘汰不再符合当今需求和目标的 API 或服务。这可能是删除一些字段、特定的端点，或者停用整个服务。

• 维护服务的成本超过收入如果服务不再有利可图，并且维护成本超过了它为您的组织或业务部门带来的收入，您可能希望终止该服务。

• 迁移到新的 API 平台如果重新构建平台或重写已经在您的路线图上，这可能是一个移除未充分利用的功能以缩小范围的好时机。

• 改善开发人员的体验，减少膨胀有时你想重构你的 API 规范，使其“更简洁”,从客户的角度来看更容易理解。

• 转向产品战略或业务目标当转向产品战略以满足新的业务目标时，您可能没有带宽来维护与这些目标不一致的旧用例。

• 失去关键团队成员和机构知识如果服务或功能的原所有者从公司离职，培养新成员的成本可能会超过该功能的价值。

• 传统功能带来安全和合规风险为传统支持维护易受攻击的终端可能会使您面临不必要的安全或合规风险。应该制定日落计划，将客户转移到更新的实施。

• API 效率低下或容易出错一些 API 可能容易出错，或使您的基础设施面临可靠性问题。例如，一个导出 API 可能没有被广泛采用，却消耗了您的大部分支持票或导致中断。

逐步淘汰和废弃的 API

放弃一个端点需要一个定义良好的过程来最小化对 API 消费者的干扰，不管他们是组织中的其他团队还是创收客户。这个过程有时被称为日落，不出所料，它指的是夜幕降临前的那段时间，我们知道夜晚即将来临，但还没有到来。在工程术语中，日落是从向客户宣布弃用到该功能被永久关闭的这段时间。

1.确定客户影响

第一步是通过放弃一个端点或功能来了解影响。您应该很好地理解谁在使用即将过时的 API，以及它如何影响客户的实现。至少，您应该了解有百分之多少的客户在积极地使用不推荐使用的功能。然而，仅仅测量 API 调用的数量是不够的。您应该有一个可量化的业务指标来衡量影响，例如潜在的收入损失、迁移到替代方案所需的工程时间或类似的指标。

如何用 Moesif 理解不推荐使用的 API

在本例中，我们放弃了端点/reviews的 v1。从两个图表中可以相对容易地看出这种贬值的影响。首先，我们希望看到 API 的使用按公司名称进行分类。在本帖的后面，我们还将展示如何理解美元对收入的影响。

2.宣布折旧计划

既然您决定继续进行弃用，那么您需要向您的 API 客户宣布您的弃用(终止)计划。这应该发布在你的项目博客 changelog 上，也可以直接通过电子邮件发给开发者。您还应该在任何开发人员文档或 API 参考中将端点标记为不推荐使用。如果你使用 OpenAPI 或 Swagger，很容易通过将deprecated设置为 true 来将参数对象或操作对象标记为不推荐使用

你的时间表应该有几个关键日期:

• 弃用公告日期
• 限电日期和流程
• 最终关闭日期

限制用电或滚动封锁是一种不赞成使用的策略，在短时间内(如 15 或 30 分钟)阻止对不赞成使用的功能的访问，以帮助提醒 API 消费者即将关闭。

你会想尽快发送这些邮件，开始你的日落倒计时。

3.当客户使用不推荐的功能时，向他们发送电子邮件

即使你通过电子邮件或博客宣布反对，也不是每个人都会阅读该公告，或者他们认为该公告无关紧要而不予理会。这就是提供基于 API 行为的个性化客户之旅的关键所在。每当客户使用不推荐的功能时，马上让他们知道。这可以通过 HTTP 响应头和行为电子邮件(客户生命周期电子邮件)的组合来实现。

如何使用 Moesif 自动发送反对电子邮件

要使用 Moesif 自动发送反对警告电子邮件，您需要执行两个步骤。首先，创建一个保存的用户群组，这些用户仍然在使用不推荐使用的功能。在本例中，我们取消了 API 的v1版本的/reviews/端点，因此我们创建了一组在过去 7 天内至少访问过reviews一次的所有用户。我们还排除了拥有专职客户经理的企业客户。

一旦完成，下一步就是设计一封发送给这些用户的 HTML 电子邮件。这可以通过使用行为邮件编辑器来完成。我们希望每 14 天提醒一次客户，只要他们仍然是用户群体的一员(即在过去 7 天内访问过不推荐使用的 API 的用户)。

4.使用 HTTP 响应头警告客户

即使您向数据库中的每个客户发送警告电子邮件，有时负责人也不会收到，因为开发人员的联系信息不再有效，电子邮件被发送到垃圾邮件，开发人员跳槽到了另一个项目或雇主，等等。确保相关开发人员收到弃用通知的推荐方式是应用内通知。虽然您可能首先想到的是应用内门户，但并不是每个人都会定期登录 API 提供商的仪表板。

我们建议采用 Clearbit 的 API 弃用方法,其中包括添加一个X-API-Warn响应头。这也可能被您拥有的任何客户端 SDK 截获并打印到 stdout。

如何用 Moesif 自动设置 HTTP 响应头

使用 Moesif，这相对来说没有痛苦。您可以利用类似的流程，为使用不推荐的端点的客户创建用户群组。然后，当客户使用废弃的/reviews端点时，您可以使用治理规则来自动添加X-API-Warn。在这种情况下，我们还不想阻塞请求，我们只是想添加响应头，所以我们没有选中阻塞。只要客户继续使用不推荐使用的端点，此规则将保持启用并添加标头。

5.实施限电策略

您永远不能过多地传达可能会破坏客户集成的更改，例如 API 弃用。然而，有时开发者仍然不采取行动。一种半强迫客户做某事的方法是用限电或滚动停电策略。该策略暂时关闭对特征或服务的访问，例如一周内每两天关闭 15 分钟。这将有助于触发您的客户可能设置的任何警告和警报。

当开发人员在计算机前的机会很高，他们可以迅速采取行动，但最终用户的影响很小时，建议强制实施限电。例如，您可能需要在正常工作时间进行限电。然而，如果你提供一个位于美国境内的电子餐饮 API，你可能不希望在东海岸或西海岸的午餐时间前几个小时关闭你的 API。

如果您预计会有大量的支持票，您可以实施滚动停电，每次只“关闭”选定的客户，而不是所有人，就像在非常高的需求期间(如热浪期间)计划的滚动停电一样。

6.监控使用情况，看弃用是否安全

既然您已经执行了大部分弃用计划，那么分析弃用端点的使用趋势是一个好主意，这样可以了解永久关闭访问是否安全。希望到目前为止，没有多少客户在访问过时的端点或功能。您可能有一些掉队的服务，它们是不再维护的幽灵服务，但是最好是安全的，并且完全了解谁还在使用端点。

如果 API 用户是关键客户，你可能需要推迟一段时间来与这些客户合作。拥有复杂系统的大客户有时是最后迁移的。这可以使用 Moesif 的 API 分析轻松完成。

如何理解 Moesif 对收入的影响

有时最好更进一步，不仅要了解谁在使用不推荐的端点，还要了解潜在的收入损失。这取决于 API 如何打包和定价，但无论 API 利用基于使用的定价还是预付费客户合同，都可以做到这一点。在这种情况下，使用/reviews的 v1 的所有客户的总收入按客户的行业细分。我们可以看到软件&服务(最大的类别)一项就代表了超过 1800 万英镑的收入。

7.关闭对该功能的访问

现在您已经添加了正确关闭该特性的所有步骤，是时候永久关闭它了。进行最后一次检查，以确保没有相邻的服务由于之前没有意识到的依赖性而出错。恭喜，您正确地完成了终止 API 的步骤。

如何恰当地利用弹性搜索和用户行为分析实现 API 安全性

原文：https://www.moesif.com/blog/technical/api-security/How-to-Properly-Leverage-Elasticsearch-and-User-Behavior-Analytics-for-API-Security/

Kibana 和 ELK 栈的其他部分(Elasticsearch、Kibana、Logstash)非常适合解析和可视化各种用例的 API 日志。作为一个开源项目，它可以免费开始(你仍然需要考虑任何计算和存储成本，这对分析来说并不便宜)。Kibana 最近发展起来的一个用例是为 API 安全提供分析和取证，随着公司向客户、合作伙伴公开越来越多的 API，并被单页面应用和移动应用利用，这是工程领导者和 CISO 越来越关注的问题。这可以通过检测应用程序将所有 API 流量记录到 Elasticsearch 来实现。然而，一个简单的实现只会存储原始的 API 日志和调用，这对于 API 安全用例来说是不够的。

为什么 API 日志是 API 安全的一种幼稚的方法

原始 API 日志仅包含与执行单个操作相关的信息。通常会记录 HTTP 标头、IP 地址、请求正文和其他信息，以供以后分析。可以通过购买 Elasticsearch X-Pack 的许可证来添加监控功能。问题是，孤立地查看 API 调用并不总能检测到安全事件。相反，黑客能够执行精心设计的行为流程，以一种意想不到的方式运行您的 API。

让我们以一个简单分页攻击为例。分页攻击是指黑客能够通过像/items或/users这样的资源分页，在不被发现的情况下抓取您的数据。也许这些信息已经是公开的、低风险的，例如在电子商务平台中列出的项目。然而，资源也可能有 PII 或其他敏感信息，如/users，但没有得到正确的保护。在这种情况下，黑客可以编写一个简单的脚本来转储存储在数据库中的所有用户，如下所示:

skip = 0
while True:
    response = requests.post('https://api.acmeinc.com/users?take=10&skip=' + skip),
                      headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})
    print("Fetched 10 users")
    sleep(randint(100,1000))
    skip += 10 

有几点需要注意:

1. 黑客在每次调用之间随机等待一段时间，以免遇到速率限制
2. 由于前端应用程序一次只获取 10 个用户，黑客一次只获取 10 个用户以避免引起任何怀疑

单个 API 调用中绝对没有任何东西可以区分这些坏请求和真正的请求。相反，您的 API 安全和监控解决方案需要全面地检查用户行为。这意味着检查由单个用户或 API 键发出的所有 API 调用，这被称为用户行为分析或 UBA。

如何在 Kibana 和 Elasticsearch 中实现用户行为分析

为了在 Kibana 和 Elasticsearch 中实现用户行为分析，我们需要将我们以时间为中心的数据模型转变为以用户为中心的数据模型通常，API 日志存储为时间序列，使用事件时间或请求时间作为组织数据的日期。通过这样做，旧的日志可以很容易地标记为只读，移动到较小的基础架构，或根据保留策略停用。此外，当您只查询有限的时间范围时，它可以加快搜索速度。

用用户 id 标记 API 日志

为了将它转换成以用户为中心的模型，我们需要用用户标识信息标记每个事件，比如租户 id、用户 id 或类似信息。因为大多数 API 都是由某种 OAuth 或 API 键保护的，所以将 API 键直接映射到永久标识符(如用户 id)或者在 Redis 这样的键/值存储中维护这种映射是相当容易的。这样，您的日志可能看起来像这样:

| 请求时间 | 动词 | 途径 | 用户标识 |
| 2021-08-02t 02:14:48 | 得到 | /items | One thousand two hundred and thirty-four |
| 2021 年 8 月 02 日 15 时 49 分 | 得到 | /items | One thousand two hundred and thirty-four |
| 2021-08-03T02:16:19Z | 得到 | /users | Six thousand seven hundred and eighty-nine |
| 2021-08-03T02:24:49Z | 得到 | /users | One thousand two hundred and thirty-four |

将相关的 API 日志分组在一起

现在，您已经用用户 id 标记了所有 API 日志，您将需要运行一个 map reduce 作业来将用户的所有事件分组在一起，并为每个用户计算任何指标。不幸的是，Logstash 和 Fluentd 等日志聚合管道一次只能丰富单个事件，因此您需要一个定制的应用程序，该应用程序可以在 Spark 或 Hadoop 等分布式计算框架上运行分布式 map/reduce 作业。

按用户 id 分组后，您会希望在“用户配置文件”中存储一些项目，例如:

1. 用户的 Id 和人口统计数据
2. 该用户制作的原始事件
3. 汇总指标，如 API 键的数量或用户下载的数据量

存储用户配置文件

即使您按用户 id 分组，将所有事件存储到单个数据库实体也是不可行的，因为这样会降低时间序列数据存储的灵活性，包括:

1. 包含太多数据的胖实体
2. 无法废弃旧数据
3. 由于接触了大量数据，查询变得很慢

为了解决这个问题，我们可以用这种以用户为中心的方法覆盖我们原来的时间序列架构，创建一个两级数据模型。

| 用户标识 | 开始时间 | 结束时间 | 登录次数 | 接触的用户数量 | API 键的数量 | 事件 |
| One thousand two hundred and thirty-four | 2021-08-02T00:00:00Z | 2021-08-02T23:59:59Z | Two | Two hundred and fifty thousand two hundred and twenty-three | one | [] |
| Six thousand seven hundred and eighty-nine | 2021-08-0300:00:00Z | 2021-08-03T23:59:59Z | Thirteen | Two hundred and thirty-two | Twelve | [] |
| One thousand two hundred and thirty-four | 2021-08-0300:00:00Z | 2021-08-03T23:59:59Z | Zero | Three hundred and twenty-three thousand nine hundred and ninety-seven | Zero | [] |

在这种情况下，我们每天都会创建一个新的“用户配置文件”，其中包含相关的安全指标和原始事件。

检测 API 安全漏洞

现在，我们已经将 API 数据重新组织为以用户为中心，无论是通过视觉检查、静态警报规则还是高级异常检测，识别坏用户和好用户都变得容易得多。

在这种情况下，我们看到典型的用户(6789)只接触或访问了 232 个用户和 12 个项目。显然，这看起来像标准的交互式流量。另一方面，我们有一个坏演员(1234)，他在过去两天里每天触摸或下载超过 250，000 个项目。此外，他在第二天访问 API 时没有任何相应的登录。现在，您可以创建一个基础结构来以编程方式检测这种情况，并在任何用户“一天内接触超过 10，000 个项目”时向您发出警报像 Moesif 这样的 API 安全和监控解决方案已经内置了这种功能。

为了 API 安全，将 API 日志保留多长时间

与用于调试目的的 API 日志不同，这些实体应至少存储一年，因为大多数违规研究表明检测数据违规的时间超过 200 天。如果为了降低成本，您只保留几天或几周的 API 数据，那么您将无法访问审计和事后审查所需的有价值的取证数据。像对待数据库备份一样对待 API 数据，因为您永远不知道何时可能需要它们，并且应该定期测试您的系统以确保捕获正确的数据。大多数安全专家建议保留 API 日志至少一年。天真的决策过于强调降低存储和计算成本，而没有考虑他或她给公司带来的风险有多大。

由于 API 日志可能包含 PII 和个人数据，将数据存储一年会使您的 GDPR 和 CCPA 合规性复杂化。幸运的是，GDPR 和 CCPA 已经对出于检测和防止欺诈和未经授权的系统访问以及确保 API 安全的合法目的而收集和存储日志的行为进行了豁免。此外，由于您已经将所有 API 日志绑定到个人用户，处理 GDPR 请求(如擦除权或访问权)变得轻而易举。

如何保护您的 API 免受攻击和故意滥用

原文：https://www.moesif.com/blog/developer-marketing/behavioral-emails/How-to-Secure-Your-API-Against-Attacks-and-Intentional-Misuse/

聘请一家纽约州或门洛帕克市的律师事务所来编写你的应用程序的服务条款(ToS)可能会让你放心，但你如何确保你昂贵的规则得到切实遵守呢？就像 B2C 公司普遍滥用客户审查指南一样，B2B 公司也存在多重/未经核实的审查问题。

类似地，根据其设计，API 也容易被不良行为者滥用，但这次是通过暴力攻击。如何保护您的 API 平台免受这两种滥用行为的侵害？

用例

在线评论本应是对产品和服务提供公正和有益观点的灵丹妙药。不幸的是，Yelp 上的餐馆评论或亚马逊上的产品评论经常被邪恶势力劫持。例如，亚马逊在英国《金融时报》调查后删除了 2 万条可疑评论，而在 2019 年，Yelp 发出了超过 1300 条关于企业公然试图操纵评级和评论的警告。

为了保持用户的信任，保持平台内容的完整性和质量是非常重要的。如果某些用户藐视你的 ToS，滥用你的 API 来创建多重评论，那么你的解决方案的可信度将会受损，你的客户可能会去别处。尽早发现那些向你发送垃圾邮件的人是很重要的。

API 为开发人员提供了一个易于使用、灵活且可扩展的接口。不幸的是，这也是攻击者社区偏好的特性集。通过将 API 访问权限限制在那些已经向您验证了其帐户的用户，可以确保一个适当的保护级别。

然而，如果一个不良分子决定使用暴力攻击来探测你的平台，那么你的帐户可能会受到威胁。如果发生这种情况，负面的用户信任和品牌资产，更不用说的法律后果可能接踵而至。因此，在受影响的客户的帐户被封锁和无法访问 API 之前，检测这种攻击并向他们发出警告是非常重要的。

保护您的 API 免受有意误用和攻击的行动手册

自动化重复过程是整个产品设计的一个关键属性。通过将高级用户行为分析(UBA)与行为电子邮件相结合，Moesif 能够让您通过许多功能、性能和产品问题的复杂工作流程提高工作效率。

本演示手册侧重于防范 ToS 违规和攻击，通过向您展示如何处理在过去 7 天内创建过多评论的警告用户或警告用户过多未经授权的错误，具体说明了 Moesif 的功能。

其他行动手册关注的是自动通知配额和计费问题以及如何指导客户使用 Moesif 自动集成 API。这三部行动手册仅仅触及了我们平台的皮毛；一旦你掌握了创建自己的群组、指定触发事件和设计行为邮件的诀窍，你就会想知道在 Moesif 之前你都做了些什么。

配料清单

我们将使用 Moesif 的分析工具来构建这个应用程序。如果你还没有创建账户，你可以免费注册。

行动手册创建的步骤

行动手册包括工作流、sop 和文化价值观，它们共同形成了一个一致的反应—行动。不管你想达到什么目的，Moesif 行动手册包含两个关键要素:团队规范和电子邮件创建。

群组规范

Moesif 将用户和公司定义为不同的实体，这些实体可以被分组到共享相似标准的群组中。不同的群组包括共享类似领域的群组，例如:订阅计划、端点使用、请求代码等。正如之前的教程中所解释的那样，通过对用户/公司人口统计数据和行为进行过滤，可以创建群组。

要创建新的用户群组，请转到 Moesif 工具的用户>用户查找部分，并从下拉菜单中选择与和执行事件匹配的用户字段，如下所示。事件过滤器和用户/公司字段的完整列表可以在我们的用户分析面板中找到。

警告创建过多评论的用户

为了创建那些行为不端用户的群组，从执行的事件中选择过滤器:request.URI route is /reviews/和request.HTTP Verb is POST，然后将时间段设置为At Least 1000 times in Last 24 Hours，如下所示。

提醒用户在过去 7 天内出现超过 100 个未经授权的错误

要创建在过去 7 天内超过 100 个未授权错误的用户群组，请转到用户>保存的用户群组，并在执行的事件中选择过滤器:response.Status.Code is 403 Forbidden (0)，然后将时间段设置为At Least 100 times in Last 7 Days，如下所示。

一旦设置了过滤器，Moesif 将查看所有当前和历史数据，并将所有符合过滤器标准的用户/公司组合在一起。我们还将监控用户/公司是否继续属于该群体，而无需任何人工干预。

然后，该群组可用于填充行为电子邮件中的收件人列表。

行为电子邮件创建

你可以使用拖放式所见即所得编辑器在 Moesif 中设计 HTML 邮件。要创建行为电子邮件，请转到 Moesif 工具的警报和治理>行为电子邮件部分。

第一步是添加一个新的+模板，其中模板包括电子邮件设计以及其他相关信息，例如哪些群组应该接收电子邮件。关于创建电子邮件模板的完整文档在可用，但可以说，电子邮件创建非常简单，一旦完成，可以使用测试按钮来验证电子邮件。

警告创建过多评论的用户

只需将预定义的群组添加到行为电子邮件的收件人列表中，通知他们创建了太多评论，违反了您的 ToS:

每当新客户在过去 24 小时内超过 1，000 条评论时，他们将被自动添加到队列中，并会发送一封电子邮件。

提醒用户在过去 7 天内出现超过 100 个未经授权的错误

类似地，只需将您之前定义的用户群组添加到行为电子邮件中，无论何时发生多次未经授权的访问，都会触发该行为电子邮件:

外卖食品

维护用户信任和品牌资产从未如此重要。识别并通知那些违反 ToS 的人，或者提醒您的客户他们的帐户可能会受到暴力攻击，这些都是良好产品治理的一部分。

借助我们的 SaaS 平台，我们努力让我们的客户尽可能高效。通过有效负载可观察性和行为电子邮件的结合，我们创建了自动化的警告流程，为您节省时间和资源。

如何销售你的 API

原文：https://www.moesif.com/blog/api-product-management/api-analytics/How-To-Sell-Your-APIs/

众所周知，API 绝对无处不在。API 驱动着现代科技企业甚至非科技企业的几乎每一个方面。您可能有一个内部 API，开发人员使用它来支持内部系统和外部 API，后者更公开地公开功能。与任何功能一样，API 也可以通过出售给有需求的用户来增加收入。无论你是销售 REST API、GraphQL API，还是其他 API，学习如何销售你的 API 已经成为一个流行的问题。让我们来看看销售 API 的一些注意事项。

你如何构建一个 API 并销售它？

构建一个 API 并打算出售它需要一个重要的东西:价值。在查看 API 产品时，您应该能够确定是否存在对该 API 的外部需求、需要此类服务的企业数量，以及最重要的是，他们是否愿意为此付费。如果你已经确定一个人或企业愿意为你的服务付费，这是一个很好的起点。

一旦构建了一个 API，要销售它，你需要做一些事情。首先要做的是进行身份验证和授权。这是必要的，这样您就可以确保付费用户被授予访问权限，并且没有未经授权的或非付费用户可以访问该 API。

接下来，您需要确保设置了适当的速率限制和配额限制。这确保了用户只根据他们协议中的条款访问 API。它还确保端点不会被流量淹没，从而防止拒绝服务攻击。

在此之后，您将需要找到一种对 API 使用收费的方法。这包括决定定价策略、注册/签约流程以及统计使用和收费的方式。这一部分通常被称为 API 货币化，是实际收入的来源。

销售 API 有哪些挑战？

销售 API 的挑战包括正确实现货币化、服务可用性和安全性。这些挑战在上一节中有所介绍，通常可以通过使用合适的 API 管理工具、创建和部署安全的 API 以及使用易于使用的货币化平台来解决。

除了货币化组件之外，销售 API 的挑战与简单地提供 API 供一般消费非常相似。安全和保持严格的授权是一场持久战。通过高可用性设置使服务持续可用也是至关重要的，因为服务宕机可能是灾难性的，尤其是在 API 为使用它的企业带来收入的情况下。可靠性是让用户留在平台上或继续为你的 API 付费的一个重要因素。

要考虑的最后一个挑战是 API 在内部花费了您多少成本。例如，假设您已经创建了一个信用评级 API，它从各个信用机构检索用户的信用评分。您向用户收取每个 API 调用 3 美元的费用，后付费。信用局还对每次 API 调用收取 1 美元，这意味着每次调用的净收入是 2 美元。如果用户使用了你的服务，并决定在月底不支付他们的发票怎么办？即使你的客户拒绝付款，你仍然要对信用局的 API 费用负责。这个挑战并不是 API 特有的，而是在考虑潜在挑战时应该考虑的。

你如何将一个 API 货币化？

您已经构建了一个 API，并决定出售它，现在需要弄清楚如何收费和收取收入。为此，您需要有一个记录 API 流量的系统，并可以对其收费。总是有机会构建一个定制的解决方案来处理货币化，但它可能会有陷阱。对于任何自主开发的解决方案，必须准确预测工程和持续支持成本。一般来说，这些成本会膨胀，尤其是当您扩展时。

另一种方法是使用现成的解决方案，可根据您的使用情况进行定制。Moesif 通过平台上的计费表功能提供了这样一个解决方案。有了 Moesif 计费表，API 流量被记录、过滤并发送给计费提供商，如 Stripe 或 Recurly ，这样就可以收取收入。这种方法非常灵活，因为 Moesif 可以与多个 API 集成和计费提供者一起工作。

货币化能力到位后，最后一步是为您的 API 决定一个定价模型。一旦定价决定并纳入货币化设置，你就开始创造收入了。

API 市场与 API 门户

API 门户是开发者可以注册和管理对 API 的访问的地方。大多数情况下，API 网关将用于生成这个面向客户的 API 门户，以便用户可以访问已发布的 API。API 门户是一种非常流行的管理 API 访问的方式，它为用户提供了一种直接使用 API 的方式。典型的 API 门户允许用户浏览特定公司提供的可用 API，注册并生成 API 密钥以供访问。门户还可能包含 API 文档或其他 API 知识库文章，以帮助用户了解如何使用 API。

API 市场是一个开发者可以列出他们的 API 来吸引更多用户的地方。流行的 API 市场的例子包括 Rapid API 、 APILayer 等等。API 市场允许开发者浏览市场上列出的任何公司提供的 API。市场通常也提供一个 API 门户，这样用户可以以自助的方式管理他们的 API 访问。

让开发者使用你的 API

销售 API 的一切都准备好了，最后一步是让开发者使用它。这可以通过在 API marketplace 上列出它，建立一个网站并围绕它进行营销，或者你通常推广产品的许多其他方式来实现。

一旦你吸引了一些开发者，让 API 上线对于让开发者使用你的服务是至关重要的。如果 API 很难使用或注册，开发者可能会粗制滥造而不使用该服务。跟踪你的入职流程是一个很好的方法，可以确保用户快速方便地从你的服务中获得价值。当试图吸引和留住使用 API 的开发人员时，入门和整体易用性是需要关注的两件事。

包扎

销售 API 来推动业务收入变得越来越普遍。希望上面的概述能给我们一些关于如何去做和需要克服的挑战的见解。在这篇文章中，我们讨论了如何销售 API，面临的挑战，API 门户和 API 市场之间的差异，以及如何实现货币化。最后，我们看了一些吸引和留住使用你的 API 的开发者的因素。

为了确保你跟踪和分析 API 流量，并有效地将你的 API 货币化，请查看 Moesif。立即注册，试用时间序列图表、留存报告、计费表以及其他帮助您销售 API 的优秀工具。

如何用 MailChimp 和 Moesif 发送行为邮件

原文：https://www.moesif.com/blog/developer-marketing/behavioral-emails/How-to-Send-Behavioral-Emails-with-Mailchimp-and-Moesif/

在本指南中，你将学习如何用 Mailchimp 发送 Moesif 行为邮件。

Moesif 行为电子邮件是一项根据客户的 API 使用情况自动向客户发送电子邮件的功能。这可用于通知客户有关技术问题，例如:达到速率限制、使用废弃的 API 或试图运行中断的集成。您甚至可以使用它来触发与业务相关的事件，比如某个商品何时发货。如果某个东西可以映射到一个 API 调用，那么你可以从它发送一封电子邮件。

在的配套文章中，我们介绍了如何在 Moesif 仪表板中配置行为电子邮件。

Mailchimp 是一项托管电子邮件服务。他们提供了一个 API 来向你的用户发送电子邮件，并为你托管 SMTP 服务器。

先决条件

该操作指南需要一个 Moesif 账户和一个 Mailchimp 账户。

你还需要一个 Mailchimp 交易账户来使用 Mailchimp API，这是一项付费服务，但 Mailchimp 提供免费试用。

设置电子邮件服务器

设置电子邮件服务器的第一步是从 Mailchimp 获取 SMTP 凭证:

• 地址:smtp.mandrillapp.com
• 端口:25、587、2525 或 465 (SSL)
• 用户名:您的 Mailchimp 帐户上的主要联系电子邮件
• 密码:任何有效的 Mailchimp 事务 API 密钥

Mailchimp 事务 API 密钥可以在设置中生成。只需点击“+新 API 密钥”按钮，它将生成您的密钥。

这些凭证必须输入到 Moesif 电子邮件服务器配置表中。

要导航到该表单，请遵循下一个屏幕截图中的步骤。

您可以将凭据从 Mailchimp 站点复制并粘贴到 Moesif 站点。

Moesif 表单如下所示:

测试设置

然后，您可以使用 Moesif 通过新配置的 SMTP 服务器发送一封示例电子邮件。

配置邮件服务器后，创建一个新的电子邮件模板:

在新模板中，填写必填字段:模板名称、主题行和【T4 发件人邮件地址。

完成后，点击“测试”按钮并输入目标电子邮件。

如果一切正常，你会在收件箱里看到一封新邮件。

摘要

用 Mailchimp 设置 Moesif 行为邮件只需几分钟。

使用 Mailchimp 这样的服务可以缓解发送电子邮件时可能出现的许多常见问题，例如验证问题或电子邮件被错误地识别为垃圾邮件。

通过将 Moesif 的行为电子邮件服务与 Mailchimp 相结合，您可以让您的 API 消费者及时了解重要问题。

如何使用 Mailgun 和 Moesif API Analytics 发送行为邮件

原文：https://www.moesif.com/blog/developer-marketing/behavioral-emails/How-to-Send-Behavioral-Emails-With-Mailgun-And-Moesif-API-Analytics/

在本指南中，你将学习如何使用 Mailgun 发送 Moesif 行为邮件。

Moesif 行为电子邮件是一项根据客户的 API 使用情况自动向客户发送电子邮件的功能。这可用于通知客户有关技术问题，如达到速率限制、使用废弃的 API 或集成中断。您甚至可以使用它来触发与业务相关的事件，比如某个商品何时发货。如果某个东西可以映射到一个 API 调用，那么你可以从它发送一封电子邮件。

在的配套文章中，我们介绍了如何在 Moesif 仪表板中配置行为电子邮件。

Mailgun 是一种托管电子邮件服务。他们提供了一个 API 来向你的用户发送电子邮件，并为你托管 SMTP 服务器。

先决条件

该操作指南需要一个 Moesif 账户和一个 Mailgun 账户。

设置电子邮件服务器

设置电子邮件服务器的第一步是从 Mailgun 获取 SMTP 凭证。

为此，您必须登录到 Mailgun 仪表板。

下面的屏幕截图说明了如何导航到凭据。

这些凭证必须输入到 Moesif 电子邮件服务器配置表中。

要导航到该表单，请遵循下一个屏幕截图中的步骤。

您可以将凭据从 Mailgun 站点复制并粘贴到 Moesif 站点。

Moesif 表单如下所示:

测试设置

然后，您可以使用 Moesif 通过新配置的 SMTP 服务器发送一封示例电子邮件。

配置完邮件服务器后，您必须创建一个新的电子邮件模板:

对于新模板，您必须填写必填字段:模板名称、主题行和发件人电子邮件地址。

完成后，点击“测试”按钮并输入目标电子邮件。

如果一切正常，你会在收件箱里看到一封新邮件，同时 Mailgun 仪表板会显示它已经发送了该邮件。

摘要

用 Mailgun 设置 Moesif 行为邮件只需要几分钟。

使用 Mailgun 这样的服务可以缓解发送电子邮件时可能出现的许多常见问题，例如验证问题和电子邮件被错误地识别为垃圾邮件。

通过将 Moesif 的行为电子邮件服务与 Mailgun 相结合，您可以让您的 API 消费者及时了解重要问题。

如何使用 Moesif 为 Strapi 无头 CMS 设置监控和分析

原文：https://www.moesif.com/blog/technical/how-to/How-to-Set-Up-Monitoring-and-Analytics-for-Strapi-a-Headless-CMS-with-Moesif/

Strapi 是一个基于 Node.js 的 Headless CMS。Headless 意味着它通过 HTTP API 提供所有内容，因此您可以轻松地围绕它构建面向用户的前端。由于它是一个完全成熟的 CMS，它带来了一个开箱即用的管理前端，使得发布和维护内容变得简单明了——即使对于那些没有技术背景的人来说也是如此。因为 Strapi 中的一切都是通过 api 工作的，所以它非常适合 Moesif API 监控。

在本操作指南中，我们将探讨如何将 Strapi CMS 与 Moesif API 监控和分析相集成。

先决条件

按照这个方法，你需要一个 Strapi 安装和一个 Moesif 账户。

安装和包装 Moesif SDK

Node.js 的 Moesif SDK 是作为 Express 和 Koa 等框架的中间件提供的。由于 Strapi 构建在 Koa 框架之上，这使得集成非常容易。您需要围绕 Moesif 中间件编写一个小的包装器，使它的行为像一个为 Strapi 定制的中间件，并根据您的需求配置它。

第一步是安装 NPM 包 moesif-nodejs 作为一个新的依赖项。

$ npm i moesif-nodejs 

接下来，您需要在./middlewares/moesif/index.js在 Strapi 项目中创建一个新的 JavaScript 文件。

它应该有以下内容:

const moesif = require("moesif-nodejs");

const middleware = moesif({
  applicationId: "<MOESIF_APP_ID>",
  // Optional hook to link API calls to users
  identifyUser: (request, response) => {
    if (request.state.user) return request.state.user.id;
    return null;
  },
});

module.exports = (strapi) => ({
  initialize() {
    strapi.app.use(middleware);
  },
}); 

你需要用你的钥匙替换<MOESIF_APP_ID>。点击右上角的用户菜单，选择“API Keys”，就可以在 Moesif 控制台中找到这个密钥

一个定制的 Strapi 中间件需要用 initialize 方法公开一个对象，所以您需要在这里用一点胶水代码包装 Moesif 中间件。

注意:如果你使用的是 Strapi 的用户&权限插件，你会发现认证后的用户对象处于请求状态。如果您查看传递给 Moesif 中间件的identifyUser函数，您会了解如何提取特定于用户的数据。这同样适用于您可以用来配置 Moesif 中间件的identifyCompany函数。

配置 Strapi 以加载中间件

既然我们已经创建了 Moesif 中间件，我们必须告诉 Strapi 它应该加载它。为此，我们必须在创建一个配置文件。/config/middleware.js，并将以下配置代码添加到其中:

module.exports = {
  settings: {
    moesif: { enabled: true },
  },
}; 

本例中的 moesif 设置对应于目录。/中间件/moesif 在这里。

在 Moesif 控制台中查看 Strapi 事件

如果设置正确，现在可以在 Moesif 控制台中看到 Strapi HTTP 事件。只需导航到“事件”，然后“实时事件日志”

正如您在截图中看到的，甚至管理请求都在事件日志中，这样您就可以跟踪与您的 Strapi 安装的每次交互。

摘要

Strapi CMS 是一个低代码解决方案，这意味着它让您无需编码就可以做很多事情，但是当您需要更多定制时，您仍然可以添加代码。这种方法使得非技术团队成员可以轻松使用 Strapi，并允许您在需要时添加定制的功能，如 Moesif API 监控和分析。

由于 moes if API monitoring and analytics 附带了一个出色的图形用户界面，非技术团队成员可以从一开始就独立工作。

如何使用 Stripe 和 Moesif 为您的 API 设置基于使用的计费

原文：https://www.moesif.com/blog/developer-platforms/stripe/How-to-Set-Up-Usage-Based-Billing-with-Stripe-and-Moesif-for-your-API/

一个好的商业模式是一个容易产生收入的模式。通常，当开发人员构建一些东西时，它很容易被另一个组织打包和使用。对于 API 来说，这一点尤其正确。如果一个 API 正在解决一个众所周知的问题，它很可能会有市场。能够公开 API 供公众使用可以通过许多方式实现，一个流行的选择是使用 API 网关。当你决定开始按使用计费时，真正的障碍就来了。货币化是希望为其 API 实现基于使用计费的公司所面临的最大挑战之一。

API 货币化通常需要大量的集成、大量的代码、定制，还会导致大量的支持负担。当事情没有按计划进行时尤其如此，可能是由于计费设置中的错误，计费问题出现了。简而言之，无论是在实施过程中，还是在计费系统启动并运行后，都存在挑战。

如果有一种更简单的方法是可能的呢？在 Moesif，我们最近为计费表引入了一项功能。此功能允许您汇总进入 Moesif 的使用数据，将这些数据发送给计费提供商，并向用户提供准确的账单，所有这些工作只是实现定制解决方案所需工作的一小部分。

为了说明它是如何工作的，让我们假设我们有一个 API，我们希望对客户的使用进行收费。作为一个例子，让我们假设我们已经创建了一个新的信用评分 API，公司可以使用它将消费者的信用评级带回他们的应用程序。我们的 API 将是 /RetrieveCreditScore ，用户将为他们发送到端点的每个查询/调用付费。

我们的 API 货币化模型将非常简单。我们将有 3 个使用层级来决定向用户收取多少费用:

• 每月 1-100 次查询(每次查询 5 美元)
• 每月 101-1000 次查询(每次查询 3 美元)
• 每月 1001 次以上的查询(每次查询 2 美元)

这种分级定价方案很常见，使用的服务越多，折扣就越大。

Stripe 将作为计费提供商，我们将使用它向客户开具发票并收取使用费。Stripe 易于使用，使我们能够轻松设置产品和定价，以符合上述定价方案。在 Stripe 中，这种定价方案被称为分级定价。

当然，有多种方法可以在 Stripe 中实现与 Moesif 兼容的定价方案。这只是如何做到这一点的一个例子。

我们现在将使用 Moesif 来统计端点的使用情况，并将使用指标发送到 Stripe。然后，Stripe 可以使用这些指标，根据指标对应的层，向客户开出相应的账单，并收取费用。

将您的应用和 API 与 Moesif 集成

为了使用 Moesif 中的计费表特性，您需要将您的 API 与 Moesif 集成。这是因为 Moesif 将需要来自 API 使用的指标，以便向 Stripe 发送准确计费所需的信息。一旦您的 API 与 Moesif 集成，您还可以使用与我们的计费表功能配合良好的其他功能，包括行为电子邮件、治理规则和警报。

如果您目前没有使用 Moesif 来监控您的 API，那么集成可以通过几种不同的方式来完成。如果您使用的是 API 网关或 API 管理平台，您可以使用我们众多插件中的一个，这些插件允许您将度量数据从您的 API 快速移动到 Moesif 中。如果您不使用第三方网关或管理平台，或者希望在 API 代码级别使用，您可以使用我们的 SDK 之一。Moesif SDK 将允许您直接从代码中轻松地将 Moesif 与您的 Node、Python 或 Java APIs(加上许多、许多语言和框架)集成在一起。两种方式都很容易支持。

为了使计费正常工作，您需要部署的另一个 Moesif 特性是实现用户和公司跟踪。通常，这可以通过几个简单的步骤来设置。我们需要启用此功能，以便 Moesif 中的使用数据可以绑定到特定的用户和公司。这就是 Stripe 如何将使用情况映射到 Stripe 内的客户，以便他们可以相应地计费。

一旦您与 Moesif 集成，并启用了用户和客户跟踪，您的下一步将是在 Stripe 中实际创建您的产品，以便它们可以在 Moesif 中使用。

在条带中创建计划和附加组件

创建 Stripe 帐户并登录后，您可以开始创建用于计费的产品。在本例中，我们将创建一个具有分级定价方案的产品。

您需要创建一个条纹产品，该产品:

• 包括一个分级定价模型
• 有一个月的计费周期
• 使用计量计费
• 在时间段内使用价值总和的计量使用费用
• 可选(但推荐)，包括价格描述

完成所有配置后，我们将创建我们的定价方案。该配置在条带中将如下所示:

现在，在月末，当 Stripe 创建发票时，它将根据这些层来创建发票。当然，在这一点上，我们只定义了计划，但没有人会被收费，因为我们还没有任何使用数据被发送到条带。

将条纹与 Moesif 集成

我们仍然需要将数据从 Moesif 转移到 Stripe，反之亦然。有两种机制用于此:webhook 和 Stripe API。在促进平台之间的数据共享方面，两者各有不同的作用。

通过将 webhook 添加到 Stripe 中，订阅更新可以发送回 Moesif。通过使用 Stripe API，Moesif 可以向 Stripe 发送使用详细信息，还可以检索 Stripe 中可用产品和定价的详细信息。这两个接触点是 Stripe 和 Moesif 集成所需要的。幸运的是，当您将 Stripe 设置为计费提供商时，Moesif 会带您完成这一步，并提供所有需要的详细信息。具体情况，你也可以查看我们关于条带集成的文档。

设置您的计费参数

一旦你在 Moesif 中集成了 Stripe，你就可以设置你的计费表了。对于我们的例子，这将是非常简单的。我们要做的是，每当对 /RetrieveCreditScore 的 API 调用返回一个 200 OK 响应时，就向 Stripe 发送使用度量。这意味着我们将只对成功的呼叫计费，而不会意外地对出现错误的呼叫计费。

一旦我们创建了计费表，每个小时每个客户的使用量将被发送到 Stripe。月底，Stripe 将根据我们的分级价格结构创建发票，并向用户收费。

您还可以使用 Moesif 为每一个成功的电话自动发送行为电子邮件，或者如果他们即将进入下一个折扣级别。您还可以使用 Moesif 的治理规则来阻止发票过期的用户访问 API，直到他们的发票得到结算。

你自己试试吧

如您所见，离易于实现和支持的健壮 API 货币化只有几步之遥。通过同时使用 Moesif 和 Stripe，您可以在几分钟内向客户收取使用费，管理订阅，甚至可以使用 Moesif 的其他功能来创建终极客户体验。我们的计费设置非常简单，甚至不需要任何开发人员的技能就可以完成。

所有 Moesif 用户均可使用计费表功能。立即注册moes if，立即访问我们的计费表功能，开始为您客户的 API 使用计费。如果您已经在使用 Moesif，请点击左侧导航菜单中的计费表，查看我们的文档，了解让您将 API 货币化的具体步骤。

如何用嵌入的指标展示你的 API 的商业价值

原文：https://www.moesif.com/blog/business/dashboards/How-To-Show-The-Business-Value-Of-Your-APIs-With-Embedded-Metrics/

当你向你的客户提供 API 的时候，你希望确保他们从中获得价值。同时，最好的 API 被设计成完全自动化，不需要人工干预。这可能会让您的客户不知道您的 API 是否被组织使用，以及您是否满足企业合同中的任何 SLA 义务。

要显示的度量类型

大多数 API first 公司都有某种类型的开发者门户供客户登录、管理 API 密钥和定制特性。这个区域也是向您的客户展示关键指标的好方法，展示他们从您的 API 中获得了多少价值。这可以是一个简单的计数器，显示一个计费周期内进行的 API 事务的数量，或者提供有关这些事务的其他指标。每个客户都有他们想要查看的不同指标。开发人员希望查看访问日志，因为产品和工程领导对使用和性能指标更感兴趣。最后，财务部门可能需要查看容量和财务规划的计费使用情况。

提供 API 日志

向开发人员展示你的同情心的一个快速简单的方法是提供 API 日志。工程师们现在正在集成无数的 API 来发布他们的应用程序。他们没有时间去理解你的 API 创建的每一个响应或错误代码。然而，拥有详细的结构化日志对于调试集成问题非常有帮助。您可以轻松地直接在开发人员门户中提供 API 日志，而不是依赖您的客户来检测您的集成。如果您采用这种方法，请通过包括以下功能来确保您的访问日志是有用的:

• 结构化数据，使开发人员能够快速向下钻取，而无需缓慢搜索
• 除了请求参数(如客户端位置或 API 版本)之外，还包括上下文
• 高级过滤器支持创建包含正文字段的复合查询
• Curl、Swagger UI 和 Postman 等工具中的重放功能
• 可以与开发人员支持共享的事件 id

显示 API 用法

虽然业务和工程领导可能需要检查 API 日志本身，但他们渴望拥有正确的指标来做出明智的决策。如果他们赞助一个新项目，他们希望确保他们的钱花得值。提供平台使用指标有助于展示企业领导者获得的价值。

API 调用本身并不显示价值，但是它们代表了某种商业交易，无论是付款还是发送文本消息来提醒终端用户有货物。因此，请确保您的使用情况报告可以显示给定时间段内的历史事务数量。对使用情况报告的要求包括:

• 能够看到使用不同的时间间隔，如小时/天/月
• 显示业务交易的数量，即使您的 API 可以批量处理请求
• 一种按用户统计细分使用情况的方法

显示性能指标

虽然有些 API 仅由内部应用程序使用，但许多 API 集成在面向客户的应用程序中。如果您的 API 有性能或可靠性问题，这会影响他们的最终用户。这可能会损害他们的声誉或导致收入损失。如果您有义务满足某些 SLA(服务水平协议)，请向您的客户展示这一点。这可以让您放心，因为您知道您的 API 是可靠和高性能的。

提供计费仪表板

大多数 API 利用基于消费的计费。如果你正在提供一个支付 API，这可能是每月的交易数量或美元交易量的百分比。然而，如果您提供消息传递 API，您可能会根据一个计费周期内发送的消息数量来计费。您的客户会希望优化他们的使用来最大化您的 API 的价值，这意味着您应该显示他们的钱花在了哪里。请记住，您应该有一个一致的真实账单来源，否则您的支持团队将会因为账单差异而收到大量请求。

除了计费之外，您还应该显示您的客户受到的任何费率限制或配额。事实上，这可以是一种简单的方法，通过显示它们离当前的限制有多近来追加销售更大的计划。因为许多业务团队不知道或者不登录您的开发人员门户，所以您也应该发出通知，让您的客户在配额被突破时知道。

如何开始使用嵌入式图表

使用 Moesif，您可以在几分钟内嵌入 API 日志和使用报告。集成有三个部分

1. 使用正确的视图和过滤器在 Moesif UI 中创建一个嵌入模板。您还应该选择动态变量名，如user_id或company_id，它们将在第二步中设置
2. 后端的一个 API 调用 Moesif 管理 API 来获得一个有时间限制的工作区 URL。这将返回到您的前端
3. 使用带有生成的工作区 URL 的 iFrame 嵌入图表。

一个使用 Moesif 嵌入模板的 React 应用程序在这里可用。

要嵌入图表或 API 日志:

第一步。在 Moesif 中创建新的嵌入模板

1. 从顶部菜单转到事件并选择您想要嵌入的视图。
2. 添加要应用于嵌入图表的任何筛选器和其他图表设置。
3. 点击右上角的共享按钮，然后选择嵌入模板选项卡。

1. 添加任何动态变量，如用户 Id 或公司 IdT2。
2. 点击获取嵌入代码，您将看到要添加到您的应用程序中的代码片段(如下所示)。

第二步。生成工作区 URL

创建一个新的端点，调用 Moesif API 来生成工作区 URL。当您调用 Moesif API 时，设置您在步骤 1 中添加到模板中的动态变量。在本例中， user_id 是一个需要填充正确值的动态字段。

curl -X POST -H 'Authorization: Bearer YOUR_MANAGEMENT_API_KEY' -H 'Content-Type: application/json' -i 'https://api.moesif.com/v1/portal/~/workspaces/{WORKSPACE_ID}/access_token
  -d '{
  "template": {
    "values": {
      "user_id": "1234"
    }
  }
}' 

Moesif 返回一个工作区 URL。该 URL 只能访问步骤 1 定义的数据。在这个例子中，数据的范围是用户 id 1234。

{
  access_token: '{WORKSPACE_ACCESS_TOKEN}',
  url: 'https://www.moesif.com/public/{WORKSPACE_ACCESS_TOKEN}/ws/{WORKSPACE_ID}?embed=true
} 

第三步。添加 iFrame

使用步骤 2 中生成的工作区 URL 向前端添加 iFrame。具有工作区 URL 的用户只能访问基于您在步骤 2 中设置的动态变量的数据。

<iframe
  id="preview-frame"
  src="https://www.moesif.com/public/{WORKSPACE_ACCESS_TOKEN}/ws/{WORKSPACE_ID}?embed=true"
  name="preview-frame"
  frameborder="0"
  noresize="noresize">
</iframe> 

结论

展示你的客户所获得的价值可以帮助你的客户走向成功。使用 Moesif，只需几行代码就可以轻松地将 API 指标和日志嵌入到您的应用程序中。

如何用 Nodejs 进行 Web 和 API 产品分析

原文：https://www.moesif.com/blog/technical/api-analytics/How-To-Stand-Up-Web-And-API-Product-Analytics-With-Nodejs/

本指南将带您了解如何通过跨平台分析来跟踪您的 API 和 web 应用程序中的客户行为。通过跟踪客户在 API 和 web 应用上的行为，您能够全面了解客户的旅程和指标，如首次 Hello World 的时间和价值实现时间。更多信息请见我们的博客文章，追踪开发者从注册到第一次 API 调用的旅程

然而，收集数据本身是不够的。毕竟，如果不付诸行动，就没有多大用处。这就是为什么我们会指导您如何根据客户的使用情况和行为，通过行为电子邮件使用这些数据向客户发送电子邮件。

专业提示:一个用户注册了，但从来没有集成或激活？向他们发送关于如何集成 API 的有用资源。

在一篇配套的文章中，我们写了如何在 Moesif 仪表板中配置行为电子邮件。在本文中，我们将介绍基于 Node.js 的 API 的整个设置过程。

先决条件

该操作指南需要一个 Moesif 账户和 Node.js 。

项目设置

首先，我们需要用 NPM 创建一个新的 Node.js 项目:

$ mkdir moesif-email
$ cd moesif-email
$ npm init -y && npm i express moesif-nodejs 

如果一切顺利，输出应该包括以下几行:

- express@4.17.1
- moesif-nodejs@3.0.0 

在 Node.js 和 Express 的基础上，我们将建立我们的 API 和注册网站。Moesif SDK for Express 会将 API 监控数据发送到 Moesif 服务。

使用 Moesif 浏览器 SDK 创建网站

首先，我们需要创建一个网站。我们将使用 Moesif browser SDK 发送带有特定用户 ID 的客户端事件。这将在 Moesif 服务上创建一个新用户，并提供元数据，稍后，我们可以将用户链接到一个从网站发送的 API 请求。moesif-email/index.html 的代码如下所示:

<script src="//unpkg.com/moesif-browser-js@^1/moesif.min.js"></script>

<h1>Demo API</h1>
<button id="start">Send client event</button>
<button id="api">Send API request</button>
<pre id="target"></pre>

<script type="text/javascript">
  moesif.init({ applicationId: "<YOUR_MOESIF_APP_ID>" });
  const userId = "demo-user-123";
  moesif.identifyUser(userId, {
    email: "<YOUR_EMAIL>",
    firstName: "Jane",
    lastName: "Doe",
  });
  document.getElementById("start").addEventListener("click", () => {
    moesif.track("clicked_start");
    document.getElementById("target").innerHTML = "clicked_start";
  });
  document.getElementById("api").addEventListener("click", async () => {
    const response = await fetch("/api", {
      headers: { Authorization: userId },
    });
    const json = await response.json();
    document.getElementById("target").innerHTML = JSON.stringify(json, null, 2);
  });
</script> 

我们包含了 Moesif browser SDK，创建了两个按钮并将它们与两个动作链接起来，发送一个客户端事件和一个 API 请求。SDK 是用 userId 配置的，所以 Moesif 知道是谁发送了客户端事件。不要忘记将<YOUR_MOESIF_APP_ID>替换为您实际的 Moesif 应用 ID，将<YOUR_EMAIL>替换为您自己的电子邮件。

客户端动作使用浏览器 SDK 将网站上发生的事情告诉 Moesif。在这种情况下，单击按钮。这与我们的 API 无关，但以后可能会很有趣。例如，当用户通过网站注册，但随后没有发送任何请求。

API 请求将使用授权头告诉 API 关于用户 Id 的信息。通过这种方式，Moesif 可以在以后将客户端事件与 API 请求联系起来。

使用 Moesif Express SDK 创建 API

下一步是 API 服务器。我们将使用 Express 框架来构建它。这也将服务于我们在最后一步中创建的网站。

moesif-email/index.js 的代码应包含以下内容:

const fs = require("fs");
const express = require("express");
const moesif = require("moesif-nodejs");
const website = fs.readFileSync(__dirname + "/index.html");

const app = express();
app.use(
  moesif({
    applicationId: "<YOUR_MOESIF_APP_ID>",
    logBody: true,
    identifyUser: ({ headers }) => headers.authorization,
  })
);
app.get("/", (request, response) => response.end(website));
app.get("/api", (request, response) =>
  response.end(JSON.stringify({ timestamp: Date.now() }))
);
app.listen(8888, () => console.log(`Running at http://localhost:8888`)); 

首先，我们加载 index.html，然后我们可以创建一个 Express 应用程序，并将其配置为使用 Moesif Express SDK 作为中间件。您需要用您实际的 Moesif 应用程序 ID 替换YOUR_MOESIF_APP_ID。

测试 API

要测试 Express API，我们必须使用以下命令启动服务器:

$ node . 

这将输出以下行:

Running at http://localhost:8888 

如果一切顺利，我们可以用浏览器导航到http://localhost:8888，查看我们的网站并点击按钮。一个将发送客户端事件，另一个将发送 API 请求。

图 1:实时事件日志

如果您现在导航到 Moesif 仪表板，在那里您得到了YOUR_MOESIF_APP_ID,并点击顶部的“Events”选项卡，您应该看到四个不同的事件，如上面的图 1 所示。

用户动作事件是客户端事件。GET /api 事件是我们发送给 api 的请求。它们都标注了用户名和公司。另外两个事件是关于浏览器加载网站和 favicon 的请求。包含它们是因为我们使用与 API 相同的 Express 服务器交付网站，但是由于请求缺少授权头，我们没有得到用户或公司注释。

图 2:用户总结

如果您单击用户，您会看到他们的“用户摘要”,其中包括该用户的电子邮件地址，如图 2 所示。

设置行为电子邮件

既然我们已经创建了我们的 API，并且知道它收集数据，我们可以设置行为电子邮件。

创建群组

发送电子邮件的第一步是创建一个群组，即一组符合特定标准的用户。这些标准可以包括人口统计信息，如地理位置，但也包括执行的事件。

为此，我们需要转到用户查找。要访问该页面，请单击顶部导航栏中的“用户”链接，然后单击第一个导航栏下方第二个导航栏中的“用户查找”链接。

图 3:用户查找

您现在看到的视图应该类似于图 3 中的屏幕截图。

我已经在截图中为我们的队列添加了一些标准。该群组中的用户应该有一封电子邮件，并且在过去 7 天中应该没有 API 调用。您可以复制该设置，单击“创建群组”，并将其命名为“没有 API 调用的用户”。

创建电子邮件模板

根据群组定义，我们告诉 Moesif 用户应该满足什么标准才能获得电子邮件，或者用户必须做什么或不能做什么才能加入群组。

如果您导航到“警报和治理”，然后导航到“行为电子邮件”，您可以配置您的 SMTP 服务器并创建用于通知您的用户的电子邮件模板。

图 4:电子邮件模板创建

图 4 显示了电子邮件模板创建的屏幕截图。在“发送至”下，您可以选择您的群组。如果你选择“循环工作流”，Moesif 不会只发送一次邮件，而是在特定的时间间隔内检查用户是否满足标准，是否应该收到新邮件。

摘要

将端到端分析添加到基于 Express 的 Node.js API 和网站中，只需要 Moesif 的几行代码。

Moesif 浏览器和 Node.js SDKs 使您能够跟踪从初始注册到最后一次 API 调用的所有内容。这允许您将用户来自的渠道与 API 的实际使用联系起来，以便稍后可以分析整个用户旅程。

通过行为电子邮件，你可以使用这些信息自动通知你的用户任何与 API 使用相关的事情。使用 Moesif 发送有用的电子邮件。

如何跟踪开发人员使用 Docusaurus 和 Moesif API Analytic 的体验

原文：https://www.moesif.com/blog/api-product-management/docusaurus/How-to-Track-Developer-Experience-with-Docusaurus-and-Moesif-API-Analytics/

如果你的产品是一个 API，你的客户通常是开发者。虽然许多开发人员不喜欢为他们自己的应用程序编写文档，但他们肯定喜欢为他们使用的 API 编写好的文档。写得好的文档可以帮助开发者更快地发布他们的集成和应用，而不是陷入集成问题和错误中。

好的文档也可以是一个强大的营销工具，因为它超越了页面这样的典型参考，向您的开发人员客户展示了您平台的潜在用例。当开发人员为客户最迫切的问题寻找解决方案时，他们可能会从搜索引擎中找到您的文档。目标是让你的解决方案在搜索引擎优化中排名第一。

好的文档是通过不断调整开发人员的体验而反复编写的。这需要有合适的工具来衡量指标，如首次 Hello World 的时间，并找出客户最纠结的地方。当客户在你的 API 中遇到 400 错误时，看看他们浏览的是什么文档页面。如果他们一直遇到 400 个错误而没有解决，也许这些文档页面需要更新

用于 Moesif API 分析的 Docusaurus 插件

Docusaurus 是一个由脸书开发团队开发的用于编写和发布文档的流行框架，为分析供应商、搜索供应商等提供了各种插件。[Moesif 有一个 Docusaurus 的插件](https://www . moe SIF . com/docs/client-integration/Docusaurus 使您能够跟踪正在浏览的文档页面，并跟踪客户的旅程。Moesif 是为 API 产品设计的，因此可以跟踪 web 活动并监控 API 流量。这使您能够构建高级漏斗报告，如首次 API 调用时间。

SDK 自动从用户设备收集有用的上下文，包括任何营销属性、设备类型和位置信息，并存储在 Moesif 中的用户和/或公司简介中。您可以通过 identifyUser()和 identifyCompany()方法添加其他客户属性，如用户电子邮件和公司域。

这使得你只需要几行代码就可以将 Moesif 集成到你的docusaurus.config.js中。

使用以下命令安装它:

$ npm i docusaurus-plugin-moesif 

像这样更新你的docusaurus.config.js:

module.exports = {
  plugins: ["docusaurus-plugin-moesif"],
  themeConfig: {
    moesif: {
      applicationId: "Your Moesif Application Id",
      // Add other Moesif options here.
    },
  },
}; 

这会将你的文档的所有视图发送到 Moesif，这样你就可以看到你的哪些文档是受欢迎的。

如果您想获得更深入的见解，您还可以识别哪个用户当前正在浏览哪个文档，然后将他们查看的内容链接到他们的 API 请求。

window.moesif.identifyUser("12345", {
  email: "john@example.com",
  firstName: "John",
  lastName: "Doe",
  title: "Software Engineer",
  salesInfo: {
    stage: "Customer",
    lifetimeValue: 24000,
    accountOwner: "ceo@example.com",
  },
}); 

跟踪文档访问和 API 流量

一旦你设置了 Moesif，你就可以利用它来跟踪你的转化漏斗，比如有多少看过你的文档的开发者真正转化为活跃用户。然后，你可以根据他们浏览的内容，通过查看每个转化率来了解你最好和最差的文档。

对文档进行分析也是确定潜在客户对哪些功能感兴趣的绝佳方式。这也意味着你可以同时解决两个问题:向现有客户提供解决方案，并利用这些解决方案获得新客户。

从对文档运行分析中获得价值的另一种方式是将文档页面的查看与 API 的行为联系起来。如果你看到一个客户读了一个特定的 API 文档，然后因为他们发送了错误的请求而从你的 API 得到错误，这可能是你的文档传递了错误的信息。相反，如果客户收到的错误回复在阅读文档后消失了，你可以断定文档帮助了他们。

为了做到这一点，你应该安装一个 Moesif 服务器集成。下面是如何为 Node.js 执行此操作的示例:

1.安装 SDK

npm install --save moesif-nodejs 

2.初始化 SDK

// 1\. Import Modules
const express = require('express');
const app = express();
const moesif = require('moesif-nodejs');

// 2\. Set the options, the only required field is applicationId
const moesifMiddleware = moesif({
  applicationId: 'Your Moesif Application Id',

  // This function should return the same id used in the above window.moesif.identifyUser
  identifyUser: function (req, res) {
    return req.user ? req.user.id : undefined;
  },
});

// 3\. Enable the Moesif middleware to start logging incoming API Calls
app.use(moesifMiddleware); 

Docusaurus 中用于函数window.moesif.identifyUser的用户应该与服务器集成的identifyUser方法中使用的 id 相匹配。这确保 Moesif 可以正确缝合在一起。

跟踪你的文档的搜索词是最重要的问题之一，因为这样你就可以发现你的文档甚至你的 API 中缺少了哪些部分。

摘要

API 文件是 API SaaS 公司的表格。当文档详细而完整时，即使是一个普通的 API 实现也是一种乐趣。

如果你对你的 API 文档的使用情况进行分析，你可以深入了解你的客户的心态:他们想用你的 API 做什么，这可能吗，文档是否缺乏，你的 API 是否缺乏。分析可以从分析你的文档的使用中提取所有这些东西。

有了 Moesif，你可以在一个地方对你的 API 和它的文档进行分析，甚至把动作和请求联系起来，从而收集更多的信息。您的客户是否找到了与他们的错误相关的文档，这些文档是否解决了他们的错误？使用集成的解决方案，您可以确保始终了解客户如何使用您的 API 产品，以及您如何改进它。

如何跟踪每个合作伙伴或客户的 API 键进行的 API 调用的数量

原文：https://www.moesif.com/blog/api-analytics/usage-tracking/How-To-Track-Number-of-API-Calls-Made-By-Each-Partner-or-Customer-API-Key/

为什么要跟踪 API 调用的数量？

如果你是一家 B2B 公司，你很有可能想要向组织外的团队公开你的一些内部 API。这些可能是为你的 API 付费的客户，或者你的合作伙伴。无论哪种方式，当 API 公开时，跟踪每个合作伙伴或客户进行了多少次 API 调用是至关重要的。通过这样做，您可以发现是一个客户消耗了您的大部分 API 资源，还是您的 API 没有被您的客户采用。

处理过期的 API 密钥

跟踪每个合作伙伴的 API 调用数量可以通过两种机制来完成，这取决于您的 API 密钥是如何发布的。如果您的 API 密钥是永不过期的永久令牌，并且每个客户最多可以拥有一个令牌，那么跟踪就变得相对简单了，每当您看到针对特定令牌的 API 调用时，您可以增加内存中的计数器。这些计数器可以通过快速键值存储(如 Redis)保存到磁盘中。计数器可以在每月的第一天重置。

但是，这种方案在以下情况下可能会有问题:

• 您的 API 令牌会在几小时或几分钟后过期
• 您的客户可以创建多个 API 密钥，例如，如果您允许更改令牌的范围

如果是这样，你的追踪就变得更复杂了。最好的处理方式是通过一个别名表

会话别名表

会话别名表将跟踪客户创建的所有未完成令牌，并将这些令牌映射到单个 user_id 。您可以在 Redis 中保留一个别名表，其中键是 API 键，值是 user_id。这样，当您的 API 服务器收到新的 API 请求时，它可以通过 API 键查找 user_id。

第一步。捕获 API API 数据

您将需要为您的 API 框架创建中间件，该中间件可以在 API 请求进入并调用您的服务时捕获和处理这些请求。如果你正在寻找一个托管服务，Moesif 已经为许多流行的框架提供了预构建的中间件，如 Moesif Express SDK 否则，如果你正在尝试推出自己的分析服务，可以在 GitHub 上找到中间件源代码。中间件应该满足某些要求:

1. 事件处理是在核心业务逻辑的带外异步完成的
2. 敏感数据在发送到下游分析服务之前会被清除

Node.js 的一个例子

让我们看一个例子，创建一个构建在 Node.js 上的 API，并添加中间件来跟踪每个合作伙伴的请求数量。首先，我们创建一个 app.ks，导入 Express 框架。我们将设置一个返回一些基本 JSON 的端点/api。

因为，API 通常需要通过某种类型的 API 密钥或令牌进行认证，让我们添加express-jwt库。

const express = require('express');
const jwt = require('express-jwt');
const app = express();

// Add JSON Web Token Library for authentication
const jwtMiddleware = jwt({
  secret: Buffer.from('12345'),
});

app.use(jwtMiddleware);
app.get('/api', (req, res) => {
    res.json({
      my_object: {
        my_message: 'Hello World!'
      }
    }));
});

app.listen(8080, () => console.log('API listening on port 8080!')); 

添加日志中间件

接下来，让我们创建一个简单的中间件，它可以捕获关于谁在调用 API 的特定信息

const moesifExpress = require('moesif-express');

const moesifOptions = {

  applicationId: process.env.MOESIF_APPLICATION_ID, // You should set your APPLICATION_ID as an environment variable

  identifyUser: function (req, res) {
    // The subject of the JWT (i.e. the user_id) is automatically saved to req.user via JWT middleware
    if (req.user) {
      return req.user.id;
    }
    return undefined;
  },

  identifyCompany: function (req, res) {
    // Our company id is in the form of the URL via GET /accounts/1234/items
    const extracted = req.path.match(/accounts\/\d+[\/-]/);
    const companyId = extracted && extracted[0];
    return companyId;
  },

  getSessionToken: function (req, res) {
    return req.headers['Authorization'];
  }
}; 

一旦我们设置了获取所需信息的选项，我们就可以添加 moesif 日志中间件:

const express = require('express');
const jwt = require('express-jwt');
const app = express();

// Add JSON Web Token Library for authentication
const jwt = jwt({
  secret: Buffer.from('my_super_secret'),
});

app.use(jwtMiddleware);
app.use(moesifMiddleware);

app.get('/accounts/:id/message', (req, res) => {
    res.json({
      my_object: {
        my_message: 'Hello World!'
      }
    }));
});

app.listen(8080, () => console.log('API listening on port 8080!')); 

第二步。启动您的 API 并创建流量

一旦中间件连接起来。启动节点服务器。

node app.js 

我们需要生成一个假的合作伙伴 API 令牌。由于我们使用 JWT，我们可以通过 JWT.io 快速生成一个。为了使事情更容易，请查看我预先填充的 jwt.io 链接。

JWT 有几个关键要素:

• JWT 秘密my_super_secret被设置为我们在 Node.js 应用中使用的相同秘密。当然，对于生产，您应该生成一个安全的 256 位密码。
• 有效负载包含一些我们的中间件将记录的关键信息:

{  "sub":  "513",  "name":  "John Doe",  "iat":  1516239022  } 

sub字段是主题的缩写，是认证术语中 user_id 的技术名称。我们还看到了另外两个字段，用户名和字段iat，它是在发布的的缩写。我们可以向 JWT 有效负载添加任意字段，比如向 JWT 添加 tenant_id，以满足任何要求。

下面是我创建的 JWT.io(可以从jwt.io网站复制。)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1MTMiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.FPN2Bj5b6OUzeTJ7lrNQPWUkZnnBnhMFYeyMjJ_-tN0 

接下来，使用新创建的合作伙伴 API 令牌向您的 API 发出一些 API 请求

curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1MTMiLCJuYW1lIjoiSm9obiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9.FPN2Bj5b6OUzeTJ7lrNQPWUkZnnBnhMFYeyMjJ_-tN0' http://localhost:8080/accounts/abcdef/message 

注意对于 JSON Web 令牌，它们是不记名令牌，这意味着任何持有令牌的人都可以访问 API。有关 API 认证和授权的更多信息，请查看这篇博文。

改变sub字段，如 1234 和 2560 时，用几个额外的令牌重复curl命令。

第二步。可视化 API 数据

现在，您已经进行了一些 API 调用，登录到您的www.moesif.com并点击 API 分析- >事件流。您应该可以在 Moesif 中看到通过 curl 命令创建的 API 调用。现在，转到 API 分析- >分段，选择按用户 Id 分组。您应该会看到如下图表:

结束语

使用中间件和 Moesif，您看到了如何跟踪进行最多 API 调用的客户。接下来，您可以跟踪他们使用了哪些 API 路线，以及他们在您的 API 平台上坚持了多长时间。

我们如何构建 Node.js 中间件来记录 HTTP API 请求和响应

原文：https://www.moesif.com/blog/technical/logging/How-we-built-a-Nodejs-Middleware-to-Log-HTTP-API-Requests-and-Responses/

有许多不同的运行时和生态系统用于构建 API，在 Moesif，我们试图尽可能简单地与它们集成。我们构建了许多有助于这种集成的库，其中之一是 Moesif Express 中间件库，或简称 Moesif-Express。

尽管名为 Moesif-Express，但它可以与使用内置http模块的 Node.js 应用程序一起使用。

Node.js 异步处理请求，这有时会导致问题，尤其是当我们想要调试系统或记录它们正在做什么的时候。

在本文中，我们将介绍构建 Moesif-Express 库的步骤、相关日志数据的位置以及如何挂钩 Node.js' http模块，以便在管道中的正确时间处理数据收集。

Node.js' HTTP 模块

Node.js 附带了一个现成的 HTTP-server 实现，虽然它并不直接用于大多数应用程序，但它是理解请求和响应的基础的一个良好开端。

GET 请求的基本日志记录

日志背后的想法是，我们将某种类型的数据写入某个持久数据存储中，以便我们可以在以后查看它。为了简单起见，我们先用console.log()写stdout。

有时记录到stdout不是一个选项，我们必须将记录数据发送到其他地方。就像在无服务器环境中运行时一样，其中的函数没有持久存储。

让我们尝试一个简单的服务器，它除了为每个请求发送空响应之外什么也不做，以说明如何获取可以记录的请求数据。

const http = require("http");

const server = http.createServer((request, response) => {
  console.log(request);
  response.end();
});

server.listen(8888); 

如果我们向 http://localhost:8888 发送一个请求，我们会看到一个巨大的对象被记录到stdout，它充满了实现细节，找到重要的部分并不容易。

让我们看看 Node.js 文档中的 IncomingMessage ，我们的请求是这个类的一个对象。

在这里我们能找到什么信息？

• headers和rawHeaders(无效/重复标题)
• httpVersion
• method
• url
• socket.remoteAddress(针对客户端 IP)

这对于 GET 请求应该足够了，因为它们通常没有主体。让我们更新我们的实现。

const server = http.createServer((request, response) => {
  const { rawHeaders, httpVersion, method, socket, url } = request;
  const { remoteAddress, remoteFamily } = socket;

  console.log(
    JSON.stringify({
      timestamp: Date.now(),
      rawHeaders,
      httpVersion,
      method,
      remoteAddress,
      remoteFamily,
      url
    })
  );

  response.end();
}); 

输出应该如下所示:

{  "timestamp":  1562331336922,  "rawHeaders":  [  "cache-control",  "no-cache",  "Postman-Token",  "dcd81e98-4f98-42a3-9e13-10c8401892b3",  "User-Agent",  "PostmanRuntime/7.6.0",  "Accept",  "*/*",  "Host",  "localhost:8888",  "accept-encoding",  "gzip, deflate",  "Connection",  "keep alive"  ],  "httpVersion":  "1.1",  "method":  "GET",  "remoteAddress":  "::1",  "remoteFamily":  "IPv6",  "url":  "/"  } 

对于我们的日志记录，我们只使用请求的特定部分。它使用 JSON 作为格式，所以这是一种结构化的日志记录方法，并且有时间戳，所以我们不仅知道谁请求了什么，还知道请求是何时开始的。

记录处理时间

如果我们想添加关于请求处理时间的数据，我们需要一种方法来检查请求何时完成。

当我们发送完响应时，请求就完成了，所以我们必须检查何时调用了response.end()。在我们的例子中，这相当简单，但有时这些结束调用是由其他模块完成的。

为此，我们可以看看 ServerResponse 类的文档。它提到了一个finish事件，当所有的服务器完成发送它的响应时，该事件被触发。这并不意味着客户收到了所有东西，但这表明我们的工作已经完成。

让我们更新我们的代码！

const server = http.createServer((request, response) => {
  const requestStart = Date.now();

  response.on("finish", () => {
    const { rawHeaders, httpVersion, method, socket, url } = request;
    const { remoteAddress, remoteFamily } = socket;

    console.log(
      JSON.stringify({
        timestamp: Date.now(),
        processingTime: Date.now() - requestStart,
        rawHeaders,
        httpVersion,
        method,
        remoteAddress,
        remoteFamily,
        url
      })
    );
  });

  process(request, response);
});

const process = (request, response) => {
  setTimeout(() => {
    response.end();
  }, 100);
}; 

我们将请求的处理传递给一个单独的函数来模拟负责处理它的另一个模块。由于setTimeout的原因，处理是异步发生的，所以同步日志记录不会得到想要的结果，但是finish事件通过在调用 response.end()之后触发来处理这个问题。

记录尸体

请求主体仍然没有被记录，这意味着 POST、PUT 和 PATCH 请求没有被 100%覆盖。

为了将主体也放入日志中，我们需要一种从请求对象中提取它的方法。

IncomingMessage 类实现了 ReadableStream 接口。当来自客户端的主体数据到达时，它使用该接口的事件发出信号。

• 当服务器从客户端接收到新的数据块时，触发data事件
• 发送完所有数据后，调用end事件
• 出问题时会调用error事件

让我们更新我们的代码:

const server = http.createServer((request, response) => {
  const requestStart = Date.now();

  let errorMessage = null;
  let body = [];
  request.on("data", chunk => {
    body.push(chunk);
  });
  request.on("end", () => {
    body = Buffer.concat(body);
    body = body.toString();
  });
  request.on("error", error => {
    errorMessage = error.message;
  });

  response.on("finish", () => {
    const { rawHeaders, httpVersion, method, socket, url } = request;
    const { remoteAddress, remoteFamily } = socket;

    console.log(
      JSON.stringify({
        timestamp: Date.now(),
        processingTime: Date.now() - requestStart,
        rawHeaders,
        body,
        errorMessage,
        httpVersion,
        method,
        remoteAddress,
        remoteFamily,
        url
      })
    );
  });

  process(request, response);
}); 

这样，当出现问题时，我们会记录一条额外的错误消息，并将正文内容添加到日志中。

注意:主体可能非常大和/或二进制，所以需要验证检查，否则数据量或编码可能会搞乱我们的日志。

记录响应数据

既然我们已经记录了请求，下一步就是记录我们的响应。

我们已经监听了响应的finish事件，所以我们有一个非常安全的方法来获取所有数据。我们只需要提取响应对象包含的内容。

让我们看看 ServerResponse 类的文档，看看它为我们提供了什么。

• statusCode
• statusMessage
• getHeaders()

让我们将它添加到代码中。

const server = http.createServer((request, response) => {
  const requestStart = Date.now();

  let errorMessage = null;
  let body = [];
  request.on("data", chunk => {
    body.push(chunk);
  });
  request.on("end", () => {
    body = Buffer.concat(body).toString();
  });
  request.on("error", error => {
    errorMessage = error.message;
  });

  response.on("finish", () => {
    const { rawHeaders, httpVersion, method, socket, url } = request;
    const { remoteAddress, remoteFamily } = socket;

    const { statusCode, statusMessage } = response;
    const headers = response.getHeaders();

    console.log(
      JSON.stringify({
        timestamp: Date.now(),
        processingTime: Date.now() - requestStart,
        rawHeaders,
        body,
        errorMessage,
        httpVersion,
        method,
        remoteAddress,
        remoteFamily,
        url,
        response: {
          statusCode,
          statusMessage,
          headers
        }
      })
    );
  });

  process(request, response);
}); 

处理响应错误和客户端中止

目前，我们只在响应finish事件被触发时记录日志，如果响应出错或者客户端中止请求，情况就不是这样了。

对于这两种情况，我们需要创建额外的处理程序。

const server = http.createServer((request, response) => {
  const requestStart = Date.now();

  let body = [];
  let requestErrorMessage = null;

  const getChunk = chunk => body.push(chunk);
  const assembleBody = () => {
    body = Buffer.concat(body).toString();
  };
  const getError = error => {
    requestErrorMessage = error.message;
  };
  request.on("data", getChunk);
  request.on("end", assembleBody);
  request.on("error", getError);

  const logClose = () => {
    removeHandlers();
    log(request, response, "Client aborted.");
  };
  const logError = error => {
    removeHandlers();
    log(request, response, error.message);
  };
  const logFinish = () => {
    removeHandlers();
    log(request, response, requestErrorMessage);
  };
  response.on("close", logClose);
  response.on("error", logError);
  response.on("finish", logFinish);

  const removeHandlers = () => {
    request.off("data", getChunk);
    request.off("end", assembleBody);
    request.off("error", getError);
    response.off("close", logClose);
    response.off("error", logError);
    response.off("finish", logFinish);
  };

  process(request, response);
});

const log = (request, response, errorMessage) => {
  const { rawHeaders, httpVersion, method, socket, url } = request;
  const { remoteAddress, remoteFamily } = socket;

  const { statusCode, statusMessage } = response;
  const headers = response.getHeaders();

  console.log(
    JSON.stringify({
      timestamp: Date.now(),
      processingTime: Date.now() - requestStart,
      rawHeaders,
      body,
      errorMessage,
      httpVersion,
      method,
      remoteAddress,
      remoteFamily,
      url,
      response: {
        statusCode,
        statusMessage,
        headers
      }
    })
  );
}; 

现在，我们也记录错误和中止。

当响应完成时，日志处理程序也被删除，所有的日志都被转移到一个额外的函数中。

记录到外部 API

目前，脚本只将日志写入控制台，在许多情况下，这就足够了，因为操作系统允许其他程序捕获stdout并使用它做自己的事情，比如写入文件或发送给第三方 API，比如 Moesif。

在某些环境中，这是不可能的，但是由于我们将所有信息收集到一个地方，我们可以用第三方函数替换对console.log的调用。

让我们重构代码，使其类似于一个库，并记录到一些外部服务。

const log = loggingLibrary({ apiKey: "XYZ" });
const server = http.createServer((request, response) => {
  log(request, response);
  process(request, response);
});

const loggingLibray = config => {
  const loggingApiHeaders = {
    Authorization: "Bearer " + config.apiKey
  };

  const log = (request, response, errorMessage, requestStart) => {
    const { rawHeaders, httpVersion, method, socket, url } = request;
    const { remoteAddress, remoteFamily } = socket;

    const { statusCode, statusMessage } = response;
    const responseHeaders = response.getHeaders();

    http.request("https://example.org/logging-endpoint", {
      headers: loggingApiHeaders,
      body: JSON.stringify({
        timestamp: requestStart,
        processingTime: Date.now() - requestStart,
        rawHeaders,
        body,
        errorMessage,
        httpVersion,
        method,
        remoteAddress,
        remoteFamily,
        url,
        response: {
          statusCode,
          statusMessage,
          headers: responseHeaders
        }
      })
    });
  };

  return (request, response) => {
    const requestStart = Date.now();

    // ========== REQUEST HANLDING ==========
    let body = [];
    let requestErrorMessage = null;
    const getChunk = chunk => body.push(chunk);
    const assembleBody = () => {
      body = Buffer.concat(body).toString();
    };
    const getError = error => {
      requestErrorMessage = error.message;
    };
    request.on("data", getChunk);
    request.on("end", assembleBody);
    request.on("error", getError);

    // ========== RESPONSE HANLDING ==========
    const logClose = () => {
      removeHandlers();
      log(request, response, "Client aborted.", requestStart);
    };
    const logError = error => {
      removeHandlers();
      log(request, response, error.message, requestStart);
    };
    const logFinish = () => {
      removeHandlers();
      log(request, response, requestErrorMessage, requestStart);
    };
    response.on("close", logClose);
    response.on("error", logError);
    response.on("finish", logFinish);

    // ========== CLEANUP ==========
    const removeHandlers = () => {
      request.off("data", getChunk);
      request.off("end", assembleBody);
      request.off("error", getError);

      response.off("close", logClose);
      response.off("error", logError);
      response.off("finish", logFinish);
    };
  };
}; 

有了这些改变，我们现在可以像使用 Moesif-Express 一样使用我们的日志实现了。

loggingLibrary函数将 API-key 作为配置，并返回实际的日志记录函数，该函数将通过 HTTP 将日志数据发送到日志记录服务。日志记录函数本身接受一个request和response对象。

结论

登录 Node.js 并不像人们想象的那样简单，尤其是在 HTTP 环境中。JavaScript 异步处理许多事情，所以我们需要挂钩正确的事件，否则，我们不知道发生了什么。

幸运的是，有许多日志库，所以我们不必自己编写一个。

以下是一些例子:

• 班扬-https://github.com/trentm/node-bunyan
• 调试-https://github.com/visionmedia/debug
• log4js-https://github.com/log4js-node/log4js-node
• 摩根 https://github.com/expressjs/morgan 公司
• NPM log-https://github.com/npm/npmlog
• 温斯顿-https://github.com/winstonjs/winston