Moesif-博客中文翻译-二-
Moesif 博客中文翻译（二）
原文：Moesif Blog
我们如何从一个带有 Chrome 扩展的网站标签中捕获 AJAX 请求
背景
我以为会有很多 Chrome 扩展来监控来自 AJAX 调用的 HTTP 请求，但是我们发现的少数几个(比如 Postman Intercept Chrome 扩展)似乎只捕捉请求而不捕捉响应。尽管 Chrome DevTools 有网络选项卡，但很难与队友分享这些捕获的 HTTP 跟踪。
我们的工程师在前端和后端之间划分了职责，因此在调试 API 问题时，我们必须不断地将 HTTP 头和 JSON 有效负载从 DevTools 复制/粘贴到电子邮件或 Slack 中。发送多兆字节 *。har 文件通过 Slack 也一样麻烦。除了不容易共享之外，在 Chrome DevTools 中检查 HTTP 流量也不理想，因为没有简单的方法来过滤 API 调用或检查 JSON 有效负载。网络标签是为传统的 HTML 网站设计的，而不是现代的返回 JSON 的单页应用和 API。
由于这个时间下沉，我们决定构建一个 Chrome 扩展,使得从任何网站捕获和调试这些 AJAX 请求(和响应)变得非常容易。该扩展是为 REST APIs 设计的，比如那些支持单页面应用程序的 API。然而，由于 Chrome API 的局限性，需要一些猴子业务来捕获 Chrome 扩展 API。
WebRequest 方法的问题
Chrome WebRequest API 是 Chrome API 扩展集的一部分。
最初，我查看了 Chrome 的 WebRequest APIs，以便从打开的浏览器标签中捕获 API 调用。我们之前为我们的 CORS 和起源改变者利用了这些 API。这似乎是获取数据最自然的地方。
然而，我们遇到了一个 bug，WebRequest API 没有公开一个接口来读取响应体。见铬的问题。
虽然我们对缺少响应主体 getters 感到惊讶，但我们现在理解了为什么大多数其他扩展不能捕获响应的可能原因。我们的要求是捕捉响应，以便与团队成员共享。如果没有响应，调试会很痛苦，解决问题也会很慢。
XmlHttpRequest 事件侦听器方法
由于所有浏览器都使用 XmlHttpRequest 进行 AJAX 调用，我利用这一点通过 monkey 补丁来监控 API 调用。
有几个 XmlHttpRequest 侦听器可以挂钩到:
- 负载启动
- 进步
- 流产
- 错误
- 负荷
- 超时
- 装载的；子弹上膛的
- readystatechange
从侦听器回调中，我可以获得事件目标，也就是 XmlHttpRequest 对象本身。查看 XmlHttpRequest api 文档，我意识到它有与 WebRequest API 完全相反的问题。该对象具有获取 HTTP 响应而不是原始请求的接口。有一个setRequestHeaders()，但是没有 getter 方法与之配对来获取请求 HTTP 头。事实上，它甚至没有一个公共方法或属性来获取原始的 URL 或路径。
XmlHttpRequest 猴子补丁。
为了真正监控所有数据(即请求头/正文和响应头/正文)，我必须对其进行 monkey 修补。猴子补丁允许我们记录数据。
修补的主要方法有
- 每当发起一个新的 AJAX 调用时，这个方法就会被调用，然后我可以捕获这个方法和 url。
- 当请求头被设置时，这个方法被调用。我可以给它打补丁，这样每次调用这个方法时，我都会把头保存为 hash。
- 此方法用于将数据作为请求的一部分发送。我可以从这个补丁中捕获请求体。
现在，我可以简单地添加addEventListener('load', event)来捕获响应数据。
网上有一些资源，比如本文解释了如何打猴子补丁。
执行环境
代码准备好进行猴子修补后，我们必须执行它。 Chrome 扩展标签 API 有一个执行代码的方法:executeScript()。然而，executeScript()执行的代码与网页上的代码在不同的上下文中执行，网页上的代码是 AJAX 调用的地方。这意味着猴子补丁不会对开放网站产生任何影响。
要了解关于执行环境如何工作的更多信息，请参见关于内容脚本的视频。
解决方案:注入脚本
由于孤立的上下文，我不得不采取不同的方法来成功地猴子补丁网站。我不得不使用chrome.tabs.executeScript()来创建一个<script>标签，注入到网站中，它将在网站的上下文中加载猴子补丁代码。
const actualCode = `
var s = document.createElement('script');
s.src = ${resourceUrl};
s.onload = function() {
this.remove();
};
(document.head || document.documentElement).appendChild(s);
`;
chrome.tabs.executeScript(tabId, {code: actualCode, runAt: 'document_end'}, cb);
有几种方法可以将代码添加到脚本标记中。因为我们还想添加一些不错的 UI 元素，所以我们决定将 monkey 补丁代码和 UI 相关代码放入一个脚本文件中，这个脚本文件与resourceUrl链接。如果这样做，请确保将资源 url 添加到清单中的web_accessible_resource。关于网络无障碍资源的更多信息
我们忽略的已知问题
CSS 泄漏
由于代码是作为网页的一部分运行的，所以我们生成的 UI 会受到页面上已经存在的 CSS 的影响。我们使用 React 和 Material-UI 库，它使用内联样式来最小化 CSS 泄漏。然而，CSS 泄露仍然会在一些网站上发生。
内容安全策略:content-src
内容安全政策是另一个问题。如果content-src设置得非常严格，比如在GitHub.com上，那么它可以阻止对不在白名单中的服务器的 AJAX 调用。由于我们想要记录和存储从 ApiRequest.io 上的可共享工作区链接中检索的 API 调用，所以我们需要发布到我们自己的 API。这使得 HTTP 跟踪可以保存 30 天，作为以后调试时的参考。
Chrome 扩展执行环境并不完全受此限制。有一个修改内容安全策略的解决方案，将作为单独的文章发布。
目前，除了 GitHub 和 Twitter 等几个大网站之外，许多网站都没有使用如此严格的内容安全政策。我们假设，如果你正在使用我们的 Chrome 扩展，那么它很可能在你自己的网站上使用。如果是这样，那么您可以暂时关闭该限制。如果您对我们的 Chrome 扩展有任何问题或功能要求，请发送电子邮件给我们。
更新:内容安全策略问题已解决
现在 Apirequest.io Chome 扩展可以在具有严格内容安全策略的网站上工作。我们创建了另一篇关于如何围绕内容安全策略工作的文章，它也对 Chrome 扩展的不同执行环境进行了更深入的解释。
结束语
我很喜欢创建这个 Chrome 扩展，所以我希望你喜欢使用它。和往常一样，对于使用扩展时的任何功能请求或问题，只需通过给我们发电子邮件让我们知道。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
HTTP-API 与 React 生命周期方法和挂钩的集成
原文：https://www.moesif.com/blog/technical/HTTP-API-Integration-with-React-Lifecycle-Methods-and-Hooks/
为什么
当我们创建单页面应用程序(SPA)时，我们经常需要集成 API。有时是第三方 API，但至少是我们自己的后端来获取我们需要显示的数据。这些 API 基于 HTTP 或 WebSocket 协议，每种协议都有自己的连接建立和拆除要求。
在本文中，我解释了 HTTP APIs 的基本集成。
什么
HTTP 是一种无状态协议。这是从服务器获取数据的最简单的方法。
有时 HTTP 请求会失败，有时我们会取消请求，因为数据还没有到达，但已经不再需要了。
生命周期方法
生命周期方法是具有特殊名称的组件方法，由 React 对特定事件进行调用。
例如，componentDidMount将在 React 渲染一个组件到 DOM 后被调用。
钩住
钩子是 React 的一个新的部分，它允许我们做我们用生命周期方法做的事情，但是不需要创建一个组件类，它们只和功能组件一起工作。
例如，每次 React 渲染一个组件时，都会调用提供给useEffect钩子函数的回调。
怎么
首先，让我们通过生命周期方法进行集成。
生命周期方法
为了使用生命周期方法，我们需要创建一个具有三种方法的类组件，render、componentDidMount和componentWillUnmount。
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
loading: true,
data: null,
error: null
};
}
async componentDidMount() {
this.abortController = new AbortController();
try {
const response = await fetch(API_URL, {
signal: this.abortController.signal
});
if (response.status >= 300)
throw new Error(response.statusText);
const data = await response.json();
this.setState({ loading: false, data });
} catch (e) {
if (e.name != "AbortError") this.setState({ error: e.message });
}
}
componentWillUnmount() {
this.abortController.abort();
}
render() {
const { data, error, loading } = this.state;
if (!!error) return <h2>{error}</h2>;
if (loading) return <h2>Loading...</h2>;
return <h2>{data}</h2>;
}
}
让我们一步一步来。
1 -定义constructor中的状态
对于 HTTP 请求，我们需要三种状态。loading、data和error。
2 -在componentDidMount生命周期方法中启动请求
我们在这里使用异步函数，所以我们可以用await处理fetch函数的承诺。
首先，我们需要定义一个允许我们取消 HTTP 请求的 AbortController 。然后我们称try块中的fetch为await块中的response。
我们还将abortController的signal传递给 fetch 调用，用请求连接控制器。当我们调用abortController的abort方法时，这个信号用来取消请求。
如果我们请求的status不是错误代码，我们假设数据已经准备好被解析；我们将它添加到我们的状态，并将loading设置为false。
如果fetch调用抛出一个错误，我们从服务器得到一个错误代码，或者abortController的abort方法被调用，我们catch这个错误并呈现一个错误。
3 -在componentWillUnmout生命周期方法中取消请求
因为我们保存了对abortController到this的引用，所以我们可以在componentWillUnmount方法中使用它。React 在组件从 DOM 中移除之前调用这个方法。
对abort的调用导致对fetch承诺的拒绝。
在catch块中，如果错误不是AbortError，我们只调用setState方法，因为我们知道 React 会从 DOM 中删除我们的组件。
4 -渲染不同的状态
最后，我们必须渲染不同的状态。主要的逻辑在生命周期方法中，所以render方法不再需要太多的逻辑。
钩住
要使用钩子，我们必须创建一个功能组件。在这个函数中，我们必须使用两个钩子，useState用来存储我们的状态，useEffect用来处理 API 调用。
function MyComponent() {
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
const [data, setData] = useState(null);
useEffect(async () => {
const abortController = new AbortController();
try {
const response = await fetch(API_URL, {
signal: abortController.signal
});
if (response.status >= 300)
throw new Error(response.statusText);
const data = await response.json();
setData(data);
setLoading(false);
} catch (e) {
if (e.name != "AbortError") setError(e.message);
}
return () => abortController.abort();
}, []);
if (!!error) return <h2>{error}</h2>;
if (loading) return <h2>Loading...</h2>;
return <h2>{data}</h2>; }
1 -首先用useState挂钩设置状态
useState钩子接受一个初始值，并返回一个新的状态变量和一个 setter 函数。每次调用 setter 时，它将导致 React 使用状态变量中的新值重新呈现组件。
2 -用useEffect钩子开始请求
useEffect钩子接受一个回调，每当 React 呈现组件时(例如，当我们调用 setter 函数时)调用这个回调。
当我们将一个空数组作为第二个参数传递给useEffect时，回调只在第一次渲染后执行。这允许我们模拟componentDidMount生命周期方法的行为。
回调中的逻辑与生命周期方法示例中的逻辑基本相同。主要的区别是缺少了this，因为我们没有类组件，并且我们使用了useState钩子的设置器。
3 -用返回的函数取消请求
我们从提供给useEffect钩子的回调中返回的函数在组件从 DOM 中移除之前被执行。这允许我们模拟componentWillUnmout生命周期方法的行为。
我们调用abortController的abort方法并完成。
4 -渲染不同的状态
为了渲染，我们可以使用由useState钩子返回的状态变量。大部分逻辑都在我们传递给useEffect的回调函数中，所以这里没什么要做的。
API 分析和监控
顺便说一句，如果你对如何将 API 分析添加到你的 React SPA 中感到好奇，看看这个例子。
结论
将 API 调用集成到 React 组件中的两种方式主要取决于个人喜好。有些人更喜欢面向对象的方法；其他人希望更实用。React 允许您选择任何一种方式，都允许错误处理和取消。
在您的 API *台中实现 HIPAA 技术保护
健康保险可携带性和责任法案(简称 HIPAA)是一套关于在信息系统中处理健康相关数据的法律。它定义了安全措施，即您在为客户处理健康数据时必须遵循的规则。
有三种保护类别:
- 管理保护措施，涵盖您公司的人员和流程
- 物理保护，涉及运行处理健康数据的软件的硬件
- 技术保护，软件必须实现的要求
如果您希望您的 API 符合 HIPAA，那么这三个类别都必须正确处理。在另一篇文章中，我们介绍了这些关键需求以及如何构建符合 HIPAA 标准的 API *台。在本文中，我们将深入探讨如何实现技术安全措施的具体细节。
有九种技术安全措施，其中四种是必需的，五种是可解决的。在任何情况下都必须实施必要的保障措施；如果合理的话，应该实施可寻址的安全措施。如果您不能实现可寻址的安全措施，您需要记录原因并解释为什么没有实现它们——这在数据泄露的情况下非常重要。
虽然物理安全不是本文的主题，但是请记住，您需要将您的基础设施托管在符合 HIPAA 的提供商处。否则，有可能通过物理访问服务器来绕过某些技术保护措施。如果您计划内部部署，您需要自己遵循物理安全措施。
所需的技术保障
让我们从四个必需的安全措施开始。从技术角度来看，这些是符合 HIPAA 的最低要求。
唯一用户标识
系统的每个用户都需要有一个唯一的标识符。以便系统上的每个操作都可以追溯到执行该操作的用户。
一种简单的方法是使用通用唯一标识符(UUID)。每种主要的编程语言都有一个用于创建 UUID 的库。UUID 生成器遵循标准化的算法来创建全球唯一的字符串，而无需中央权威机构。
符合 HIPAA 的托管认证服务，如 AWS Cognito ，将为您完成这项工作。Cognito 用户池将在注册时给每个新用户一个唯一的 ID。
如果您必须自己实现唯一用户标识，您可以在这里找到 UUID 的实现:
紧急进入程序
您将需要一种在紧急情况下访问受保护的医疗保健数据的方法。在这种情况下，紧急情况意味着你的系统或应用程序发生了不好的事情。例如，你的电力中断了，或者你受到了网络攻击。在这种情况下，需要通过一种替代方式来访问数据。
要实现这种紧急访问，您需要解决两个问题。第一种是某种类型的异地备份，即使您的数据中心被夷为*地，它也能让您访问数据。第二个是一个警报系统，通知你紧急情况正在发生。
对于托管数据库，比如 Amazon DynamoDB，这意味着您需要为您的表激活时间点恢复。一旦打开，最* 35 天的表格数据每五分钟备份一次，并且可以恢复。
如果您用 CloudFormation 定义您的表，您只需要为此添加两个属性:
Type: 'AWS::DynamoDB::Table'
Properties:
TableName: phiTable
PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true
对于其他著名的数据库，您可以在下面找到如何设置备份的指南:
审计控制
审计控制就是记录谁访问了医疗保健数据。它与唯一用户标识协同工作。如果您被审计，您将需要让审计员查看审计日志数据，以向他们显示一切都被正确跟踪。
一种简单的方法是为医疗保健数据建立专用的数据存储，并记录所有访问。这样，您就可以确保在您的应用程序中添加新功能时，没有开发人员会忘记实现日志记录。此外，当您将医疗保健数据与非医疗保健数据一起存储时，您不会有太多的审计日志。
另一种方法是实现事件源。在这种数据架构模式中，您只将更改保存在一个不可变的列表中，并动态地生成表。这样，三次更新实际上是事件源数据库中的三条记录，而不仅仅是最终结果。您可以看到数据在每个时间点发生了什么变化，以及是谁导致了这些变化。
您可以在以下位置找到有关如何为重要数据库启用访问日志的信息:
证明
对所有用户进行身份验证，这样就不会发生匿名访问医疗保健数据的情况。最佳做法是在任何可能访问医疗保健数据的地方使用密码和多因素身份认证。如果用户的身份认证因素之一被盗，例如解锁的智能手机，他们需要能够证明他们后来没有访问过受保护的数据。
使用像 AWS Cognito 这样的托管服务可以节省您的时间，因为它开箱即符合 HIPAA 标准。 Auth0 和 Okta 也是非常好的托管认证服务，它们也符合 HIPAA。
对于您自己的实现，您可以在下面找到主要 API *台的身份验证库:
- 快递
- 姜戈
- [ASP.NET](Core https://docs.microsoft.com/en-gb/aspnet/core/security/)
- Spring Boot
可解决的技术安全措施
可寻址的技术安全措施代表了 HIPAA 要求的大部分，尽管只有 52%的微弱多数。严格地说，它们是可选的，但是您应该将它们的“可寻址”本质视为安全措施，允许实现上的一些灵活性。
事实上，你可以实现，找到一个替代方案来完成同样的目标，或者不实现。如果您选择不实施，您需要记录下原因，并可能在进一步实施之前咨询审计专家/律师。
自动注销
保持您的用户会话尽可能短，并自动注销。基本的想法是，如果有人在登录后离开他们的设备，它可能会被未经授权的人使用。如果您在用户在线一两分钟不活动后将其注销，发生未授权访问的几率会降低。
要做到这一点，您需要降低 API 连接的会话超时。客户端可以自动请求新的会话令牌，所以与 GUI 应用程序相比，这通常不是什么大问题。使用 GUI，用户必须手动重新登录。
加密和解密
所有医疗保健数据都应加密，仅在需要时解密。这意味着静态加密，比如在您的服务器或用户设备上。这也意味着当数据通过网络传输时要加密。原因很明显——如果数据是加密的，窃取数据不会帮助攻击者。
虽然 HIPAA 规定的加密要求是技术中立的，但是您应该尽可能合理地加密数据。这意味着 ROT13 是不够的，但一次性垫是多余的。检查您的技术提供了哪些最先进的加密机制，并坚持使用。
同样，AWS DynamoDB 等托管服务会自动加密您的静态数据。
您的 API 应该强制所有连接都使用 SSL。使用严格传输安全头通知您的客户使用 SSL。如果协议是 HTTP，不要传递任何数据，它应该只通过 HTTPS 用位置头和一个 3XX 状态码重定向。也许，在正文中给出一些“不支持 HTTP”的信息。
如果您不能加密数据，但是有其他机制可以阻止对数据的访问，那么您应该记录下来。
认证 ePHI 的完整性控制和机制
您需要一种方法来确保医疗保健数据不会以未经授权的方式被更改或破坏。
这意味着您需要检查数据的完整性，例如，使用校验和或数字签名。如果经过身份验证的用户签署了更改的数据，那么未经授权的用户所做的任何后续更改都将是显而易见的。
为了防止未经授权的数据破坏，您必须实现一个不会同步未经授权用户数字签名的更改的备份。如果恶意用户删除数据，它要么会显示在审核日志中，要么删除不会传播到备份。
同样，事件源可以是解决方案。因为数据永远不会被隐式删除，所有的更改都会被设计记录下来。
如何从其他 API 访问 ePHI 数据？
如果您自己的数据已经符合 HIPAA，第三方 API 不是大问题，但是如果您不符合 HIPAA，它会导致额外的成本。
当您想要使用来自第三方 API 的 ePHI 数据时，如 EPIC ，您还需要应用安全措施。并非所有由 ePHI API 交付的数据都在 HIPAA 的保护之下，但是如果您请求的数据在 HIPAA 的保护之下，您就需要实现它。这还包括本文中没有提到的物理和管理保护措施。
Moesif 如何符合 HIPAA？
Moesif 提供了一个安全代理，您可以将它托管在自己的基础设施上。这个代理将在把你的数据发送给 Moesif 之前对其进行加密，并在显示给你之前对其进行解密，所有这些都是用你自己的私人加密密钥完成的。主加密密钥从不存储在 Moesif 服务器上；相反，安全代理支持流行的密钥存储并自动处理密钥轮换。
最后，Moesif 永远不会看到你的未加密的 ePHI 数据。
这种方法也是您可以在自己的 API 中记住的。如果客户想要向您发送他们的 ePHI 数据，告诉他们应该首先加密这些数据，或者向他们提供您自己的安全代理，他们可以在自己的基础架构上托管这些数据。
摘要
如果你想实现一个 HIPAA 兼容的 API，你最好的做法是实现所有的安全措施，甚至是可选的。今天就降低你的风险，避免以后不舒服的技术和可能的法律问题。
一些安全措施实际上是分层的，例如，实现唯一的用户标识符将遵循独立的身份验证。加密和解密也是如此，两者都被认为是独立的安全措施，但实际上是一起工作的。
此外，备份、身份验证和加密是保护您整个企业的良好实践，而不仅仅是您可能持有的与健康相关的数据。因此，您的 API 很有可能已经具备了大部分保护措施。
你也应该去看看像 AWS、Azure 或 GCP 这样的云提供商提供的托管服务。通常，这些提供商已经做了大量的工作来满足要求，您只需选择配置正确的资源。
AWS Lambda 和 AWS API 网关无服务器 API 深度指南(第 1 部分)
TL；带有示例项目的 DR 库可以在GitHubT3】上找到
围绕 API 构建软件产品是多年来的事情，从一开始就使用无服务器技术似乎很有意思，原因有很多——按需定价、自动伸缩和更少的运营开销。
为什么
当我读到人们谈论无服务器技术时，我感觉还有许多问题没有解决。
如何
- 使用查询字符串还是路由参数？
- 使用 POST 请求的参数或正文？
- 设置 HTTP 状态码？
- 设置回复标题？
- 从一个 Lambda 调用一个 Lambda？
- 为第三方 API 存储密钥？
所以我决定写一篇关于如何用无服务器技术构建 API 的文章，特别是 AWS Lambda 和 API-Gateway。
这篇文章分为两部分。
第一个是关于架构、设置和认证的。
第二个是关于实际的工作，上传图片，用第三方 API 给它们加标签，然后检索标签和图片。
什么
我们将构建一个简单的 RESTful 图像标记 API。它让我们上传图片，用名为 Clarifai 的第三方 API 自动标记它们，并将标记和图片名称存储到 Elasticsearch 中。
我心目中的工作流程是:
- 注册并登录
- 上传图像
- 获取所有图像的所有标签
- 获取所有图像及其标签
- 通过标签获取图像
怎么
对于 API，我们使用 API-Gateway，这是 Amazons 的全方位无服务器 HTTP 解决方案。它针对 RESTful APIs 进行了优化，是我们系统的入口点。
Amazon Cognito 处理认证。Cognito 是一个托管的无服务器认证、授权和数据同步解决方案。我们用它来注册我们的用户，因此我们不必在这里重新发明轮子。
我们 API 的实际计算工作由 AWS Lambda 完成，这是一个功能即服务解决方案。Lambda 是一个无服务器的基于事件的系统，允许在发生事情时触发功能，例如，一个 HTTP 请求击中了我们的 API，或者有人直接上传了一个文件到 S3。
这些图像被储存在亚马逊 S3 的一个桶里。S3 是一种无服务器的基于对象的存储解决方案。它允许通过 HTTP 直接访问和上传文件，并且可以作为 API 网关，成为λ的事件源。
标签数据和相应的图像名称存储在亚马逊弹性搜索服务中；一个 AWS 管理的 Elasticsearch 版本。遗憾的是，这不是无服务器的，而是构建在 EC2 实例上的，但是前 12 个月有一个免费层。Elasticsearch 是一个非常灵活的文档存储，并带有一个强大的查询语言。
一项名为 Clarifai 的非 AWS 服务提供了图像识别魔法。AWS 对此有其服务，称为 Rekognition，但通过使用 Clarifai，我们可以了解如何存储第三方 API 密钥。
我们构建的整个基础设施由 AWS SAM 、无服务器应用模型管理。SAM 是 AWS CloudFormation 的扩展，它减少了设置 AWS Lambda 和 API 网关资源所需的一些样板代码。
我们使用 AWS Cloud9 作为 IDE，因为它预装了使用 AWS 资源的所有工具和权限。
先决条件
- 浏览器
- Cloud9 环境下的 AWS 帐户。(设置可以在这里找到中的前 5 步。)
- 基本的 JavaScript 知识
- 基本的 Lambda、API 网关和 SAM 知识
设置
让我们从一个基本的无服务器 API 开始，它只是在 AWS SAM、API-Gateway 和 Cognito 的帮助下实现一个登录。
mkdir serverless-api
cd serverless-api
mkdir functions
touch template.yaml
首先，我们创建文件夹结构和一个template.yaml文件，该文件包含我们用 SAM 创建的基础设施的定义。
实现 SAM 模板
我们的 SAM 模板的内容如下:
AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::Serverless-2016-10-31"
Description: "An example REST API build with serverless technology"
Globals:
Function:
Runtime: nodejs8.10
Handler: index.handler
Timeout: 30
Tags:
Application: Serverless API
Resources:
ServerlessApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Cors: "'*'"
Auth:
DefaultAuthorizer: CognitoAuthorizer
Authorizers:
CognitoAuthorizer:
UserPoolArn: !GetAtt UserPool.Arn
GatewayResponses:
UNAUTHORIZED:
StatusCode: 401
ResponseParameters:
Headers:
Access-Control-Expose-Headers: "'WWW-Authenticate'"
Access-Control-Allow-Origin: "'*'"
WWW-Authenticate: >-
'Bearer realm="admin"'
# ============================== Auth =============================
UserPool:
Type: AWS::Cognito::UserPool
Properties:
UserPoolName: ApiUserPool
LambdaConfig:
PreSignUp: !GetAtt PreSignupFunction.Arn
Policies:
PasswordPolicy:
MinimumLength: 6
UserPoolClient:
Type: AWS::Cognito::UserPoolClient
Properties:
UserPoolId: !Ref UserPool
ClientName: ApiUserPoolClient
GenerateSecret: no
PreSignupFunction:
Type: AWS::Serverless::Function
Properties:
InlineCode: |
exports.handler = async event => {
event.response = { autoConfirmUser: true };
return event;
};
LambdaCognitoUserPoolExecutionPermission:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
FunctionName: !GetAtt PreSignupFunction.Arn
Principal: cognito-idp.amazonaws.com
SourceArn: !Sub "arn:${AWS::Partition}:cognito-idp:${AWS::Region}:${AWS::AccountId}:userpool/${UserPool}"
AuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/auth/
Environment:
Variables:
USER_POOL_ID: !Ref UserPool
USER_POOL_CLIENT_ID: !Ref UserPoolClient
Events:
Signup:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signup
Method: POST
Auth:
Authorizer: NONE
Signin:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signin
Method: POST
Auth:
Authorizer: NONE
Outputs:
ApiUrl:
Description: The target URL of the created API
Value: !Sub "https://${ServerlessApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/"
Export:
Name: ApiUrl
首先，我们定义一个 ServerlessApi 资源。在 SAM 模板中，该资源通常是为我们隐式创建的，但是当我们想要启用 CORS 或使用授权者时，我们需要显式定义它。
我们还将所有路由的默认授权者设置为 CognitoAuthorizer，然后立即使用我们稍后在模板中定义的 Cognito user pool 对其进行配置。
然后我们定义一个UNAUTHORIZED网关响应，因为 API-Gateway 不会自己给我们的响应添加 CORS 头。在我们的 Lambda 支持的路由中，我们可以通过 JavaScript 代码来实现，但是当我们没有权限调用它们时，这没有用。网关响应是用 API-Gateway 直接添加头的一种方式。
接下来，我们定义与认知相关的资源:
UserPool是 Cognito 的一部分，保存着我们用户的账户。UserPoolClient是 Cognito 的一部分，允许与用户池进行编程交互。PreSignupFunction是一个 Lambda 函数，在实际注册用户池之前调用。它允许我们激活用户，而无需向他们发送电子邮件。它只有几行代码，所以我们内联它。LambdaCognitoUserPoolExecutionPermission授予被管理的认知服务执行我们的PreSignupFunction的许可。
最后，我们定义一个 Lambda 函数，由 API-Gateway routes 调用。具体来说就是POST /signup和POST /signin。这个AuthFunction还获取用户池 ID 和用户池客户机 ID 作为环境变量。这些值是在部署时动态生成的，但是环境变量是将这些值从 SAM/Cloudformation 传递到函数中的一种方式。
用我们设置在顶部的Global/Function/Handler和我们的AuthFunction属性中的CodeUri，我们可以决定我们的 JavaScript 文件必须在哪里，以及它必须如何为 Lambda 导出一个处理函数。
...
Handler: index.handler
...
CodeUri: functions/auth/
该文件必须被称为index.js，它必须导出一个名为handler的函数，它必须在functions/auth/目录中。
端点定义的Auth属性被设置为Authorizer: NONE，因此 API-Gateway 允许我们请求端点而不需要令牌。
在文件的末尾，我们有一个名为ApiUrl的输出；我们在部署之后使用它从 CloudFormation 获取实际的 API URL。
实现 Auth Lambda 函数
我们一开始就创建了functions目录，所以我们只需要添加一个带有index.js的auth目录
index.js包含以下代码:
const users = require("./user-management");
exports.handler = async event => {
const body = JSON.parse(event.body);
if (event.path === "/signup") return signUp(body);
return signIn(body);
};
const signUp = async ({ username, password }) => {
try {
await users.signUp(username, password);
return createResponse({ message: "Created" }, 201);
} catch (e) {
console.log(e);
return createResponse({ message: e.message }, 400);
}
};
const signIn = async ({ username, password }) => {
try {
const token = await users.signIn(username, password);
return createResponse({ token }, 201);
} catch (e) {
console.log(e);
return createResponse({ message: e.message }, 400);
}
};
const createResponse = (
data = { message: "OK" },
statusCode = 200
) => ({
statusCode,
body: JSON.stringify(data),
headers: { "Access-Control-Allow-Origin": "*" }
});
它需要一个user-management.js来完成它的工作，但是我们稍后再讨论这个。首先，让我们看看这个文件做什么。
正如我们在template.yaml中所说的，它导出一个handler函数，当有人向/signup或/signin端点发送 POST 请求时，该函数从 API-Gateway 接收 HTTP 请求事件。
这里我们可以看到一个最常见问题的答案。
如何访问请求正文？
exports.handler = async event => {
const body = JSON.parse(event.body);
...
};
JavaScript Lambda 函数的第一个参数包含一个事件对象。当使用 API-Gateway 事件调用该函数时，该对象有一个body属性，如果客户端发送了一个请求，该属性保存请求体的字符串。
在我们的例子中，我们期望一个带有username和password的 JSON，这样我们就可以创建新的用户帐户或者让用户登录他们的帐户，所以我们需要首先JSON.parse()主体。
接下来，我们有两个函数，signUp和signIn，它们使用所需的user-management模块，这里称为users来完成它们的工作。它们都是作为参数传递的username和password。
createResponse是一个构建响应对象的实用函数。这个对象是 Lambda 函数必须返回的。
在这里，我们从一开始就有了其他问题的答案。
如何设置 HTTP 状态码？
exports.handler = async event => {
...
return { statusCode: 404 };
};
每个 Lambda 函数都需要返回一个响应对象。该对象必须至少有一个statusCode属性。否则，API-Gateway 认为请求失败。
如何设置 HTTP 响应头？
exports.handler = async event => {
...
return {
statusCode: 200,
headers: {
"Access-Control-Allow-Origin": "*"
}
};
};
我们的 Lambda 函数必须返回的响应对象也可以有一个headers属性，它必须是一个以头名称作为对象键，以头值作为对象值的对象。
在这里，我们可以看到，我们需要手动设置 CORS 标头。否则，浏览器不会接受响应。
现在，让我们看看我们需要的user-management.js文件。
global.fetch = require("node-fetch");
const Cognito = require("amazon-cognito-identity-js");
const userPool = new Cognito.CognitoUserPool({
UserPoolId: process.env.USER_POOL_ID,
ClientId: process.env.USER_POOL_CLIENT_ID
});
exports.signUp = (username, password) =>
new Promise((resolve, reject) =>
userPool.signUp(username, password, null, null, (error, result) =>
error ? reject(error) : resolve(result)
)
);
exports.signIn = (username, password) =>
new Promise((resolve, reject) => {
const authenticationDetails = new Cognito.AuthenticationDetails({
Username: username,
Password: password
});
const cognitoUser = new Cognito.CognitoUser({
Username: username,
Pool: userPool
});
cognitoUser.authenticateUser(authenticationDetails, {
onSuccess: result => resolve(result.getIdToken().getJwtToken()),
onFailure: reject
});
});
首先，我们使用node-fetch包来填充fetch浏览器 API。这个 polyfill 是我们接下来需要的amazon-cognito-identity-js包所需要的，它为我们做了与 Cognito 服务对话的繁重工作。
我们在从 SAM 模板获得的环境变量的帮助下创建一个CognitoUserPool对象，并在我们导出的signIn和signUp函数中使用这个对象。
最激动人心的部分是在signIn函数中，它从 Cognito 用户池中获取一个 ID 令牌并返回它。
这个令牌需要在对我们的 API 的每个请求上，在带有前缀Bearer的Authorization请求头中传递，并且当它过期时需要重新获取。我们的 SAM 模板的 API 配置中的 CognitoAuthorizer 告诉 API-Gateway 如何用 Cognito 处理其他所有事情。
现在我们需要安装我们使用过的包。node-fetch polyfill 包和amazon-cognito-identity-js包。
为此，我们需要进入functions/auth目录并初始化一个 NPM 项目，然后安装软件包。
npm init -y
npm i node-fetch amazon-cognito-identity-js
当我们用剩下的 API 将函数部署到 Lambda 时，functions/auth目录中的所有文件都被上传到 S3。
部署 API
为了将我们的项目部署到 AWS，我们使用了sam CLI 工具。
首先，我们需要打包我们的 Lambda 函数源代码，并将其上传到 S3 部署桶。我们可以用aws CLI 创建这个 bucket。
aws s3 mb s3://<DEPLOYMENT_BUCKET_NAME>
桶名必须是全局唯一的，所以我们需要发明一个。
当创建成功时，我们需要DEPLOYMENT_BUCKET_NAME到package我们的 Lambda 源。
sam package --template-file template.yaml \
--s3-bucket <DEPLOYMENT_BUCKET_NAME> \
--output-template-file packaged.yaml
这个命令创建了一个packaged.yaml文件，其中保存了我们在 S3 上打包的 Lambda 源代码的 URL。
接下来，我们需要使用 CloudFormation 进行实际部署。
sam deploy --template-file packaged.yaml \
--stack-name serverless-api \
--capabilities CAPABILITY_IAM
如果一切顺利，我们使用下面的命令来获取 API 的基本 URL。
aws cloudformation describe-stacks \
--stack-name serverless-api \
--query 'Stacks[0].Outputs[?OutputKey==`ApiUrl`].OutputValue' \
--output text
该 URL 应该如下所示:
https://<API_ID>.execute-api.<REGION>.amazonaws.com/Prod/
这个 URL 现在可以用来向我们创建的/signup和/signin端点发出 POST 请求。
结论
本文是关于在 AWS 上创建无服务器 API 的两篇文章中的第一篇。我们讨论了这样做的动机、我们完成工作所需的 AWS 服务，并在 AWS Cognito 的帮助下实现了基于令牌的身份验证。
我们还回答了一些用 API-Gateway 和 Lambda 构建 API 时出现的最紧迫的问题。
在下一部分中，我们实现了两个 Lambda 函数，它们允许我们使用 API。
ImagesFunction负责创建 S3 存储桶的上传链接。TagsFunction处理 S3 上传、第三方 API 集成和已创建标签的列表。
AWS Lambda 和 AWS API 网关无服务器 API 深度指南(第 2 部分)
TL；带有示例项目的 DR 库可以在GitHubT3】上找到
这是关于用 AWS 技术构建无服务器 API 的两部分系列的最后一篇文章。
在第一部分中，我们学习了认证、请求体、状态码、CORS 和响应头。我们建立了一个连接 API-Gateway、Lambda 和 Cognito 的 AWS SAM 项目，这样用户就可以注册并登录。
在本文中，我们将讨论第三方集成、数据存储和检索以及“从 Lambda 函数调用 Lambda 函数”(我们实际上不会这样做，但会了解一种实现类似功能的方法。
添加图像上传
我们将从图像上传开始。它的工作原理如下:
- 通过我们的 API 请求一个预先签署的 S3 网址
- 通过预先签名的网址直接上传图片到 S3
所以我们需要两个新的 SAM/CloudFormation 资源。一个 Lambda 函数，为我们的图像生成预签名的 URL 和 S3 桶。
让我们更新 SAM 模板:
AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::Serverless-2016-10-31"
Description: "A example REST API build with serverless technology"
Globals:
Function:
Runtime: nodejs8.10
Handler: index.handler
Timeout: 30
Tags:
Application: Serverless API
Resources:
ServerlessApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Cors: "'*'"
Auth:
DefaultAuthorizer: CognitoAuthorizer
Authorizers:
CognitoAuthorizer:
UserPoolArn: !GetAtt UserPool.Arn
GatewayResponses:
UNAUTHORIZED:
StatusCode: 401
ResponseParameters:
Headers:
Access-Control-Expose-Headers: "'WWW-Authenticate'"
Access-Control-Allow-Origin: "'*'"
WWW-Authenticate: >-
'Bearer realm="admin"'
# ============================== Auth ==============================
AuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/auth/
Environment:
Variables:
USER_POOL_ID: !Ref UserPool
USER_POOL_CLIENT_ID: !Ref UserPoolClient
Events:
Signup:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signup
Method: POST
Auth:
Authorizer: NONE
Signin:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signin
Method: POST
Auth:
Authorizer: NONE
PreSignupFunction:
Type: AWS::Serverless::Function
Properties:
InlineCode: |
exports.handler = async event => {
event.response = { autoConfirmUser: true };
return event;
};
UserPool:
Type: AWS::Cognito::UserPool
Properties:
UserPoolName: ApiUserPool
LambdaConfig:
PreSignUp: !GetAtt PreSignupFunction.Arn
Policies:
PasswordPolicy:
MinimumLength: 6
UserPoolClient:
Type: AWS::Cognito::UserPoolClient
Properties:
UserPoolId: !Ref UserPool
ClientName: ApiUserPoolClient
GenerateSecret: no
LambdaCognitoUserPoolExecutionPermission:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
FunctionName: !GetAtt PreSignupFunction.Arn
Principal: cognito-idp.amazonaws.com
SourceArn: !Sub 'arn:${AWS::Partition}:cognito-idp:${AWS::Region}:${AWS::AccountId}:userpool/${UserPool}'
# ============================== Images ==============================
ImageBucket:
Type: AWS::S3::Bucket
Properties:
AccessControl: PublicRead
CorsConfiguration:
CorsRules:
- AllowedHeaders:
- "*"
AllowedMethods:
- HEAD
- GET
- PUT
- POST
AllowedOrigins:
- "*"
ImageBucketPublicReadPolicy:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref ImageBucket
PolicyDocument:
Statement:
- Action: s3:GetObject
Effect: Allow
Principal: "*"
Resource: !Join ["", ["arn:aws:s3:::", !Ref "ImageBucket", "/*" ]]
ImageFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functioimg/
Policies:
- AmazonS3FullAccess
Environment:
Variables:
IMAGE_BUCKET_NAME: !Ref ImageBucket
Events:
CreateImage:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /images
Method: POST
Outputs:
ApiUrl:
Description: The target URL of the created API
Value: !Sub "https://${ServerlessApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/"
Export:
Name: ApiUrl
好吧，我们有了三个新资源。我们还需要一个BucketPolicy来允许公众读取我们的新图像桶。
ImagesFunction有一个 API 事件，所以我们可以用它来处理 POST 请求。该函数获得一个 S3 访问策略和一个环境变量，因此它知道ImageBucket。
我们需要为功能代码functioimg/index.js创建一个新文件。
const AWS = require("aws-sdk");
exports.handler = async event => {
const userName = event.requestContext.authorizer.claims["cognito:username"];
const fileName = "" + Math.random() + Date.now() + "+" + userName;
const { url, fields } = await createPresignedUploadCredentials(fileName);
return {
statusCode: 201,
body: JSON.stringify({
formConfig: {
uploadUrl: url,
formFields: fields
}
}),
headers: { "Access-Control-Allow-Origin": "*" }
};
};
const s3Client = new AWS.S3();
const createPresignedUploadCredentials = fileName => {
const params = {
Bucket: process.env.IMAGE_BUCKET_NAME,
Fields: { Key: fileName }
};
return new Promise((resolve, reject) =>
s3Client.createPresignedPost(params, (error, result) =>
error ? reject(error) : resolve(result)
)
);
};
那么，这个函数会发生什么呢？
首先，我们从event对象中提取userName。API-Gateway 和 Cognito 控制对我们函数的访问，所以我们可以确定当函数被调用时用户存在于event对象中。
接下来，我们基于随机数、当前时间戳和用户名创建一个唯一的fileName。
createPresignedUploadCredentials助手函数将创建预签名的 S3 URL。它将返回一个具有url和fields属性的对象。
我们的 API 客户端必须向url发送一个 POST 请求，并在其主体中包含所有字段和文件。
集成图像识别
现在，我们需要集成第三方图像识别服务。
当图片上传时，S3 将触发一个由 lambda 函数处理的上传事件。
这就把我们带到了第一篇文章开头的一个问题。
如何从一个 Lambda 调用一个 Lambda？
简而言之:你没有。
为什么？虽然您可以通过 AWS-SDK 直接从 Lambda 调用 Lambda，但这带来了一个问题。如果出现问题，我们必须实现所有需要发生的事情，比如重试等等。此外，在某些情况下，调用 Lambda 必须等待被调用的 Lambda 完成，我们也必须为等待时间付费。
那么有哪些选择呢？
Lambda 是一个基于事件的系统，我们的功能可以由不同的事件源触发。主要的方法是使用另一个服务来实现。
在我们的例子中，我们希望在文件上传完成时调用一个 Lambda，所以我们必须使用一个 S3 事件作为源。但是也有其他事件源。
- 阶跃函数让我们用状态机来协调λ函数
- SQS 是一个队列，我们可以将结果放入其中，以便其他 Lambdas 获取这些结果
- SNS 是一项服务，它允许我们将一个 Lambda 结果以扇出方式并行发送给许多其他 Lambda。
我们在 SAM 模板中添加了一个新的 Lambda 函数，它将被 S3 调用。
AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::Serverless-2016-10-31"
Description: "An example REST API build with serverless technology"
Globals:
Function:
Runtime: nodejs8.10
Handler: index.handler
Timeout: 30
Tags:
Application: Serverless API
Resources:
ServerlessApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Cors: "'*'"
Auth:
DefaultAuthorizer: CognitoAuthorizer
Authorizers:
CognitoAuthorizer:
UserPoolArn: !GetAtt UserPool.Arn
GatewayResponses:
UNAUTHORIZED:
StatusCode: 401
ResponseParameters:
Headers:
Access-Control-Expose-Headers: "'WWW-Authenticate'"
Access-Control-Allow-Origin: "'*'"
WWW-Authenticate: >-
'Bearer realm="admin"'
# ============================== Auth ==============================
AuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/auth/
Environment:
Variables:
USER_POOL_ID: !Ref UserPool
USER_POOL_CLIENT_ID: !Ref UserPoolClient
Events:
Signup:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signup
Method: POST
Auth:
Authorizer: NONE
Signin:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signin
Method: POST
Auth:
Authorizer: NONE
PreSignupFunction:
Type: AWS::Serverless::Function
Properties:
InlineCode: |
exports.handler = async event => {
event.response = { autoConfirmUser: true };
return event;
};
UserPool:
Type: AWS::Cognito::UserPool
Properties:
UserPoolName: ApiUserPool
LambdaConfig:
PreSignUp: !GetAtt PreSignupFunction.Arn
Policies:
PasswordPolicy:
MinimumLength: 6
UserPoolClient:
Type: AWS::Cognito::UserPoolClient
Properties:
UserPoolId: !Ref UserPool
ClientName: ApiUserPoolClient
GenerateSecret: no
LambdaCognitoUserPoolExecutionPermission:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
FunctionName: !GetAtt PreSignupFunction.Arn
Principal: cognito-idp.amazonaws.com
SourceArn: !Sub 'arn:${AWS::Partition}:cognito-idp:${AWS::Region}:${AWS::AccountId}:userpool/${UserPool}'
# ============================== Images ==============================
ImageBucket:
Type: AWS::S3::Bucket
Properties:
AccessControl: PublicRead
CorsConfiguration:
CorsRules:
- AllowedHeaders:
- "*"
AllowedMethods:
- HEAD
- GET
- PUT
- POST
AllowedOrigins:
- "*"
ImageBucketPublicReadPolicy:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref ImageBucket
PolicyDocument:
Statement:
- Action: s3:GetObject
Effect: Allow
Principal: "*"
Resource: !Join ["", ["arn:aws:s3:::", !Ref "ImageBucket", "/*" ]]
ImageFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functioimg/
Policies:
- AmazonS3FullAccess
Environment:
Variables:
IMAGE_BUCKET_NAME: !Ref ImageBucket
Events:
CreateImage:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /images
Method: POST
TagsFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/tags/
Environment:
Variables:
PARAMETER_STORE_CLARIFAI_API_KEY: /serverless-api/CLARIFAI_API_KEY_ENC
Policies:
- AmazonS3ReadOnlyAccess # Managed policy
- Statement: # Inline policy document
- Action: [ 'ssm:GetParameter' ]
Effect: Allow
Resource: '*'
Events:
ExtractTags:
Type: S3
Properties:
Bucket: !Ref ImageBucket
Events: s3:ObjectCreated:*
Outputs:
ApiUrl:
Description: The target URL of the created API
Value: !Sub "https://${ServerlessApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/"
Export:
Name: ApiUrl
我们添加了一个新的无服务器函数资源，它有一个 S3 事件，当在我们的ImageBucket中创建了一个新的 S3 对象时，就会调用这个事件。
在我们的 Lambda 函数中需要调用第三方 API，即 Clarifai API，这给我们带来了下一个问题。
如何存储第三方 API 的凭证？
有许多方法可以做到这一点。
一种方法是用 KMS 加密凭证。我们通过 CLI 对其进行加密，将加密的密钥作为环境变量添加到 template.yaml 中，然后在 Lambda 中，我们使用 AWS-SDK 对凭证进行解密，然后再使用它们。
另一种方法是使用 AWS 系统管理器的参数库。该服务允许存储加密的字符串，这些字符串可以通过 Lambda 中的 AWS-SDK 进行检索。我们只需要为我们的 Lambda 提供定义凭证存储位置的名称。
在本例中，我们将使用参数存储。
如果你还没有创建一个 Clarifai 账户，现在是时候了。他们将为您提供一个 API 密钥，我们接下来需要将它存储到参数存储中。
aws ssm put-parameter \
--name "/serverless-api/CLARIFAI_API_KEY" \
--type "SecureString" \
--value "<CLARIFAI_API_KEY>"
这个命令将把密钥放在参数存储中并加密它。
接下来，我们需要通过一个环境变量告诉 Lambda 函数这个名字，并允许它通过 AWS-SDK 调用getParameter。
Environment:
Variables:
PARAMETER_STORE_CLARIFAI_API_KEY: /serverless-api/CLARIFAI_API_KEY_ENC
Policies:
- Statement:
- Action: [ 'ssm:GetParameter' ]
Effect: Allow
Resource: '*'
让我们看看 JavaScript 方面的东西，为此，我们创建了一个新文件functions/tags/index.js。
const AWS = require("aws-sdk");
const Clarifai = require("clarifai");
exports.handler = async event => {
const record = event.Records[0];
const bucketName = record.s3.bucket.name;
const fileName = record.s3.object.key;
const tags = await predict(`https://${bucketName}.s3.amazonaws.com/${fileName}`);
await storeTagsSomewhere({ fileName, tags });
};
const ssm = new AWS.SSM();
const predict = async imageUrl => {
const result = await ssm.getParameter({
Name: process.env.PARAMETER_STORE_CLARIFAI_API_KEY,
WithDecryption: true
}).promise();
const clarifaiApp = new Clarifai.App({
apiKey: result.Parameter.Value
});
const model = await clarifaiApp.models.initModel({
version: "aa7f35c01e0642fda5cf400f543e7c40",
id: Clarifai.GENERAL_MODEL
});
const clarifaiResult = await model.predict(imageUrl);
const tags = clarifaiResult.outputs[0].data.concepts
.filter(concept => concept.value > 0.9)
.map(concept => concept.name);
return tags;
};
通过 S3 对象创建事件调用该处理程序。将只有一个记录，但我们也可以告诉 S3 批量记录在一起。
然后，我们为新创建的图像创建一个 URL，并将其交给predict函数。
predict函数使用我们的PARAMETER_STORE_CLARIFAI_API_KEY环境变量来获取参数存储中的参数名。这允许我们在不改变 Lambda 代码的情况下改变目标参数。
我们得到解密的 API 密钥，并可以调用第三方 API。然后我们把标签放在某个地方。
列出和删除标记图像
现在我们可以上传图像，它们会被自动标记，下一步是列出所有的图像，通过标记过滤它们，如果不再需要就删除它们。
让我们更新 SAM 模板！
AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::Serverless-2016-10-31"
Description: "An example REST API build with serverless technology"
Globals:
Function:
Runtime: nodejs8.10
Handler: index.handler
Timeout: 30
Tags:
Application: Serverless API
Resources:
ServerlessApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Cors: "'*'"
Auth:
DefaultAuthorizer: CognitoAuthorizer
Authorizers:
CognitoAuthorizer:
UserPoolArn: !GetAtt UserPool.Arn
GatewayResponses:
UNAUTHORIZED:
StatusCode: 401
ResponseParameters:
Headers:
Access-Control-Expose-Headers: "'WWW-Authenticate'"
Access-Control-Allow-Origin: "'*'"
WWW-Authenticate: >-
'Bearer realm="admin"'
# ============================== Auth ==============================
AuthFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/auth/
Environment:
Variables:
USER_POOL_ID: !Ref UserPool
USER_POOL_CLIENT_ID: !Ref UserPoolClient
Events:
Signup:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signup
Method: POST
Auth:
Authorizer: NONE
Signin:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /signin
Method: POST
Auth:
Authorizer: NONE
PreSignupFunction:
Type: AWS::Serverless::Function
Properties:
InlineCode: |
exports.handler = async event => {
event.response = { autoConfirmUser: true };
return event;
};
UserPool:
Type: AWS::Cognito::UserPool
Properties:
UserPoolName: ApiUserPool
LambdaConfig:
PreSignUp: !GetAtt PreSignupFunction.Arn
Policies:
PasswordPolicy:
MinimumLength: 6
UserPoolClient:
Type: AWS::Cognito::UserPoolClient
Properties:
UserPoolId: !Ref UserPool
ClientName: ApiUserPoolClient
GenerateSecret: no
LambdaCognitoUserPoolExecutionPermission:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
FunctionName: !GetAtt PreSignupFunction.Arn
Principal: cognito-idp.amazonaws.com
SourceArn: !Sub 'arn:${AWS::Partition}:cognito-idp:${AWS::Region}:${AWS::AccountId}:userpool/${UserPool}'
# ============================== Images ==============================
ImageBucket:
Type: AWS::S3::Bucket
Properties:
AccessControl: PublicRead
CorsConfiguration:
CorsRules:
- AllowedHeaders:
- "*"
AllowedMethods:
- HEAD
- GET
- PUT
- POST
AllowedOrigins:
- "*"
ImageBucketPublicReadPolicy:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref ImageBucket
PolicyDocument:
Statement:
- Action: s3:GetObject
Effect: Allow
Principal: "*"
Resource: !Join ["", ["arn:aws:s3:::", !Ref "ImageBucket", "/*" ]]
ImageFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functioimg/
Policies:
- AmazonS3FullAccess
Environment:
Variables:
IMAGE_BUCKET_NAME: !Ref ImageBucket
Events:
ListImages:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /images
Method: GET
DeleteImage:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Pathimg/{imageId}
Method: DELETE
CreateImage:
Type: Api
Properties:
RestApiId: !Ref ServerlessApi
Path: /images
Method: POST
TagsFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/tags/
Environment:
Variables:
PARAMETER_STORE_CLARIFAI_API_KEY: /serverless-api/CLARIFAI_API_KEY_ENC
Policies:
- AmazonS3ReadOnlyAccess # Managed policy
- Statement: # Inline policy document
- Action: [ 'ssm:GetParameter' ]
Effect: Allow
Resource: '*'
Events:
ExtractTags:
Type: S3
Properties:
Bucket: !Ref ImageBucket
Events: s3:ObjectCreated:*
Outputs:
ApiUrl:
Description: The target URL of the created API
Value: !Sub "https://${ServerlessApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/"
Export:
Name: ApiUrl
我们向我们的ImagesFunction添加了一些新的 API 事件，现在也需要为它更新 JavaScript。
const AWS = require("aws-sdk");
exports.handler = async event => {
switch (event.httpMethod.toLowerCase()) {
case "post":
return createImage(event);
case "delete":
return deleteImage(event);
default:
return listImages(event);
}
};
const createImage = async event => {
const userName = extractUserName(event);
const fileName = "" + Math.random() + Date.now() + "+" + userName;
const { url, fields } = await createPresignedUploadCredentials(fileName);
return response({
formConfig: {
uploadUrl: url,
formFields: fields
}
}, 201);
};
const deleteImage = async event => {
const { imageId } = event.pathParameters;
await deleteImageSomewhere(imageId);
return response({ message: "Deleted image: " + imageId });
};
// Called with API-GW event
const listImages = async event => {
const { tags } = event.queryStringParameters;
const userName = extractUserName(event);
const images = await loadImagesFromSomewhere(tags.split(","), userName);
return response({ images });
};
// ============================== HELPERS ==============================
const extractUserName = event => event.requestContext.authorizer.claims["cognito:username"];
const response = (data, statusCode = 200) => ({
statusCode,
body: JSON.stringify(data),
headers: { "Access-Control-Allow-Origin": "*" }
});
const s3Client = new AWS.S3();
const createPresignedUploadCredentials = fileName => {
const params = {
Bucket: process.env.IMAGE_BUCKET_NAME,
Fields: { Key: fileName }
};
return new Promise((resolve, reject) =>
s3Client.createPresignedPost(params, (error, result) =>
error ? reject(error) : resolve(result)
)
);
};
删除功能很简单，但也回答了我们的一个问题。
如何使用查询字符串或路由参数？
const deleteImage = async event => {
const { imageId } = event.pathParameters;
...
};
API-Gateway 事件对象有一个pathParameters属性，保存我们在 SAM 模板中为事件定义的所有参数。在我们的例子中imageId，因为我们定义了Pathimg/{imageId}。
以类似方式使用的查询字符串。
const listImages = async event => {
const { tags } = event.queryStringParameters;
...
};
剩下的代码并不太复杂。我们将使用偶数数据来加载或删除图像。
查询字符串将作为对象存储在我们的event对象的queryStringParameters属性中。
结论
有时新技术会带来范式的转变。无服务器就是这些技术中的一种。
it 的全部力量通常归结为尽可能使用托管服务。不要使用自己的加密、身份验证、存储或计算。使用您的云提供商已经实施的技术。
这里的大问题往往是，做事情有很多方法。正确的方法不只有一种。我们应该直接使用 KMS 吗？我们应该让系统经理为我们处理事情吗？我们应该通过 Lambda 实现 auth 吗？我们是否应该使用 Cognito 并结束它？
我希望我能在某种程度上回答使用 Lambda 时出现的问题。
在 Moesif 中引入个人资料仪表板
原文：https://www.moesif.com/blog/api-product-management/api-analytics/Introducing-Profile-Dashboards/
我们很高兴地宣布个人资料仪表盘现已在 Moesif 中上线！我们设计了个人资料仪表盘，让面向客户的团队能够以便捷的方式监控和分析您客户的账户健康状况。这项新功能以简单、一致的方式提供客户特定信息。简档仪表板允许您查看特定用户和公司的个性化仪表板。
个人资料仪表盘是查看特定用户和公司关键指标的最简单方式。让我们了解如何查看和利用 Moesif 中的个人资料仪表板！
什么是简档仪表板？
Moesif 的个人资料仪表板是一个新添加的功能，可为您的整个客户群提供个性化的账户指标。这是通过提供应用于每个客户的个人资料页面的可定制模板来实现的。
Profile Dashboards 为 Moesif 用户提供了客户账户健康状况的直观分析。以前，Moesif 用户可以在每个用户和公司的个人资料下查看实时事件日志，该日志显示用户的活动以便于查看。Profile Dashboards 在此基础上进行了扩展，它允许您使用自己喜欢的图表创建一个控制面板模板，自动筛选和显示特定用户或所选公司的指标。
为什么要使用个人资料仪表板？
Profile Dashboards 只需导航到客户的个人资料页面，您就可以查看您想了解的关于客户使用情况和与您*台互动的一切信息。您的所有个人资料仪表板都源自一个模板，可以根据您的特定使用情形进行定制。以前，您需要覆盖现有的控制面板来筛选特定用户或公司，或者为每个唯一的用户或公司手动创建一个全新的控制面板。现在，您可以一次性创建模板，并在查看用户或公司简档时自动过滤和填充简档仪表板。
Profile Dashboards 的灵活性可以帮助您业务的许多领域，包括您的销售和客户成功团队。与手动过滤您需要的数据或操作现有的仪表板过滤器相比，即时访问帐户健康状况可以使某些任务变得更加容易。
一个很好的例子是，当客户向您的团队寻求支持时，他们从 API 接收到了 400 状态代码响应。您的支持代表可能需要几分钟时间来筛选和提取他们的信息。如前所述，他们首先需要复制一个现有的工作区，或者甚至需要从头开始创建一个新的工作区。然后，他们需要为客户遇到的问题设置所需的过滤器，并根据客户 ID 过滤结果。Profile Dashboards 允许客户成功代表转到用户的个人资料，并查看显示 4XX/5XX 错误的仪表板磁贴，从而简化这一过程。然后，销售代表可以轻松查看错误，并快速提供故障排除建议。
一旦设置完毕，个人资料仪表盘将是您团队工具库中的一大补充，有助于查看和维护良好的帐户健康状况。使用 Moesif 构建美观、面向客户的仪表盘。
在哪里可以找到个人资料仪表板？
个人资料仪表板模板位于左侧导航窗格的已保存仪表板标题的底部。在这里，我们可以为每个配置文件定制我们的布局。点击个人资料仪表板下拉菜单，显示两个子类别用户资料和公司资料。
让我们进入用户档案子部分。仪表板预览显示了我们的工作区当前的样子。它还让我们深入了解将在我们的个人用户资料仪表板上显示的内容。
与用户档案类似，公司档案可以通过点击公司档案以同样的方式访问和编辑。
使用左侧导航窗格，我们可以访问用户简介或公司简介下拉列表。我们可以看到所有已配置工作区的列表。单击其中任何一项都会直接进入配置视图，在这里我们可以根据具体的使用情形对每一项进行定制。
如何查看简档仪表板
有多种方法可以导航到特定用户或公司的简档。您可以通过以下方式做到这一点:
- 进入事件屏幕，点击实时事件日志中的用户 ID 或公司 ID
- 导航至用户或公司屏幕，点击查找中的用户/公司 ID
调出用户或公司资料后，滚动到屏幕底部，查看所选用户或公司的资料仪表板。在此屏幕上，您将看到您创建的 Profile Dashboard 模板(或默认模板，如果您没有接触过它),其中包含为特定用户/公司筛选的指标和图表。不需要额外的工作，这都是为你自动过滤。
尝试一下
如您所见， Profile Dashboards 是一个很好的工具，可以为使用您*台的每个用户和公司提供个性化的图表和指标，从而帮助您业务的许多方面。我们已经为您提供了一组很好的默认仪表板磁贴来帮助您入门，但是您可以根据自己的需要轻松定制您的个人资料仪表板。要开始使用个人资料仪表盘，只需登录 Moesif 或立即注册。如果你对 API 货币化感兴趣，也可以看看我们新的计量计费功能。
通过个人资料视图了解您的帐户健康状况
Moesif 产品团队最*一直很忙！我们一直在倾听我们的合作伙伴并收集反馈，我们听到的是对新工具的大量请求，这些工具可以提供对您的客户帐户健康状况的 360 度优势。因此，我们非常兴奋地宣布，我们已经发布了我们的最新功能:个人资料仪表板视图。
我们的个人资料视图旨在为面向客户的团队提供一个监控和分析客户账户健康状况的中心资源。我们创建了一个迷你仪表板，是 Moesif 的用户和公司部分的一部分，其中有许多与我们最相关的图表。该工具将允许支持团队快速了解您的客户在哪些方面取得了成功，以及他们可能会遇到哪些问题。目标是驱动更多令人愉快的*台体验。
我们开发 Profile View 工具的一个重要原因是，我们的合作伙伴告诉我们以简单统一的方式访问客户指标的重要性。他们不想管理跨*台分布的一组不同的图表。相反，我们的合作伙伴指出了在一个屋檐下拥有关键客户指标的必要性，以便准确地了解每个客户的情况。使用 Moesif 的个人资料视图，您可以使用单个模板进行操作，您的指标可以应用于您的客户群，而无需进行手动调整。
例如，假设你接到一个客户的电话，他们正在为 400/500 错误而努力。支持代表必须敏捷地工作以快速解决问题，而没有时间构建新的报告。为了实现这一点，销售代表现在可以在 Profile 视图中收集必要的产品指标，这样他们就可以诊断问题并让开发人员回到正轨。
此外，支持团队需要从战略层面运作，通过建立趋势来显示客户是否适合扩张或客户是否有流失风险。能够访问多个信号，例如最*的登录、日常使用和以简化方式呈现在 Profile View 中的功能利用，对于未来的收入目标和支持团队的成功至关重要。
虽然支持团队必须管理各种优先级，但成功指标本身可能会有很大差异，这取决于您希望优化的业务成果。这就是为什么我们的个人资料视图能够定制您想要报告的指标。也就是说，Moesif 确实提供了一些图表发件箱供你的团队使用，这为你的支持团队提供了一个很好的起点。仅举几个例子:
- 新帐户登录
- 每日 API 增长率
- 最活跃的用户
- API 错误日志
- MRR 增长
了解更多关于 Moesif 如何围绕您的分析实现协作。
在哪里可以找到 Moesif *台上的个人资料视图:
登录您的 Moesif 帐户。在左侧边栏导航中的“Saved Dashboards”下，您现在应该会看到一个标题为“Profile Dashboards”的控制面板。单击该行(或其左侧的“展开”箭头)显示“用户资料”和“公司资料”选项。然后单击其中一个仪表板进行查看。这些模板决定了在每种客户类型的相应配置文件中显示哪些图表，其中“用户”代表个人用户，而“公司”代表整个组织。
在用户视图或公司视图中，您都可以找到 Moesif 的现成仪表板，但是如前所述，您可以根据组织的需求定制图表。我们的 Profile 视图在与我们的工作区相同的框架中运行，您只需点击几下鼠标就可以添加和删除图表。
一旦你完成了个人资料视图的定制，你可以在 Moesif 的客户或用户页面中测试新的个人资料。例如，如果您想要检查某个特定客户的帐户健康状况，您可以搜索该客户，然后单击他们的橙色公司 ID，从那里您可以向下滚动并查看带有您预先建立的图表的公司 dash 视图。
结论
有了 Moesif 的个人资料视图，支持团队现在可以以闪电般的速度工作，以更好地了解他们客户的账户健康状况，因为您只需点击一下鼠标，就可以看到您需要了解的任何客户的所有信息。无论您需要从运营角度还是从战略业务角度开展工作，Moesif Profile View 都能为您的支持团队提供帮助。
让你的 API 产品团队开心
原文：https://www.moesif.com/blog/api-product-management/api-metrics/Keeping-Your-API-Product-Team-Happy/
Moesif 有幸向撰写了关于 API 产品管理的书籍的专家请教。在与 Amancio Bouza 博士的广泛讨论中，我们发现作为一名 API 产品经理，你真正应该关心的是什么，而不是你可能认为的那样(提示:见标题)。我们还将讨论 API 的定价，如何成为更好的产品经理，以及床头柜上应该放什么书。
作为 API 产品经理、产品负责人、技术负责人和工程师，Amancio Bouza 拥有* 15 年的经验。除了出版关于 API 产品管理的书籍，他还帮助建立了 API 作为数字经济产品的概念，如 API 作为价值主张的接口:VPI。如今，他通过结合精益创业方法、客户关注和生态系统开发，帮助公司创造商业价值。
以下是我们的问答。为了清晰和长度，对它们进行了编辑。
问:你认为 API 产品公司最重要的 KPI 是什么？
答:要真正看一个提供 API 产品的公司是否成功，应该把重点放在留存上。
通常情况下，顾客会尝试某些东西。他们说他们想去使用你的 API，或者计划以某种方式使用它。但是当他们真正做项目时，将它集成到他们的产品或内部业务流程中，只有这样你才能真正验证他们是在以满足他们用例的方式使用它。然后，如果他们继续使用它，并且你观察到 API 使用的增长，那么你知道它在那个公司是成功的。
如果你看到有更多的吸引力，更多的公司对它感兴趣，那就更好了。但这实际上取决于 API 产品。可能市场规模很小，但对你的 API 产品来说价值巨大。
问:如果绝对数字不重要，你如何量化你的 API 可能给潜在客户带来的价值？
答:为此，您必须真正了解客户的使用情形。
我举个例子来解释一下。我曾与一家保险公司合作，该公司创建了一个新的在线门户网站来吸引用户并销售保险产品。在 onboarding 中，他们看到人们去*台、开始注册过程和注册服务的转化率只有百分之十。
我们深入研究了入职流程，以了解潜在客户必须做什么，我们看到的是大量的验证和确认步骤——发送电子邮件以验证电子邮件地址，发送短信以验证手机号码，甚至向家庭地址发送信件以验证人们的住址。
从那以后，我们看了下电话号码，发现在电话号码阶段你会失去一些人，电子邮件会让你失去更多，但是写信会让你失去更多。不仅如此，除了将信件发送到*台的营销费用之外，信件的准备和发送也要花费 6 个邮资。从那里我们估计，如果能解决这个问题，不仅公司将节省邮寄成本，但提高他们的转换率。所以我们知道，当你提供一项服务，我们可以提高转化率，他真的得到了一个胜利，通过节省邮资，他得到了另一个提升。基于此，我们还对 API 进行了定价。
因此，只有真正理解这个过程，你才能衡量你的 API 的价值。
问:就初始定价而言，如何确定 API 的收费标准？
答:我们使用一种通用的经验法则，即我们需要在一定的时间范围内收回营销成本。
我们通常从最初的估计开始，即你为注册一个新用户而投入到市场营销中的成本大约是 10 到 15 美元。请记住，10%的转化率会让你失去 90%最初被营销项目吸引的人。
然后，对于真正的定价，你不能说，好吧，听着，你作为一个公司或你作为一个潜在的客户，你将为每个呼叫节省 10 美元，所以请继续给我们 9 美元，然后你将节省 1 美元。通常将你提供的价值除以 10，甚至更多，以使它变得如此引人注目，以至于他们无法拒绝。或者像电影《格伦加里·格伦·罗斯》里那样，给他们开出一个他们无法拒绝的条件。所以在 10 倍到 100 倍之间的某个地方，是你应该结束的地方。
问:对于那些考虑提供一个 API 来补充他们现有的有前端等的“完整”产品的公司，产品经理应该对完整产品应用什么折扣？
答:我的合著者 Andrea Zulian 说，这是 API DNA 的一个缺陷，你不能只是购买和使用它，你还必须集成它，这通常不是小事。
将一个 API 集成到一个产品中通常需要公司投入相当多的资金。他们必须打开一个程序，加入一个项目团队，创建任务以将其集成到他们的测试环境中，管理持续集成、持续交付管道、沙盒测试等等。因此，这是客户为了使用 API 而不得不投资的一笔巨大成本，在您确定价格时必须考虑这一点。
但这也是整个 API 产品设计的某种机会。最好的项目经理会尽力让开发人员尽可能容易地以适当的方式集成，通过:提供一个沙箱来测试它，让用 API 进行持续测试变得容易，提供测试数据和良好的文档、SDK 和用例。
API product managers should make data-driven decisions. After specifying the API product, verify whether it brings value to the customer by closing the monitoring log file, or using a tool like Moesif to provide more insight into what is happening to the user
问:一个产品经理应该提供什么最重要的特性来使开发者的旅程尽可能的顺畅？
答:其他人可能不同意，但这是一个沙盒环境。
事实证明，通常只有少量的文档就足够了。使用或集成 API 的开发人员能够使用 API，并了解他们可以从中获得什么样的信息。通常，真正缺乏的是提供某种沙盒或测试环境。一个好的工程师想要做敏捷开发，他们想要做持续开发，或者 CI/CD，并且自动化流水线。如果你不提供某种自动化测试，他们就不能自动化测试。
*年来，开发模式已经发生了变化，真正实现了整个过程的自动化。你总是希望优化渠道，尽快将产品投入生产。如果没有适当的测试，你就不能真正确定你集成的 API 是否仍然工作，即使该 API 仍然可用。
通过排除一个测试环境，工程师将不能发光——他们将不能确定他们实际构建的是不是他们所期望的。他们定义测试用例，他们知道什么应该是正确的答案，他们知道什么应该是错误的答案，他们知道如何使用 API。但是如果没有测试环境，就会缺少一个关键部分。这通常是使用其他供应商 API 的开发人员最失望的地方。
问:API 产品经理通常必须指定测试环境吗？
答:最好的产品经理需要了解开发人员是如何思考的，他们是如何工作的，他们的需求是什么。
API 产品经理应该决定实际交付的内容和实际的 API 产品本身。因此，这是完整*台功能的一部分，就像提供沙盒环境、测试日期等，产品经理必须定义。这应该被视为他的 API 产品的一个重要特性，就像一种 SLA 特性。当然，这取决于 API 产品经理的开发团队来监控 API 的工作情况，改进*台，提供更好的沙盒环境等等。
这是 API 产品经理必须具备的新技能或视角。他现在需要了解开发人员是如何思考的，他们是如何工作的，他们的需求是什么，此外还有他的传统职责，即了解他的客户将如何消费 API。
问:产品经理如何让自己的角色更加有效？
答:充分理解 DevOps 和开发者的心态。
真正读到 DevOps 这个话题。DevOps it 将开发、运营和在生产中运行软件的整个过程自动化结合在一起，或者将软件毫无摩擦地投入生产。产品经理有一个内部开发团队，所以他应该直接问他们是怎么做的。有趣的是，提供 API 的公司也在做 DevOps，但通常 API 是以 DevOps 不友好的形式提供的。
所以我真的建议产品经理去和他们的软件工程师谈谈。他们应该从他们那里听到他们喜欢什么，他们想要什么，他们需要什么，以及他们的痛苦在哪里。有了这种视角，产品经理将对公司外部的开发人员有更好的理解。
问:深入挖掘 API 的有效负载以了解最终客户如何使用它是否有很大用处，或者产品经理的工作范围是否仅仅停留在基础设施监控上？
答:通过研究有效载荷可以获得很多价值。
我认为这两者都为 API 产品本身提供了有用的视角。举个例子，如果你在你的 API 调用中发现很多错误，比如 4xx 响应(某些东西不存在)，可能是某些东西出错了，或者消费者，从他的角度来看，正在做一些正确的事情，错误消息实际上是一个有效的结果。这可能发生在数据库中不存在 person 的搜索 API 中，但是 4xx 错误实际上是有效信息。
API 产品经理很少能够看到有效负载，真正理解 API 消费者需要什么样的信息，然后解释并从中学习。
例如，我与一家支付 API 提供商合作，我们发现所有的交易，或者说大部分交易，都是小额支付。然后我们说，好吧，作为一个供应商，我们需要改进我们的微支付计划——我们需要尽可能降低这些交易的成本。如果你不能支持微交易，因为它们太贵了，也许你应该提供批量微支付。你看，在这个案例中，我们了解了消费者如何使用 API，然后调整 API 产品，这样我们的客户获得了更多的价值，组织也获得了额外的价值。
问:你参与开发的其他 API 产品是否受益于以用户为中心的分析？
答:大型电信运营商的数据治理。
在一家大型运营商处，我们构建了一个身份验证 API 产品，该产品在数据隐私/数据治理方面有非常具体的规则。他们的法律部门说我们不能提供运营商客户的信息，只能提供运营商以外的信息。
在设计阶段，我们实现了一个系统，允许直接调用来进行身份验证，只是规定如果您正在验证运营商的零售、商业或 VIP 客户，则不允许使用 API。当我们查看日志文件时，我们发现客户在不应该使用它的时候使用它。为了指导他们做正确的事情，我们重新设计了 API 产品，以符合我们的内部规则——我们实现了一个密钥，只有在验证他们没有搜索客户后才提供该密钥。
问:成功的 API 产品经理应该遵循的首要标准是什么？
答:这可能不是一个衡量标准，但它是构建您的 API 的团队的快乐。
当他的团队受到鼓舞和激励时，当他们学习新的东西来提高自己时，这对项目经理真的很有帮助。如果你有一个快乐的团队，那么他们真的关心提供好的错误消息，他们关心他们的客户，想让他们真正成功，他们会为 API 产品经理提供支持，帮助创造最好的 API 产品供消费。我不知道如何，或者在多大程度上你可以真正衡量它，但至少你应该和他们谈谈，感受一下他们是否快乐，如果不快乐，你可以做些什么来改变这种情况。
问:你要遵循的另一个最重要的衡量标准是什么？
答:入职时间。
第二个是入职流程，或者说一个公司真正集成一个 API 需要多少时间。这不仅仅是遵循一个很好的指标，如首次 Hello World 的时间，或首次 API 调用的时间，它实际上是关于客户需要多少时间来支持 API:测试它，集成它并将其投入生产。
好的一面是，如果你正在记录 API，或者有这样的工具，比如 Moesif 的，这些将显示真实的情况。你可以问你的客户他们是否在使用你的 API，但是如果你没有看到任何你不知道的流量，好吧，他们没有使用它。我们与一家保险公司合作，他们说他们在使用 API，但是我们从来没有看到任何流量，所以我们知道有问题。我们找到他们，问他们我们如何帮助他们整合，然后我们一起想出了该怎么做。有时项目被推迟或者有依赖性，但是其他时候有集成问题，你真的可以帮助解决。
问:除了你自己的书，你推荐产品经理应该读什么？
答:全面的产品经理知道如何围绕客户旅程创建生态系统。这四本书就如何做提供了全面的描述。
Roman Pichler 的《运筹帷幄:数字时代的产品战略和产品路线图实践》是第一本关于数字产品的书。作者真正理解了如何做利益相关者管理，如何将数字产品定义为服务。他预见了数字产品的趋势。
The Lean Startup:How Today ' s Entrepreneurs using The Continuous Innovation to Create probably business 作者 Eric Ries 了解基于数字验证你的想法的方法。
Mehdi Medjaoul 等人的《持续 API 管理:在不断发展的环境中做出正确的决策》面向 API 架构师、开发人员和产品经理，从您需要的角色类型到组织主题，从技术角度提供了 API 产品管理的全貌。
詹姆斯·马龙的《竞争之死:商业生态系统时代的领导力和战略》讲述的是如何构建商业生态系统。API 的最终承诺是你成为一个生态系统的一部分，一个让你在特定行业之外有价值的生态系统。行业之间不再有壁垒，相反，你可以通过正确的合作方式，参与围绕客户旅程创建的生态系统。
利用 API 分析*台的用户行为分析
行为分析揭示了用户在你的产品中采取的行动。从一开始，Moesif 就将原始事件数据、特定的 API 调用组织成每个用户行为或旅程的时间线。其中最著名的例子是我们追踪新用户转化的漏斗视图:注册>第一个 API 调用>第一个工作应用。
我们现在已经增强了我们的用户和公司过滤功能，因此您可以超越按客户人口统计和其他传统属性进行的典型分析，而是专注于了解用户如何行动以及他们为什么执行这些行动。相反，用户行为使您能够了解跨多个 API 调用的复杂用户交互事件，或者客户进行这些调用的频率，而不是关注单个值的时间序列指标。
担心上周 API 调用(400 或 401)失败的美国公司？
行为过滤器
我们刚刚在用户查找和公司查找下完成了一个相当大的更新。新功能包括:
- 动作:过滤公司或用户，不仅通过人口统计，还通过动作——他们在你的 API 上做了什么
- 数量:在特定的时间范围内有多少行动
- 组合:可以使用 AND 和 OR 函数一起检查多个动作
- 图形化:过滤不仅在 lookup 中受支持，在复合视图中也受支持
查看行为过滤器灵活性的最佳方式是通过用例的图解:
用例 1:显示在过去 24 小时内进行了至少 9 次 API 调用的所有用户
用例 2:向我展示上一季度美国所有 API 调用失败的用户
用例 3:按营销活动渠道绘制的图表所有购买的美国用户，按 API 的年龄
结论
随着 Moesif 行为过滤器的发布，您现在可以使用简单的下拉菜单和查询框来询问复杂的数据问题:
想要通过活动来源识别在过去 3 天内提出 3 次购买请求的用户？
有了行为过滤器，产品经理现在可以对功能做出更具洞察力的决策，营销人员现在可以在正确的时间向正确的用户群提供正确的产品。
使用 Docker 实现 Kong API 网关的负载*衡
原文：https://www.moesif.com/blog/technical/kong/Load-Balancing-using-Kong-API-Gateway-with-Docker/
为了打破单一应用架构的僵化，开发人员正大量转向微服务。微服务是大型软件中的小型、独立、松散耦合的模块，它们通过 API 相互通信。微服务架构提供容错能力，支持连续交付，并能够跨多个区域扩展以确保高可用性。
在本文中，我们将展示一个例子，说明如何使用最流行的 HTTP 服务器之一 NGINX 作为核心构建的一个流行的开源 API 网关来实现负载*衡。通过 Kong，您可以从一个集中的位置获得更多的控制，以处理身份验证、速率限制、数据转换等事项，即使您拥有多个微服务，而不是典型的负载*衡器。
为什么要负载*衡？
负载*衡是高可用性基础设施的关键组成部分，用于将用户的请求负载分布在健康主机的多个服务上，以便没有主机过载。
单点故障可以通过引入负载*衡器和服务副本来缓解。每个服务都将返回相同的响应，因此无论调用哪个服务，用户都会收到一致的响应。
Kong 为多种服务提供了不同的负载*衡请求方法——基于 DNS 的方法、循环法和基于哈希的*衡方法。基于 DNS 的方法将以这样的方式在 DNS 中配置域，即用户对域的请求分布在一组服务中。循环法会将负载均匀有序地分配给主机。当使用基于散列的*衡方法时，Kong 将充当服务注册中心，通过一个 HTTP 请求来处理服务的添加和删除。
在本地设置孔
Kong 可安装在多种操作环境中。根据您当前使用的环境设置 Kong。关于如何安装孔的更多细节
设置服务
我们将启动两个服务，它们将是两个 NGINX 实例。我们会拉基于 NGINX 和 LuaJIT 的 OpenResty 官方 docker 镜像。
docker pull openresty/openresty
让我们启动两个服务，并将其映射到不同的端口
docker run -p 9001:9001 -d openresty/openresty
docker run -p 9002:9002 -d openresty/openresty
在配置服务之前，我们将安装软件包。
docker exec -it <container> /bin/bash
apt-get update
apt-get install vim
apt-get install libnginx-mod-http-ndk nginx-common libnginx-mod-http-lua
现在，我们将使用两个端点/和/profile来配置服务，我们将分别验证和监听端口9001和9002。我们将更新etc/nginx/conf.d/default.conf的配置文件。
listen <port_number>;
location / {
return 200 "Hello from my service";
}
location /profile {
content_by_lua_block {
local cjson = require "cjson"
local consumer_id = ngx.req.get_headers()["X-Consumer-ID"]
if not consumer_id then
ngx.status = 401
ngx.say("Unauthorized")
return
end
ngx.header["Content-Type"] = "application/json"
ngx.say(cjson.encode{
id = consumer_id,
username = "moesif",
description = "Advanced API Analytics platform"
})
}
}
我们将重新启动服务，以确保反映最新的配置更改。
docker restart <container>
如果我们根据配置点击它们，我们将很快看到服务的响应。
# Service A
curl -XGET 'http://localhost:9001'
# Service B
curl -XGET 'http://localhost:9002'
这个想法是让两个服务成为彼此的副本，这样我们就可以在它们之间负载*衡我们的流量。
启动孔
我们将从 Kong 开始，将通过 Kong 的流量代理为反向代理，而不是直接访问 NGINX 实例。
为此，我们必须向代理端口8000和管理端口8001发出请求。
创建服务
我们将创建一个名为moesif-service的服务。
curl -i -X POST \
--url http://localhost:8001/services/ \
--data 'name=moesif-service' \
--data 'url=http://localhost:9001'
创建路线
我们将创建一个接受流量的路由，并将从该路由收到的所有流量发送给上面创建的服务。
curl -i -X POST \
--url http://localhost:8001/routes \
--data 'paths[]=/' \
--data 'service.id=<service-id>' \
-f
此时，我们能够通过 Kong 将流量代理到 port 9001服务。
curl -i -X GET \
--url http://localhost:8000/
太棒了，我们实际上是通过 Kong 将流量代理到上游，因为 Kong 将在响应中添加几个报头。
我们还可以将流量代理到任何上游端点，这使得 Kong 完全透明，因为它不关心我们发送哪个请求，只要它匹配我们在路由中定义的规则，它就会将该请求代理到上游。在我们的例子中，它是/,这基本上意味着通过 Kong 的每个请求都将被代理到端口9001服务。
现在让我们谈谈我们在上游定义的另一个端点/profile。
如果我们想强制每个请求通过/profile上游被认证，我们可以创建一个路由并在该路由上应用key-auth插件。
创建路线
curl -i -X POST \
--url http://localhost:8001/routes \
--data 'paths[]=/profile' \
--data 'service.id=<service-id>' \
-f
为了尽可能的灵活，Kong 有一个配置参数来定义我们是否剥离请求路径，默认为 true。这意味着/profile被代理为上游的/。因此，我们必须通过一个简单的补丁请求来禁用它。
curl -i -X PATCH \
--url http://localhost:8001/routes/<service-id> \
--data 'strip_path=false'
现在，如果我们向/profile发出请求，它将正确地向上游的/profile发出请求。
curl -i -X GET \
--url http://localhost:8000/profile
现在让我们将key-auth插件应用于/profile路线。
curl -i -X POST \
--url http://localhost:8001/routes/<service-id>/plugins \
--data 'name=key-auth'
我们需要在调用/profile端点时传递 API 键，因为我们必须创建消费者。
curl -i -X POST \
--url http://localhost:8001/consumers \
--data 'username=moesif'
为了获得 API 密钥，我们将发出一个 POST 请求
curl -i -X POST \
--url http://localhost:8001/consumers/<username>/key-auth
我们用 API-key 作为头向/profile发出请求，
curl -i -X GET \
--url http://localhost:8000/profile \
--header 'apikey:<apikey>'
我们可以看到,/profile已经过身份验证，并按照上游配置返回响应。
您已经观察到另一个服务处于空闲状态，没有接收任何流量。这里的目标是*衡两个服务之间的流量负载。
我们不打算使用基于 DNS 的负载*衡，而是使用类似于 NGINX 中的upstream模块的upstreams手动完成。我们必须给出的唯一参数是name，在我们的例子中是localhost。因此，每个主机名为localhost的服务都将通过上游代理，这将做出负载*衡决策。
curl -i -X POST \
--url http://localhost:8001/upstreams \
--data 'name=localhost'
我们将为这两个端口添加目标，并开始在服务之间代理负载*衡流量。
curl -i -X POST \
--url http://localhost:8001/upstreams/<upstream-id>/targets \
--data 'target=localhost:9001'
现在，如果我们通过 kong 发出请求，它将在两个服务之间实现负载*衡。
如果我们关闭其中一个服务，Kong 将使用重试机制。但是在某些情况下，如果我们在相同的上游用尽所有的重试，仍然可能有错误。在监控 Kong 日志时，您可以看到 Kong 正在做出的决定。它正试图与第二个上游通信，但未能成功，并重试对第一个上游的请求。我们的负载*衡槽的大小相当大，可能需要一段时间来访问另一个服务。在这种情况下，我们必须继续发送更多的请求。
要了解如何使用您的 API，捕获 API 请求和响应并记录到 Moesif，以便通过 Kong 轻松检查和实时调试您的 API 流量。有关如何安装 Moesif 插件的更多详细信息，请查看此方法。
同时，如果您有任何问题，请联系 Moesif 团队
Logstash Filter 在 Scala 中动态运行 ElasticSearch 查询
Scala 中弹性搜索查询的 Logstash 过滤器
不要将此过滤器与 Logstash 内置过滤器 ElasticSearch 混淆，后者可用于将 ElasticSearch 中现有事件(或任何其他对象)的字段加载到当前事件中。这里解释的 Logstash filter 用于检查事件是否与给定的 es 查询相匹配，并根据事件是否满足查询来采取行动。这个 logstash 过滤器也是在 Scala 中开发的(除了 java 中的插件链接部分)。
因此，无论是对设计通过在事件上运行 ES 风格的查询来采取某种行动的解决方案感兴趣的人，还是对在 scala 中开发 Logstash filter 感兴趣的人，这篇文章都是相关的。本文首先关注如何在 scala 中开发 Logstash filter，然后关注如何实现 Logstash filter 来通过 es 风格的查询过滤事件
如何在 Scala 中开发 Logstash 过滤器
Logstash 7.2.0 包含对 Java 插件(GA)的原生支持。早期的版本(6.6.0) 提供了测试版支持。关于如何编写 java 过滤插件的 Logstash 文档对如何用 Java 编写插件有明确的说明。我将只关注在 scala 中开发插件所需的额外变化。
下面是如何将 scala 源文件链接到 Java 示例过滤器插件的说明
创建 scala 源模块
您需要在项目 src/main 下创建一个 scala 目录，并将其标记为 source 文件夹(这些是针对 IntelliJ 的说明，其他 IDE 可能需要遵循不同的步骤)。确保在 IntelliJ 模块设置中包含 scala 库依赖。在 scala 源代码模块下，可以根据需要创建包和源文件。项目结构可能如下所示
梯度构建配置
Gradle 构建配置文件可用此处需要更改为包括
-
scala 库依赖
-
首先编译 scala 代码，然后编译 java 代码的配置
对于步骤 1，当构建插件时，确保 scala 库 jar 包含在最终的 jar 中(grad le dependencies . implementation 选项编译代码，但是除非使用 dependencies.compile 选项，否则不会包含所需的 scala 库)，否则您会遇到问题，插件的 scala 部分不会在 Logstash 中执行。这是因为 Logstash 运行时环境不需要 scala 库
apply plugin: 'java'
// gradle plugin for scala
apply plugin: 'scala'
// step 1 to include scala library into final jar
dependencies {
compile 'org.scala-lang:scala-library:2.11.12'
}
// step 2 to comple scala code first
tasks.compileJava.dependsOn compileScala
tasks.compileScala.dependsOn.remove("compileJava")
sourceSets {
main {
scala {
srcDirs = ["src/main/scala"]
outputDir = file("$buildDir/classes/scala/main")
}
java {
srcDirs = ["src/main/java"]
outputDir = file("$buildDir/classes/java/main")
}
}
}
通过对 gradle.build 文件的上述更改，src/main/scala 中的 scala 源代码应该在 java 和 gem 文件中生成的 fat jar(之后)之前编译。/gradlew gem)应该包含在 Logstash 中运行插件所需的所有库
在 java 源文件中使用 scala 类
在 java 类中使用 scala 类/对象/方法非常简单，这里有几个例子
针对事件运行 ES 样式查询的 Logstash 过滤器
ElasticSearch 查询支持多种运算符，包括搜索数据的聚合。这里我们只关注测试事件字段的布尔查询。测试事件字段的示例查询
查询 A
{ "query": { "range": { "time": { "gte": "2022-01-17T18:00:00.000" } } } }
查询 B
{ "query": { "bool": { "must": [ { "bool": { "must": [ { "term": { "source.type": "Moesif" } } ] } }, { "exists": { "version": "api_version" } } ] } } }
一旦事件匹配给定的 es 查询，应该做什么取决于您正在处理的项目。在这篇博客中，我们解释，假设每个查询都有唯一的标签，如果事件满足给定的查询，如何用查询标签来标记事件。
我们的方法包括两步
使用 and、or 等将 ES 查询优化为简单的*面表达式
上面的示例查询将被转换成如下的*面表达式，并在前面加上查询标记
A:( range [time] gte 2021-07-17T18:00:00.000 )
Query B flat expression equivalent
B:( and ( eq [source][type] Moesif ) ( defined [api_version] )
将 es 查询转换成*面表达式的 Scala 代码可从这里获得ElasticSearchQueryTransformer。ElasticSearchQueryTransformer 不仅转换查询，还通过删除不必要的表达式来优化查询，同时保持逻辑等价
{ "query": { "bool": { "must": [ { "bool": { "must": [ { "match": { "source.type": "Moesif" } } ] } } ] } } }
上述查询转换成*面表达式
Flat expression without optimization
( and ( and ( eq [source][type] Moesif ) ) )
Flat expression with optimization
( eq [source][type] Moesif )
日志隐藏过滤器弹性搜索 _ 查询 _ 过滤器
在 Apache 许可下可用的 elastic search _ query _ filter这里使用简单的*面表达式来评估事件。上面步骤中的*面表达式需要对过滤器可用，这可以通过几种方式实现
- 将*面表达式存储在 ES 中，并使用内置过滤器 elasticsearch 将*面表达式加载到事件本身中(这是我们所做的，也是 elasticsearch_query_filter 所期望的，不会改变)
- *面表达式可以保存到任何其他数据库中，并可以使用特定于该数据库的不同插件加载到事件中
- 更改 ElasticSearchQueryFilter 类，以便在插件初始化时将*面表达式加载到内存中
ElasticSearchQueryFilter 根据*面表达式评估传入事件，并用匹配的查询标签标记事件
测试 Logstash 过滤器插件
需要首先安装 Logstash 过滤器
bin/logstash-plugin install logstash-filter-elasticsearch_query_filter-1.0.0.gem
logstash_test.conf 有测试日志 stash 配置
input {
generator {
message => "Hello world!"
add_field => {
"es_query_config" => ["tag1:( defined [request][time] )", "tag2:( and ( or ( eq testField 10 ) ( defined [request][verb][field] ) ) ( range [request][time] gt 2021-01-01 ) )"]
"[request][verb][field]" => "GET"
"[request][status]" => "404"
}
count => 1
}
}
filter {
ruby {
code => "event.set('[request][time]', Time.now());"
}
elastic_query_filter {}
}
output {
stdout { codec => rubydebug }
}
安装过滤器后，可以使用上面的配置运行 logstash 来测试过滤器插件，输出事件应该包含值为 tag1 和 tag2 的字段 matched_query_tags
bin/logstash -f logstash_test_conf.conf
结论
Java 执行引擎的性能与 Ruby 执行引擎不相上下，甚至更好。现在，如果你像我一样喜欢用 scala 编码，我们可以使用 java 进行更快的插件开发，以及来自其丰富的生态系统或 scala 的其他好处。上面的说明应该可以指导你如何在 scala 中编写插件。如果你的插件项目需要根据事件是否匹配 Elasticsearch 风格的查询对事件采取一些行动，你可以使用代码这里
基于成千上万的 API，在 API 和应用中处理时区、时间戳和日期时间的最佳方法和格式是什么
原文：https://www.moesif.com/blog/technical/timestamp/manage-datetime-timestamp-timezones-in-api/
背景
假设您有一个应用程序(移动或网络)，通常您希望显示终端用户的当地时间。但是，您的数据库仍然需要存储时间。虽然这是一个常见的场景，但经常会出现几个问题:
- 您应该如何在数据库中存储用户的时区？
- 你什么时候把它转换成当地时间？
- 假设您在客户端和后端之间有一个 API，时间戳应该如何表示？
- 日期时间将以什么格式存储在数据库中？
数据库如何存储日期时间
数据库被设计成高效地存储日期，最小化空间，同时尽可能快地进行查询。因为整数比字符串更容易查询、索引，并且空间效率更高，所以日期通常存储为 64 位整数，例如以毫秒为单位的 unix 纪元。作为数据库的用户，您通常不需要关于实现细节的详细信息，因此可以利用数据库提供的date或datetime数据类型。应该没有理由将日期存储为原始字符串或 bigint。
数据库会将任何datetime转换成 UTC 纪元以存储在内部。但是，一些数据库可能支持存储时区信息。如果是这种情况，建议在存储之前将所有日期转换为 UTC。
不要使用本地时区。否则，当您的数据库部署在跨多个时区的多个数据中心的高可用性设计中时，您将会非常紧张。
在 API 中使用什么格式
移动应用和单页应用等前端客户端需要通过 API 与后端通信，这些 API 可能有datetime字段。像数据库一样，为了保持 API 的一致性，HTTP 响应的有效负载应该总是使用 UTC。然而，你的 API 应该遵循健壮性原则:在你做的事情上要保守，在你从别人那里接受的东西上要开明。因此，您的 API 应该解析 HTTP 请求体或 URL 参数中的任何时区，而不需要 UTC。一些 API 将时区信息的缺失默认为 UTC。
与大多数数据库不同，JSON 中没有本地的datetime数据类型，因此日期必须存储为 JSON number或 JSON string。这两种方法都可行，但是应该遵循标准，这意味着日期字符串应该被格式化为 T4 的 ISO 8601 格式之一。日期数字应该存储为 Unix 纪元时间和指定秒或毫秒的 API 契约。
这两种方法之间存在分歧。Twitter、DropBox、Segement.io APIs 使用 ISO 8601，Chargebee、Pusher 和 Stripe APIs 使用 Unix Epoch Time。
我们 Moesif 更喜欢 ISO 8601 ( yyyy-MM-dd'T'HH:mm:ssZ)，因为它是人类可读的，并且有特定的时区。如果历元是以秒或毫秒为单位，则没有歧义。ISO 8601 字符串是以一种支持体面的字符串排序和比较的方式编码的。
Epoch 也比 ISO 8601 有优势。如果您正在处理大容量传感器数据或物联网设备的 API，您可能需要 epoch，因为它支持较小的有效载荷，无需考虑压缩，并且更熟悉来自物联网/嵌入式背景的数据。
存储用户的时区并以当地时间显示
首先，决定是否需要存储用户的时区。
如果您的需求是在应用程序中只显示用户本地时间的日期时间，您甚至不需要存储用户的时区。浏览器 javascript 和移动 API 可以根据用户设置的时区和地区转换日期时间并打印出来。
但是，您可能会发现，您稍后将执行后端处理来启动与您的用户的通信，例如 Slack 警报或电子邮件。在这种情况下，您可能会在数据库中缓存用户的时区/地区信息。因此，您可以在发送提醒或电子邮件之前转换并漂亮地打印任何日期时间。
避免存储 UTC 偏移量的陷阱，因为偏移量经常会因夏令时等因素而改变。建议存储时区标识符，如America/Los_Angeles。有一个大多数日期时间库本身支持的时区的完整列表。
摘要
如果您有一个全球应用程序或 API，管理不同时区一开始看起来很有挑战性。这篇文章基本上概述了保持简单的策略，并且在向用户显示之前一直使用 UTC 时间。
Moesif 是最先进的 API 分析*台，支持 REST、GraphQL、Web3 Json-RPC 等。成千上万的*台公司利用 Moesif 进行调试、监控和发现见解。
在不确定时期营销你的 SaaS *台
原文：https://www.moesif.com/blog/developer-marketing/Market-Your-SaaS-Platform-To-Developers/
如何在不确定的时期向开发者推销你的 SaaS *台
健壮的 API 和开发者*台对不确定性具有弹性
在数字*台上创建一个有凝聚力的营销形象不仅对加强品牌知名度，而且对消费者参与度都至关重要。虽然为最坏的情况做计划从来都不是一件有趣的事情，但是必须有适当的结构来利用长期的解决方案来应对(希望)短期的下降趋势。冠状病毒疾病的溢出效应和随后的就地安置给初创企业带来了严重后果。由于就地安置规则而关闭的小型实体企业不再花钱在脸书或 Yelp 上推广他们的业务，也不会维持他们的 SaaS 订阅。大型企业可以也将会在预期业务下滑的情况下缩减销售和营销支出。虽然不能保证，但这种行为会导致 SaaS 合同的使用或座位数的减少。首席财务官和财务总监将阻止比以前更多的收购，这可能会迫使 SaaS 的交易陷入僵局。..
好消息是，许多开发人员*台和 API 都有一些技巧，可以让他们更好地适应快速变化的环境。然而，如果你今天没有执行这些想法，现在是时候重新考虑，以确保你的产品和/或公司的寿命。
专注于自助服务业务
在不确定时期，许多大型企业由于自身的财务限制，不愿投入财力和人力资源来开展有偿试点或签署大型企业合同。你可以通过案例研究和强大的客户标识获得最好的社会证明和量化数据，但副总裁可能已经收到冻结所有非关键任务支出和招聘的指令，让他们别无选择。从积极的一面来看，许多高级工程师和经理都有 SaaS 工具的自由支配支出预算。
虽然预算可能很小，仅允许每月 100 美元到 1000 美元之间的支出，但这些支出通常不需要签核或批准。通过正确的基于使用的定价模式，您将能够随着时间的推移扩展这些帐户，甚至可能接*您通常在小型企业协议中看到的 ACV，即使客户是通过信用卡按月支付。当你的竞争对手眼看着他们的销售渠道枯竭并解雇大量销售人员时，你开始获得自助服务客户，一旦他们的市场开始复苏，他们的使用可能会迅速增加。
防止你的定价策略被愚弄
自助服务企业有多种定价方式。通常，您希望使用价值指标而不是成本指标来定价。但是，您可以利用多个价值指标。理想情况下，确保您的定价支持自动追加销售，即使在裁员的情况下也是如此。例如，通过 CRM 中的联系人数定价的销售工具或通过 MAU(每月活跃用户)定价的营销工具将比利用每席位定价的工具做得更好。大量裁员会导致公司重新协商降低座位数。然而，很少有公司会经历 MAU 或联系人数的下降。
虔诚地追踪你的采纳漏斗
如果你还没有任何产品分析工具，现在正是时候。尽你所能探测一切。检测您的 API。检测您的 web 应用程序。确保每个广告或外部链接都利用了 UTM 参数。。这使您能够了解哪些获取渠道具有最高的投资回报率，并推动产品增长。漏斗顶端的增长不再理想。你应该只投资直接转化的渠道。对于大多数开发人员*台来说，这意味着客户实际上已经集成并正在积极使用您的 API。如果你只是在衡量页面浏览量和注册量，那就停下来重新评估一下你的真实想法
建立你的在线形象
随着会议线路慢慢恢复生机，现在是时候考虑一下你的在线表现了。创建博客帖子和网络研讨会，既可以发布到您自己的博客上，也可以联合发布到您的空间中的合作伙伴。内容的关键是确保它的真实性和相关性。高质量的内容几乎总是胜过纯粹的数量。通过创建内容，你增加了你在有机搜索中的存在，但你也获得了其他好处。例如，潜在客户将通过社交渠道分享内容，让你免费获得额外的曝光率。您还可以在跟进潜在客户时利用这些内容。你可以通过分享内容让他们按照自己的节奏消费来展示价值，而不仅仅是“让我们安排一个时间来聊天”这样一致的暗示。
最小化流失风险
在任何不确定时期，识别和最小化客户流失风险变得比漏斗增长顶部更重要。很多时候，我们可以通过重新安排已经注册和/或正在付费的潜在客户的优先顺序来找到额外的增长。您应该有一个机制来跟踪帐户健康状况，并在情况不妙时得到提醒。需要注意的事项:
- API 使用率逐年下降的客户
- 仅访问一个或两个终端的客户
- 查看下降较高的 SDK，这可能表明存在缺陷或缺少文档
- 具有大量错误或延迟(如未经授权的错误)的客户
- 尚未访问您的主要价值创造端点的客户
关注客户的成功和开发者的支持
取决于你的公司，你可能有一个更传统的客户成功部门，或者可能有一个 devrel 组，开发人员支持接管一些更传统的客户成功职责。在任何低迷时期，你当前的客户都是你最大的支持者。让他们用你的 API 和令人敬畏的开发者体验获得成功，他们会告诉他们的同事和朋友。一些小事情包括跟进那些已经集成了你的 API 的开发者，看看他们在构建什么，你能提供什么帮助。如果您发现客户遇到了集成问题，请伸出援手。
寻求合作和整合
当付费营销预算缩减，销售人员减少时，实现同样的增长里程碑可能看起来像是一个梦想。然而，有无数的开发者*台利用合作和集成来实现有机的低成本增长。看看任何一家提供你可以上市的市场的公司，比如 GitHub、Heroku、AWS 等等。因为其中一些可能会减少你的知名度拥挤，你也应该看看其他 SaaS 工具，你的目标买家也在使用。如果你是一个营销工具，也许与 Hubspot 整合是有意义的。如果您是一个 API 监控工具，那么构建与 PagerDuty 和 Slack 的集成可能是有意义的，这样您的客户就可以通过他们现有的设置获得警报。
总结想法
向开发者推销一个 API *台是困难的。通常营销和销售预算需要减少，企业更不愿意签订新合同，等等。通过关注你的采用漏斗，寻找廉价的增长渠道，如内容和合作伙伴关系，可以奏效。
衰退期间对开发商的营销
这是德里奇·吉利恩 在 DevRelCon Earth 2020 上的演讲。
https://www.youtube.com/embed/Ph3KeQezQXY?start=17075
下面是附带的幻灯片。
//www.slideshare.net/slideshow/embed_code/key/Ieri5aXOZ31Suj
掌握 API 程序的 API 分析:开发者漏斗
你有一个开发人员正在采用的 API 程序，但是不确定采用了多少。新的集成需要多长时间才能产生收入？如果你有网络或移动产品管理背景，你可能已经熟悉了用于衡量应用参与度和留存率的移动产品分析。成长中的 API 有相似的 KPI 来衡量你的 API 程序的成功。本文将更多地讨论您应该测量什么以及如何利用这些信息。
开发者漏斗
而传统的客户漏斗将仅由营销和销售漏斗组成。然而，作为一种产品，客户和合作伙伴包括开发人员的 API 拥有所谓的开发人员漏斗或集成漏斗。开发者漏斗在营销漏斗之后，销售漏斗之前，有三个核心阶段:
预整合阶段
开发者进入营销漏斗后的预整合阶段。虽然什么是营销漏斗，什么是开发者漏斗，这是一个模糊的概念，但意图是主要因素。他们只是在考虑通过案例研究、内容和演示账户等明确定义的营销资产来开发解决方案，还是承诺自己测试解决方案。
一旦评估或考虑阶段是积极的，就有测试的意图。这将导致开发人员开始安装，这可以通过创建一个空白工作区、下载一个配置文件或复制一个 API 密钥来看到。
这意味着你的产品是免费增值，有免费试用，或其他。
沙盒阶段
一旦在 API 上采取了一个动作，潜在客户就进入了沙盒阶段，这给了开发人员一种温暖的感觉，他们完成了一些事情，并且能够验证这是一个对他们来说可行的解决方案。从预集成阶段到沙盒阶段的时间通常用到第一个 Hello World (TTFHW)的时间来衡量。这是一个关键的 KPI，每个 API 产品经理都应该尽可能地跟踪和减少它。
开发人员可能不会进入沙盒阶段，原因有很多，包括:
-
集成问题，如 SDK 或实现中的错误和 bugs】
例如，如果开发人员从您的 API 收到 500 个错误，或者 SDK 没有对您的 API 进行任何调用。后者是最难衡量的，因为开发人员完成了实现，但您没有采取任何行动。
-
没有简单的方法来验证实施是否正确
如果你的产品在集成后看起来是空的，开发者可能会认为它不起作用。对于安全和分析公司来说，这种情况可能会发生，因为在处理大量数据之前，这些公司不会有有意义的见解。
-
对 API 采取了行动，但不清楚值是什么
这个行动应该有一个明确的价值，而不仅仅是一个“你被整合了”的信息对于通信 API，该值可能是发送一条 SMS。对于分析公司来说，它可能是捕获和显示单个事件。
当集成成功并且有明确的价值标志时，开发人员就进入了沙盒阶段，从而创造了你的啊哈时刻。这些开发人员开始成为您的解决方案的内部倡导者。
生产阶段
一旦开发人员看到了解决方案的价值，他们就会希望尽快将他们的实现推向生产。然而，由于内部的阻碍，开发者可能无法将你的 API 推向生产，很多阻碍都超出了开发者个人的控制范围。
开发人员可能出于多种原因不进入生产阶段，包括:
-
项目优先级
客户错误或其他项目特性可能会优先考虑。您的通信 API 集成退居二线，只是因为开发人员被分配了一堆吉拉入场券。
-
法律与合规部
特别是在金融和卫生等受监管的行业，开发人员可能必须等到法律部门的必要批准。
-
功能和性能测试
公司可能有测试第三方服务的内部政策，这些服务需要首先完成。
您的目标是让开发人员拥有正确的工具来消除这些异议。一旦开发人员进入生产阶段，就会有大量的流量从该帐户流向您的 API。达到生产级流量所需的时间可以称为到第一个工作 App 的时间 (TTFWA)或到第一个付费 App 的时间 (TTFPA)。
创建漏斗目标
为了对你的 API 业务有一个准确的快照，每个漏斗边界都需要明确的目标。让我们以搜索 API Algolia 为例。
集成前步骤目标
Algolia 的第一步将是开发人员使用 API 密钥复制功能。此时，开发人员已经注册，并且正在经历入职流程。
沙盒步骤目标
Algolia 的 API 有两个核心特性。查询或搜索 API 和索引 API。Algolia 的成功标准是开发者能够通过索引 API 索引至少一个实体。如果开发人员在 Algolia 中没有存储任何数据的情况下调用查询 API，这不被认为是成功的，因为查询将是空的。
为了简化集成，他们可以:
- 驱动用户通过
POST /1/indexes/端点索引新实体 - 使用示例数据引导开发人员可以查询的示例索引
假设我们使用(1)，那么我们的漏斗转换点将是任何至少执行了一个POST /v1/indexes操作的开发者。Algolia 可能想要一个更严格的转换指标，以便他们可以跟踪任何至少执行了一个 POST /v1/indexes操作和一个 POST /1/indexes/{indexName}/query操作的开发者，其中响应内容长度> 0 。这意味着开发人员成功地索引了至少一个实体，并且能够读回它。
生产步骤目标
为被认为是生产级别的流量创建一个指标可能很难，因为它可能依赖于行业或项目。对于 Algolia 来说，电子商务应用程序与拥有大量动态内容的内部企业应用程序相比，具有不同的生产使用级别。对于具有动态内容的企业应用程序，每个实体可以用更新的数据以编程方式在一天内被重新索引数十或数百次。但是，如果数据从来不被查询，那么 Algolia 的值还没有被看到。因此，只寻找拥有超过 1000 个POST /1/indexes/操作的开发人员可能不是跟踪的最佳价值指标。一个更好的价值衡量标准可能是拥有超过 1000 个 POST /1/indexes/{indexName}/query操作的开发者，其中响应内容长度> 0 。
请注意我们如何关注 Algolia 的核心价值，即搜索。我们不太关注辅助功能，如 Algolia 的监控 API、报告 API 等，也不关注高级功能，如同义词或规则 API。
开发者群体细分
现在我们已经了解了开发者漏斗每个阶段的转化率，重要的是利用 API 分析来了解不同的开发者群体如何通过你的开发者漏斗。没有它，你会有一种虚假的成功感。
例如，从预集成到生产阶段，您可以有很高的转换率，但是如果大多数开发人员在没有购买力的情况下从事辅助项目，那么您可能需要重新评估您的目标。
建立用户和公司的档案
为了进一步细分你的漏斗，你的 API 分析解决方案应该有办法创建用户简介和公司简介。建议在用户配置文件中跟踪的变量包括:
- 电子邮件
- 名字
- 职称
- 参考网站
建议在公司中跟踪的变量包括:
- 公司收入
- 雇员人数
- 工业
- Alexa 等级
- MRR 计划
一旦你有了这些信息，你的开发者漏斗分析就会变得更有价值。您可以看到谁在集成，谁没有，而不仅仅是跟踪高层次的集成之旅。例如，我们可以通过公司收入进行细分，以比较从事副业项目的用户转化率与财富 500 强公司工程师的转化率。
将公司(即客户)与用户分开跟踪，确保您能够创建使用您的解决方案的组织中开发人员或团队数量的指标。
理解 API 设计
就像建立用户和公司的档案一样，你的 API 分析解决方案应该理解你的 API 的业务功能。如果您的 API 是 rest，那么只跟踪POST /items/1和POST /items/2将没有价值。然而，添加与 API 事务相关联的元数据可以为您提供更高级别的使用模式趋势。例如，如果您的 API 是 RESTful 的，那么您的分析解决方案应该将 API 事务存储到一个特定的 REST 资源操作中，比如POST /items/:id。这支持更高级别的图表，如下图所示，显示了使用每个 REST API 操作的顶级公司。
定义 API 项目
在我们深入研究获取渠道绩效和 API 增长等关键业务指标之前，我们需要定义什么是 API 参与度。毕竟，一个开发人员仅仅触及你的根端点或者仅仅探查 API 的健康可能不被认为是真正的参与。继续 Algolia 的例子，Algolia 的核心商业价值问题是快速搜索。因此，他们定义 API 参与度的标准是客户在过去 28 天内至少执行一次搜索POST /1/indexes/{indexName}/query。
衡量开发商收购
有效的新客户获取可以成就或摧毁一个原料药企业。在衡量不同流量来源的在线营销活动的有效性时，必须考虑开发者漏斗中定义的三个步骤的转化率。API 产品营销领导应该超越注册等基本指标，考虑开发者集成漏斗。这使您能够了解这些注册在整合步骤中进行了多少。
例如，像脸书广告这样的渠道可能会给你的 B2B 解决方案带来很大的影响，但如果这些注册中有很小一部分由于目标不明确而最终通过了整合过程，那么你的渠道的整体有效性就会降低，因为你不太可能从那些只注册而不做任何其他事情的人那里获得太多价值。
如何正确衡量开发者营销渠道
如果我们同步营销数据，例如来自营销自动化和分析工具(如 Hubspot 或 Amplitude)的海胆跟踪模块(UTM)参数，那么我们可以在队列分析中利用这些数据。这使我们能够利用我们早期的开发者漏斗，并通过渠道进行细分。一旦我们做到这一点，我们就能够看到按活动细分的每个步骤的转化率。
什么是 Moesif？ Moesif 是最先进的 API 分析*台，被数以千计的*台用于了解您最忠实的客户正在使用您的 API 做什么，他们如何访问它们，以及从哪里访问。
衡量 API 增长和参与度
API MAU 和 API DAU
如果你想跟踪你的 API 程序的增长，那么 API 月活跃用户 (API MAU)和 API 日活跃用户 (API DAU)是每个数据驱动的产品领导者应该跟踪的两个 KPI。
这类似于 web 和移动 MAU，可以提供增长指标和 KPI 的高级概述。然而，API MAU 不是跟踪执行 UI 交互(如在应用程序中点击按钮)的不同用户，而是跟踪执行与 API 的编程交互的不同用户。根据您所在的行业，不同的用户可以是个人用户或开发人员，也可以是不同的公司或帐户。像 Moesif 这样的 API 分析产品可以跟踪哪个对账户级分析至关重要。
为什么是 28 天？
尽管我们说的是 MAU，但我们实际上应该衡量固定的 28 天窗口中的活动，而不是整个月。通过使用 28 天，我们能够忽略由于一个月中的天数不一致而产生的偏差。此外，28 天确保每个时间窗口在同一个工作日开始。这保证了我们在每个时间窗口中总是有相同数量的工作日和周末。许多公司，尤其是 B2B 公司，在周末的使用水*与工作日不同。通过保持这些数字的一致性，我们可以消除这些偏见。
28 天 API 使用量/28 天活跃公司
您还应该跟踪每个活跃公司对同一合约定义的总 API 使用量。API 使用量只是 API 调用子部分的总 API 使用量，而不是计算不同的用户。通过按活跃的公司划分 API 的使用，您可以跟踪每个客户是如何随着 API 的发展而增长的。该指标是收入增长的领先指标。如果 API 使用量/活跃公司数持*(或者更糟的是下降)，您的 API 不会随着客户的增长而增长，并且可能很难推动销售突破计划限制。然而，随着 API 使用/活跃公司的快速增长，API 计划将享有不断增长的*均合同价值和总收入。当然，这假设你的定价是基于一些使用指标，比如 Algolia 的搜索操作或索引操作。
独特的 API 操作/应用
如果你有一个像 GitHub 或 Intuit 的 API 一样有数百个独立功能和实体的 API，那么测量每个应用程序调用多少个独立的函数可以帮助你了解 API 使用的广度。将此绘制成直方图有助于找出完全使用您的 API 的高级用户与可能只使用一两个端点的其他开发人员相比所占的百分比。如何跟踪不同的 API 操作将取决于 API 的架构。例如，如果您的 API 是 REST，那么您可能有 REST 端点，如:
GET /items
GET /items/:id
POST /items
GET /users
GET /users/:id
POST /users
GET /purchases
GET /purchases/:id
POST /purchases
...
然而，如果您的 API 是 GraphQL，您可能希望跟踪查询和变异操作，如:
getItems
createItem
createItem
getUsers
getUser
createUser
getPurchases
getPurchase
createPurchase
结论
如果您打算构建一个不断增长的 API 程序，那么您应该跟踪许多更深入的 API 指标。然而，如果您还没有开始采用数据驱动的方法，这些指标是一个很好的起点。随着您的 API 程序的发展，您将跟踪其他 KPI，这些 KPI 可以显示您的 API 程序的健康状况。像 Moesif API Analytics 这样的工具可以帮助您通过快速安装 SDK 来开始测量这些指标。
掌握 API 程序的 API 分析:群组保持分析
对于*台业务来说，很少有指标比留存率更重要。如果你以 25 美元获得客户，但是他们在一个月后停止使用你的 API，那么你就有一艘漏船。在留住人才的问题解决之前，不要在开发人员获取上花更多的钱。这需要准确测量原料药的保留率。
如果你来自网络或移动产品背景，你可能已经熟悉了移动留存来衡量有多少获得的用户保持使用一个移动应用。发展 B2B *台需要跟踪类似的 KPI 来衡量你的收购和产品策略的成功。本文将深入探讨跟踪和提高 API 保持率的最佳实践。
什么是 API 保留？
保持率衡量的是一群人中再次使用你的产品并保持活跃的用户的百分比。对于您的产品，什么被认为是有效的取决于产品的类型。对于流媒体移动应用程序来说，在某一天活跃可能意味着播放一首歌曲。对于一个支付 API，它可以在一天中处理一次信用卡支付。
为了准确地测量用户保持率，你需要将你的用户分成不同的群体。通常，这是通过注册日期来完成的，但对于 API，建议根据集成日期或第一个 Hello World 的时间来划分。这是用户第一次通过您的 API 集成并进行第一笔交易的日期。然后，每天、每周或每月，我们都会统计返回并执行某项操作的独立用户的数量，您认为这是活跃的有力指标。
下图显示了按第一次 API 调用日期划分的新用户。从那里，我们跟踪每天仍然活跃在我们的 API 上的用户的百分比。该图表显示，37.5%的新用户在集成后的第一天仍然在积极地进行 API 调用。整合五天后，只有 24%的初始队列仍然活跃。
什么是良好的 API 保留率？
虽然只有 24%的群组在集成后 5 天内是活跃的，这看起来并不算高，但根据您的使用情况，此图表可能相当不错。留存不应衡量参与度或粘性水*。相反，您应该使用保留曲线来查看有多少用户被保留。最好的方法是判断曲线有多*坦。
保留曲线持续下降直至达到 0%的产品保留性较差。然而，保留曲线变*或略微上升的产品具有良好的保留。
第一天应该有最大的衰减。大多数*台都有一批注册的开发者，他们在沙盒里摆弄 API，但永远不会回来。一旦客户发现了价值，他们会在第二天、第三天继续使用 API，以此类推。这些用户发现了 API 的价值，并保持整合。另一方面，如果你的 API 或者 SDK 有问题或者不能提供即时的价值，开发者会逐渐移除他们的实现，导致留存率逐渐下降到 0%。
与上图不同，下图显示了糟糕的 API 保留情况。
请注意，在这种情况下，保留率一直下降到 0%。
按细分市场细分
以前，我们关注的是整个用户群。然而，要更深入地探究为什么保留率下降，重要的是找到驱动这种下降的变量。一种方法是将您的用户分组到桶中。这可以通过用户属性来划分，比如他们来自哪个国家，用户获取渠道，甚至是产品特定的信息，比如开发者使用的 SDK。
在这种情况下，我们可以更清楚地了解是什么推动了长期保留。虽然整体保留曲线相对*坦(即良好的保留)，但我们看到大多数非美国客户下降到 0%。只有美国用户继续利用 API。我们应该进一步调查为什么非美国用户不使用这个 API。是因为高延迟吗？非本地化文档？阻止收养的当地法律和法规？在金融、医疗保健和其他受监管的行业尤其如此。
定义初始和返回操作
从商业角度来看，退货行为应该是只有活跃用户才会做的事情，并从你的产品中获取价值。为了正确测量保持力，你需要定义初始动作和返回动作的。虽然不是必须的，初始动作通常是新用户使用你的产品的第一个动作。
以前，我们只是跟踪第一次进行 API 调用的新用户，然后进行任何返回 API 调用的。然而，我们可以更具体地了解那些初始或返回动作是什么。
例如，我们可以认为只有当用户返回并在 API 上进行支付交易时，用户才是活跃的。
例子
假设您正在构建一个管理信用卡交易的支付 API。API 提供的主要价值是通过信用卡处理支付，因此商家得到支付，因此我们考虑每天通过 API 处理至少一次信用卡支付的活跃用户。
对于 API，我们可以按如下方式跟踪留存率:
首次事件标准:
- 第一次调用 API 的新用户
返回事件标准:
- 回来并至少进行了一笔支付交易
结论
如果您打算构建一个不断增长的 API 程序，那么您应该跟踪许多更深入的 API 指标。然而，如果您还没有开始采用数据驱动的方法，这些指标是一个很好的起点。随着您的 API 程序的发展，您将跟踪其他 KPI，这些 KPI 可以显示您的 API 程序的健康状况。像 Moesif API Analytics 这样的工具可以帮助您通过快速安装 SDK 来开始测量这些指标。
最大化您的 API 收入
原文：https://www.moesif.com/blog/developer-platforms/api-analytics/Maximize-your-API-Revenue/
国际货币基金组织(IMF)预计，未来几年全球经济增长将大幅放缓，从 2021 年的 6.1%大幅降至 2022 年和 2023 年的 3.6%。与此同时，路透社的民意调查显示，T2 的全球高通胀还远未结束。
因此，企业需要竭尽全力实现收入最大化——不是通过增加新基础设施的支出，而是通过从现有产品中获得最大商业价值。你已经在构建你的 API 上花费了大量的财富，不要通过低价出售它。
基于使用的计费使您能够实现 API 的真正商业价值。它允许您创建高度独特的过滤器来为特定的端点及其使用方式计费，而不是基于原始的原始计数。在从 API 中的数据推断可操作的见解方面，Moesif 一直处于领先地位。现在，您也可以使用这种密集的粒度审查来货币化您的 API。
底线呢？更好的底线。
如何最大化你的 API 的商业价值
Moesif 的基于使用的计费意味着您可以将 API 调用或 API 有效负载中的任何参数货币化——您可以计量特定的端点、交易计数、独立用户、数据量、美元量或*台上任何其他基于使用的指标。通过 Moesif 的计费表，您可以快速试验不同的定价杠杆，看看如何获取最大的收入增长和扩张收入
起床跑步很容易。当实时患者预约*台 NexHealth 实施基于使用的计费时，一个人不到一周就完成了系统的集成、全面测试和部署。
“Moesif 允许我们灵活地采用基于 API 使用、基于呼叫或任何类型的定价模式。我们很快就可以开始向客户收取 API 使用费用，这很快成为我们的收入来源。”NexHealth 总经理 Paul Fung。
Moesif 位于您的应用程序/API 和您首选的计费提供商 Stripe、Recurly、Chargebee 等之间。我们的*台计算并向计费提供商发送数据。这意味着您可以根据客户的使用情况准确地向他们收费，而易于使用的仪表板则允许您直观显示使用情况并跟踪付款情况。
我们还提供了一个嵌入式的非品牌仪表板，您可以与您的客户共享，让他们清楚地了解他们需要的一切。与此同时，行为电子邮件让他们的客户了解和更新他们的使用水*。
无需任何代码，只需在配置设置中点击几下，就可以启动并运行 Moesif 的计费系统。然后，您可以跟踪客户对您的 API 的使用情况，获得非常灵活和可定制的基于使用情况的 API 计费选项。
为今天交付，为明天规划
当涉及到您的 API 和您的客户时，数据安全性是最重要的。这就是 Moesif 提供 SOC 2 合规保证的原因，它对静态和传输中的数据进行加密。公司还可以利用 Moesif 客户端加密功能，使其数据对组织保密或满足监管要求。我们提供您今天需要的安全性，使您能够为明天建立一个利润更高、更具前瞻性的企业。
通过在我们的分析*台上构建基于使用量的计费产品，我们将 Moesif 多年的知识和经验放在您的指尖。我们在分析方面的专业知识为我们基于使用情况的计费产品提供了更精细的细节，这意味着您现在可以最大化每个 API 的商业价值。
它不仅有可能增加你的利润，而且基于使用的计费也能吸引你的客户。过去几年是一个强有力的教训，说明公司需要灵活。借助这种计量计费安排，您的客户可以根据需要灵活地扩大和缩小规模。他们可以这样做，同时坚持与你的业务，减去任何尴尬的谈判，试图缩减固定利率合同，不再适用于他们的变化情况。结果呢？更快乐的客户和更高的忠诚度。双赢。
是时候发挥你的潜力了
如果你遵循传统的 API 使用计费方式，那么你就是在浪费钱。鉴于国际货币基金组织对未来几年相当黯淡的全球前景，现在真的是随波逐流、让潜在收入收不回来的时候吗？即使不考虑当前的经济环境，充分利用您已经投资建设的基础设施难道不合理吗？
Moesif 基于使用量的 API 计费使你的 API 产品前所未有的货币化成为可能。快速且易于实现，它可以最大化 API 的商业价值，同时让您的开发人员和产品团队以及您的客户满意。
您可以在此阅读更多关于基于使用的 API 计费的详细信息或联系 Moesif，了解您的需求或安排演示。我们在这里支持你把你的 API 货币化到一个新的水*。
会见 Moesif 与 AdOps 经理雷切尔基舍列夫
原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-with-AdOps-Manager-Rachael-Kiselev/
你能想象用两只猫在你腿上喵喵叫来解释 API 的可观测性吗？认识一下我们的常驻多任务专家，雷切尔·基舍列夫。她是用不到 300 个单词宣传一种全新的分析 API 的方法的策划者。作为我们 Meeting Moesif 博客系列的一部分，我们向她询问了关于 API 的未来，以及在全球疫情期间从一名新毕业生转变为技术营销人员需要做些什么。
你的职称是什么？你的工作需要什么？
我是一名内容营销经理，但这确实是一个相当不固定的头衔。我负责与内容相关的数字营销。你可能在 Reddit 等网站上看到的很多数字广告都是我的。嗯，它们是营销和设计的共同努力，以创造一个有凝聚力的广告战线。我处理一些 SEO 实践，比如 UTM 给博客文章加标签，或者在 Moesif 其他员工写的文章中加入行动号召。作为一名多面手，我也在业余时间支持营销团队。因此，从转录播客到做竞争对手的研究，等等。我尽量专注于支持销售漏斗。
我们刚刚从改变了一切的全球化疫情中走出来。你的职业生涯和你的余生是如何发展的？
在 COVID 之前，我实际上刚刚从大学毕业。所以真的，我在工作世界中没有任何真正的“工作”经验，更像是之前的亲身实习。当我毕业时，我在一家非营利组织工作，管理他们的谷歌广告词、时事通讯之类的东西。当第一次封锁开始时，我结束了在一家小的精品代理处的工作。在那里的时候，我和很多人一样，完全处于偏远地区，非常怀念面对面的交流。这有点孤独，只能通过聊天或缩放来交流。
当我离开那个职位时，我知道我想去一个允许远程工作的灵活性，但提供面对面协作空间的地方。由于海湾地区的人数下降，Moesif 的员工已经能够根据自己的意愿在办公室工作。在我最初的入职经历后，我成了一名“灵活”的员工，所以我每周至少来一次，但每周不超过两三天。这对我有好处，因为我住在离半岛很远的地方，直到最*，我们的公共交通系统才增加了更好的空气过滤器。简而言之，去办公室的通勤可能会有点拥挤，所以最好不要每天都这样。此外，在家工作意味着我可以实时处理家里出现的问题，而不是对我的猫留给我的礼物(和混乱)感到惊喜。
你认为 Moesif 适合 API 的未来吗？
我想在理想的世界中，API 看起来不会像今天一样，这意味着今天的 API 很可能会与明天的 API 有所不同。我认为 Moesif 是随着 API 环境的发展，公司将进行的变革的一个组成部分。我认为 Moesif 将继续加深客户对其 API 的理解，从而推动细分市场的发展。我认为 Moesif 最大的价值是能够挖掘 API 来理解和货币化 API 的使用。因此，能够站在事物的最前沿，让公司有机会迭代和改进他们的 API，将有助于整体技术的发展。同样，我们已经看到 API 经济已经从 REST APIs 转向 GraphQL，所以 API 格局已经发生了变化。我认为在接下来的几年里，我们将扩大我们的支持能力，并成为 API 优先公司的一部分，以保持迭代和技术的前沿。
你的工作空间是什么样的？
坦白说，很乱。我工作时的桌子看起来没人住，除了我的一个小丙烯酸支架。我的键盘和鼠标还在它们的盒子里。在家里，我的办公桌上有几台显示器，但通常我会把时间分配在办公桌和沙发上。我一气呵成地掌握了高效工作和毁姿的艺术。还有，我的猫跟随着我，所以它们是我的额外同事。
你能告诉我们一些关于你的背景，以及你是如何进入 Moesif 的吗？
我过去的经验是倾向于数字营销。我有一个广告学学位和一个信息科学辅修专业，但最终选择了市场营销。我的很多辅修专业都围绕着数据聚合和可视化(重点是关于信息的道德和政策)。我认为我的分析背景加强了我的营销和广告技能，因为数据驱动一切。Moesif 是一个“分析优先”的产品，这使我们成为一家天生的数据驱动型公司。就这一点而言，它感觉很适合我。
关于会见 Moesif
在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API *台。
会见 Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。
如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击链接查看其他 会议 Moesif 团队成员访谈。
会见 Moesif 和开发者支持者 Dylan Frankcom
原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-With-Developer-Advocate-Dylan-Frankcom/
Dylan 是 Moesif 的一名助理开发人员。他最*刚从加拿大安大略毕业，是开发人员宣传的新手。他拥有独立软件开发人员的经验，为许多开源项目做出了贡献，并为 Mac 和 iOS 发布了软件。作为我们 Meeting Moesif 博客系列的一部分，我们询问了他在 Moesif 中的角色，他如何处理在不同国家的远程工作，以及他对 Moesif 适应当今和未来 API 环境的看法。
你的职称是什么？你的工作需要什么？
我是 Moesif 的一名助理开发人员。我本质上是一名开发人员，作为开发人员的拥护者，我有责任向其他开发人员详细介绍我们的产品和*台。这项工作需要通过各种媒体展示我们的产品，并与其他开发人员合作，帮助他们充分利用我们公司的产品和服务。
开发者倡导者可以承担许多不同的角色。有些人在内部支持开发人员，与工程团队合作，帮助他们了解开发人员社区的需求。其他人在外部工作，通过活动、社交媒体和其他渠道与开发人员接触。在 Moesif，我尽力做到这两点。我觉得我在 Moesif 的角色非常明确:帮助 Moesif 为开发者提供最好的服务。
你完全远程工作；你是怎么把自己和工作分开的？
远程工作是一个很好的机会，可以很好地*衡工作和生活。这是我第一份完全远程的工作，最初，我担心如何管理我的时间并保持高效率。然而，我很快意识到远程工作是管理你的时间和保持高效的好方法。
关于远程工作，我学到了一些关键的东西，它们帮助我保持高效，并保持良好的工作/生活*衡。首先，有专门的工作空间是很重要的。这可以是一张桌子，或者是你房子或公寓里专门用来工作的特定区域。一个专用的工作空间有助于在你的工作和个人生活之间建立一个界限。第二，养成日常作息并坚持下去是至关重要的。这种日常生活可以包括休息，为深度工作留出时间，为个人生活活动安排时间。
帮助实现这种*衡的一个方法是利用无限带薪休假(PTO)。这让你有足够的时间充电，并在职业生活之外获得一个身份。Moesif 提供无限制的 PTO，可用于各种目的，如休假、个人时间和病假。
在远程工作时，健康的工作/生活*衡是一个重大障碍，因为如果你总是工作，你会筋疲力尽，这是显而易见的。所以花时间给自己充电是很重要的，这样你在工作的时候就能更有效率。
你的工作空间是什么样的？
我了解到在多个工作区之间分配工作有很多好处。例如，当你为特定的任务指定了区域，它可以帮助你保持更加专注和有效，不太可能分心或偏离方向。另一个好处是，它可以帮助你保持条理。不同类型的工作有不同的区域可以帮助你记录你的进度，最有效地利用你的时间。最后，将你的工作分成两个工作区也有助于提高你的工作效率。例如，当你有一个专门的空间来完成每一项任务时，你更有可能迅速完成它。这可以让你腾出时间做其他任务，或者给你一种成就感。
至于工作区本身，它们都是围绕 MacBook Pro 设计的，并考虑到了坞站。这使我的开发环境保持一致，同时能够在多个地点工作。我在办公室的主要工作区由典型的开发者显示器设置组成:一个是横向的，另一个是纵向的。我和我的搭档共用一间办公室，有时我们都远程工作。所以我们创造了我们喜欢称之为“不可知工作站”的东西。“不可知工作站”只有一个外部显示器、外部键盘、触控板和鼠标。根据我们每天的安排，我们会在办公室和工作站之间来回穿梭。我也喜欢在露台上喝咖啡开始我的早晨，同时由于时差的原因，补上一些错过的松散线索和前一天的概念票更新。
由于 Moesif 是一家小公司，你是否觉得有必要以你以前从未有过的方式进行领导？
是的，肯定的。我喜欢在小公司工作，因为这让我觉得我可以产生巨大的影响。小公司通常更灵活，可以更快地利用新的机会。他们也更乐于接受新思想，更愿意承担风险。这意味着员工通常有更多的机会直接影响公司的成功。我觉得我的工作与众不同，我可以帮助塑造公司的方向。当然，这也带来了更多的责任，但我认为这是值得的。
当你在一家小公司或初创企业工作时，你需要能够身兼数职。这有助于你变得自在，成为人们可以为各种任务而去找的人，无论是回答客户问题、开发概念证明，还是尝试可能不属于你特定领域的事情。
作为一名开发者倡导者，我负责与我们的客户交谈，了解他们的需求，然后在内部为他们辩护。然后，我与我们的工程和营销团队合作，帮助他们了解我们的客户如何使用我们的产品。这也告诉我如何开发内容，以帮助我们的客户充分利用我们的产品。我通过撰写指南和博客文章、制作视频以及帮助开发人员与客户沟通来支持我们公司的目标。到目前为止，这是一次很棒的经历！我也喜欢每个人为了共同的目标一起工作时形成的紧密团结的社区。
你认为 Moesif 适合 API 的未来吗？
目前，在开发 API 产品时，Moesif 可以在几个方面提供帮助。首先，通过了解您的 API 是如何被使用的，您可以做出关于改进它的明智决策。其次，Moesif 可以通过提供哪些功能最常被使用以及被谁使用的见解来帮助制定货币化战略。最后，通过了解哪些功能对用户最有价值，开发人员可以相应地为他们的 API 定价，并确保他们从最受欢迎的功能中获得收入。
我认为 Moesif 在 API 领域具有独特的优势。Moesif 分析套件附带的功能，如计量计费、治理和行为警报提供的不仅仅是统计和日志。能够在一个*台上利用分析提供的见解、行为电子邮件提供的即时客户支持以及计费表产生的收入来开发您的 API 产品，这确实改变了游戏规则。随着我们继续构建和增加这些功能，未来看起来很有希望。
关于会见 Moesif
在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API *台。 Meeting Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。
如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击以下链接查看其他 会议 Moesif 团队成员访谈。
会见 Moesif 和开发者关系主管 Matt Tanner
Matt 是 Moesif 的开发者关系主管。他目前居住在加拿大安大略省和爱德华王子岛。在进入开发人员关系之前，Matt 曾在多家大型企业担任软件开发人员、团队领导和架构师。作为我们 Meeting Moesif 博客系列的一部分，我们询问了他在 Moesif 中的角色，他如何处理在不同国家的远程工作，以及他对 Moesif 适应当今和未来 API 环境的看法。
你的职称是什么？你的工作需要什么？
我的职位是 Moesif 的开发者关系主管。这个角色相当多样化，因为你帮助公司的所有方面，包括营销、销售、工程和产品。成为这些部门之间的粘合剂和产品的主题专家对我们在开发人员关系中的角色至关重要。我们做任何事情，从写技术博客，与其他公司讨论潜在的合作机会，甚至坐在客户的电话上，从开发人员的角度帮助解释产品。在 Moesif 的开发者关系工作中，我们有一个目标:帮助 Moesif 成为开发者(以及所有 Moesif 用户)的最佳选择。
你完全远程工作；你是怎么把自己和工作分开的？
远程工作有利也有弊。你有很大的责任来确保你高效地完成工作，但是你也需要成为一个看门人来确保你有足够的时间离开工作。我坚信，当人们喜欢他们所做的工作，得到充分休息，并受到赏识时，他们的工作就做得最好。这是我在自己的工作和生活中为之奋斗的，也是为我们团队的任何人奋斗的。Moesif 在这方面做得很好。尽管如此，我非常喜欢在开发者关系领域与 Moesif 一起工作，以至于大多数时候我真的感觉不像是在工作。
你的工作空间是什么样的？
根据我所做的工作，我的工作空间看起来会有所不同。如果我需要对视频或书面内容进行一些深入的工作，我通常会使用带有大型超宽显示器的办公桌。如果我在进行销售拜访或其他会议，我通常会在房子的不同地方进行，以保持一天中我的环境不同。
在设备方面，我使用 17 英寸的 MacBook Pro，如果我不在办公桌前工作，我会使用 Sidecar 将我的 iPad 用作第二个屏幕。当您离开办公桌时，这种能力为您提供了极大的灵活性。
由于 Moesif 是一家小公司，你是否觉得有必要以你以前从未有过的方式进行领导？
多年来，我为许多小型创业公司工作，这是意料之中的。Moesif 的伟大之处在于，当你开始拓展并与公司的不同部门合作时，协作就发生了。这里确实有一种学习的文化，让每个人都有机会以他们想要的方式学习和领导。
Moesif 是一家鼓励每个人提问并充分理解我们正在构建的公司。甚至我们的销售和营销团队也完全了解我们的产品愿景和我们要解决的问题。如果有人想领导，总是有信任让一个人这样做，并支持确保他们也能成功。
你认为 Moesif 适合 API 的未来吗？
我认为 Moesif 适合所有产品的未来，包括 API。我们的*台允许任何企业分解他们做得好的地方和他们需要改进的地方。此外，我们为这些用户提供工具，让他们开始根据这些见解采取行动，并跟踪以确保他们所做的更改能够为他们的用户带来改善。如果有人正在开发一个产品或者希望改进一个现有的产品，无论是入职还是留任，等等。，那么 Moesif 就可以给他们工具集进行改进。
我真正感到兴奋的最后一件事是我们的计费表功能。过去我一直致力于将 API 货币化，我能体会到有效地实现这一目标有多难。借助计费仪表，我们可以通过一个非常简单的集成(设置大约需要 5 分钟)将使用数据发送到 Stripe、Recurly 和 Chargebee，设置计费标准，并在几分钟内将使用情况报告给提供商。对我来说，这确实是一个有助于巩固 Moesif 对 API 和 API 产品的未来的直接影响的特性。
关于会见 Moesif
在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API *台。 Meeting Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。
如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击以下链接查看其他 会议 Moesif 团队成员访谈。
与 SEO 经理萨凡纳·惠特曼会面
原文：https://www.moesif.com/blog/business/company/Meeting-Moesif-with-SEO-Manager-Savannah-Whitman/
会见 Moesif - SEO 经理萨凡纳·惠特曼
职业发展既令人害怕又令人兴奋，我们的 SEO 经理 Savannah Whitman 在加入 Moesif 之前就经历了这两种情况。现在，她正在培育搜索排名，将 API 可观察性的最新成果带给需要的技术人员。在本期会见 Moesif 中，我们将与她探讨 API 技术的发展方向，以及如何跟上它的步伐。
你如何描述你在 Moesif 的角色？
理论上？我是内部的 SEO 经理，确保任何对 API 可观察性感兴趣的人都能找到我们的建议。
真相？SaaS 的每个人都对 API 的发展方向有自己的看法。不是每个人都有像 Moesif 的以用户为中心的 API 分析这样的类别创建产品。这足以证明我们的知识库是针对那些在可能性边缘工作的技术专家的。这就是为什么我利用我的(不那么)神奇的力量让我们的内容在 Google、DuckDuckGo 或 API 爱好者搜索答案的任何地方弹出。
像任何初创公司的员工一样，我通常会戴不止一顶帽子。我实际上是从公关和数字营销开始的，所以我经常被 SEO 之外的项目所对待。
由于 Moesif 是一家小公司，你是否觉得有必要以你以前从未有过的方式进行领导？
绝对的。在我过去的角色中，我为大型团队提供幕后支持。在我职业生涯的前五年，我做过公关助理、市场自由撰稿人、代笔人，应有尽有。这些经历让我明白了互利的品牌客户关系是什么样的。与此同时，我开始花时间与我真正感兴趣的品牌——API 优先的公司，如 Auth0 和 Postman 。最终，我意识到我知道我想要什么，以及如何得到它。是时候进入我职业生涯的下一阶段了。
然而，迈出这一步说起来容易做起来难。我认为，对于女性和不同性别的科技工作者来说，有一种感觉是，你需要为自己的位子而战。重要的是要记住，不是每个公司都是这样运作的。
在 Moesif，每个人都有一个座位，无论我们是坐下来吃午餐还是参加规划会议。我很惊讶在这个团队中成长是如此容易。在这里，我可以自由地设计和运行自己的项目，而不仅仅是执行别人的项目。更令人耳目一新的是，我是在整个团队的支持下这样做的，而不是作为一个自由职业者独自这样做。
如今 API 产品面临的最激动人心的挑战是什么？
我渴望看到 API 将他们作为一种新的、未验证的技术的身份转变为一种可靠的、成熟的技术。
API 优先的公司和我差不多同时成熟，在 2000 年代后期。脸书和 Twitter 第一次宣布了他们的 API，建立了一个新的标准。那时候，我还是一名第一机器人公司的学生，第一次交流技术，向赞助商推销消费技术。这可以说是多愁善感，但我希望我的职业生涯能随着那个时代诞生的科技潮流一起成长。
我们现在是在 2020 年，我已经实现了我的愿望。API 为我们全球互联的应用和微服务世界提供动力。就像在任何趋势转变的革命中一样，大规模采用发生在细节被整理出来之前。例如，API 仍然特别容易受到新出现的安全威胁的攻击，并且仍然不确定如何应对监管。
比起看到任何一个问题得到解决，我更兴奋地看到一个完整、可靠的生态系统出现。API 分析只是其中的一部分，但是每一个小的改进都很重要。我期待着传播这样一个信息，“API 会一直存在，并且每次都能完美运行。”
驱动你的价值观是什么？
我是一个终生的技术爱好者，但最重要的是，我重视像对待人类一样对待人类。这不是硅谷众所周知的价值观。这是有正当理由的，但我相信技术有服务于公共利益的潜力。
可以理解的是，大型科技公司的丑陋之处受到了关注。操控软件。“科技兄弟”文化。能源使用失控。即使在科技工作者中，我也听到了对道德的担忧。谁愿意相信他们的工作对世界有害？当我们把不道德的企业框定为“创新”的顶峰时，很容易感觉整个科技行业都是如此。
但是，创新本身是公正的。当我看到关于“邪恶”科技公司的头条新闻时，我看到的是一个社会问题，而不是新工具的问题。这就是为什么我寻找那些为了大多数人而不是少数人的利益而拥抱非传统的公司，并且诚实地承认他们有能力做到这一点。这意味着意识到它们对员工、社区和技术生态系统的影响。我确实认为这个游戏目前倾向于不守信用的演员，但如果说科技领域有什么是不变的，那就是进化——大的变化往往始于小步。
即使足迹很小，每个敢于做得更好的公司都树立了榜样。我喜欢认为我们正在这样做，在 Moesif。我们正在朝着计算的进步而不是寻求短期回报而努力。Moesif 是管理 API 的“缺失部分”。无论产品发生什么，我们正在建立的利基市场将进一步完善 API 技术。我们在这样做的同时，将员工视为真实的人，他们有时会面临挑战或需要额外的支持。成就和责任之间的*衡让我有家的感觉。
关于会议 MoesifT3】
在 Moesif，我们帮助客户了解他们的 API 是如何使用的，以及他们如何发展他们的 API *台。 Meeting Moesif 凸显了将愿景变为现实的人们。我们以人为本的文化重视开放的沟通、主动性和影响力，更不用说确保员工健康的弹性工作制等福利了。
如果你有兴趣加入，你可以从了解成为 Moesif 的一员开始。我们的 Meeting Moesif 博客系列让我们得以一窥我们的办公室生活，以及我们如何为所有客户扩展 API 可观察性。点击以下链接查看其他 会议 Moesif 团队成员访谈。
Runscope 交通检查员 Moesif 迁移指南
原文：https://www.moesif.com/blog/companies/runscope/Migration-guide-for-Runscope-Traffic-Inspector/
Runscope 是测试 API 的一个很好的产品。他们相信 API 的发展方向，并希望帮助 API 开发者以一种简单的方式测试他们的 API。很遗憾看到他们将关闭他们的流量检查员(网关 URL、网关代理、流量流、请求捕获、共享请求等)。)来关注其他产品特性，比如他们的 API 测试。
如果您正在寻找一个*台来运行复杂的测试序列来测试您的 API，我们仍然推荐 Runscope。事实上，Runscope 测试序列与 Moesif API 分析相结合，为您提供了一个强大的*台来测试任何新的 API 更改，并监控这些更改对您的客户群的影响。
Runscope 和 Moesif 的区别
Runscope 主要关注于测试一个 API，按照设定的时间表 ping 它并检查结果。您可以定义更精细的测试序列，也可以从 CI/CD webhooks 等中触发。如果其中一个测试序列失败，也可以配置松弛警报。
Runscope 还有一个交通检查员，可以用来检查这些测试的结果。一些低流量用户甚至使用 Traffic Inspector 对生产流量进行常规 API 监控，但这超出了该功能的设计范围。
Moesif 不关注测试序列，也没有合成 ping的概念。相反，Moesif 的主要关注点是 API 分析，为您的生产应用提供对实时 API 流量的深入了解。这意味着 Moesif 被动地捕获您的 API 数据，以了解使用趋势并检测您的 API 上的异常。
有了 Moesif，您可以看到前 10 大 API 客户调用最多的 API 端点，或者得到提醒，在推出新的 SDK 版本后，欧洲用户在 Java SDK 上遇到了更高的错误率。
Moesif 提供了许多不同的视图来可视化您的 API 数据，包括事件流、热图、分段和时间序列。
对于那些从 Runscope 的流量检查员迁移过来的用户来说，Moesif 的事件流是 Runscope 用户在开始时最熟悉的。
Moesif 支持各种 API 协议/架构，包括 RESTful、GraphQL 和 Web3/JSON-RPC。
集成差异
Runscope 的交通检查员唯一的集成是通过代理。传入的 API 调用将通过 Runscope 的代理路由，然后被中继到您真正的 API。
Runscope 有一个云代理可用于所有计划，还有一个本地代理设备可用于某些企业级计划。
Moesif 主要集成不是云代理。相反，Moesif 的大多数客户使用开源的服务器中间件 SDK，如 moesif-express 或 moesif-servlet。对于像 DApps 这样的客户端应用，也有 moesif-browser-js 可用。
Moesif 还有一个高可用性的云代理服务器，在你不能安装 SDK 的环境中非常有用，比如捕获 T2 网页钩子。
应该选择 SDK 还是云代理？
如果你想要更多的定制和最高的性能，请使用 SDK，如果你想要替换 Runscope 的流量检查器或无法安装 SDK，请使用云代理。
SDK 的一些额外好处
- 而不是另一跳，这意味着对延迟没有影响。数据异步发送到 Moesif。
- Moesif SDK 或 Moesif 服务中的故障不会影响您自己的服务正常运行时间。
- 可以自定义 API 调用如何归属于您的 user_id 和会话/身份验证令牌
- 可以在发送到 Moesif 之前清除任何敏感数据。
云代理的一些额外优势
- 没有软件安装，它只是创建了一个编码的网址。
- 替换 Runscope 交通检查员。
- 可用于 webhooks 或捕获健康探测的结果。
综合
遵循服务器中间件 SDK或云代理各自的集成指南
在成功集成 Moesif 之后，您应该开始看到数据立即出现在 API 事件流中。可能需要几分钟事件才会开始出现。
Runscope 没有用户的概念，所以我们建议查看 moesif 文档中关于创建用户配置文件的内容，以使您的集成更加强大。
Moesif 和 Datadog:特点相似性、差异以及它们如何协同工作
Moesif 和 Datadog 都是提供监控和查看指标能力的*台。然而，从本质上讲，这两个*台为您的组织和使用它们的团队做了非常不同的事情。两者可以很好地互补，并包含有助于制造无缝扩展的更好产品的功能。
Datadog 非常适合确保基础设施按预期运行，向您发出错误警报，并监控停机时间和性能下降。这都是良好的应用程序性能监控解决方案的一部分。从本质上讲，如果您拥有对您的运营至关重要的基础设施和资源，Datadog 是查看您的运营状况全貌的绝佳方式。该*台可以帮助确保您的技术操作的所有部分都顺利运行，并在不顺利时提醒您。
另一方面，Moesif 更关心从用户和公司的角度进行监控和分析。Moesif 可以确保用户再次使用你的产品，提供关于他们如何使用它的有价值的见解，授权使用它的团队推动采用，等等。Moesif 让你看到端到端的用户旅程，包括用户如何与你的应用或 API 产品交互，以及他们如何使用它。通过启用公司跟踪，您还可以查看特定公司的一组用户是如何与您的产品进行交互的。
两者都有不同的目的和目标，但它们一起可以创建一个端到端的业务图，包括您的用户和操作。建立一个伟大的企业包括拥有伟大的产品体验和坚实的基础设施监控，以确保最佳性能。
高基数、高维度分析
像 Datadog 这样的工具擅长单维分析，这意味着有一个度量名称和一个随时间变化的值。可能有少量的标签或维度，但通常为数不多。对于产品驱动的团队来说，重要的是不仅要理解交易量，还要理解客户通过 API 发送的不同类型的负载和查询。这可以跨数千个不同的查询参数、HTTP 头和主体键来定义。此外，这些字段中的每一个都可以有大量不同的值(高基数)，包括客户标识符本身。
这就是 Moesif 的优势所在，它使产品所有者能够通过无数种不同的可能性来分割他们的 API 使用数据。例如，在下图中，我们可以在响应有效负载“标签”中跟踪每天经历缺货与可用的独立用户数量。虽然 DevOps 工程师对独立用户和他们是否看到缺货不太感兴趣，但这些见解对于做出良好的业务决策至关重要。
由于两个*台针对不同的目标使用不同的指标和数据，因此一起使用它们是有意义的。将两者结合使用有很多好处，有助于生成整个业务的整体视图。涵盖一切，从客户如何使用您的产品，一直到产品运行的基础设施如何运行。
现在，让我们看看每个*台都包含哪些功能。
分解特征
这两个*台都提供了多种功能，可以从多个方面帮助您的企业。下面是对每个*台提供的内容、其重要性以及如何补充其他*台的分析。
连接器、插件和集成
这两个*台都支持市场上许多最常见的*台，具有各种集成。由于这两个*台在一个组织中服务于不同的功能，它们的连接器、插件和集成反映了这一点。
Datadog 更支持基础设施，因此有许多连接器，如帮助监控安全性、容器、编排、成本管理和问题跟踪的连接器(仅举几例)。AWS、Google Cloud Platform 和 Azure 上许多最流行的工具和*台都得到了支持，这里仅举几例。
Moesif 支持大多数 API 框架。其中包括 Node.js、Python、Java 等的服务器集成。Moesif 还为流行的 API 网关和 API 管理工具提供插件，包括 Kong、NGINX、Tyk、Envoy 等等。
Moesif 的连接器更侧重于产品用例。一些包括 Slack、Segment、Pendo、HubSpot、Salesforce、Marketo 等。
TL；灾难恢复-两个*台都有许多可用的集成。Datadog 涵盖了大多数*台，在这些*台上，基础设施监控将是有益的。Moesif 集成了构建和管理 API 的最流行的方法，包括直接插入代码的服务器集成 SDK 或与 API 网关集成的插件。T3】
仪表盘
仪表板是汇集数据进行快速浏览的好方法。展示单一领域的关键见解是两个*台都擅长的事情。
Datadog 允许您构建自定义仪表盘来显示基本指标。运营团队可以非常轻松地查看每个系统的运行情况，包括性能、使用情况和其他表明*稳运行的关键值。
Moesif 仪表板可用于为所有可能关注的部门提取关键的客户洞察。例如，营销仪表板可以显示流量来源、网站参与度和客户保持率。产品仪表板可以显示客户激活漏斗、*均 TTFHW(首次 Hello World 的时间)以及显示客户如何使用 API 或*台的其他指标。
TL；Datadog 中的 DR - Dashboards 可让您深入了解您的运营情况，并确保您的关键业务正常运行。这些都是可定制的，易于设置和优化。Moesif 还提供易于使用和设置的仪表板，包括一些开箱即用的仪表板。Moesif 仪表板可以显示许多团队，包括营销和销售，粒度指标，以帮助绩效和采用。T3】
发信号
在监控工具中，关键事件发生时向特定通道发送警报的能力至关重要。当满足特定条件时，警报允许用户在其选择的*台上得到通知。这意味着用户不必手动观察事件，而是可以“设置并忘记”，知道他们将自动和实时收到警报。
Datadog 警报可以围绕您的基础设施内的条件。Datadog 能够创建主动检查指标、集成可用性、网络端点等的监视器。当警报被激活时，Datadog 可以通过电子邮件、吉拉、PagerDuty、Slack 或 WebHooks 发送警报。
当用户遇到某些情况时，Moesif 可以创建警报。这些可能是新用户注册、进行一系列 API 调用、API 流量异常增加或减少，或者用户遇到大量错误或集成问题。这些警报中的许多可以帮助您的团队积极主动，确保良好的用户体验，并快速缩小产品中的问题范围。
TL；DR - Datadog 非常适合提醒您基础设施问题和一般技术操作，确保系统正常运行。Moesif 非常擅长警告特定的用户行为，并主动让开发人员、产品经理和支持团队意识到用户陷入困境或收到错误。T3】
用户和公司跟踪
用户行为分析的一个关键特性是能够分析不同用户所做的事件序列，而不仅仅是孤立地看待事件。为了能够分析复杂的用户行为，Moesif 中的 API 调用和动作可以绑定到用户 id 或公司 id 。从那里，您可以跨多个 API 调用创建报告。例如，使用 Moesif，您可以找到对 GET /widgets/category/:id 进行了至少 10 次 API 调用，但对/purchases 进行了 0 次 API 调用的用户。
借助用户行为分析，以产品为导向的团队可以分析他们的激活漏斗，并执行群组保持分析，以了解他们业务的健康状况。
这些类型的分析对于以产品为主导的组织来说是一个巨大的优势，因为在这些组织中，用户体验是最重要的考虑因素。
漏斗可以让你看到你的产品漏斗中不同步骤之间的转换率，比如注册用户中最终进行第一次 API 调用的用户的百分比。在此基础上，你可以根据用户统计数据(如营销活动)进行细分，以了解在哪里投入更多资源。留存分析可以让你看到用户是否忠诚，是否继续从*台中获取价值。细分让你可以深入了解谁是你的用户和公司，以及他们属于哪个细分市场。
因为 Moesif 可以通过 API 或像 Segment 这样的连接器获取客户数据，所以您可以根据客户的人口统计数据来划分您的 API 使用和 API 指标。例如，为了更好地理解公司规模或职位的使用。这使得按计划或其他客户信息跟踪使用情况变得更加容易。
通过分析 API 有效负载和 UI 事件(通过 Moesif 的 BrowserJS 包或片段)，可以很容易地收集和操作战略性业务洞察。一个例子是优化应用程序中的电子商务交易。通过跟踪未完成的结帐，您可以确定不成功结帐的确切路线，与卖方一起解决问题，并主动通知买方该问题。这些信息也可以在产品团队中使用，以改善结账流程，从而避免将来的交易出现以前没有结账或结账不完整的问题。
Moesif 跟踪每个用户及其公司的能力使得“行为度量”的使用成为可能。这些类型的指标允许我们查看多个事件，而不是允许我们将多个事件联系起来以确定特定的行为模式。这正是 Moesif 能够做上述所有事情的原因。
有了 Datadog，你也可以看到用户正在做的动作，但是没有 Moesif 那么精细。然而，Datadog 支持一些非常基本的用户跟踪，这有助于调试*台上出现的基础设施和安全问题。但是 Datadog 不支持每家公司跟踪。由于 Datadog 应用于其分析模型的模型，因此不支持“行为指标”。
TL；DR - Datadog 支持跟踪用户动作和调用，但更适合显示整体流量、API 调用和性能。Datadog 的用户跟踪功能更符合网络分析。Moesif 允许跟踪用户和公司的使用情况。这一功能使 Moesif 用户能够查看转换漏斗、保留分析和探索用户细分。Moesif 的功能旨在从用户第一次访问您的应用程序到他们最*的转换，增强用户的能力并改进您的产品。T3】
行为邮件
通常，用户在我们的产品中表现出的某些行为或采取的行动可以被跟踪。能够自动发送定制和模板化的电子邮件是通知用户接下来的步骤或他们可能违反的某些条件(如速率限制)的好方法。
借助 Moesif 跟踪个人用户的能力，我们可以监控特定的条件或行为，并根据它们发送电子邮件。Moesif 可以在用户在入职或开始时遇到困难、接* API 速率限制或任何其他用户可能受益于电子邮件的标准时检测并发送电子邮件，以引导他们回到正确的道路上。
因为 Datadog 更关心的是基础设施和整体性能监控，所以它不支持这个功能。这是 Moesif 可以增强您已有的监控并帮助改善您的产品和用户体验的另一个案例。
TL；DR - Behavioral 电子邮件可用于根据用户显示的行为或采取的行动，在他们的入职和用户旅程中提醒和帮助用户。Datadog 本身不支持行为电子邮件，因为它在指标方面不是以用户为中心的。Moesif 允许根据用户何时符合特定标准来发送定制的电子邮件。T3】
治理规则
治理规则是 Moesif 更加关注基于用户的分析的另一个因素。这些要求包括阻止未经授权的访问或阻止过期发票用户的访问，这只是几个例子。
此功能不仅仅是监控和警报，而且像行为电子邮件一样，允许您自动根据指标采取实际行动。在 Moesif 中，您可以创建阻塞和非阻塞规则。阻止规则可以阻止对 API 的访问，同时通知用户为什么会发生服务中断。非阻塞规则仍然允许请求继续到您的上游服务。Moesif 将只覆盖任何 HTTP 响应头，但不覆盖正文和状态代码。
Moesif 提供这一功能，作为创建和实施治理规则的一种简单方式。由于确定和执行这些规则所需的所有指标都已经存在于*台中，这使得它成为创建它们的绝佳场所。
Datadog 不支持这种方式的治理。Datadog 可以用来探索对组织的治理需求可能很重要的数据，但它不能像 Moesif 那样强制执行规则并通知用户。
TL；Moesif 可以创建和实施灾难恢复治理规则，例如阻止未授权或可能的恶意访问。这些规则可以是阻塞的(停止请求)或非阻塞的(仍然允许请求通过)。Datadog 不能用于这样的功能，但是仍然可以被治理团队用作高级调查的一部分。T3】
基础设施监控
无论服务和产品有多好，只有当它们所依赖的基础设施运行良好时，它们才能成功。基础架构监控是组织确保其运营正常运行的一种重要方式。您可以监控网络速度变慢、流量异常增加、服务器出现问题以及其他影响系统稳定性和用户体验的事件。
Datadog 最初的功能主要集中在这种类型的监控上。可以说，Datadog 是满足这些需求的最佳和最受欢迎的工具之一。各种基础设施和服务可以轻松连接到 Datadog 并进行监控。由于这是 Datadog *台的核心用例，难怪世界上许多最大的公司都利用 Datadog 来忽略他们的运营(包括 Moesif！).
Datadog 提供了一些很棒的仪表板，让您可以监督您的整个操作。您的架构中的每个基础设施都可以使用该*台进行监控、查询和优化。
Moesif 不提供基础设施监控，但是 Moesif 中的许多指标——包括那些表示 API 性能问题的指标——也可以通过使用 Datadog 来快速调试。一个很好的例子就是当大量的问题和警报开始涌入 Moesif 时。我们可以检测到用户遇到的问题，然后转向 Datadog，将其缩小到基础设施问题，或者可能是一些问题，如一些坏代码的发布问题。
TL；DR - Datadog 是基础设施监控的最佳*台之一。几乎所有的系统都可以连接到 Datadog，因为它们提供了大量的集成。查看端到端操作和基础设施状态是 Datadog 真正擅长的地方。Moesif 不提供任何类型的基础设施监控，但是当与 Datadog 一起使用时，可以很容易地帮助诊断和解决影响用户的问题。T3】
包扎
Moesif 中的指标可以帮助塑造更好的用户体验，并帮助发现应用程序中的困难。这可能涵盖从前端体验(使用 Moesif 的 BrowserJS 或 Segment)到后端事件(比如与 API 的成功集成)的所有内容。Moesif 还可以通过将指标与生成自动电子邮件、通知甚至治理规则的工作流联系起来，帮助实现以产品为主导的组织。
Datadog 中的指标非常适用于跟踪运营和系统健康状况、整体流量、监控基础设施成本，以及确保您的应用以最高水*运行的多个方面。
如您所见，两个*台都为不同的受众和角色提供了许多有价值的见解。Moesif 专注于帮助您构建更好的产品，而 Datadog 则专注于确保您的基础设施和其他操作变量能够让这些产品发挥应有的性能。*台之间的功能重叠很少，因为它们在如何使您的业务扩展方面有两个非常不同的角色。将 Datadog 和 Moesif 结合使用是构建完整而全面的分析和监控堆栈的最佳方式之一。
Moesif API 分析符合 SOC 2 标准
原文：https://www.moesif.com/blog/business/soc2/Moesif-API-Analytics-is-SOC2-Compliant/
Moesif 很高兴地宣布，它已成功完成其 SOC 2 认证。Moesif API 分析*台现已通过独立验证，符合最高安全标准。
通过完成这一全面级别的认证，Moesif 证明了它能够可靠、安全地维护企业关键数据资产的机密性、可用性和完整性。
重要的认证
SOC 2 法规遵从性表明组织可以保持高水*的信息安全。这种负责任地处理敏感信息的承诺在银行、保险和政府部门尤为重要。
事实上，SOC 2 的框架规定，合规组织只能与通过审核的其他组织共享数据。Moesif 现在能够与其他 SOC 2 兼容组织建立业务关系。
Moesif 在数据保密性和安全性方面大放异彩
SOC 2 审计流程包括五个用于评估和报告信息和系统控制的信托服务标准:安全性、可用性、保密性、处理完整性和隐私性。
由于 Moesif 一直处理客户数据，我们在构建解决方案时考虑了安全性。我们安全、保密地处理数据的强大流程包括:加密所有存储的静态数据、对访问生产数据的内部控制，以及对所有涉及客户数据的软件修改的变更控制流程。
除了从不将客户数据存储在公司基础架构或工作站之外(所有这些都是远程监控的)，我们还为核心服务实施自动安全更新，并在发现安全问题时进行现场更新。
客户端加密提高了安全性
除了服务器端加密和 SOC 2 之外，通过客户端加密实现零知识安全，具有敏感数据的应用程序可以对您的组织保密。获得了内部安装的隐私优势，而没有构建和扩展您自己的数据基础架构的复杂性。
Moesif 致力于客户数据的安全。我们的 SOC 2 合规性是我们*台发展的下一步，以应对更苛刻的市场。
moesif Chrome CORS 扩展达到重要里程碑
原文：https://www.moesif.com/blog/cors/chrome-extension/Moesif-CORS-Extension-For-Chrome-Milestone/
我们很高兴看到 Chrome 浏览器的 Moesif CORS 扩展达到了一个重要的里程碑:超过 10，000 周活跃用户。
这也是最高评级的 CORS 浏览器插件。
也可以查看我们在 CORS 的流行指南以及如何用 CORS 设置你的 API。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
来自 Moesif 在 GraphQL 和 Serverless 上的开发者会议的视频
原文：https://www.moesif.com/blog/meetups/graphql/Moesif-Developer-Meetup-on-GraphQL-and-Serverless/
Moesif 在 GraphQL、Serverless 和 API 上举办了第一次会议。我们与 Box 开发者*台团队的创始人以及 Back4App 和 StdLibs 的首席执行官进行了富有洞察力的谈话。
有大量的免费啤酒和比萨饼，这是与更大的 API 和开发人员社区的成员交流的一段美好时光。以下是会谈中的一些亮点。
Jeremy Glassenberg 谈开发者*台的最佳实践
首先发言的是 Jeremy Glassenberg，他是 Box 开发*台团队的创始人，现在是 API 策略师。开发者*台是那些可以半途而废，但很难正确吸引开发者的东西之一。Jeremy 讨论了避免激怒开发人员的不同方法，比如 API 版本控制和与开发人员社区交流的力量。
主要采取的方式是把你的 API 当作一个产品，而不仅仅是试图发布内部 API。然而，API 不是网站，因此 API 产品管理不同于一般的 API UI 设计。像 A/B 测试和分析这样的常规 UI 实践更难实现，但同样重要。如果你推出一个突破性的改变，你可能会严重影响一小群非常高收入的顾客。与可以不断更新的网站不同，您的开放 API 可能会被数百家不同的公司用于数千种不同的产品和集成。
https://www.youtube.com/embed/VI-gXpnVCnc
要获得更多资源，我们建议查看我们的 API 开发者体验指南。
Back4App 的 CEO 给出了一个使用 GraphQL 像 BaaS 一样增强解析的演示。
Back4App 是一个后端即服务，让开发者无需担心后端就能快速创建应用。
达维·马塞多(Back4App 的首席执行官)一直在 AWS Lambda 上试验 GraphQL，供内部使用，并将其作为 Back4App 产品的一部分。许多为要在 AWS Lambda 上托管的 GraphQL APIs 生成无服务器函数的搭建工具可能会造成某些复杂性，尤其是当您的应用程序很大时。具体来说。达维注意到，支架工具不是在真正的无服务器/FaaS 架构中创建许多小函数，而是生成一个单独的 AWS Lambda 函数来保存整个 GraphQL API 的所有业务逻辑。这可能会导致可伸缩性问题，例如冷启动缓慢，在函数能够响应传入的 GraphQL 请求之前，必须下载许多 javascript 库。
不幸的是，我们没有记录整个会议，下面只是一个简短的片段，但查看Back4App.com了解更多信息。
https://www.youtube.com/embed/FKcVtsCXy1o
StdLib 首席执行官演示如何在 30 秒内创建一个 API
Stdlib 帮助开发人员和非开发人员快速创建 API，而无需考虑底层基础设施。
他们的 CEO Keith Horwood 在 StdLib 上给我们演示了如何创建一个快速的 Hello World API。看到您可以如此轻松地启动和运行 API 是非常令人着迷的。如果你所做的只是将 Salesforce 连接到另一个服务，你可能不需要微服务或甚至 AWS Lambda 的全部重量。很高兴看到 Zapier 的易用性和更大的灵活性。下面看。
https://www.youtube.com/embed/dPYZ3JgY9F4
结论
这是 Moesif 主办的第一次开发者聚会，但很高兴将来能主办更多。如果您未能出席，请加入meetup 群组或我们的邮件列表(在左侧栏),以便获得未来活动的通知。如果你真的参加了，我们很乐意通过给我们发邮件来听听你对我们能做的任何改进。
Moesif 是最先进的 API 分析*台。成千上万的*台公司利用 Moesif 进行调试、监控和发现见解。
监控 API 集成:来自 Fusebit 及其客户的故事
根据 Blissfully 的年度 SaaS 报告，员工人数在 250-500 人之间的公司*均使用 123 个 SaaS 应用程序来支持他们的业务，并将在两年内更换其中令人震惊的 39%。对于较小的公司，这个数字上升到 46%。为了在这种环境中生存，为特定问题提供一流的解决方案正在成为 SaaS 供应商的赌注，并且不再足以确保持续的成功。成功的 SaaS 供应商在其*台中提供了出色的集成和定制功能，以提高转化率和保留率。
构建健壮和有效的集成经常是一个挑战。在 Fusebit ，我们每天都听到客户的声音，他们在可靠性、隔离、安全性和版本控制等问题上苦苦挣扎。然而，监控几乎是每一次谈话中最棘手的问题。开发时的可观察性问题首先出现，但随着生产负载的增加以及 API 的发展和破坏，很快就被确保可靠性的需要所取代。
用我们客户的话说，以下是一些常见的棘手问题和故障模式:
-
“我对附加组件/web hook 和现有附加组件的标注没有内聚的可追溯性”~德国跨国公司软件开发高级总监
-
“我们的故事很糟糕，合作伙伴在可检查性方面举步维艰。我们经常听到:‘我收不到事件，告诉我你发送给我的是什么’或类似的话”~同一家德国公司的技术产品管理副总裁
-
“很难知道我们什么时候被调用，开发者不想‘错过’一个 webhook 调用。(在我们的案例中)这可能会决定订单是否得到支付。”~湾区启动工程经理
-
“在提供 API 时，我们必须针对客户和大公司(Skype、Stripe)设定防御性费率限制。”~湾区启动时的首席技术官
-
“如果失败，Zendesk 将关闭我们的 webhook……我们这边几分钟的中断将导致 web hook 停用。我们必须建立一个主动监控和通知解决方案来处理这个问题
-
“因为集成是机器对机器的，所以很难知道发生了什么。人们给我们带来大量的交通流量，却忘了关掉它。没有人会看到这些消息…我们的客户不擅长记录和监控。”~湾区创业公司的联合创始人兼首席执行官
-
“我们的集成最*被关闭，因为我们没有及时响应。有时它会被关掉，不知道为什么。我们开始监控我们合作伙伴的 webhooks 状态页面，我们甚至围绕它建立了自动化，以获得更多的可见性。”~西雅图创业公司工程经理
在这种代表 SaaS 主要参与者对 API 集成监控系统投资不足的背景下，寻求构建强大集成的公司经常只能用自己的监控基础设施来填补空白。这就是像 Moesif 这样的解决方案可以为开发人员节省数周不必要的前期工作的地方，更不用说持续的安心和减少操作痛苦了。
大多数监控解决方案提供商关注客户自己的 API 表面，但是在集成领域，监控集成合作伙伴的基础设施同样重要。在这里，Moesif 的产品以其为监控第三方 API 而定制的特性集脱颖而出:
调试和测试
- 通过实时事件流查明导致 API 调用失败的确切 JSON 或 XML 键。
- 比较数以百万计的成功和失败的 API 调用，并审计发生了什么变化
分析学
- 了解进入集成合作伙伴的请求量，衡量表现不佳的第三方 API 如何影响您自己的客户体验。
可靠性监控
- 当合作伙伴失败时获得提醒，并确保他们支持该问题
- 查看哪些合作伙伴出现故障的全球状况以及发生故障的频率
- 将多个失败的事务关联在一起，以避免警报风暴
在构建客户要求的集成时，SaaS 供应商通常有一个选择:是在内部构建集成，还是利用集成*台(iPaaS)合作伙伴，如 Fusebit 。如果 SaaS 供应商只开发少量的集成，并计划成为维护这些集成的专家，那么前一种方法是有意义的。如果集成的数量预计会增长，并且供应商选择利用该领域专家合作伙伴的技术和运营知识，后一种方法是更好的选择。Moesif 的解决方案可以与任何一种方法结合使用，同时仍能提供显著的价值。
因此，无论你是自己构建集成还是与合作伙伴合作，都不要像上面引用的 Fusebit 客户那样结束；投资一流的监控和分析！
监控用 Apollo & Express 构建的 GraphQL APIs
原文：https://www.moesif.com/blog/technical/graphql/Monitoring-GraphQL-APIs-Built-With-Apollo-and-Express/
当我们想了解最新的功能和性能问题时，监控我们的 API 是必须的。
Keyur Doshi 已经写了一篇关于监控用 Django 和 Graphene 构建的 GraphQL APIs 的文章，所以让我们深入 JavaScript 生态系统，看看需要什么来启动和运行它！
有许多 JavaScript GraphQL 实现，在本文中我们将讨论两个最突出的参与者:Apollo-server&express-graph QL
本文的第一部分是关于如何为每个 GraphQL 实现设置 Moesif API 分析。
第二部分是关于如何使用 Moesif API 分析来保持我们的 API 游戏的领先地位！
设置 Apollo 服务器
Apollo server 提供了一个独立版本和多个框架的集成。我们将在这里讨论独立版本。
首先，我们和 NPM 一起建立了一个项目。
$ mkdir apollo-example
$ cd apollo-example
$ npm init
其次，我们安装所需的两个 NPM 软件包。
apollo-server包括运行 GraphQL 服务器所需的一切moesif-express连接到 Moesif API 分析服务
$ npm i apollo-server moesif-express
接下来，我们创建一个保存所有设置代码的index.js。
const { ApolloServer, gql } = require("apollo-server");
const moesif = require("moesif-express");
const applicationId = "<MOESIF_APPLICATION_ID>";
const typeDefs = ...;
const resolvers = ...;
new ApolloServer({ typeDefs, resolvers })
.listen(8888)
.then(({ server }) => {
const moesifMiddleware = moesif({ applicationId });
server.on("request", moesifMiddleware);
});
代码的关键部分在最后。ApolloServer对象的listen方法返回一个承诺。
这个承诺让我们可以通过server对象访问底层的 HTTP-server。
这个服务器对象是request事件的事件发射器。
我们可以在moesif工厂函数的帮助下创建一个中间件函数，并将其用作request事件的事件监听器。
设置 Express GraphQL
Apollo server 也有一个 Express 集成，但是有一个替代的 GraphQL 服务器实现可以与 Express 一起工作，所以让我们看看如何设置它。
首先，我们创建一个项目。
$ mkdir express-example
$ cd express-example
$ npm init
其次，我们安装所需的软件包。
express是底层的 HTTP 服务器框架express-graphql是 express 中间件，它使用 Node.js 的参考 GraphQL 实现- 是连接我们和 Moesif API Analytics 的库
const express = require('express');
const expressGraphql = require('express-graphql');
const moesif = require("moesif-express");
const applicationId = "<MOESIF_APPLICATION_ID>";
const schema = ...;
const moesifMiddleware = moesif({ applicationId });
const graphqlMiddleware = expressGraphql({ schema });
const app = express();
app.use(moesifMiddleware);
app.use("/graphql", graphqlMiddleware);
app.listen(8888);
这里的过程相当简单。我们使用moesif工厂函数来获得一个可以与 Express app对象一起使用的中间件函数。
就代码而言，这是所有要做的工作。现在，每个到达服务器的请求，无论是 Express 还是 Apollo，都将被转发到 Moesif API 分析服务，并可以进一步检查。
GraphQL 的 moesif api 分析
在我们用我们选择的框架建立了我们的 GraphQL 服务器之后，Moesif 中间件将把请求数据发送给 Moesif 服务。就 GraphQL 而言，这意味着 Moesif 服务现在知道我们的查询和变化。
如果我们使用 apollo-server 独立版本，GraphQL API 会在所有路由上应答。Moesif 期望 GraphQL 查询在
/graphql路线上，所以我们必须使用这条路线。
如果我们用浏览器登录到我们的 Moesif 控制台，我们会在 API 分析部分找到所有记录的事件。这包括但不限于:将 GraphQL 请求发送到/graphql路由。
为了只显示 GraphQL 查询请求，而不显示其他 HTTP 请求，比如加载 GraphiQL UI 的 HTML 或获取 GraphQL API 信息的自省查询，我们必须使用左侧的过滤器侧栏。
在 API 过滤器中，我们选择请求- > URI 路由，并将其设置为/graphql以去除非 GraphQL 请求。
现在我们只有 GraphQL 请求，我们可以应用 GraphQL 查询过滤器来关注我们想要监控的特定查询。
例如，我们可以通过选择request.graphql.operation_name作为 GraphQL 查询过滤器并将其设置为 ≠ IntrospectionQuery 来消除IntrospectionQuery请求。
结论
用 Node.js 框架将 Moesif API Analytics 添加到我们的 GraphQL API 构建中只是几分钟的事情。我们必须通过 NPM 安装moesif-express,需要中间件，用我们的 Moesif 应用密钥配置它，我们就可以开始了。
设置完成后，我们所有的请求将被发送到 Moesif API 分析服务，并保存以备后用。
稍后，当我们的 API 启动并运行时，我们可以根据 GraphQL 查询的内容进行过滤、排序和分段，以深入了解我们的查询。
哪些是
- 最受欢迎？
- 最慢的？
- 最容易出错？
监控用 Django 和 Graphene 构建的 GraphQL APIs
本教程假设您熟悉使用 Django 和 Graphene 的 GraphQL 和 Python。如果没有，你可以参考本系列之前的文章Python 和 GraphQL 入门
在前面的文章中，我们创建了 API 来查询、变异、搜索和过滤数据。在本教程中，我们将讨论如何使用 Moesif API Analytics 来监控我们构建的 API。
我们将通过在 requirements.txt 或中包含moesifdjango来安装moesifdjango库
pip install moesifdjango
一旦安装了库，我们需要更新graphene_python/settings.py来向应用程序添加中间件。
MIDDLEWARE = [
...
'moesifdjango.middleware.moesif_middleware'
...
]
我们还需要将MOESIF_MIDDLEWARE添加到settings.py文件中
MOESIF_MIDDLEWARE = {
'APPLICATION_ID': 'Your Moesif Application Id',
'LOG_BODY': True,
...
# For other options see below. }
您的 Moesif 申请 Id 可以在 Moesif 门户 中找到。注册 Moesif 帐户后，您的 Moesif 申请 Id 将在入职步骤中显示。
登录 Moesif 门户 ，点击右上方菜单，然后点击安装，您随时可以找到您的 Moesif 应用 Id。
一旦中间件被集成，所有的 API 调用将被 Moesif 捕获，我们将能够分析它。
现在我们将查询events对象并选择id、name和url字段，可以看到 API 调用被捕获。
我们可以通过提供配置选项来添加与 API 调用相关联的定制元数据、用户或公司 id。
# User Id def identifyUser(req, res):
# if your setup do not use the standard request.user.username
# return the user id here
return '12345'
# Company Id def identifyCompany(req, res):
# return the company id here
return '67890'
# Metadata def get_metadata(req, res):
return {
'foo': '12345',
'bar': '67890',
}
# Mask Event def mask_event(eventmodel):
# do something to remove sensitive fields
# be sure not to remove any required fields.
return eventmodel
MOESIF_MIDDLEWARE = {
'APPLICATION_ID': 'Your Moesif Application Id',
'LOG_BODY': True,
'IDENTIFY_USER': identifyUser,
'IDENTIFY_COMPANY': identifyCompany,
'MASK_EVENT_MODEL': mask_event,
'GET_METADATA': get_metadata,
...
}
关于配置选项的更多细节可在这里找到。
设置配置选项后，捕获的所有 API 调用将包括元数据、用户和公司信息。
要查看 GraphQL 的运行情况，您可以从 GitHub 克隆并运行这个示例应用程序。
在下一个教程中，我们将讨论更多关于分页的内容。同时，如果您有任何问题，请联系 Moesif 团队。
本系列前情提要:
开源 API 网关综述
原文：https://www.moesif.com/blog/api-engineering/api-gateways/Open-Source-API-Gateway-Roundup/
API 优先的公司依靠广泛的服务套件来构建他们的 API，并为他们的客户创造价值。多个团队可能使用不同的技术开发 API。通过流程和工具，您希望这些 API 与您的 API 消费者(无论是内部的还是外部的)保持一致。公司用来将多个 API 结合在一起的一个工具是 API 网关。
API 网关是一种简化访问、认证和管理公司众多 API 端点的工具。通常，网关不知道您的架构、数据格式和其他 API 决策。例如，一个成熟的 API 程序可能有不同的 API 类型。类似地，网关可以处理内部和外部服务，这意味着您可以使用一个网关来处理微服务、移动后端，甚至是合作伙伴或公共 API。
在本文中，我们将讨论 API 网关的常见特性。我们将详细介绍一些最通用、最受欢迎的开源 API，它们是如何工作的，以及如何利用它们来监控 API 的使用和性能，从而为 API 消费者创造更多价值。
API 网关的特性
API 网关在实现上有所不同，但都有一些共同的特性:
- 数据有效性
- 证明
- 版本控制
- 贮藏
- 分析学
如果一个 API 不返回它所声称的，开发者将很难或者不可能使用它。数据验证将确保您的用户向您的端点发送正确的数据类型，您的服务器正确地存储它们，并且您的 API 向您的用户返回正确的数据类型。
您还可以通过 API 网关实现身份验证。例如，您可能需要对 API 中的特定端点和特性进行速率限制或限定，以供经过身份验证的用户使用。API 网关有助于保持跨终端的身份验证的一致性，即使您实现了多个后端服务。
大多数 API 网关还处理每个端点的版本控制，因此您的组织和用户都可以跟踪您的 API 发生了什么变化。这为您的 API 用户带来了很好的开发体验，并且当您知道开发人员正在使用哪个版本时，可以提供更好的客户支持。
网关也可以实现缓存来提高 API 的性能。根据请求的复杂程度，有些调用可能不需要与数据源进行完整的往返。在这些情况下，您可以配置网关来提供缓存和其他节省资源的过程，以保持 API 的性能和响应性。
最后，可以配置网关来收集 API 分析。这使得它成为关于 API 及其使用的数据的单一来源。使用持续监控来收集端点的使用日志，然后分析数据或与强大的分析工具集成，以便您的组织能够获得对您的 API 的重要洞察。
这些 API 网关特性将帮助您构建可靠地随用户伸缩的 API。虽然您会找到许多解决方案，但我们还是收集了一些开源 API 网关供您考虑。这些工具不仅提供了所需的特性，还提供了在社区贡献的帮助下随时间扩展的能力。此外，您的工程团队可以构建满足您需求的功能，并将其回馈给社区。
在接下来的几节中，我们将分解一些流行的开源 API 网关，以便您可以获得一些关于它们如何工作的信息。
Tyk
Tyk 是一个模块化的开源 API 网关。它是灵活和开源的，因此您可以集成第三方中间件或部署定制插件，使您的 Tyk 实现适应您公司的需求。Tyk 允许您连接系统中的每一个数据源、API 端点和后端服务，使您能够轻松地查看您的 API、控制访问、记录您的 API 以及监控您的 API 路由。您可以将 Tyk 实现为一个自托管解决方案，由您的组织负责管理用于运行 Tyk 的服务器，或者您可以将其用作一个完全托管的解决方案，如果这对您的组织更好的话。
Tyk 开发团队通过与用户交流和构建插件来满足他们的需求，在社区中发挥着积极的作用。通过使核心 Tyk *台模块化，默认的 Tyk 体验可以保持轻量级和敏捷，同时为具有不常见用例的用户维护一个易于访问和易于实现的插件库。这使得 Tyk 成为可能改变或扩大范围的 API 的最佳选择，因为随着时间的推移，Tyk 也可以变得更适合您的 API。
NGINX
虽然 NGINX 主要被认为是一个流行的 web 服务器、反向代理和负载*衡器，但 NGINX 也可以充当 API 网关。如果 NGINX 已经是您的 API 技术栈的一部分，您的团队可以快速地将它部署为 API 网关，这是一个很好的选择。它也非常适合单一服务整体和微服务后端实现。
NGINX 受益于他们为在互联网上提供和开发服务而构建的大型 NetOps 和 DevOps 工具套件。对 NGINX 进行故障排除非常简单，因为它有一个庞大的现有用户群，这些用户共享关于在生产中使用 NGINX API 网关的实用信息。NGINX 被大公司和小公司使用，它适合许多常见的用例，并且很容易上手。
Gravitee
Gravitee 是一个流行的开源 API 网关，它通过一个独特的实现与我们列表中的其他部分共享一组核心特性。它允许您控制谁访问您的 API 以及如何访问，限制他们可以在您的 API 上使用哪些资源，并添加功能来监控您的 API。它旨在为具有 HTTP 服务器经验的开发人员快速实现。Gravitee 被构建得尽可能的轻量级和灵活，因此您的开发人员在构建它的时候会有最小的开销，这样您就可以为您的用户创造价值。
Gravitee 在这个列表中是独一无二的，因为它的所有服务都是开源的，而不仅仅是 API 网关。这包括增强核心 Gravitee API 网关的托管服务。这为他们提供了独特的社区参与度和透明度。用户可以公开报告 Gravitee 的问题，并跟踪他们的问题是如何解决的，或者通过软件更改，或者记录用户自己可以做些什么来解决常见问题。
孔（姓）
Kong 基于 NGINX，一个已经出现在我们名单上的 API 网关。Kong 的某些独特之处使其成为各种规模的组织的普遍选择。Kong 专注于实现大规模的微服务 API 架构，并提供了一套大型插件来实现这一目标。不需要安装每一个 Kong 服务就可以上手。它是模块化和灵活的，因此您只需安装您的团队想要使用的服务。
Kong 的插件开发工具包(PDK)也允许你使用 Go 或 Lua(一种基于 C 的脚本语言)构建插件来扩展 Kong 的功能。这导致了大量由 Kong、他们的合作伙伴以及他们的庞大社区构建的插件可供选择。如果核心的 Kong API gateway 不能满足您组织的所有需求，您可以利用现有的插件库，或者专门为您的独特用例构建一个全新的插件。如果您正在寻找一个社区驱动的、开源的 API 网关，Kong 可能是您的正确选择。
扩展您的 API 网关
我们列出的 API 网关超越了 API 网关最常见的核心特性，具有独特的方面，可能使它们更适合您的组织。在评估 API 网关时，考虑您的长期需求是很重要的，这样您就不会在产品开发周期的后期被迫迁移到不同的解决方案。我们讨论的所有 API 网关都有方法来轻松扩展它们的功能。随着时间的推移，您的 API 需求会发生变化，您将需要能够更改您的 API 网关以满足您的需求，从而继续为您的用户提供最佳体验。
API 可观察性是一个重要而强大的特性，可以添加到 API 网关中。您可以向 API 网关添加强大的分析和监控功能，以获取产品指标，并构建一个为客户创造价值并推动增长的 API。Moesif 为最流行的 API 网关提供了优秀的本地插件，并且可以很好地适应许多 API 管理栈。Tyk 和 NGINX 有很好的与 Moesif 集成的例子，你可以快速实现或适应另一个 API 网关。
乍一看，为您的组织选择 API 网关似乎是一个挑战。只要您选择的 API 网关具有我们讨论过的核心特性，并且可以扩展到包括像使用 Moesif 的 API 监控这样的强大特性，您就可以随着 API 产品的增长而不断改进您的 API 网关。
API 安全性和 FHIR 建议
原文：https://www.moesif.com/blog/podcasts/api-security/Podcast-API-Security-and-FHIR-Recommendations/
Ep。12:艾丽莎·奈特(Alissa Knight)，康复黑客和 API 安全专家
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是 Alissa Knight ，她是 CISO Knight Ink Media 的合伙人，网络安全专家、电影摄影师和出色的内容创作者，擅长大规模讲述品牌故事。
莫里斯国际基金会的 CMO 拉里·埃布林格是今天的主持人。
Moesif · 12. API Security and FHIR Recommendations
在 SoundCloud 上听这一集，在我们的 YouTube 频道上观看，或者在苹果或谷歌上下载。
目录
拉里·埃布林格(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络的第 12 集。我是劳伦斯·埃布林格，今天的主持人，也是 Moesif 的首席营销官，API 可观测性*台。
和我一起的是艾丽莎·奈特，CISO(首席信息安全官)，网络安全专家，电影摄影师和出色的内容创作者，擅长大规模讲述品牌故事。她是一个定期的会议发言人，这也是我第一次在 apidays 界面会议上看到她做主题发言的地方。她正在做一个关于安全和医疗保健应用的精彩演讲，我想我们的观众会很乐意听到她对 API 安全性的看法。
所以我们在这里。欢迎艾丽莎。我们在哪里能找到你？
艾丽莎·奈特(奈特墨媒):所以，首先感谢拉里。这是一个伟大的介绍。我总是为人们不得不提供我的简历和介绍我感到难过，因为这感觉就像可以永远继续下去。所以我要开始让人们介绍我，你知道，那个“安全小妞”，那个“黑客小妞”但是不，谢谢你邀请我参加你的节目。很荣幸来到这里。非常感谢。
所以我在拉斯维加斯。很多人不知道有人住在这里。这不仅仅是为了参加会议，而且人们确实住在这里。我和妻子住在一个叫萨姆林的地方，离加沙大约 20 分钟的路程。
Larry: 很高兴你能参加我们的节目，我们很高兴你能和我们分享你对安全的看法。
顺便提一下，当我向家人提到我在我们的播客上主持你时，我一个 12 岁的女儿问你是白帽子还是黑帽子。科技语言已经变得如此主流，甚至连十几岁的孩子都很熟悉。因此，为什么不与我们分享你从黑帽到白帽的历程，创办两家网络安全公司，然后到今天经营 Knight Inc. Media。
避免监狱黄-成为一个道德黑客
“快进到我 17 岁的时候。我做了一个非常糟糕的决定，黑了一个政府网络。被抓了…最后在网络战中为美国情报部门工作。”即使你一开始是一名黑帽黑客，你也可能成为一名道德黑客。
艾丽莎:所以，令人惊讶的是，即使是 12 岁的孩子也知道黑帽子和白帽子之间的特殊区别。很好的问题，我认为这是一个很好的开场方式。
我大约 13 岁的时候开始从事黑客工作。不幸的是，我很少有指导。但是当时的情况非常不同。你说的是一个不同的时代，那时你还没有今天所有这些可用的资源。你知道，那时还没有 SANS，甚至谷歌。
我通过 IRC 参与了黑客活动。有一个 IRC 服务器，互联网中继聊天，叫做 EFnet，我非常喜欢这些 EFnet IRC 频道。所以，那真的是我的家人。因为，我的意思是我花在网上的时间比和家人互动的时间还多，所以他们几乎把我养大。我是在 IRC 上长大的。
在这些渠道中，我通过其他人学习，也通过自己学习。当时，外面的知识非常少。如今，通过谷歌和所有这些资源，我们可以获得如此多的知识，但那时候真的很难学。你真的需要靠自己去学习。
快进到我 17 岁的时候。我做了一个非常糟糕的决定，黑了一个政府网络。被抓了，他们在学校逮捕了我，信不信由你。在指控被撤销后，他最终在网络战领域为美国情报部门工作。所以我被迫扮演一个白帽子的角色。我穿橙色很难看。监狱不适合我。
我脱离了自己的控制，从黑帽子变成了白帽子，这很好，因为我意识到我是谁，我很清楚，我可以做我最喜欢的事情，赚很多钱，那就是黑客。
因此，渗透测试/道德黑客技术诞生了——实际上是黑客攻击公司网络，并向他们解释我们是如何做的，以便他们能够抵御真正的攻击者。
拉里:我觉得没人穿橙色那么好看。
艾丽莎:橙色不是新的艾丽莎骑士。
Larry: 在你的一个很棒的 YouTube 视频中，顺便说一下，我推荐我们的听众收听，你给黑客下了一个精彩的定义，它是一个想要理解事物如何工作的人，然后发送一个开发者没有预料到或考虑到的刺激。所以，并不像人们想象的那么邪恶。同样，在你的 YouTube 和博客内容上，你真的用大量的经验数据来支持你所有的主张，这真的使它更有价值。
认证不等于授权
开发人员在开发 API 时最大的系统性问题是，他们会记得对 API 请求进行认证，但却无法授权。理解授权和认证之间的区别:您可能有一个 API 密匙来证明您有发送 API 调用的合法权限，但是您不一定被授权接收您所请求的数据。
Larry: 所以，作为一个坐在桌子两边的人，可以这么说，并且写了大量关于黑客攻击银行&健康技术应用编程接口的文章，现在我刚刚听说了一个政府网络。最*有人向 Gartner 报告了您对 API 安全性的看法，开发人员在 API 安全性方面最常犯的错误是什么？
艾丽莎:好问题。我认为，对我来说，最系统的问题是开发人员会记得认证 API 请求，但他们不会授权它。所以，这是理解授权和认证之间的区别。身份验证是您拥有或知道的东西，而授权是被允许实际查看数据。
我可能有一个 API 令牌或 API 密钥来证明我有一个合法的用户帐户，可以合法地访问 API 来发送 API 调用，但是我无权接收我所请求的数据。这是我所看到的所有 API 都存在的一个问题，就是缺乏授权。特别是围绕所谓的破坏对象级授权(BOLA) 漏洞。
对于那些不完全理解这意味着什么的听众来说，我最喜欢用的比喻是整个衣帽间的事情。如果你和我去参加一个鸡尾酒会，我看到你把你那件昂贵的博柏利外套寄存在衣帽间，我想把它带回家。衣帽间的人给了你 18 号，我得到了 17 号，我拿了一支记号笔，把 7 号换成 8 号，然后把它还给衣帽间，说我想要我的大衣。这是 BOLA 漏洞的一个很好的例子。我通过验证了，我有票，但是我没有权利把你的博柏利外套带回家。授权漏洞基本上就是这样工作的。
用望远镜防止流星雨
当您没有指定您的用户有权访问的内容时，BOLA 漏洞经常发生。如果您使用像 OATH 这样的令牌，那么您可以通过将作用域绑定到令牌来限制访问。
拉里:你实际上抢先问了我最后一个关于博拉的问题。请告诉我们，我们的开发人员如何防范此类 BOLA 攻击。
艾丽莎:所以你可以做不同的事情。我注意到的一件事是许多开发者会实现令牌，但他们不会实现范围。一个非常重要的建议是，如果你要实现 OATH 之类的令牌，你要确保你将范围与这些令牌联系起来，这些令牌定义了访问级别或允许你查看的记录。它基本上围绕您的令牌设置参数，并定义您可以请求什么。举例来说，如果我是一名临床医生，我有一个登录帐户，通过这些示波器，我只能查看这些特定的患者。或者，如果我是一名患者，我的令牌的范围应该只允许我查看我的患者记录，而不是/patient/1，2，3，4，5，所有这些其他患者记录。我应该只能要求我的特定病人记录。
显然也有商业解决方案可以实现这一点。但是我发现的许多漏洞只是基本的授权问题。它们不像 sequel injection，可以由传统的 Web 应用防火墙(WAFs) 来处理。waf 非常适合基于规则/基于逻辑的安全控制，因此无法真正抵御 BOLA 攻击。
不要使用 WAFs 来保护你的 API
分析师已经将 Web 应用防火墙和 API 网关提升为抵御 API 攻击的有效安全控制手段。waf 对于识别有效负载中的 sequel 注入或跨站点脚本很有用，但是它们不能知道我是否被授权查看我所请求的数据。
关于基于规则的 waf，比如 ModSecurity 甚至 API 网关，我注意到在你最*的一篇 YouTube 帖子中，你说它们对保护你的 API 毫无用处。
艾丽莎:我很固执己见！
Larry: 有趣的是，我认为这是来自 Gartner 的 2019 年报告，你需要做什么来保护你的 API，他们在报告中拥护 API 网关和 WAFs 的优点。然后你上了 Gartner，基本上把它否决了。
艾丽莎:我觉得他们不太喜欢我。
Larry: 还有什么可以做的，比如先进的异常检测，可以进一步保护你的 API。
艾丽莎:这是我的立场。我不认为安全性应该成为产品的一个特征。例如，当您有一个 API 网关时，他们会将安全性作为一项功能添加到他们的主要职责中。对我来说，这是一个问题。
Gartner 发布了一份关于 Web 应用程序防火墙的报告，其中他们说 WAFs 是针对企业的有效安全控制。这是我可以整天谈论的事情——关于付费游戏和分析师行业之类的东西。但我不会去那里。事实是，我认为这造成了这种虚假的安全感，因为 CISOs 正在购买 WAFs，他们正在实施 API 网关并打开安全性，这造成了这种虚假的安全感。
我最*入侵的每一个 API 都受到 WAFs 的保护。这些首席信息官正在倾听来自分析师行业的信息，他们不得不发表和谈论这些信息，因为这些是他们的付费客户。但问题是，它们不是抵御 API 攻击的有效安全控制措施。WAF 如何知道我是否应该请求不属于我的数据？它将在有效载荷中寻找 sequel 注入、跨站点脚本攻击之类的东西。但是它不知道我是否被授权查看某些东西，这超出了它的理解范围。我认为这回答了你问题的四分之三，另外四分之一是什么？
了解哪些流量流向您的 API
保护您的 API 的第一步是了解它实际上要做什么。合法的人流量和合成的流量有很大的不同。你不能保护你不知道自己拥有的东西。
Larry: 如果 WAFs 和 API 网关不摆动它，你怎么保护你的 API？事实上，我认为你提到了一个非常有说服力的观点，我也在你的 YouTube 频道中听到过，那就是许多 CISOs 和开发人员将安全性视为事后的想法或附加条件。你说，不要这样，你应该从一开始就把安全作为重要的考虑因素。
我想以这样一个事实作为这个答案的开头，即任何拥有 API 的组织都需要知道他们的 API 将会得到什么。他们需要知道:这是人流量——合法的人流量，是合成流量，还是使用凭证填充的账户接管(ATO)攻击？寻找高频工具也是一个好主意，这些工具可能会持续攻击您的 API，并从合法用户那里窃取非常昂贵的带宽和资源。每个人都应该知道自己拥有什么——你无法保护你不知道自己拥有的东西。这非常重要。因此，我想以这样一个事实作为开始，即您应该知道流向您的 API 的流量内部是什么。
向左移动安全护罩向右移动
使用双管齐下的方法在编写代码时实现安全性，让开发人员参加安全代码培训，并使用工具在编写不安全的代码时发出警告。保护权:在你的保护被部署到生产中后保护它。
Alissa: 在了解哪些类型的流量流向您的 API 后，最重要的事情之一是左移安全，但也要屏蔽右移。左移安全的概念是，当你写代码的时候，你应该把你的开发人员送到安全的代码培训，你应该实现一个工具，这个工具会监视他们写不安全的代码，当他们写不安全的代码时，对他们大喊大叫。寻找一个解决方案，你可以用应用程序编译 SDK，如果你有一个基于应用程序的架构，那么，把安全转移到左边:当产品被创建时，当代码被编写时，实现安全。
“保护权利”的理念是，不仅要在编写时保护它，还要在它部署到生产环境后保护它。因为我们知道网络安全是一个非常转瞬即逝的行业。它移动得非常快。就在你我谈话的这段时间，又有几个新的零日漏洞出现了。每隔几分钟就会有新的漏洞和漏洞出现，所以你需要对即将发生的事情保持警惕。
未知的未知。这就是现在让每个人都紧张的原因，也是现在让很多人被攻破的原因——未知的未知。对我来说，已知是传统的安全控制，如网络入侵检测，就像过去的 Snort，当你为这些漏洞编写 Snort 签名时，你基本上是在记录已知的已知。但是未知的未知呢？我不知道什么是我还不知道的，所以这就是神盾局可以带我们去未来了解我们不知道的事情的地方。
拉里:我刚看完妮可·珀尔罗斯的一本书，他们是这样告诉我世界末日的。
艾丽莎:哦，妮可，实际上我刚刚在 MoneyFest，Money2020 上采访了她。所以如果你还没看过，我强烈建议你和你的观众去看一看。这是一本很棒的书。她是纽约时报的一名非常非常出色的记者。
拉里:对。这本书又长又厚。一本厚书。它读起来像一部犯罪惊悚片，涵盖了整个剥削行业，从 2000 年、2002 年的早期开始。左移右护的绝佳视角。我喜欢这个比喻。
PHI 的价值是信用卡信息的一千倍
你的医疗保健信息是持久的，如果它被发布到黑暗的网络上，它就消失了，无法改变或恢复。相比之下，在 Target 被黑客攻击后，银行只是简单地给你邮寄一张新的信用卡。
拉里:继续前进。由于 Moesif 用于一系列健康技术应用程序，并且我们的一些观众在健康技术部门工作，根据您的经验，ePHI(电子患者医疗保健信息)或个人银行信息在黑暗网络上更有价值，为什么？
艾丽莎:哦，实际上我对此做过研究。这是一个很好的问题。所以很明显，在我的工作中，我经常浏览 Tor 网站，黑色网站，我可以告诉你的一件事是，电子健康记录的价值是美国信用卡号码的 1000 倍。所以当你有一个 PHI 记录，EHR 记录，不管你怎么称呼它，你有很多数据。所以，如果我妥协了，在妥协中，我偷了拉里的信用卡号码，你的银行可以很快发给你一张新卡。银行花了几块钱。他们送你一张新卡，你有一张全新的卡，你很好。
如果我泄露了你的健康史，并把它放在黑网上出售，你有多容易通过邮件获得新的健康史？不可能的。没有这回事。它不见了。一旦公开，就结束了。如果我想知道如何杀死拉里，我找到他的 PHI，我发现他对蜜蜂叮咬过敏。所以我带着大黄蜂去追你。但事情一旦发生就无法挽回了。这也是我认为它价值如此之高的原因之一。另一件事是，已经妥协了这么多的医疗保健 API，我可以告诉你，那里有一个数据宝库。
有一次，我不仅看到了医院的入院记录，还看到了那个人的家庭成员信息。所以，当你去一家医院，他们要求*亲信息和所有这些其他的东西，所有这些其他的数据，他们需要知道，这就形成了一个非常丰富的内容，非常丰富的数据环境。在 PHI 记录中有很多关于个人信息的数据，这就是为什么我们需要如此认真地对待这个问题，这也是我很多医疗保健研究的动力。
当你谈论人们的健康时，这和破坏一个公司网站是完全不同的。在过去的二十年里，发生了太多的变化。我是说，以前我在 IRC 上玩这个的时候，都是关于，地狱世界的大规模毁损。现在是钱。这是一个利润丰厚的行业。当你谈到黑暗面和这些勒索软件集团带来的数千万美元时，这是疯狂的。我的意思是，许多勒索软件集团比一些国家赚得更多，手头的现金比一些大公司还多。所以很恐怖。这是一个巨大的行业，对于你的问题，冗长的答案是 PHI 绝对比财务数据更有价值。
这并不是说，不要误会我的意思，拉里，这并不是说它不重要，它只需要比 PHI 少得多的钱。
原料药是医疗保健中最薄弱的环节
最大的问题之一是 PHI 的监管链，数据从一个非常安全的 API 转移到一个不太安全的 API。Cerner 和 Epic 有非常强的安全性，但是一旦 PHI 离开了 API，你就不知道下一个系统有多安全了。黑客瞄准了不太安全的 API——拆东墙补西墙。
Larry: 考虑到 PHI 和 EHR 的患者记录如此宝贵，锁定 healthtech APIs 是否存在独特的挑战，相对于那些来自 fintech 的挑战？
Alissa: 我认为 API 可能是安全方面最薄弱的环节。不同的医疗保健提供商将使用不同的人力资源系统，无论是 Epic 还是 Cerner 或其他系统，请填写此处的空白。这些系统之前，我相信我们会谈到这一点，但在 FHIR 之前，他们不能互相交谈。有一些问题，例如，如果我的目标是像塞尔纳·EHR 系统这样的系统，它可能受到非常非常好的保护，非常安全，但一旦那些 PHI 离开该系统，转而使用不太安全的 API，作为一名黑客，你认为我会以哪里为目标呢？我将针对安全性较低的 API。我要走阻力最小的路。
我认为最大的问题之一是监管链，或最薄弱的环节——PHI 可以从一个非常安全的 API 变成一个不太安全的 API。它不太安全，因为编写它的人只是一些小企业，他们不知道自己在做什么，也不知道任何关于安全的事情。我抢劫了他们。我抢了保罗而不是彼得。
此外，我认为第二件事是普遍性，我甚至敢说，在我观察的许多移动应用程序中，这是非常系统化的，在这种移动健康或移动健康应用程序的新概念中，API 密钥和令牌以明文形式存储在移动应用程序中，或以明文形式硬编码。开发人员只是伸出他们的手臂说，“嘿，如果我不能把它们存储在应用程序中，我应该把它们存储在哪里？”他们不知道该把它们放在哪里。所以这确实是个问题。我认为在应用程序方面存在问题，密钥和凭证被硬编码，然后在 API 所在的后端也存在问题。
API 有多个攻击面
由于数据无处不在，城堡和壕沟的安全是不可能的。攻击面很广，从面向合作伙伴的 API(考虑供应链威胁),到 web APIs(没有 SDK 来捆绑额外的安全性),再到中间人攻击(证书安全性影响服务器/客户端 API 安全性)。
拉里:对。您能否详细介绍一下 ePHIs 可能受到攻击的不同攻击面，以及如何加强这些攻击面？我们讨论了一些应用程序本身，但是关键商店、网络、API 端点以及数据泄露又如何呢？
当然可以。显然到处都有数据。城堡和护城河的整个概念在这一点上被完全抹去了。你控制不了。因此，在客户端，密钥和令牌或凭证的硬编码才是真正的问题。您有不同类型的 API，所以让我们来讨论不同的攻击面。
您有面向合作伙伴的 API，其中供应链攻击是当今的真正威胁。我甚至不需要从网上追踪你，我可以找到你和谁做生意，然后追踪他们。因为你们两个之间有联系，通过一个合作伙伴 API，一个 B2B API，它正对着你们两个公司，我加入了。因为不管是谁写的，都觉得这是一个面向 API 的合作伙伴，而不是面向互联网的合作伙伴，所以我们不用太担心安全性。
你有 web APIs，如果你没有移动应用，客户端的安全控制将会大不相同。虽然你可以用移动应用程序编译一个 SDK 来增加额外的安全层，但是当你不能用 SDK 编译 Chrome 浏览器时，你该如何处理 web APIs 呢？让谷歌帮你发布吗？
还有一个关于中间人/中间人/中间人攻击的问题，在这种情况下，许多组织没有实施证书锁定。作为一名攻击者，我可以用很多这样的应用程序将自己插入到客户端和后端 API 之间的通信中。然后我向两个方向提交 SSL 证书，告诉 API 我是客户机，告诉 API 客户机我是 API 端点的 API 服务器。他们都认为他们在和对方说话，但他们实际上是在和我说话。这使我能够解密 SSL 加密的流量并查看它。我可以通过拦截流量并解密，然后将这些 API 请求复制并粘贴到我自己的 API 客户端(如 Postman)来了解 API 的工作原理。然后，我可以用 API 客户机自己手动跟踪 API 端点。
禁止监狱坏手机上的应用程序没有帮助
黑客不在乎你的手机应用程序是否能在越狱的手机上运行。下载 APK，或者拦截从手机应用程序到&的 L7 流量，通常足以找出如何访问所有数据。
拉里:明白了。我最*听了你的一个教程，是关于如何真正做到这一点的，而且出乎意料的简单。我也不是超级伟大的程序员。事实上，我根本不是一个程序员。但是有一点令人震惊的是，你可以通过下载到你的 MAC 上的 Postman 和一些软件包，把所有的信息都提取出来。
艾丽莎: 《吃豆人》让事情出奇的简单。这是一个像红帽转速和真正强大的包管理器。这些工具很多都是免费下载的。比如我觉得叫高级休息客户端，那是免费下载的。问题是，当你进行黑客攻击时，这是我不明白的，许多开发人员会实现安全性，并说“哦，别担心，我们希望确保移动应用程序不会在越狱或路由的手机上运行。”我不在乎那个。我不需要在越狱的手机上运行它。面对许多这样的 API 攻击，我只是从我的 android 设备上提取了 APK。然后使用 Apk Extractor 将它加载到我工作站上的工具中，讽刺的是，你可以从谷歌商店下载。我不需要执行它。我不需要在监狱环境中运行它。我可以在笔记本电脑或工作站上完成所有这些工作。
或者，我甚至可以在 android 设备上运行它，并用工具拦截流量。然后再次访问所有数据。信不信由你，我更喜欢这样做，而不是看 API 文档。对于 FHIR，有很多关于它的文档，因为 FHIR 的要点是你已经为它开发了。但我更喜欢实际拦截流量并观察它。我是一只包猴。我倾向于通过查看包和 API 在第三层如何工作来学习，而不仅仅是阅读文档。
使用 MobSF 查找 API 密钥
要解构一个应用程序，只需将 APK 文件拖放到 MobSF 中，它只需将其拆开，还原到原始源代码，然后用 Grep 找到硬编码的密钥/令牌。
拉里:我注意到你是 Grep 的支持者。
是的，我是一个希腊女孩。哇，你看了我的视频，不是吗？但谢谢你跟踪我，我很感激。爱我的粉丝。
有一个很棒的工具叫做 MobSF ，给那些可能不熟悉它的观众。它被称为移动安全框架，它允许您将数据包 APK 文件拖放到该工具中，然后它会对其进行解构。它只是把它拆开，倒回到原来的源代码。所以我才能找到所有这些硬编码的钥匙和令牌。有趣的是，很符合你的观点。我不喜欢使用图形用户界面，实际上我会用它来返回源代码。然后我进入我的命令外壳，进入终端，使用一串 Grep 字符串。这是我在应用程序中寻找硬编码 API 秘密的首选方式。
原料药需要符合 FHIR
最*的《医疗法案》规定医疗技术公司需要向请求者提供患者数据。符合 FHIR 的 API 提供了一种安全的方式来满足这些需求。
拉里:有趣的东西。继续关注 HL7 的工作以及他们即将发布的最新版本 FHIR(快速医疗互操作性资源)标准。这项工作有多重要，开发人员是否应该按照最新的 FHIR 标准进行构建，您认为这对医疗保健领域的 API 安全行业有多重要？
艾丽莎:这一点都不重要——不，只是开玩笑。这是巨大的。在我所有的脆弱性研究中，这可能是我做过的最重要的事情，因为你知道，我接触了很多来自医疗保健行业的人，谈论这项研究有多么重要。
很多人不知道这一点，但他们自然而然地认为我们黑客天生就知道这些东西。我不知道怎么拼写 FHIR，更不知道当我走进这里的时候它到底是什么。我不得不做作业。我不得不研究。我甚至不知道 HL7 是谁。HL7 是组织的名称，也是标准的名称。这就像是整张面巾纸。这些都是我需要研究和理解的。这花了我几个月的时间，我仍然不知道它的全部，我仍然不完全理解它的许多内容。我对这项研究感到非常兴奋。我目前正在研究 FHIR 的 R4，这是该标准的第 4 版。
它是由 HL7 国际组织创建的，健康七级国际组织，就像你提到的，在 FHIR 之前，有所有这些在 FHIR 之前的 HL7 的不同版本。并且 ONC(国家健康信息协调员办公室)已经基本上为医疗保健支付者和医疗保健提供者设定了这些截止日期，并且说“你需要使这些患者数据对请求它的人可用，否则你就违反了这个数据封锁规则，信息封锁规则。”这可能意味着严厉的处罚和罚款。如果你被发现违反了这条信息封锁条例，那可就麻烦了。这有一个截止日期，组织和医疗保健支付者需要实现 FHIR APIs，并使这些医疗保健数据可用。
唯一的事情是，我想展示当这些 API 没有被正确保护时会发生什么。这是这项研究的动力。这是我过去一年一直关注的。这项研究的第一阶段目标是存储医疗数据的移动医疗 API。在第二部分，我们称之为玩 FHIR，我们专注于入侵 FHIR APIs。这就是即将发布的报告将详细介绍的内容，它将给出我们的发现以及我们在那里看到的情况。有很多，我真的很兴奋能够公布这项研究。我知道你们在医疗保健领域也做了很多工作。医疗保健是一个目标非常丰富的环境。那里有如此多的钱，黑客们知道这一点。数据太多了，通过这些易受攻击的 API 很容易获取。
正确实施 FHIR
使用 OAuth、认证、授权和其他最佳实践创建坚如磐石的 FHIR APIs。如果人类实现了它们，它们就会有漏洞。让他们很难被发现。
拉里:在这里戳熊，但如果修订版 4 即将推出，你一直在努力，许多其他聪明人也一直在努力，它发布后会有很多漏洞吗？或者，它将会是安全健康、移动健康和 ePHI 超越 AIPs 的涅槃，继续前进？
Alissa: 我需要向您的观众澄清，当您部署 FHIR 时，您不会真的像购买收缩包装的 FHIR API 一样购买，并确保将安全性包括在内然后它就展开了。这将取决于实施。
一个组织可能实现了一个 FHIR API，但是没有遵循最佳实践，因此它非常容易受到攻击。但是，另一个组织可能会实现 FHIR APIs 并使之坚如磐石。漏洞在哪里可能并不明显。也许会比其他组织花更长的时间来找到它。我永远不会说任何事情都是不可破解的。如果人类正在实现它，它会有漏洞，但它们可能更难被发现。这就是他的特点。你和我都可以实现 FHIR APIs 来服务我们的 PHI 记录，但是你的可能比我的更安全，因为我不知道我在做什么，而且我实现得不安全。
所以要看实现。这取决于谁在实施它，以及他们是否知道如何正确地保护它。因此，在 FHIR 上的智能带来了 OAuth 和所有其他事情，如认证和授权。因此，实现 FHIR 当然在很大程度上取决于实现者，以及他们是否正确地实现了它。
获得 FHIR 认证
作为额外的检查，让你的 FHIR API 获得认证是值得的。
Alissa: 现在，我真的想插一句——组织可以通过一个认证过程来获得 FHIR API 认证。因此，如果你要实现一个 FHIR API，我也要实现一个，我实际上可以让我的 FHIR API 获得认证，证明它是根据标准实现的，并有适当的安全控制。您可以继续运行您的 FHIR APIs，但无需认证。这不是强制性的。你不需要得到你的认证。
在这项研究中，我接触过的 EHR 供应商当然都在追求认证。但是你可以有非认证的和认证的 API。这意味着易受攻击和非易受攻击的 API 将会非常多。我这么说的时候要小心，因为我并不是说一个经过认证的 API 将是安全的和不可破解的，我只是说你将拥有两者的混合。
FHIR 认证与 HIPAA 合规性
与 HIPAA 不同，FHIR 有第三方机构可以认证你的 API。
拉里:这听起来有点像 HIPAA 合规，没有第三方认证机构；有您应该遵循的最佳实践，也有人会审核您构建的内容，但是 HIPAA 基本上是您应该遵循的一系列指导原则。听起来，HL7 更进了一步，有第三方机构可以检查你是否按照标准实现了 FHIR。
Alissa: 我采访过的一家 EHR 供应商，我不会说出他们的名字，但他们确实说他们正在争取年底前获得认证，这将使他们成为第一家获得 FHIR 的公司。我不知道谁是真正的认证机构，也许是 HL7，我不知道。但是你绝对可以选择去获得认证或者不获得认证，就你的例子来说，你不需要这样做。
API 安全没有一个合适的解决方案
有很多很好的 API 安全解决方案。但是实际的最佳方法是什么，我不知道是否会有答案。
拉里:明白了。好了，我们今天的播客已经涵盖了很多内容。关于如何保护你的 API，特别是你的移动医疗和医疗技术 API，你已经给出了很多精彩的见解。作为倒数第二点，我们还没有看到 API 和安全性的下一步是什么？
艾丽莎:我认为#更多请。这是结束节目和面试的好方法。首先，如果我戴上算命的帽子，这绝对是世界前进的方向:我们正在完全远离整体架构，转向微服务，一切都在转向云，一切都是由 API 驱动的微服务。我认为我们将会看到越来越多的这种情况。
问题是组织将从运行 1 到 2 个 API，发展到运行 1，000 到 2，000 个 API。我现在正在与一个拥有超过 1600 个 API 的组织合作。这么多 API。我认为这将创造一个更大的市场。在向 Gartner 提交的关于 API 状态的演示文稿中，有一点是市场正在经历一场身份危机。
API 安全市场还不知道它是什么。每一家拥有 API 安全威胁管理解决方案的公司都相信他们的做法是正确的。这不一定是错的。每一家公司可能都在用正确的方法处理 API 安全问题，但是我认为陪审团仍然不知道它会落在哪里。它是在线的吗？是被动吗？我们用 SDK 吗？我们使用分布式跟踪吗？我们是否使用…有很多非常棒的方法，其中很多是我的客户，他们都有很好的解决方案。实际的最佳方法是什么，我不知道是否会有答案。
但我知道什么是错误的方法。我们已经在节目中讨论过这一点，那就是这些传统的基于规则的系统，如 Web 应用程序防火墙。或者，我们已经有了一个 API 管理解决方案，让它来确保安全性。我的研究表明，我可以攻击和破坏这些 API，并通过受 WAFs 和 API 网关保护的 API 窃取所有这些数以千计的患者记录，这证明了没有人应该使用这些来保护他们的 API。他们应该关注像 Moesif 这样的解决方案，关注像 Traceable 和 Approve 这样的其他威胁管理解决方案，以及其他许多优秀的解决方案。
检测您的 API
保护您的 API 最重要的一步是了解它们发生了什么。给自己配备一个工具，让你能够深入研究你的 API 的流量。
首先，每个人都需要明白的是，你无法保护你不知道自己拥有的东西。您需要知道您有多少 API，它们提供什么类型的数据，它们是否与互联网隔开(我可以从互联网访问它们吗)或者它们是否面向合作伙伴，我们是否授权和认证(我们给予您对此的认证访问，但是我们是否授权您可以请求什么数据)？所有这些都非常重要。了解您的 API 服务的数据类型。如果我有 1600 个 API，你认为我会知道哪些 API 服务于 PII 或 PHI，哪些服务于 PCI 数据吗？我应该知道这一点，但我不可能记住它，所以我需要一个工具来做这件事。我对你们所有人的建议是知道哪些数据将进入你们的 API，拦截它，查看它，分析它。知道那里发生了什么，知道什么占用了 API 的带宽，以及正在发送什么 API 请求。用工具装备你自己，这将给予你观察它的能力。
拉里:然后采取行动。多么精彩的总结和采访收获。我的最后一个问题:我们的观众在哪里可以找到更多关于艾丽莎的信息，你接下来会在哪里演讲？我知道你是一个非常多产的主题演讲人。艾丽莎会有什么下场？我们的观众还应该关注哪些资源？
作为一名内容创作者和电影制作人，我认为我发布漏洞研究和内容的主要渠道是 YouTube。所以，一定要订阅我的 YouTube 频道，打破通知的铃声图标。但是，也请在 Twitter 上关注我，并在 LinkedIn 上与我联系。总的来说，我喜欢对 API 安全和黑客技术的研究。我有一本关于通过 Wiley 入侵 API 的新书要出版了。我的第二本书。我正在为一部新电视剧写剧本。我的世界里发生了很多事情，我肯定会敦促所有人在 YouTube、LinkedIn 和 Twitter 上关注我，因为这是我的主要去处。除非他们想看我食物的照片，否则我会在 Instagram 上发布我食物的照片。
我感谢你们所有人，作为我的网络的一部分，我的追随者和粉丝们请保持关注，因为这将是非常令人兴奋的一年。我将在 HIMSS 上发表演讲，我想说，这可能是世界上最大的医疗保健会议，我将在那里做主题演讲。除了其他一些令人惊叹的主题演讲人，如 A-Rod 和 Michael Coats。
如果有人想过来打个招呼，我肯定会看看会发生什么，我也会在 DEFCON 上发言，今年我会在 30 多个会议上发言。所以很多激动人心的事情。我还将在即将到来的 Money2020 会议上发表主题演讲。这真的很令人兴奋。实际上，我会在我的网站这里和【KnightInkMedia.com T2】T3】上发布我的活动日程，请留意。再说一次，找我的最好方式是在社交媒体上。
拉里:太好了。非常感谢艾丽莎今天抽出时间。我相信我们的观众会非常喜欢这个播客。
谢谢你。感激不尽。
适合业务案例的 API
原文：https://www.moesif.com/blog/podcasts/developer-marketing/Podcast-APIs-for-the-Right-Business-Case/
Ep。14:埃里克·王尔德，阿克斯韦公司的催化剂
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是 Axway 的催化剂、作家和标准撰稿人 Erik Wilde。他帮助组织进行数字化转型，确保愿景、战略和技术保持一致，并得到业务和组织计划的补充。
劳伦斯·埃布林格，Moesif 的 CMO，是你今天的主持人。
Moesif · 14. APIs for the Right Business Case
在 SoundCloud 上听这一集，在我们的 YouTube 频道上观看，或者在苹果或谷歌上下载。
目录
- 1:55 从您的 API 中驱动价值
- 3:53 专注于一项超级有价值的业务能力
- 8:23 大学生关注 API 商业案例
- 11:54API 的互联网——引擎盖下的 API
- 15:17 最佳的 API 风格是由 API 的用途决定的
- 17:13 为什么安全性对 API 健康很重要
- 23:30 API 可观察性 vs API 监控
- 26:28 通过指标和结论衡量 API 的成功
- 30:15 整个 API 生态系统的未来
拉里:欢迎来到 Moesif 的 APIs over IPAs 播客网络的第 14 集。我是劳伦斯·埃布林格，今天的主持人，也是 Moesif 的首席营销官，API 可观测性*台。
加入我的是 Eric Wilde，多产的 YouTuber，作者，标准贡献者，Axway 的催化剂，最*是加州大学伯克利分校哈斯商学院的客座讲师。
Eric 的大部分职业生涯都在从事 web 技术和 API 方面的工作。虽然他的背景是计算机科学，但他认为技术很少是阻碍组织发展的因素，所以现在他专注于帮助制定战略，以确保公司成功。
欢迎埃里克，我们在世界的什么地方能找到你？
谢谢，谢谢拉里的热情欢迎，也谢谢邀请我。现在，你可以在伯克利找到我，因为我计划在这里参加一个为期四天的校内课程，就像本周的前四天。嗯，像很多事情一样，最后一分钟它变成了一个在线的事情，但我仍然在这里。所以，是的，我在东湾，我想你在半岛的某个地方。
拉里:实际上，我就在旧金山海湾大桥的对面。伯克利和你*常的家完全不同。你一年中大部分时间住在哪里？
埃里克:我现在住在苏黎世。我曾经在伯克利住过一段时间，那时我在伯克利工作，但是几年前我们搬到了苏黎世。我们仍然喜欢回到这里，因为这是一个如此可爱的地方。
从您的 API 中获取价值
如今 API 专业人员应该关注什么？人们不再需要被说服为什么原料药很重要，它们就像蘑菇一样冒出来。更确切地说，重点在于什么是好的 API，我如何让我的团队设计它们，以及我如何用一个*台来支持它们。
拉里:对，的确如此。那是非常真实的。
现在，你和三个火枪手最*发布了开创性工作持续 API 管理的新版本。除了封面的彩色照片之外，自第一版以来的过去三年中，API 生态系统有什么新的变化以及如何变化？
埃里克:这是个好问题。在某种程度上，新的是，你可以说现在发生的事情是，我们必须越来越少地告诉人们为什么 API 很重要，它们很重要，以及如何设计 API。我们必须更多地讨论如何大规模地做到这一点。
就像我的一个好朋友，Isabelle Mauny，在一个播客上说，“API 就像蘑菇一样到处涌现。”。我认为在某种程度上这是真的。我认为越来越多的组织没有看到这一点，当然，他们正在使用 API，每个人都在使用 API。如今，如果不使用大量的 API，你就无法使用计算机。
但是，管理这些并弄清楚我如何获得为组织驱动价值的 API，而不仅仅是“我们有 API，所以可能会发生好事情”。而且还要了解什么是好的 API？什么可能不是这么好的 API？我如何让我的团队设计出好的 API？我如何用一个*台来支持他们？
所有这些，我认为我们仍然会看到这个行业的发展势头，因为我们知道 API 不是你唯一需要的东西，但它们可能是一个限制因素。因此，重要的是要真正做到这一点，而不仅仅是抱最好的希望。
使用 Moesif 强大的 API 监控功能评估和优化您的 API。T3】
专注于一项极具价值的业务能力
API 实际上只是一个接口。业务价值的交付很重要，但这不是开发 API 产品时要考虑的最重要的事情。
拉里:嗯，很有趣。多棒的 segway 给你的一条 pins tweets，上面写着“为正确的事情构建 API 比为事情构建正确的 API 更重要”。我的意思是，这不仅是一个绕口令，而且有点难以解开。你能为我们打开它并告诉我们你是什么意思吗？
当然，当然。
我认为关于 API 的一件重要的事情是理解它实际上只是一个接口。API 是一种能力的交付机制，有时我认为，我们在 API 领域高估了交付的重要性，而不是交付的内容。我的意思是说，如果你有世界上最好的 API，有很好的文档记录，设计完美，使用所有正确的 http 方法，并正确地做所有这些事情，但它提供了对没有人需要的功能的访问。那个 API 没有任何意义，从审美上看可能是一个美好的东西，但肯定不会带动任何商业价值。
另一方面，如果你有一个超级有价值的业务能力，它可能不是最好的 API，但是人们可以以某种方式忍受，这将更有价值。
最后，我认为更重要的是，至少在第一步，在你直接跳到“我们使用哪种 http 方法”之前，考虑我设计的 API 是为了什么，你知道所有这些事情。我认为，有时我们真的会专注于设计的技术部分，但我们并没有真正足够关注我们实际设计的产品，而不仅仅是产品的交付。
我认为最*的书，我认为我们有一波很好的书出版了，所以迈克尔·阿蒙森刚刚出版了一本。最*有一本是詹姆斯·希金波坦写的，对吧。有一本是 API Handyman 写的，在所有这些书中，我认为现在关注的是整个过程，而不仅仅是“你在技术上做什么？”，而是“我如何设计正确的东西？”。
我认为我们越来越理解这一点，但我认为这仍然是我们必须关注的事情，并确保设计的这一部分是重要的一步。在进入技术细节之前，我们对此非常小心。
拉里:非常有趣，是的。有趣的是，当我们与新客户签约时，传统上，首席执行官是产品人，我们看到，产品、商业案例和制造完整产品所涉及的所有问题都更加重要，然后以正确的方式实际实现 API *台。因此，你对产品经理在 API *台中具有非常重要的战略作用的分析也是我们在客户群中看到的。
埃里克:我想，最终，是这样的，对吗？思考我正在创造的价值以及一直在使用的一些例子是很重要的。像 Twilio，Stripe 和所有这些东西，我的意思是我也喜欢这些例子。
但是最后 Stripe 没有他们成功，因为他们的 API 不错。但是 Stripe 是成功的，因为每个人都需要支付服务，他们为此提供了 API，对吗？这是主要原因。
然后，他们在设计产品方面也做得很好，对吗？但是，如果没有最初的想法，即“嗯，实际上每个人都需要支付服务，没有人想自己做”，那么为什么没有一个好的 API 呢？
正是这一点让他们成为了今天的公司，然后他们在同样重要的事情上执行得很好。
了解更多关于谁使用您的 API 以及如何使用 Moesif 的信息。T3】
学生关注 API 商业案例
加州大学伯克利分校哈斯商学院的学生知道，很多业务将流向 API。教授可扩展和可持续的商业模式让学生为不断变化的 API 环境做好准备。
拉里:非常非常真实，非常真实。是的，我的意思是，我认为有很多例子，你可能有一个很好的实现，但你不一定有一个很好的业务案例来证明你的公司，即使我们在 API 领域处于一个非常泡沫的时间点。我认为市场和投资者仍然在市场中寻找收入和牵引力，而不是真正有光泽、设计良好的 API 实现。
埃里克:对，就是这么回事，对吗？同样，这个星期有四天，我基本上在这里度过了商学院，我的意思是他们理解 API 的重要性，因为有很多业务都是面向 API 的。但是，当他们看到 API 时，他们不会对“嗯，他们以正确的方式使用 HTTP Post 吗？”。他们会问类似这样的问题:“嗯，有这样的生意吗？”。比如你的商业模式是什么？你将如何建立一个可持续发展的业务来提供服务？然后也许你也应该在技术层面上做好设计，但那真的不是主要的。这很重要，但不是主要的事情，也不是我们应该关注的唯一事情。
拉里:对，对。最*我们的播客中有一位大型企业软件公司的首席 API 产品人员，她的任务是真正提出通过 API 实现一些功能的整体计划。他们的一些客户要求这样做，但这并不是足够的理由。与她交谈很有趣，她告诉我，做好这件事最重要的一点是，它首先必须是一个收入中心。它必须有能让高管团队说“是的，这是值得投资的”的东西。
Erik: 是的，如果你做得好的话，你还可以使用 API 来了解一些人们或多或少感兴趣的东西。不久前，我与 Tanya Vlahovic 进行了交谈，我想她现在在 Salesforce，她那时曾在易贝工作。她讲述了一个故事，在易贝，有一个 API 是很重要的，但最初他们认为“API 对于人们可能寻找物品和做这类事情很重要”，他们就是这样。
但事实证明，推动更多价值的是，美国石油学会现在推动最大价值的是那些将过剩库存放在易贝的大公司。对吗？他们通过一个 API 来做这件事，他们需要一个 API，因为，当然，他们必须卖出，我不知道，大概 10 万双鞋。你需要一个 API 来确保这个库存从你所在的地方进入易贝。
拥有一套初始的 API，然后理解“嘿，这似乎是真正推动价值的东西”，然后在这方面投入更多的努力，对吗？这是一个很好的方式来理解我们必须找出真正推动业务的是什么，然后我们可以在这个方向上分配我们的资源。
通过 Moesif 了解您的 API 采用情况和规模
API 的互联网——引擎盖下的 API
API 很复杂，但是理解创建和支持 API 的基本构件对于构建一个优秀的 API 产品是很重要的。
拉里:对。非常非常突出的一点，非常有趣。这是一个小小的不合理的推论，实际上是从商业案例跳到更多的底层技术和对一般技术的理解。我真的很喜欢你在 YouTube 上关于互联网如何工作的 12 分钟讲解，你解释了 IP，TCP，SSL 和 UDP。
和我们分享一下为什么你认为这样的理解对 API 专业人员很重要。
Erik: 所以我认为，至少在一定程度上，理解整个 API 到底是如何工作的是很重要的。
当然，你不需要理解，比如所有的东西都是玻璃纤维，我是说在那种情况下，我也不知道这些东西是如何工作的。但我认为真正理解基本机制很重要，这样你也能理解一些风险，以及一些可能正确发生的事情。
例如，你可以得到延迟，你可以得到，取决于正确的技术，你可以得到事物的重复，当然，总是 API 可以某种程度上正确地删除。
我认为重要的是比仅仅理解 http 和 json 更深入一点，并且理解它是建立在什么之上的。至少给我展示一下它的基础，它的基础就是 TCP/IP。
我认为这也有帮助，例如，你变得更加意识到事情可能会失败，对吗？我认为，我们仍然看到的许多事情是，API 领域的太多设计只是建立在快乐的道路上，假设一切都将永远正确。现在你看到许多应用程序，如果事情不顺利，它们会悲惨地失败。你可以很容易地说“嗯，那没有必要”，对吗？通过更好地理解事情是如何失败的，只要考虑到这一点，您就能够拥有一个更健壮的应用程序。
我认为这对于从事这方面工作的人来说是很重要的，他们将 API 作为工具来组装部件。为了理解事情是如何出错的，我理解它们会继续出错，它们会如何出错，然后我可以更好地为那些情况设计。我认为为失败而设计变得越来越重要。
就在最*，Gartner 的这篇文章预测，到 2025 年，我想他们会说，“组织对 API 的外部依赖性将是现在的三倍。”这意味着你越来越依赖他人，这很好，因为你可以组装东西，这很好。但是你也必须负责任地管理这些依赖，并且可能构建一些东西，这样，如果那个东西失败了，我仍然至少做我的工作的一部分，对吗？
我认为，理解有时仍然是我们需要更多一点的基础来真正理解什么会出错，所以我们只是设计一个更有弹性和更健壮的系统。
借助 Moesif 深入了解您的 API，从采用漏斗分析到端点延迟。T3】
最佳的 API 风格是由 API 的目的决定的
有许多类型的 API 风格可供选择，但是“正确的”风格可以由 API 项目决定。为什么要建立一个 API 对于这个过程来说和如何一样重要。
Larry: 关于这个话题，你有没有列出一系列你会选择或强调的流行 API 风格？
Erik: 在我概述风格时，我会谈到这五种风格，其中有面向资源的风格、超媒体风格、RPC，就像传统的面向函数的函数调用，还有面向查询的风格，比如 GraphQL，甚至基于事件的 API。
最后，我认为 API 只是一个工具，这个工具允许我们从现有的连接到网络的构建模块中构建新的东西。更好地理解什么样的工具是好东西，对于哪种设计，对于哪种目的，我认为这是一件好事。围绕 rest 的这整个原教旨主义总是正确的，或者 GraphQL 总是正确的，或者基于事件总是正确的。我认为我们正在慢慢地远离这一点，这很好。
我最想告诉人们的是，不要那么原教旨主义，更好地理解有不同的风格。他们没有天生的好坏，只是周围有不同的约束。更好地理解它们是如何工作的，也许也更好地理解，在什么情况下，哪种风格，也许是更好的选择。我认为这会让你成为一个更好的设计师，因为最终，设计师不应该总是说“我总是这样做”。作为一名设计师，你应该明白你必须为一个问题设计，为面临这个问题的人设计。你必须给他们一个适合这种环境的解决方案。
通过 Moesif 的定制仪表板，与队友协作监控 KPI。T3】
为什么安全性对 API 健康很重要
良好的 API 安全性始于理解您的 API 环境。全面了解当前正在使用的 API 对于构建安全框架至关重要。
拉里:非常有趣，是的。作为我们必须支持的 API *台提供商，有多种风格和实现过程似乎越来越困难，但我认为这是野兽的本性。
谈到 API *台和第三方解决方案的重大变化，人们必须意识到这一点。请告诉我们您对 API 安全性的看法，为什么它很重要，我们如何促进安全性的黄金标准，以及您对最*标准化的最新版本 fhir for APIs 的看法。
Erik: 好了，让我们从安全性开始吧。
安全当然是非常重要的。API 总是提供一些与你的系统环境交互的方法，它可能是只读的，但是即使这样，你也可能暴露出某种风险。这种能力总有可能以某种形式被滥用。
对于一个好的 API 安全性来说，最开始的地方就是了解你拥有哪些 API，这让我感到很惊奇，就像我与许多非常大的组织一起工作一样。每当我们与那些组织中的人交谈时，他们都不知道他们有哪些 API。组织中有人构建 API 并发布 API，因为他们只需要完成一些工作。他们可能没有意识到有一个*台可以保护它，或者他们只是说“它足够好了，它只是与我的应用程序对话，所以它能有多坏”。有时，在理解每个 API 都是潜在的安全风险方面，存在所有这些缺失的实践。
你必须考虑可能发生的最糟糕的事情是什么，而最糟糕的事情通常是可以准备好的。安全性并不是一件超级复杂的事情，它只是人们需要了解的一系列实践，他们必须应用这些实践。您可以为他们提供非常好的工具，确保他们自己不必做那么多。
但这仍然是一个组织内部的事情，我认为我们仍然经常看到它没有以足够严格的方式完成。有时候，我看到一些组织在某个时候关闭了防火墙中的某些端口，这真是令人惊讶。基本上说了一小会儿让我们不要通过通过某些端口的流量，然后他们基本上只是等待报告进来，关于“嘿，这个应用程序停止工作”。然后人们就理解成“哦，那里好像有个 API”。没有人告诉任何人，人们只是创造了它，它运行在那里。它可能一点也不安全，甚至没有人知道它在那里。
在黑客之前找到这个应用程序是非常重要的。这就像我们现在看到的正在爆炸的整个可观察空间。我认为这是非常重要的，有时你必须观察事情，只是为了清楚地了解我的网络中正在发生的事情。
有时候，组织越大，越少组织真正知道发生了什么。我认为这是安全性的一个基本方面，在技术层面上，它几乎比“你是如何做到的”更重要。我认为，一旦你知道你有一个 API，如何保护它，如何为它提供工具，我们已经做得很好了。只要知道你有 API，它们是什么，谁应该访问它，以及所有这些事情。我认为有时这几乎是棘手的部分，因为你的网络上有太多未知的东西。
拉里:对，非常正确，非常正确。Alissa Knight 最*参加了我们的播客，她谈到了中间人拦截以及如何使用 API 避免这种情况。她的大外卖，这真的强调了你的问题，只是知道你有哪些 API。她的主要观点是，你可以解决 90%的问题，方法是确保当你对用户进行身份验证时，并不一定意味着他们可以访问所有内容。当她入侵人们的 API 时，她发现我可以被认证，但是然后，通过改变我的一些令牌，仅仅一两个字符，我现在可以获得对一整套其他用户 API 有效载荷材料的访问。她说这太棒了，我是说，她出版了这个。她为医疗应用和银行应用做了这个。她说，令人惊讶的是，很多人认为“哦，这个人已经通过认证，现在他们可以访问任何东西了。”。
是的，我认为这是 owasp 安全列表中的第一项。这是对象级访问，就像人们只是假设你可以访问某些东西，所以这里是一切。浏览一下 owasp 十大应用，你会发现，“是的，你知道，我们实际上并不是所有的应用都做得这么好。”。
借助 Moesif 的 SOC2 兼容客户端加密技术，自信地获得深入的 API 分析。T3】
API 可观察性与 API 监控
可观察性和监控似乎是同义词，但它们是同一枚硬币的两面。可观察性是关于将机制放在适当的位置以支持主动迭代。监控可以被看作是一个技术层面的观察。
拉里:对，非常正确，非常正确。回到你提到的一些事情，那就是现在有一个关于 API 可观察性的大运动。
你为什么不告诉我你对 API 可观察性和 API 监控的区别的定义。为什么可观测性，更重要的是停留和仅仅是纯粹的监测。
Erik: 我不会给你下定义，因为我需要再考虑一下。但我认为，至少在我使用它的方式上，我认为大多数人都会使用它，就是说如果你有一个 API，监控通常是你应该做的事情。这是一个相当技术性和具体的组成部分，你把它放在那里，说“让我们数一下访问次数”或其他什么。这是一种非常具体的观察层次，是这样的，但我想，它更具体，我们需要看一些我们知道的东西。
我认为可观察性更加根深蒂固，随着我们看到的工具的出现，它更加根深蒂固于我们知道有事情在发生。但我们并不确切知道它是什么，它的行为如何，甚至可能不知道我们有什么。所以我们观察环境，观察正在发生的事情，并从中学习。与其说只是通过数东西来学习，不如说是监控。我们了解到我们有一些我们并不真正了解的 API，我们了解到这些 API 有一些我们认为不会被使用的使用方式。
我要说的是，它的内部要深得多，其中还涉及到许多更先进的技术，这些技术不仅试图计算字节数，还试图真正了解正在发生的事情。为了帮助你更好地了解发生了什么，然后你可以做所有这些事情，你也可以像 Phil Sturgeon 一样进行逆向工程，他最*发表了一篇文章，内容是关于从监控流量基础或观察流量来推断开放 API 信息。我要说的是，这类事情比我们现有的相当简单的监控更能洞察流量。
拉里:对，非常正确。我的意思是有点自私，但我为一家 API observability 公司工作。我们总是强调这样一个事实:是的，您可以计算服务器正常运行时间、延迟和地理位置问题。但实际上，通过深入研究有效负载中的细微差别，以及客户实际上是如何使用它的，您会获得更多的商业价值。这似乎有更大的价值。
通过 Moesif 获得关于您的 API 和用户的深入、细致的分析和指标。T3】
通过指标和结论衡量 API 的成功
评估原料药的功效并不总是像选择一个指标来衡量那样简单。因为 API 只是一个工具，衡量成功应该从 API 的业务目标以及在 API 使用过程中发现的任何见解开始。
非常有趣的 segway 来衡量 API 的价值。你如何衡量你的 API 是否成功，如果不成功又如何，你认为哪些指标是重要的，或者你可以从你所监控的事物中得出什么结论，然后观察并把它变成一个性能 API。
Erik: 让我大胆地说，API 不可能成功。能够成功的是一种能力，一种产品，或者你通过 API 实际交付的东西。我有这个视频，我必须指出来，因为这是我最喜欢的视频之一，我在这里谈论啤酒。我给出的类比是，API，传递机制，所以它就像一个瓶子或一个罐子，它是你获得啤酒的方式。最终真正重要的是啤酒，但啤酒不是交付机制，这是有区别的，我认为真正理解 API 仍然很重要…不要太关注 API，API 只是让事情运转的机制。
最后，你必须考虑我想用这个做什么生意。我正在工作的实际能力是什么，这更像是做好产品管理的人？谁真正负责设计该产品，交付该产品，确保它被使用，监控它如何被使用，计算出它产生的收入多于我们运行它的成本。
在这种程度上，我认为纯 API 指标只是其中相对较小的一部分。您可以看到这是没问题的，这可能是我们提供访问此功能的另一种方式。最终，真正重要的是“我们推动业务了吗？”所以我认为 API 有价值的整个想法可能很有趣，但主要是关于我是否在正确的方向上推动了正确的事情。
拉里:非常有趣，是的。是的，重要的是再次回到 SaS 的 Jeannie Hawrysz，她对在现有企业软件公司中创建 API 的观点，你的 API 必须是一个中心收入意识，不能只是一个好东西，或者因为产品经理想把它放在那里。业务案例和业务指标是你必须做好的最重要的事情。
Erik: 很抱歉，因为它对我来说非常重要，我的意思是我见过一些公司，他们做的事情之一基本上就是统计 API 访问次数，这不是很有趣，而且几乎产生了不好的激励，因为不是创建更好的 API，而是更细粒度的 API，这样你就可以用一个 API 做更多的事情。他们受到激励，基本上有“不，我们有这 25 个 API，如果你想做任何事情，你必须调用所有 25 个 API”。然后说，这很好，这里有 25 个 API 调用，所以这可能不好，但我知道为什么会这样，应该有人阻止这种情况发生。
将您的 API 分析与您更大的业务目标联系起来，并通过 Moesif 加速采用。T3】
整个 API 生态系统的未来
随着技术和非技术方面之间的桥梁越来越好，API 的前景将继续发展，从而实现商业成功。
拉里:对，没错。查看正确的指标，不要为了指标而统计指标，绝对要。所以我的最后一个问题，水晶球凝视，整个 APIs 生态系统的未来是什么样子的？
Erik: 所以我认为在 API 领域将会发生的是，我们将会看到在 API 的技术方面和非技术方面之间将会有更好的桥梁。我认为，现在，我们仍然没有足够的重叠和更具商业头脑的事物之间的*稳过渡，真正理解什么是我们应该拥有的能力，什么是我们应该提供的能力。
现在想想，我们是否有这样的 API，比如我们是否应该投资建造这些东西，然后说好吧，应该有人来设计这些东西，但我们也需要有人来思考应该设计哪些东西。回到建造正确的东西和建造正确的东西。我认为，几乎在某个时候，我们对开发人员、开发人员、开发人员有点过头了，因为开发人员当然非常重要。但他们也必须开发正确的东西，我认为建立更好的桥梁，以确保每个人都理解正在建立的东西。我认为这很重要，而且在某种程度上，我本周发现这非常有趣，当你与湾区的公司交谈时，他们当然非常注重技术，在那里你不必解释太多 API 是什么等等。但另一方面，如果我回到瑞士的家，与德国和瑞士的组织交谈，他们并不是天生数字化的。对于 IT 部门来说，业务部门和数字部门之间的差距仍然很大。
我认为跨越这一鸿沟，确保每个人都明白正在发生什么，每个人都明白需要发生什么，我认为这是我们仍然需要开发更好的工具，做更多的教育。这样到最后，每个人都真正明白，我们都应该做什么，我能做些什么。不仅仅是开发者在做贡献，所有人都在做贡献，我认为这是我们有望看到巨大变化的地方。
拉里:太好了，太好了。是的，我完全同意需要团队合作。让你的产品上市并在市场上取得成功，不仅仅是关注优秀的开发者体验。
因此，我们的听众在哪里可以听到更多你的声音，显然，请给我们一个你最新的优秀出版物的纯正插头。
当然可以。遗憾的是，我不能拿起我们的书，因为我没有带在身边，但是当然每个人都应该看看我们最新的书“连续 API 管理”第二版，这是一个月前出版的，现在是两个月前了。我希望每个人都觉得这很有趣，特别是关于 API 和一个会议案例，因为我们认为当我们围绕它开始整个计划时，这确实是世界的发展方向，我认为继续这样下去对我们有好处。
至于你能在哪里找到我，当然，你总能在谷歌上找到我。但是这些天我的主要渠道是我的 YouTube 频道，所以只要把我的名字输入 YouTube，你就会找到我的频道。这叫做“让 API 工作”。
我在那里有很多有趣的客人，他们谈论他们的 API 实践，他们在 API 领域的经验，所以去看看，除此之外，你会在我经常去的地方找到，比如 Twitter 和 LinkedIn。
拉里:太好了。埃里克，今天很高兴和你谈话。非常感谢你的真知灼见，我相信我们的听众会发现它们很有教育意义，非常有用。
拉里，非常感谢你邀请我，我希望这不是我们最后一次这么做。我总是喜欢谈论 API 的事情和空间的走向。
拉里:当然可以。下次再见，非常感谢 Eric。
开发商营销要点
原文：https://www.moesif.com/blog/podcasts/developer-marketing/Podcast-Developer-Marketing-Essentials/
Ep。10:亚当·迪万德，EveryDeveloper 的负责人
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是亚当·迪万德，他是 T2 EveryDeveloper 的负责人，也是一名开发者营销专家。在我们的播客中，他探讨了如何让开发者使用并喜爱你的 API 产品。
莫西夫的首席执行官德里克·吉林是今天的主持人。
Moesif · 10. Developer Marketing Essentials
在 SoundCloud 上听这一集，在 YouTube 上看，或者在苹果或谷歌上下载。
目录
- 0:41 讲故事搞事
- 3:38 帮助开发人员更好地完成工作
- 5:33 让你明白开发者的问题
- 7:18 使用非开发消息
- 13:23 超越 Hello World
- 16:41 衡量成功
- 18:19 找出你的解决方案
- 20:20 与你的用户交谈
- 22:16 允许开发者在你的文档中提供反馈
- 25:05 单据只有一张 DevEx
- 28:48 进行大开发重点入门项目
- 32:00 通过所有渠道沟通
- 35:14 在提出异议之前确定用法
- 38:33 精简你的指南
- 41:15 通过用例激发开发创造力
德里奇·吉林(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络第 10 集。我是德里克·吉林，今天的主持人，API 分析*台 Moesif 的首席执行官。
和我一起的是亚当·迪万德。在成为《连线》的技术记者和可编程网站的编辑后，他给提供商带来了一个非常有趣的视角。他在 Sendgrid 和 Zapier 负责开发人员沟通和营销。有趣的是，Moesif 本身就是 Zapier 的客户，所以喜欢使用该产品。他还帮助许多不同的公司和创业公司从事开发者营销和所有开发者*台的工作。很高兴你今天能来，亚当。
亚当·迪万德:是的。谢谢你邀请我。
讲故事来吸引人
作为一名偶然的营销人员，我发现在你的 API 中吸引技术受众的最佳方式是讲述一个故事，说明你所拥有的为什么重要
德里奇:好吧，那么就开始吧，我想听听你的故事，从为可编程网络写作开始，到你如何进入开发者优先的行业。
亚当:首先，我是一名开发人员。我有一个计算机科学学位，并且是一名专业的开发人员，所以我有这样的背景。但实际上，我一直对教学感兴趣，对当某人真的有所收获时的那种“啊哈”时刻感兴趣。我一直都是这么做的。《连线》的写作始于 Webmonkey 的技术教程。我是一名开发人员，心想“嘿，应该有更多的开发人员知道我正在使用的这项很酷的新技术或工具”。然后在某个时候，我意识到这是我想做的一点。
我又为 Wired 和 Webmonkey 写了一些，实际上我的最后一篇文章是“混搭已死，网络活着”。这应该是在 2000 年代末，所有的东西都是混合在一起的，我说，未来所有这些 API 都是网络的未来。当然，移动电话还处于萌芽状态。我很确定可编程网络从那篇文章中找到了我，这是一个完美的时机。我正在埋头写我的第一本关于映射 API 的书，所以这就是我开始为可编程 Web 写作的方式，然后最终作为第一个编辑全职加入。
我建立了一个团队，发现新的 API 并报告 API。我们追随了所有这些趋势。事实上，对我来说，开发者营销的一部分故事是，我会收到所有这些公司的公关宣传，他们对他们的 API 非常兴奋，但并没有真正讲述他们为什么重要。所以当我离开可编程网络的时候，我意识到这是一个帮助讲述这些故事的机会。所以我称自己是一个偶然的营销人员，因为我真的回到了我以前作为开发者为了好玩而做的那种教学和讲故事的部分，因为我意识到这实际上是公司吸引技术观众的最好方式。这就是我如何完成从开发人员到记者再到技术营销人员的转变。
帮助开发人员更好地完成工作
Dev 对传统营销持怀疑态度——这将他们引向另一个方向，浪费了他们的时间。相反，给他们一些能帮助他们更好地工作和像开发人员一样交流的东西。
德里奇:哦肯定。我喜欢听这个故事，尤其是因为与技术型观众交流非常困难。是什么让它如此艰难？为什么比传统营销难那么多？
亚当:你知道，你可以说开发者以前被狡猾的销售策略弄得焦头烂额。我想那可能是真的。他们浪费了时间。但最重要的是，这是开发人员在做他们的工作，他们工作的一部分是持怀疑态度，思考你可能遇到的所有边缘情况。因此，许多传统营销被他们视为阻碍他们实现目标的陷阱，他们的目标是构建一些伟大的软件，而不是浪费他们的时间，将他们拉向其他方向。
所以我认为，很多时候，不面向开发者的营销可能会让人产生怀疑，感觉就像“哦，这是以前浪费我时间的东西，它把我带到了其他方向”。所以他们不会被它吸引。
相比之下，有些东西会帮助他们更好地完成工作，而且确实来自这样一个地方，在那里他们可以看出发送信息的人要么有相似的背景，要么知道他们在哪里。这对于建立信任至关重要。
表明你理解开发者的问题
通过展示你熟悉开发人员的问题，与他们建立信任:“我们了解自己的情况，这是我们看到的成功案例”
德里奇:这是一个很好的观点，关于信任，把开发者，怀疑论者变成更像福音传播者的东西。一家公司可以做些什么来建立这种信任，不管是围绕产品、营销还是信息传递。
Adam: 所以我认为为开发人员开发工具的公司通常是由开发人员创办的，他们当然了解那些问题，那些他们正在解决的真正的开发人员问题。所以我认为你越能分享你对这一点的理解，就越能建立信任，因为你能说“看，我们在那里。我们明白了。这就是它存在的原因。”我的意思是，公司开始于那些观点，那些信念，认为事情比应该的要难，或者其他公司做这件事的方式不是他们认为应该做的方式。所以你越能分享这些观点，你就能让开发者参与进来。
因此，分享你理解这些问题是一部分，但也能够表明你知道如何解决这些问题是另一个关键部分。这就是我不断回到教育的原因，因为一个开发人员不可能尽可能地了解所有事情，所以，如果你能够向他们展示“我们知道我们的东西，这就是我们所看到的成功”，你将获得很多信任和潜在的客户。
使用非开发消息传递
你的产品可能会被非开发人员使用:产品、营销、支持或客户成功，所以使用非技术营销并提供非编码人员也可以使用的工具，比如可视化构建器
德里奇:这是一个很好的教育市场的想法，而且展示比告诉更好，开发者希望看到一些东西是如何工作的，是什么让他们做得更好。也就是说，有很多公司，包括 Zapier，有两种不同的受众:开发人员受众和业务人员，他们正在试图弄清楚什么是 API，或者如何称之为 API。你能给我讲讲那里的一些挑战吗？你实际上是如何同时对两种听众说话的？
Adam: 如果你考虑到 Zapier 的用户方面，Zapier 的受众可能会比这更多。所以，那些真正为你自己的工具建立自动化的人，那些为 Zapier 付费的人，就是那些观众。这些观众肯定有开发者，我仍然有一个付费的 Zapier 帐户，我经常使用，我可以编写一些我在 Zaps 中做的东西，但大多数观众不是技术人员，不知道如何在他们的工具之间建立联系。他们甚至可能不知道是 API 让这一切发生的。
然后你有*台方面，这是我在扎皮尔做的大部分工作。因此，在*台方面，你有一个 SaaS 工具，它有一个 API，你想把它连接到 Zapier，集成到那里，使你的所有用户都能够进行这些自动化。我的标题在 Zapier 有开发者营销，但花了一点时间才意识到，即使是那些观众也没有我们想象的那么发达。肯定有开发人员在构建与 Zapier *台的一些集成，但其中许多人来自产品部门，或者在某些情况下来自营销部门、支持部门、客户成功部门，公司中任何关心能够对更多客户说“是”的人，“是的，我们就是这样做的。是的，我们整合了这一点”，我们希望 Zapier 能够提供*台方面的支持，并以这种方式支持他们的客户。因此，可以肯定的是，开发者的信息要少得多。
当然，我尝试分享了一些 API 最佳实践，这些实践更多地面向技术受众。有时他们确实在业务和开发人员之间游走，但很多信息实际上是想让更多的用户看到你的产品，并扩展你的产品的能力，以做用户希望它做的事情。所以，我实际上做了一个关于这个的演讲，我有一个关于它的帖子，那就是“你的门户网站的无形观众”，我真的相信比你意识到的更多的 API 拥有的观众不是你和我可能称之为开发人员的人，不是整天写代码的人。我想通过各种方式让他们举手，让他们发现他们就在那里。
在那篇文章中，我举了一个例子，说明我们如何在 Zapier 为*台推出 CLI，这是基于一些顶级集成商的研究，他们希望获得更像开发者的体验。但是，经过几个月的时间和对开发者*台的改变，我们意识到他们在那些刚起步的人中是少数。人们真的想要一个视觉建筑者。所以我们能够根据观察他们关心的事物来确定。并慢慢做出改变，以便能够证明“哦，我们已经投资了这个真正以开发人员为主的*台，这不会消失，但我们需要另一个界面来与这里的更大群体交流”。
尽管我很喜欢开发者观众，但我认为在任何 API 中都有这样的空间，特别是在开发者优先的基础设施类型的 API 中，这种 API 可能不支持 SaaS 工具。我在这里提出的区别是，开发人员支持通常是 SaaS，在那里你需要一个开发人员来帮助你使用 API，而不是像 Twilio 或 Stripe 这样的东西，它需要你的堆栈的一部分，这成为一个更加以开发人员为先，以开发人员为中心的公司。但我认为，对于所有这些人来说，如果你能够找到那些不太懂技术的观众，他们肯定会有一席之地。但是在某种程度上，你也需要拥有开发者所寻求的所有东西。所以这确实让你走上了寻找两个地方的道路，所以如果你足够早，你可能会寻找那些准备更充分地融入的人。
超越 Hello World
通过监控您的 API 是否正被用于进行调用来确定您的 API 是否成功
derrick:听起来你做了很多测量来弄清楚他们在多大程度上被 Zapier 激活，他们在这个*台上做了什么。他们得到的入职或其他类型的沟通有任何类型的反馈吗？根据他们是开发人员还是非开发人员受众，反馈有何不同？
Adam: 大部分工作都是*台产品团队完成的，我和他们合作得非常紧密，但这部分是他们推动的。这绝对是在看“他们是否创建了一个应用程序”(一个集成到 Zapier *台的应用程序)，然后他们在这方面做了多少？在这种情况下，有触发器和动作，所以您可以查看他们是否创建了一些触发器和动作来启用他们自己的用户。然后，那些用过吗？有真正的呼声反对吗？这些都可以在日志数据中找到，至少在这一点上，我敢肯定他们仍然收集了相当多的数据，但这都是在一个系统中，我们作为员工，可以真正挖掘并整理出我们或多或少成功的原因。同样，这很大程度上取决于产品团队。
然后，当然，你可能会想象在用户端也有很多关于激活的东西。我认为，尽管这是用户方面，但肯定有一个 API 的教训，因为 Zapier，当它工作时，你不必回来。API 也是类似的东西，对吗？如果有人每天都回到你的开发者门户，那可能真的有问题，他们还没有达到完全集成。对 Zapier 的用户来说也是如此。因此，它在日志中寻找证据，扎皮尔甚至以这种方式收费。那么，有人成功运行过他们建立的这种集成和自动化吗？他们已经成功运行了多少次？随着时间的推移，他们还会继续运行吗？这也是你可以做的事情，就像你看到的“有人在使用我的 API 吗？”再次寻找那些已经超越“Hello World”的迹象，他们已经取得了初步的成功，他们已经将代码转移到他们的机器或服务器上，并且有足够频繁的呼叫，至少你知道他们仍在测试。
衡量成功
德里奇:这是一个非常好的观点，尤其是因为你不是每天都登录门户网站。如果您正在集成 Stripe，我为什么要集成呢？但是，这也带来了一个不同的挑战，即当您不希望人们登录您的门户时，您如何实际衡量和创建 KPI？这是否意味着 KPI 不同？你如何利用你之前在 Zapier 提到的 API 数据？"
亚当:我认为能够识别出成功人士的标志，然后确保你能够衡量这些标志。我的意思是这对于 Moesif 来说很棒，API 日志中有很多内容可以肯定地讲述这个故事。所以我认为寻找最*的调用，然后调用某个阈值，调用特定的端点，有希望成功。因此，如果您看到许多 401/403，那么有人仍然停留在身份认证上，当然从我作为一个内容丰富的人的角度来看，我会立即想到“入门指南中有什么”，我们是否充分讨论了获得身份认证需要什么，或者我们只是简单地浏览一下。因此，如果您看到这种类型的错误，这将是我需要查看的标志。
精确定位您的解决方案
你的*台用例越具体，你就越能成功地集成合适的开发人员
我认为你可以看到类似的事情，将是特定于你的 API，你知道它看起来像有人成功连接。即使你是全新的，你至少可以弄清楚那会是什么样子——让 API 调用通过，然后确保你看到它，并在每个用户的基础上查看它。不同的 API 会有所不同。我是一个数据库 API 的开发者关系，很多人进来踢了一次轮胎，然后继续前进，因为在一个数据库中，你不会拆掉你的整个数据库并替换它，你必须在正确的地方，在正确的时刻。我们是一个早期的创业公司，所以我们撒的网可能比他们走得更远时撒的网要宽一点，因为他们知道一些人会使用他们的 API 的用例。但是，我认为任何数据库类型的 API 成功的人都比更精确的解决方案要少。我真的认为 Twilio 和 Stripe 的一些优势在于它们有非常具体的使用案例。
与您的用户交流
要真正了解你的*台，用户可以打个电话或发个邮件，以获得关于某人可能在哪里挣扎的定性数据
Derric: 当然，业务线基本上，你提供的是非常明确的交易或业务功能。当您发现可能存在一些问题时，您谈到了围绕身份认证的工作原理创建更多内容。有没有其他方法可以让你改变你的营销策略，不仅仅是看激活情况，或者看人们是如何采用你的*台的？
亚当:有一件事我没提到，其实就是和人说话。我知道我们已经进入了分析领域，但另一个问题是人们何时会注册，这是在 Zapier，也是在 Orchestrate，这是一种数据库即服务。那就是:如果某人刚刚开始，我们如何才能通过一个电话或一封电子邮件来获得更多关于某人可能正在努力的定性数据。当然，这在很大程度上与数据库即服务有关，我们如何让他们进入“Hello World”，但在 Zapier，更多的是了解受众是什么。很多都是内部交流。这里的许多听众可能使用公司内部存在的 API，因此必须进行大量的内部对话，并帮助其他人了解您所学到的东西。这也是这个项目的一个重要部分，了解 Zapier *台的用户，将他们与愿意写代码的开发人员联系起来，并能够证明有更多的人没有这样的背景，也没有准备好在他们的终端上运行 CLI。
允许文档中的反馈
用户在你的文档中建议编辑的能力提供了另一种与你的开发者交流的重要方式。当他们提出建议时，一定要回复并解决问题。
德里奇:关于定性和定量反馈的思考，这无疑是一个很好的观点。我知道，不与开发人员交流，很容易陷入分析中，毕竟他们也是人。但有时他们不回邮件，或者他们想一个人呆着。你有没有发现一些最佳实践，可以分享给开发者，让对话进行下去？
亚当:是的，我认为接受多种沟通方式很重要。所以我们在这里已经提到了两个例子，这是对电子邮件的回复:在开发者持怀疑态度的事情列表中有一个是“我只是想占用你几分钟的时间进行视频通话”。有些人已经准备好了，但不是所有人，所以愿意把电子邮件作为另一个选择。然后，我认为每个人都可以做的事情是在文档中放置反馈的机会。我知道的 Algolia 在每个页面的几个地方都有一个感叹号，当你点击它时，你至少有机会填写“这不起作用”之类的东西。在 Zapier，我们在每一页的底部都有一个盒子。现在很多都有“编辑这个”的功能，你可以去 GitHub 里把它叉出来，然后把你认为应该放在这里的编辑内容放进去。所有这些不同的级别都是获得某种反馈的一种方式。我认为最重要的一点是，你必须真正看到它，然后采取行动。在 Zapier，我们不会感到惊讶，我们已经有了一个 Zap，它将管道到所有*台团队都在的特定松弛通道中。如果这个问题与某个特定的用户有关，有某种方法能够回复，但至少能够采取行动，特别是当有人注意到一个问题时，因为这是“我们都在文档中出现了错误的地方”,这只是一个又一个开发人员让你心烦。我的意思是，这是远离那些开发人员的捷径，就是在你的文档中继续有不准确之处。
文件只是发展的一部分
DevEx 包括某人与你的公司和产品(包括文档)的所有互动，所以要想方设法积极地展现出来，给开发者体验带来好处
我笑得很厉害，因为我知道让这些文档保持最新总是一个挑战。事实上，在 Moesif，我们利用了 GutHub 按钮上的编辑功能，我们的文档都是开源的。我们使用 Jekyll 和一个开源的静态生成器，一个很棒的产品。但是，在这种情况下，谁真正拥有文档呢？是不是说明是产品团队，是营销？有没有什么好的过程来保持这些更新，因为我们总是把这看作是对开发者*台的挑战？
Adam: 至于谁拥有它，我经常与营销团队交谈，提醒他们确实需要关心文档。许多营销团队都这样做，但我认为很少有人拥有它。我认为最常见的可能是产品本身，但我们也知道，并不是每个产品团队都将它视为产品的核心部分。较大的团队会有专门的文档团队，但是当然也不总是这样。
我认为，如果你正在听这个，那么你可能是在你自己的公司里支持它的一个很好的人，至少认识到文档在可能关心它的多个团队之间传播，并且在最起码的程度上，组成一个关心它的特设小组。我们确实这样做了，在此期间，来自支持、产品、工程和营销部门的人员多次致电 Zapier，他们有理由希望更多的人在文档方面取得成功。
文档也只是整个开发人员体验的一部分，当然入职的产品方面也是其中的一部分。我也看到了很多与开发者体验相关的开发者内容。因为即使这是他们第一次接触到某个内容，他们也能找到你，因为你写的是他们遇到的开发者问题。最初的体验是一种体验，是整个旅程的一部分，希望有人会继续使用你的 API。它肯定是从那之前开始的，从开发人员在不和谐的房间里聊天开始，关于哪个 API 更容易或者在那一刻让他们沮丧。这种口口相传的情况也在发生。如果你对开发人员体验的定义非常宽泛，我倾向于对所有人与你的公司和你的产品的交互进行相当宽泛的定义，当他们实际上开始使用你的 API 时，我正在寻找积极地展示对开发人员体验有益的方式。
关注入门项目
为了确保开发者有良好的体验，专注于提供优秀的入门类型的东西，例如流行语言的 SDK 和最新的完整参考资料
德里奇:我很高兴你刚刚定义了这一点。我正要问什么是开发者体验，你如何定义它。尽管如此，这是一个如此抽象的事情，是否有一个开发人员体验团队，或者更多的是一种思维模式？你实际上如何确保你有一个好的开发者体验，有没有一种方法来衡量它或者它是否真的不可衡量？
Adam: 所以，就团队而言，我认为这取决于 API 对公司有多重要。因此，如果 API 是一家公司的主要产品，并且我们越来越多地看到很多这样的产品，在这种情况下，开发人员的经验可能在某种程度上对整个公司很重要。在这种情况下，我不确定团队是否有意义。我绝对见过开发者体验团队。我认为大多数情况下，这些团队要么是负责 onboarding/dashboard 体验的产品团队，要么是名称不同的文档团队。我见过那两个人。我敢肯定，一些公司甚至会把这两者混为一谈，尽管我认为我更经常在单独的小组中看到这种情况。因此，我不知道是否需要有一个以这个名字命名的团队，但肯定需要有一个或多个团队想要改善开发人员的体验，不管这个名字是否在这个团队中。
因此，当然能够衡量一些东西，我们谈了一点你想要看到的一些东西，以便能够说这是开发人员的成功。从高层次来说，我有 13 个标准来判断一个人是否在一个能给开发者带来良好体验的地方。当然还有更多，不管他们是否真的成功。但要寻找的东西包括:你有流行语言的 SDK 吗，你有最新的完整参考吗，然后是我在那里寻找的许多入门类型的东西。所以我确实测量了它，但它真的意味着高水*，我认为更细粒度的测量真正涉及到我们已经谈论过的用法，因为这真的是它回答是否是一个好的开发者体验的地方——“开发者成功了吗？”。他们是否从找到你到不仅仅是“你好世界”，而是一些实际上有用的东西，推动他们解决他们的问题。
所有渠道的沟通
更改 API 时，使用所有渠道传达更改，包括:电子邮件、仪表板通知、日落标题，甚至开关灯
德里奇:然后，他们完全启动并运行后的下一步是什么？听起来他们不再踢轮胎了。在开发人员沟通方面有什么好的做法吗？
Adam: 当然，如果事情在变化，你所有的文档都应该是最新的，对开发人员的成功来说是极好的。但是如果你的 API 改变了很多东西，破坏了开发者的东西，即使你每次都在更新你的文档，每次你做了改变，它总是最新的，但是他们以前建立的东西，如果那被破坏了，那肯定会创造一个更差的开发者体验。因此，这种产品变化是必须不断发生的事情，但这意味着你需要有那些开放的沟通渠道。当一个持怀疑态度的开发人员可能用一个他们不经常查看的不同的电子邮件地址注册时，这是很困难的，诸如此类的事情。但是电子邮件可能只是获得这些信息的众多方式之一。当然，如果有人登录仪表板，你可以通过这种方式找到他们。我们，甚至在 Zapier，作为 API 大师的 Ben Peter，总是负责计算出现在 3000 个 API 中何时出现了弃用或问题。我真的希望本现在能得到一些帮助，而不仅仅是本在努力。但是他写了一些关于弃用的最佳实践，甚至在标题中加入了一些东西。
我知道埃里克·王尔德有一个日落头球。经历尝试沟通的步骤，然后将东西放入标题，甚至做一种开关灯的测试，让他们有机会捕捉到它实际上正在下降，可能会打破一些东西，但然后将它放回原处，这样他们就不会完全交火。本写了几篇关于这些最佳实践的帖子。但是当然，如果你可以开始与开发者交流，并设定期望，你将通过电子邮件和在你的博客上发布有用的东西，那么他们将更有可能希望有一个持续的交流渠道。这意味着当你不得不做出那样的改变时，你更有可能接触到他们。
在贬低之前识别用法
如果您不得不弃用，那么使用 Moesif 分析使用情况和成功情况，以了解什么会受到影响，甚至到每个呼叫的基础上
德里奇:是的，有趣的是，我们只是偶然看到了一些博客帖子。我们实际上在 Moesif 本身实现了很多功能，开关灯或一个弃用标题。你实际上如何确定什么是不赞成的，这是你写的东西吗，或者你实际上是如何决定的？
所以从完全理想的开发者的角度来看，你永远不会反对任何东西。我认为，如果你看看那里，Twilio 可能从来没有反对任何东西。我想他们是根据日期来进行版本控制的，至少我上次是这么看的。因此，如果您在某个特定时间进行集成，您就有了这个端点，您可以随时升级到最新版本，但他们会让它继续运行。这无疑对开发者非常友好，但你我都知道这并不总是可能的。可能有一个系统，你想采取了昂贵的，在某种程度上，在维护或实际服务器成本，所以有很多原因，你可能会想作出这样的选择。但是绝对不更新是好的。我认为这是典型的产品决策，比如“这个用了多少？”。如果您真的可以访问您的日志，了解谁会受到影响，甚至了解每个呼叫谁会受到影响实际上是可能的。你知道人们在呼叫什么端点。你知道他们在接收什么数据。因此，如果你要改变数据的形状，如果你已经设置好可以访问的东西，你确实有办法可以做到。
德里奇:你只需要确保提前安排好就行了。
我认为 OpenAPIs 作为 API 的一种数据格式是一种方式，我们现在必须至少对 API 中的内容有一些期望，以某种方式谈论它，甚至以编程方式测试它。有一家名为 Optic 的公司，它实际上会查看您的实时调用，并做一些我提到的事情，类似于“嘿，这个 API 调用的形式发生了变化，或者在您的下一个版本中会发生变化，这是受影响的用户”。当然，能够有一个像 Moesif 这样的*台，能够查看人们呼叫的端点，能够获得这种关于使用和成功的分析，将是另一件有帮助的事情。
简化您的指南
只有一份入门指南，并使之简化，以便清楚地显示如何打电话
德里奇:肯定。我的最后一个话题是关于那些刚刚开始考虑开发者*台的创业公司。你能为刚刚进入开发者营销领域的人分享一些最佳实践吗？
亚当:如果你刚刚开始，一定要进行我们之前谈过的那些对话。我们可以假设有人正在做这些事情:和开发人员谈论他们真正想要的东西。然后，我想去寻找一些基本的东西，让人们进入“你好世界”，因为尽管之后发生的事情很重要，但如果他们没有进入“你好世界”，他们永远也不会到达那里。那么，有没有一本入门指南，可以确保你真正专注于这一点。我在入门指南中看到的一些问题是，经常有人想要分享所有你需要知道的关于使用你的产品的背景知识，而这是错误的地方。如果你必须在开始之前研究概念，这对大多数开发人员来说是不可能的。大多数开发人员会跳过这一部分，直接进入我实际打电话的部分。因此，帮助人们能够到达他们想去的地方，所以在入门指南中简化这个过程。你总是可以在需要的时候加入一点点概念，然后你总是可以链接到其他更深入的地方。因此，这绝对是我看到的一个问题，更大的问题是根本没有那种内容可以开始。
有时会有多个入门指南，所以这也是令人困惑的。能够在一个地方发送它们。当然，还要想办法确保你的文档是最新的。我提到了 OpenAPI。你能从你的 OpenAPI 中至少生成你的 API 引用吗，这样你就知道它是最新的了。它还要求您保持 OpenAPI 文档最新，但是必须有某种方法能够做到这一点。这样，你就至少具备了某人所期望的文档基础知识。
通过用例激发创造力
通过用例向开发人员展示你能做什么通常会激发他们的创造力
然后从创业的角度来看，你会想尽可能快地了解别人想如何使用你的产品。希望你已经有了一些想法，并以用例及示例应用的形式展示出来。确认那些是某人想要解决的问题。我看到这种情况越来越少，但在上周，我就此进行了一次谈话，内容是“我们是这个*台，可以做任何事情，我们不想通过告诉他们我们做什么来抑制开发人员的创造力”，我认为告诉他们你可以做什么是启动创造力的火花。因此，能够给出一些用例会让一些人意识到“哦，这有点像他们没有想到的另一件事”，然后他们就会有创造力。但是仅仅提供一些东西并说“用这个做点什么”，并不能像人们认为的那样激发创造力。
derrick:这真是一个很好的教训，展示比讲述更好——展示不同的使用案例，并提供非常简洁和具体的入门或入门指南。但是不要有 10 个，只要一个。很好，非常感谢你邀请我们来，亚当。很高兴谈论开发营销和开发者体验。
亚当:谢谢你邀请我。
在非 API 优先公司中启动 API 程序
Ep。11: Jeannie Hawrysz，SAS API 项目负责人
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是拥有 22，000 名员工的商业分析公司 SAS 的首席 API 架构师 Jeannie Hawrysz。在此之前，她在 IBM 工作了 18 年，是 IBM 的 API Connect 微网关的技术开发经理。在我们的播客中，她分享了如何在非 API 优先的公司中成功启动 API 项目。
莫里斯国际基金会的 CMO 拉里·埃布林格是今天的主持人。
Moesif · 11. Launching API Programs in Non API-First Companies
在 SoundCloud 上听上面的剧集，或者在苹果或谷歌上下载。
目录
- 1:14 从事 API 管理工作
- 4:45 形成卓越中心
- 8:58 搭建跨越生命周期的桥梁
- 10:30 汗发人物
- 12:25 工作流程指南开发者
- 15:50 外部 API 的商业原因
- 18:29 外化的最低标准
- 22:43 产品管理负责
- 24:28 原料药赚钱
- 27:34 4 技术注意事项
- 30:15 与业务需求保持一致
- 31:37 有耐心，有眼光，有同理心
拉里·埃布林格(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络第 11 集。我是劳伦斯·埃布林格，今天的主持人，也是 Moesif 的首席营销官，API 可观测性*台。和我一起的是珍妮·霍利斯，首席 API 架构师和 SAS 经理，SAS 是一家拥有 22，000 名员工的商业分析公司。在此之前，她在 IBM 工作了 18 年，是 IBM 的 API Connect 微网关的技术开发经理。
珍妮，欢迎来到我们简陋的播客网络。我们在哪里能找到你？"
珍妮·霍利斯(SAS): 谢谢。所以我住在北卡罗来纳州的卡里。我在特种空勤团工作。事实上，我现在在家和家人一起工作。
拉里:和我们一样。
珍妮:我住在北卡罗来纳州，我喜欢这里。山和海滩，你不会错的。
从事 API 管理工作
“我的项目被取消了……我应该做些什么……你应该试试这个 API 管理的东西”,他递给我一本奥莱利的书，名为《API:战略指南》。我看了一夜。我爱不释手。我就是这样进入 API 和 API 管理的。
拉里:太棒了。好了，开始吧，你为什么不和我们分享一下你过去 18 年在 IBM 使用 API gateway 产品的经历，然后让我们了解你在 SaaS 运行所有 API 的情况。
Jeannie: 所以我会试着很快地讲述 18 年。我真的非常非常幸运，在我的职业生涯中有很多不同的机会，无论是在 IBM 还是在 SAS。我最初是一名从事大型机 TCP/IP 协议栈的工程师，后来我从事支持、性能和开发方面的工作。我第一次有机会成为跨部门的技术领导，去开发一个 SDK，人们可以用它来开发软件和虚拟硬件设备。不幸的是，这个项目实际上在 2012 年夏天因为商业优先的原因而终止了。这是一个相当大的败笔，因为这是我第一次领导的大好机会。但是所有从事这项工作的人都被邀请来从事数据电源设备的工作，这些设备做得非常好。有许多不同的技术领域需要工程帮助。当时 data power 的 CTO 实际上是我实习时的导师，这是一种偶然。所以我马上去找他说，“我的项目被取消了，我要去你的地区，我应该做些什么呢？”
他说“你知道，我认为你应该在 API 管理方面下功夫。”我不知道那是什么，我不知道。但他递给我一本名为 APIs: A Strategy Guide 的书，那是一本奥莱利的书，我一夜之间就看完了。我爱不释手。我就是这样进入 API 和 API 管理的。
在接下来的几年里，我作为一名工程师为 IBM 开发 API 管理解决方案的监控组件。后来，我成为了一个软件开发经理，负责开发 data power RestAPIs 的团队、几个云集成团队，以及最终的 IBM API Connect Microgateway。
奇怪的是，我离开 IBM 并开始寻找 IBM 之外的工作的原因之一是我真的厌倦了 API。我“精疲力尽”了，准备开始看别的东西。我有宏伟的计划。我要成为一名安全专家，彻底重塑自己。但不知何故，我最终又回到了 SAS，从事 API 方面的工作。但是，这是不同的。这与我在 IBM 的经历非常非常不同。我不得不学习、成长和拥抱更多的 API 生命周期，而不仅仅是技术方面。学到了很多我职业生涯早期没有学到的东西。所以这很有趣。
我的职业生涯实际上是围绕着网络的，但是所有的一切似乎总是被 API 所吸引。这真的很令人兴奋，就像我在 SAS 的经历一样，能够在一个项目的底层工作。
形成一个卓越的中心
API 工程卓越中心管理标准、指南和通用模式，提供目录，采用最新版本的 OpenAPI，拥有模式验证和样式规则，并审查每个版本
Larry: 嗯，这是 API 领域的丰富经验。我知道奥赖利那本书，它开启了你的旅程。这非常令人兴奋。无论是在 IBM 还是在 SAS，你已经构建了听起来相当多的 API 程序。据你估计，在一个现有的企业软件公司中，建立一个 API 程序的关键步骤是什么，根据定义，显然不是 API 优先的。
Jeannie: 所以，我要说清楚的是，在 IBM，我并不是真正的木偶师、幕后操纵者，我更像是一名软件开发经理。但是我利用这个机会尽可能多地了解了生命周期的剩余部分，我真的很感激这段经历。如果我只是尝试领导一个关于 API 的项目，而没有技术经验，我不认为我会成功。
当我在 2017 年以这个角色来到 SAS 时，实际上有一些 API 计划的好元素。他们确实有一个卓越中心，这是非常好的。他们有标准和指导方针，以及一些共同的模式。它们都被写了下来，并且已经被讨论过了。他们有一个内部 API 目录，这很棒。他们使用斯瓦格·V2，这是 2017 年的选择。他们有模式验证和样式规则，当时是自动化的。他们对每个版本都进行 API 审查。所有这些东西都非常非常棒。当我到达那里时，我想我不会有我的工作，因为他们已经解决了所有的问题。但是当我开始梳理事情的时候，我发现我们真的只关注了项目的技术方面。在业务方面也不是很好，有些东西不工作，或者不会扩展，或者不会与 CI/CD 一起工作。在我加入 SAS 的时候，我们真的没有大规模地进行 CI/CD，我们正在开始将公司向那个方向转变的过程。使用集中的团队来审查每个版本是行不通的，所以我们需要开始考虑如何分散。
一旦我了解到我们在开始一个程序的时候比我想象的要多，我肯定会害怕，因为我以前从来没有运行过 API 程序或任何这种规模的程序。我真的认为，作为一名架构师，这份工作更多的是在架构上工作，并为所有这些事情编写*台支持代码。结果是，那些东西可能处于最佳状态，而不是当时的优先事项。我们需要开始思考如何与业务的其他部分保持一致，并查看生命周期中的差距并填补它们。我问自己“我该怎么做？我怎么转大船。”我以前从未做过这种事，而且对公司来说还很陌生，当我担任这个角色时，我已经在公司工作了一年多一点，我需要建立一些信誉，因为我是谁来告诉人们他们认为他们都在正确的轨道上，有些事情需要改变？我不想成为那个从外面进来说“一切都很糟糕”的人，因为事情并不糟糕，但如果我们要让这个项目成功，肯定有一些事情需要关注。
所以过去三年我一直在解决这个问题。我真的相信 API，我相信 API 是一个商业基础。在 IBM 和 API 经济中拥有这样的背景真的激励我去实现它。我真的相信可以。所以我认为这里有机会，SAS 有如此丰富的分析能力，我知道我们可以用我们的 API 来区分。
搭建跨越生命周期的桥梁
找到其他部门的信徒，帮助在整个公司内搭建桥梁，不仅仅是在工程部门，还包括文档、产品管理和支持部门
一开始确实感觉很慢，因为最重要的是我需要开始了解我们在 API 作为一个程序的真正位置以及我们需要去哪里。我们需要获得领导地位，不仅是在工程部门，还包括文档、产品管理和支持等其他领域。我们需要让整个公司的人都明白商业价值和如何前进。我非常非常幸运地在其他部门有一些信徒，他们帮助我在那里建立了领导地位，并开始建立跨越生命周期的桥梁。肯定有一些人很早就从 API 程序的角度理解了我们想要做的事情。
最重要的是，我们开始安排关键角色，这样他们就可以帮我实现这个目标，因为我不可能一个人完成所有的事情。我们添加的第一件事是开发人员倡导者，因为我们需要有人能够围绕 API 在内部和外部帮助宣传。我们增加了一个项目经理，他现在实际上更像是一个程序而不是项目经理。文档负责人，我们组建了我们所谓的 API 优先核心团队，这是一个跨部门的领导团队，负责提供战略、方向和支持，这是所有 SAS 实现 API 所必需的。
汗水 Dev 人
开发者应该是你软件的一流用户，他们应该拥有出色的体验
有两件事我想提一下，这两件事给了我们最大的飞跃:首先，作为一个整体公司，我们在技术和成为真正的产品领导者方面转向了一个更加由外向内的视角，并支持这些设计优先的开发，不仅仅是 API 设计优先，而是设计优先的开发。事实上，无论如何，公司正在朝那个方向发展，这与我们需要 API 的方向非常吻合。我们的 API 优先倡议完全建立在这样一个理念上，即开发人员与 API 交互的用户体验是值得设计思考的，也是值得使用它们的角色付出汗水的。开发人员将是我们软件的一流用户，他们应该得到出色的体验。
第二个改变游戏规则的因素是我们从 SAS 设计团队获得的支持。因此，他们毫不犹豫地接受挑战，利用他们的用户体验设计知识，帮助找出我们如何与产品团队和利益相关者一起将用户体验转化为 API 设计研讨会。因此，当我们开始举办 API 设计研讨会，并开始让人们在整个生命周期中开始思考人们在 API 方面真正关心的是什么时，这是一件大事。如果没有跨所有学科的协调，我们不可能取得过去三年的进步。这也是我们领导层的支持，让我们的 CTO 在会议上谈论 API 的重要性。我们经历的这段旅程真是太神奇了。真的很棒。
工作流指南开发人员
为了满足治理预期，使用护栏来引导开发人员
Larry: 好的，感谢您讲述了现有企业软件公司必须经历的关键要素，正如您所说，慢慢地将大船转向攻击一个新兴市场。深入研究不同工程团队中设计 API 的最佳实践，您发现哪些标准是应该遵循的最佳标准？
Jeannie: 因此，我们的最终目标是，通过设计优先的方法，团队将从一开始就设计和记录他们的 API，以满足标准以及性能和安全期望。我们还没有走到那一步，但肯定会有团队在这条路上走得更远，我们非常乐观，现在觉得在影响团队遵循我们的标准作为最佳实践方面得到了支持。我们确实有一套记录在案的可搜索标准，比如:如何进行版本控制，什么样的 HTTP 状态响应代码是可接受的，以及可搜索的通用设计模式。对于如何进行不同类型的互动，有指导方针、建议和模式。我们也有一个单一的存储库，存放我们所有的 API 文档，这些文档现在仍在 V2，但我们正在向 OpenAPI 3 迁移。我们颁布了一项法令，要求人们在年底前采用 OpenAPI 3。这构成了我们的 API 目录的基础，以便于 Greg。
但是，就像我前面提到的，人们能够自己解析这些标准并解释它们可能需要很多信息。正因为如此，我们实际上想做一些更主动的工作来帮助我们的开发人员从一开始就能够遵循这些标准。因此，我们创建了一个我们称之为 API 优先的工作流，它本质上是一个 Jenkins 管道，接受我们的 OpenAPI 文档，这些文档存放在我们的开发人员的存储库中，以及他们编写的任何支持性降价，以帮助指导开发人员使用 API 文档。它为开发团队提供了护栏，以确保他们的 API 满足治理期望。像正确解析引用这样的事情，或者我们有大量的光谱规则，我们必须执行样式和写作指南。比如结尾没有句号的摘要，这有助于我们在 API 文档中更加一致。作为工作流程的一部分，我们设置了基于 OpenAPI 文档的模拟服务器。它是成功的，我们仍然处于采用的早期，我们正在将 OpenAPI 转换、OpenAPI 3 现代化与采用这种工作流相结合。但到目前为止，我们从领养者那里得到的反馈非常好。我们不断地接受反馈和学习，并试图让开发者更容易地建立他们的 API，以更快地满足期望。
外部 API 的商业原因
所有的 API 在设计时都应该考虑到有一天它们会被外部化，所以产品经理的商业理念必须回答这样一个问题:“这个 API 适合我的目标受众吗？”
拉里:太棒了。您当然已经构建了大量的支持基础设施和文档来设计您的 API 接口。你似乎篡夺了我的下一个问题，那就是你认为 OpenAPI 3.0 有多重要，但你肯定已经回答了这个问题。因此，我们为什么不继续下一节，讨论内部和外部 API。因此，我们最初没有涉及它，但是您在 SAS 的项目非常成功，您已经向开发人员社区公开了 50 多个 API 服务。所以，跟我们分享一下，一个产品经理把内部 API 作为外部产品发布的流程。
Jeannie: 所以最重要的是，如果我们有一个现有的内部 API，而产品经理确实想把它发布出去，那么他们的责任就是想出一个让它发生的商业理由。这是因为，向前发展，我们真正希望发生的是 API 从一开始就被构建，从一开始就被设计，被外部化。在过去，我们的所有服务并不总是如此，所以我们确实需要很好地关注“这个 API 是否适合他们所瞄准的受众”，或者它是否需要一个抽象层才能对他们所瞄准的受众有用。
因此，这方面的权威是产品经理，他最终决定是否发布。他们可以超越我们，但我有一个总体产品经理，我在业务方面与她一起工作，在她和我之间，我们查看 API，我们讨论它，我们与产品经理交谈，以真正理解用例是什么，我们讨论风险。如果你正在发布一个内部 API，并且你认为它不会持续很长时间，那么你必须考虑它的寿命将在什么时候结束。你是否考虑过他们是否会对这个 API 进行突破性的修改。我们向他们建议风险，在某些情况下，他们接受这些风险，他们发布 API 供外部使用。但在其他情况下，人们会说“哦，现在我明白了，我们真的想构建另一个需要外部化的 API。”
外部化的最低标准
发布 API 的最低验收标准包括:准确的&测试文档，来自 PM 的不做突破性更改的保证，满足适当的安全&性能预期，以及发布它的真实用例
我们有外部化 API 的标准，我们称之为最低接受标准。我们对 API 的最低接受标准是，它们必须符合我们的 SAS API 标准和指导方针，围绕它们所服务的产品的一致性和可用性的基本行业期望。他们需要有完整的书面文件，然后该文件需要准确，它需要满足消费者的需求和期望。我们希望他们对文档进行合同测试，以确保 API 的功能符合实际记录的内容。我们希望他们基本上保证不做突破性的改变，除非将来有一些可怕的理由这样做，显然是一个可怕的安全问题或需要解决的事情。但是我们希望这些东西能够长久存在，我们真的考虑得很周到，注意不要引入突破性的变化，并建议我们的产品管理团队，这对使用 API 的人很重要。我们不能把它们从下面分开，因为如果你这样做，人们会非常不安，并在 Twitter 上写一些关于你公司的刻薄的东西。所以我们对此非常关注。如果我们不得不弃用或删除某个东西，我们会非常仔细地考虑弃用声明，并围绕它循环。我们需要他们满足产品安全办公室的所有期望。他们需要满足为产品设定的任何性能预期。它需要有一个真正的用例，它不能只是像“我写了这个很酷的 API，我想把它放在那里，有人可能会使用它，或者没有人会像那里一样使用它。”把它放在那里一定有真正的商业原因。
最后一件事有点深奥，但我们希望确保在自有产品管理团队、内部消费者和面向客户的团队之间有一个反馈循环，这样我们就能不断地获得关于 API 的信息。因为如果 API 不起作用，那么我们可能需要构建其他东西。但是，所有团队之间的反馈循环，让产品经理真正了解人们希望如何使用 API，或者正在使用 API，这确实是我们知道我们最好地服务于将使用这些的社区的方式。
Larry: 没错，了解您的客户使用您的 API 的目的和用途，以及它的部署是否成功非常重要。这有点自私，因为我为一家分析公司工作，这就是我们所做的，但我完全理解这个问题。有趣的是，你提出了外部化内部 API 的标准之一，因为在之前与迈克·阿蒙森的播客中，他说当创建一个新的外部 API 时，你应该考虑的最重要的问题之一是确保它遵循你希望你的公司面向外部的服务的所有合规性和安全性问题。确保这一点的最好方法是，当你第一次构建你的内部 API 时，要有这样的心态，有一天这可能会成为一个面向外部的服务。
珍妮:是的。最重要的是，我们已经有了一堆 API，有些情况下，我们的客户会立即需要它们，从商业角度来看，我完全理解这一点，但我们的目标实际上是从一开始就开始设计这些 API，以满足这些期望。生产可以外化的东西，即使有人从一开始就不想这么做。
产品管理是负责任的
产品管理应严格确保所有检查都已完成，这样整个产品才能交付
Larry: 是的，所以你至少从第一天起就拥有内置于 API 中的能力，以防你想在外部部署它。深入研究一下您之前所说的业务案例，根据您的经验，谁需要支持一个 API 来开发或对外发布它？它必须有销售和营销人员的参与吗？他们需要一个铁证如山的商业案例吗，或者一个产品管理方面的冠军就足够了吗？
Jeannie: 所以对于内部 IP 的外化，你需要一个产品经理。你需要一个人来担当产品所有者的角色，这个人将从业务的角度接管 API 的所有权，从业务的角度对它负责，并确保它从业务的角度满足所有那些生命周期的期望。正如我所说，它们肯定是明确的业务需求。你知道，我们已经有工程团队提出了他们已经编写的 API，他们希望将这些 API 具体化。我们只需要确保所有的检查标记都完成了，不仅仅是关于满足标准，而是关于以下内容:支持团队是否经过培训，以便他们能够在这个 API 发布后支持它，它是否经过测试，我们是否有好的文档？所有这些都很重要。因此，我们真的需要某种产品管理的严格性，或者某个担任产品管理角色的人对此负责。
API 赚钱
决策者应该通过向 API 展示来自该领域的用例，并向该领域的领导者展示这些用例，来衡量 API 成为利润中心的能力
拉里:对。很有道理。就价值创造而言，从你的 API 中赚钱还是赔钱——你如何让大型组织中的决策者理解 API 的价值潜力，他们可以赚钱也可以赔钱，这取决于做得对不对？
Jeannie: 所以这肯定是一场艰苦的战斗，战斗是一个错误的词，因为像商业中的任何事情一样，专注于对业务来说是全新的、有潜力但尚未被证明的东西，特别是在一个有 40 多年历史的公司中，这自然会与其他业务优先事项竞争。随着时间的推移，我们的许多其他优先事项已经开始真正赚钱了。我们只是在推理，对吗？而且，在它成为现实之前，我们理论上认为 API 会赚钱。尽管如此，潮流确实在改变。我们已经从我们的领域中获得了许多用例。我们一直与该领域的领导者保持联系。他们一直在寻求高价值、易于使用的 API。我们将那些来找我们并告诉我们他们有 SAS APIs 用例的人与决策者、产品管理人员和我们的执行领导联系起来，他们实际上可以确定工作的优先级并雇佣人员来创建这些东西。我们提出了我们的愿景，我们一直非常坚持，希望不会令人讨厌，但我们非常坚持地试图证明这样一个事实，即有许多人正在从他们的 API 中赚钱。我认为在我们的业务中也有这样做的真正机会。
我确实认为我们确实在改变，我只是想分享一个非常酷的故事，实际上就发生在上周。在我的职业生涯中发生的最酷的事情之一是，我们公司有了一位全新的 CTO，他要求我们的 API 优先项目团队来演示我们的新重启愿景。我们正在重新启动我们的 developer.sas.com 开发者门户，这也是非常令人兴奋的，他想做一个概述，说明我们希望以服务的形式提供 API。他用自己的研究开始了会议，这让我们感到惊讶，他带来了几篇行业文章，与他的执行团队分享了 API 优先的公司和 API 优先的成功公司。听到他把 API 说成是人们愿意为之付费的东西，真的非常非常酷。并且知道我们已经得到了自上而下的支持来推进这个计划。除此之外，我很快将有机会雇用一群新人，所以请在 LinkedIn 上留意一下。
拉里:嗯，也许我们可以在播客的文字稿里放一个链接，链接到你的公开简历。
珍妮:我们肯定能做到。
4 技术考虑
在现有的企业软件公司中建立一个 API 程序时，有四个主要的技术考虑:制定设计标准&文档指南，因为标准会改变而具有灵活性，为你的开发人员提供 guardrails &工具，坚持使用 OpenAPI
拉里:很好。很好，你有来自自上而下的支持，来自新 CTO 的支持，来发展和扩展你的 API 程序。最后，请与我们分享您在现有企业软件公司中建立和发展 API 程序的最佳实践。
Jeannie: 所以，我认为你需要关注三个不同的领域。第一个领域是技术方面。将设计标准记录下来是非常重要的。制定游戏规则至关重要。我非常幸运的是，我们最初有一个卓越的中心，它确实考虑到了这一点。我继承了一个标准。我不喜欢标准的一切。有些事情我不能改变，因为那样会让一切都不一致，但我喜欢有一个标准，有一个准则可以遵循。这对需要使用 API 的人来说有很大的不同，这对他们来说非常非常重要。
认识到标准必须不断发展，这是第二件事。我已经看到了为什么我必须为低代码/无代码 API 或 API 即服务开发第二个标准的原因。我们今天的标准实际上专注于我们的微服务 RestAPIs，我发现其中一些模式对于我们未来想要进入的其他领域并不适用。所以，只要知道有些关于微服务的标准的事情我不能改变，或者会变得不一致，但是这些事情对于这些其他类型的 API 可能没有意义，没关系，向前发展没关系，发展也没关系。
技术方面的第三件事是，给制造商，也就是提供 API 的人提供护栏和工具。让他们尽可能容易地遵循风格、标准和指导方针。我有一个非常小的团队，我希望我能做得更多，给他们更多的工具，但我们非常关注这一点。我知道这很难。开发人员和工程师在构建这些 API 时，在质量方面需要担心所有这些事情。你越容易让人们做到这一点，他们就会做得越好，坚持下去。然后我只需要插入 OpenAPI，因为如果你不使用 OpenAPI，我不知道该告诉你什么。你会感谢你自己，无论是做设计还是做文档。如果你不想做，那就做吧。
符合业务需求
在现有的企业软件公司中建立一个 API 程序时，拿出证据证明这个 API 程序是值得的——面向客户的团队举足轻重
在商业方面，尤其是当你刚开始组建一个项目时，寻找同盟。真正让我们在 SAS 的 API 上向前迈进的事情是，我们真正开始与 SAS 的其他人联系，这些人相信 API 不仅仅是管道，他们不应该要求 10 倍的开发人员来执行集成。拥有 API 崇拜是一回事，我们内部称自己为“API 很重要”，但是当其他团队，尤其是面向客户的团队，开始支持我们时，事情才真正开始加速。这也非常符合我的下一个想法，你必须做的一切都必须符合某种业务需求。你需要了解你在整体优先级中的位置，并在你的限制范围内尽你所能去做。即使你努力游说以提高优先级，并获得你需要的帮助来真正使项目启动。你必须坚持不懈，你必须不断努力。如果你认为这件事对公司很重要，那就继续做下去。我知道我不会说每个公司都会得到它，或者扭转局势，但我会说，如果你带来足够的证据，最终事情会开始移动。
要有耐心、远见和同情心
构建 API 程序时要有耐心。对那些和你有不同看法的人感同身受——试着搭建桥梁帮助他们理解。有一个愿景，并为之努力。
然后在个人方面，我只想说要有耐心，我一点都没有耐心，我不是一个有耐心的人。当你发现自己刚开始做某件事，或者走进一个并不像你想象的那样糟糕的情况，你很容易就可以离开。你知道，这是我早就想过的事情，我就像“哇，这将需要很多工作，这些事情我不知道如何去做。”但我真正发现的是，这是一个创造奇迹的机会。我仍然不知道所有的事情。我还在想很多事情。但是如果你处在我的位置，你正试图找出如何构建一个程序，坚持下去，因为首先这是很好的体验，其次，API 很重要。API 值得。我认为你会发现这是一次有意义的经历，即使最初可能会有一些挫折。
第二件事是要有远见。如果你没有远见，你就有麻烦了。即使你所拥有的愿景在今天看起来真的不可能，或者看起来可能需要很长时间，拥有一个愿景多少会给你一个努力的目标。所以我认为这真的很重要，最后一件事就是对那些和你看问题的方式不同的人产生共鸣，然后试着搭建桥梁帮助他们理解。
关于这个我要说的最后一件事，就是相信 API。毫不夸张地说，API 是我们今天互联存在的基础。随着时间的推移，它们可能会采用新的协议和流行的新风格，以及各种各样的用例，但总会有集成的需求。机器总是需要能够相互交流，人类也需要能够与机器交流，这种以精心设计的无缝方式进行交流的能力具有巨大的价值。鉴于如此多的 API 优先业务的出现，围绕 API 进行商业案例变得越来越容易。所以，如果你在挣扎，或者沮丧，或者你觉得自己没有进步，坚持下去，然后“改变世界”我认为如果你继续在 API 上努力，你会成功的。
拉里:嗯。这是对这一领域的认可。我相信我们所有的听众都很高兴你没有离开 API 的世界，正如你所说，你仍然是“API 的崇拜者”。Jeannie，今天和你聊得很愉快，解释了一家大型现有企业软件公司是如何拥抱新兴的 API 世界的。以及如何通过采用正确的程序和计划来实现这一目标并获得成功和有利可图的服务。所以非常感谢你参加我们今天的播客网络。
Jeannie: 当然，谢谢你给我这个机会来谈论这个
拉里:谢谢。
LoungeBuddy 工程副总裁关于架构最佳实践的播客
Ep。7: Jessica Lam，LoungeBuddy/AmEx 前工程副总裁
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入 Moesif 的是 Jesscia Lam ，目前是初创公司的技术顾问和天使投资人，也是被美国运通收购的 LoungeBuddy 的原首席架构师和工程副总裁。在 LoungeBuddy，她设计了他们的 API，其中许多一直沿用至今。
作为多家公司的首席技术官、架构师和工程主管，Jessica 分享了她在以下方面的经验:如何构建更具弹性的产品、为什么错误处理如此重要、如何看待内部 API 和外部 API，等等。
德瑞克·吉林，Moesif 的首席执行官是今天的主持人。
Moesif · Architectural Best Practices with LoungeBuddy
在 SoundCloud 上听这一集，在苹果或谷歌上下载，或者在 YouTube 上观看。
目录
- 0:30API 是简洁的值单位
- 4:44 不要区别对待内部 APIs】
- 6:55 用流量控制器简化新的 APIs】
- 9:55 内置好错误处理
- 13:40 遵循 80-20 法则进行测试
- 15:53 尽可能减少技术债务，快速行动
德里奇·吉林(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络的另一集。今天我将和你们的主持人以及 API 可观测性*台的 CEO 和 Moesif 一起讨论。加入我的是 Jessica Lam，她曾是 LoungeBuddy 的首席架构师和工程副总裁。他们被美国运通收购，她在那里设计了许多 API，这些 API 一直沿用至今。我希望听到更多关于这方面的信息，比如您是如何设计的，以及在规划过程中做出了哪些设计决策。
API 是简明的价值单位
把你的 API 想象成简洁的价值单元，提供其他人可以重用并从中获取价值的特性或任务。
杰西卡·林(LoungeBuddy): 酷。所以这些 API 的发展在我看来就像是公司和产品的自然发展。最初，该产品只是一个移动应用程序，背后有常见的应用程序支持，除此之外没有任何 API。在那个移动应用起飞后，我在种子期前就加入了。因此，作为第一个被聘用的工程师，也是首席建筑师，我们考虑的第一个主要项目是如何为休息室采购。关于 LoungeBuddy，它最初是一个休息室搜索器，后来成为一个休息室管理*台。
在我们决定添加购买的时候，有一种想法是，购买休息室不应该在概念上仅限于应用程序。因此，当时的观点是，这是一个简明的价值单位，任何人都可以从中获取价值。因此，在未来，如果我们正在构建一个 web 应用程序，或者如果我们正在为外部合作伙伴构建一个网站，这种简洁的价值单位可以被重用。因此，回到我的计算器编程时代，在那里我抵消重复的任务，并真正思考什么是其他人可以从中获得价值的重复使用的东西，这就是 API 想法的来源。因此，我们不要将此作为应用程序后端的一部分，我们启动 API 服务会更有意义。
因此，我们思考如何集中管理所有这些东西。将它分解成购买的基本步骤，首先我们需要检查可用性，看看是否有特定休息室的库存。所以，只要看看这句话，你就会意识到有某些变量，比如哪个休息室，所以你知道那是你传递给 API 的一个参数。看完供货情况后，你会转向下一件你感兴趣的事情:它的定价是多少？然后，在那之后，弄清楚如何购买。所以最初，从概念上考虑，什么是必要的步骤，然后把它放在那里，并对它进行迭代。
我的核心工程哲学之一是，让事情变得容易比试图预测未来更好。因此，在构建了采购 API 之后，我们首先开始使用我们的移动应用程序对其进行测试。因此，在移动应用中，我们使用购买流程来帮助我们进行沟通，比如:API 是否有意义，它是否足够简洁，或者它是否过于复杂。解决了这个问题之后，我们开始开发使用相同 API 的网站。
德里奇:真的很棒，尤其是考虑到简洁的价值单位。每当你看到一个 API，了解你如何为你的客户提供更多的价值，它是否是可重复的。你是如何衡量的？有没有一种方法可以理解每种 API 给企业带来的每种价值？
Jessica: 我想说这是这个*台所缺乏的东西，我真的希望很多很多年前我们开始的时候你们还在。我们真的没有办法去衡量它。我们专注于错误处理，并确保它是健壮的，人们不会遇到错误。关于 API 调用的频率，我们有一些非常初步的表层指标，但不一定比这更多。显然，我们会知道有多少人通过 API 进行了购买。但是除了这些表面指标，我们真的没有什么其他的了。
不要区别对待内部 API
对待每一个客户，就像对待一个外部客户一样，这样，如果你真的开发了一个内部 API，它就能开箱即用了。
德里奇:我想我们应该早几年开始。说到你的 API，有些被你的移动应用使用，有些被你的网站使用，你实际上是如何组织你的内部 API 和面向外部的 API 的？它们是相同的还是不同的？
杰西卡:这是一个很好的问题，我的原则是，仅仅因为你是内部员工，并不意味着你会得到特殊待遇。使用这一原则开发 API 的一个非常有用的方法是，当我们向外部合作伙伴开放时，它就真的工作了。由于我们的开发方式，我们假设每个使用 API 的内部应用程序实际上都是一个“外部合作伙伴”，我们没有让内部 API 有一些特殊的后端东西来优化一些小东西，以便做他们想做的任何事情。而在前端和 app 后端的谈判中总是这样。对于任何与不同开发人员合作过的人来说，人们会说“哦，如果 API 只是返回所有这些，那么前端会容易得多”或类似的话。因此，抵制使用这些变通方法的冲动将会使 API 变得非常干净，并且在整个系统中关注点和责任的分离也非常干净。所以我认为我对内部开发 API 的建议是把每一个客户端都当作外部客户端来对待。
这是一个非常好的观点，特别是当我们去大公司的时候，那里有很多不同的团队访问 API，每个团队实际上都是客户。这也有助于提高安全性，确保您在外部应用的安全措施也适用于其他团队，这样您就不会遇到网络某个区域可能存在漏洞的情况。
用流量控制器简化新的 API
当支持新的 API 功能时，你不希望不得不重构你的应用。使用类似网关的服务(流量控制器)来访问您的 API，这样就可以通过控制器简单地支持迁移。
Derric: 再多讲一点这些 API，你是预先设计了这些 API，还是更像是从服务开始，然后围绕一个 API 来组织它？如何看待 API 第一？
杰西卡:这真是个好问题。我实际上用了两种不同的方法。对于采购 API 来说，从一开始就很明显，它将跨*台、跨我们所有不同的服务以及外部重用。但是还有其他的事情悄悄向我们袭来。例如，应用程序中有一个核心实用程序，它根据访问规则和访问项目查看休息室。一个访问项目的例子是你的信用卡，然后访问规则是这样的:如果你有这张信用卡，你入境到一个特定的机场，那么你可以访问这个特定的休息室，否则，如果你出境，那么你没有访问权。这些最初都在 iOS 应用程序中。因此，我们后来在与美国运通进行整合时意识到，需要能够访问该功能。在这一点上，弄清楚如何有效地将其抽象出来是一个有趣的过程。
有些人会说“好吧，让我们停止一切，完全重构那个应用程序，取出所有那些服务，把它放到一个不同的服务中”。在我看来，这实际上是一个非常高风险的努力，它不一定会给你带来你认为的那么多好处。我通常进行这种类型的迁移或改变系统内的模式的方法之一，是让它不使用真正的 API 网关，而是使用一种称为流量控制的服务。本质上，我们的期望是，如果您正在访问任何 API，您将使用流量控制服务。在流量控制服务的背后，有时实现了 API，但其他时候它实际上是重新路由到另一个服务的后端，该服务可能有您正在寻找的内容。因此，为了方便迁移，如果您想将代码从应用后端移动到实际的服务中，您可以选择使用流量控制来实现。
通过设置期望，如果你正在访问 API，使用流量控制。你不关心交通管制如何获得这些信息，只要合同是与交通管制签订的。所以我认为这也是保持速度的一个很好的方法，因为对于一个初创公司来说，速度是我们的突破口。我觉得这种操作方式真的很有帮助——不用预测未来。我们不知道我们将在外部使用这些，但有一种方法可以做到这一点，以一种风险非常低的方式。
内置良好的错误处理
当美国运通的 iPad 应用程序推出时，美国运通的集成合作伙伴没有错误处理功能，因此当出现多个 500 错误时，由 LoungeBuddy 来识别并让合作伙伴了解他们的问题。
德里奇:这是一个非常好的观点，尽快迭代的能力，特别是对于早期创业公司。但是你也提出了一个关于移民的有趣观点。你采取了什么程序来确保你没有破坏与美国运通或其他客户的整合？有合适的流程吗？
杰西卡:所以启动和流程这有点矛盾。我们与美国运通有几个整合点。一个是他们的应用程序使用了我们的购买 API。因此，现在如果你登录美国运通应用程序，然后进入休息室，最终生成的二维码来自我们的购买流程。另一次整合实际上是在 iPad 被引入美国运通贵宾室的时候。有与流程流的幕后集成，也有与外部合作伙伴的集成。因此，它的工作方式是，当有人刷卡时，卡号实际上被发送到他们的服务。因此，我们在获得认证和部署所有安全措施方面没有风险。之后，外部合作伙伴返回了一个访问项，然后我们在服务中做了一些事情来解决这个问题。
我们进行了大量的错误处理。最初与第三方的集成实际上有很多 500 错误。有趣的是，他们没有错误处理，所以他们实际上不知道发生了什么错误。但是因为我们有错误处理，我们就像“我们实际上从你那里得到了 500”这是错误信息。所以对于最初的发布，我不确定我应该谈论这个，但它有点像“所以在应用程序的前端，他们会看到 500 个错误”，但因为他们的服务没有错误处理，这取决于我们。我们和他们之间有很多的争吵。这就像当这种情况发生时，我们从你的服务中得到一个错误，即使用户在我们的应用程序上看到一个错误。这就是错误处理和非常好的错误处理的重要性。任何时候有可能出现某种错误，一定要记录下来。
德里奇:肯定。准备好错误处理和监控，这样您就可以放心发货了。没有它，你几乎是盲目飞行。您实际上是如何设置的，遇到了哪些挑战。
杰西卡:对。我想知道自从我大约一两年前离开以来，这种情况发生了多大的变化。但我们当时的方法是，我们使用 Heroku 后端，他们有一些现成的工具，如果您有超过一定百分比的错误，那么您可以设置一个警报来跟踪它。所以我们已经把这些都准备好了，还有一件事叫你，传呼机责任。我们用 PagerDuty 设置了警报，以便在不同服务上出现一定百分比的错误时，特别是较差的面向外部的服务，有人会接到呼叫。所以，准备好所有的错误处理，然后确保你不会在凌晨 3 点接到电话。
遵循 80-20 法则进行测试
不要以 100%的代码覆盖率为目标，而是测试你对外公开的特定 API 调用，比如 get 和 POSTs，运行火炮进行负载测试，然后得到一些东西，让它随着时间的推移变得更加健壮。
不，毫无疑问，我们看到很多客户在使用 PagerDuty，而且到目前为止服务还不错。Moesif 本身与 PagerDuty 有一个集成。当谈到测试时，你们有什么最佳实践或流程吗？它们是什么样的？测试 API 的挑战是什么？
杰西卡:是的，这是一个非常好的问题。当谈到启动和优化时，我们试图遵循 80/20 法则。显然有一些理论上的最佳实践，比如“哦，我们想要 100%的代码覆盖率”，或者“我们想要确保所有东西都经过测试”。我觉得在这一点上我有点与众不同。我想我的原则是测试最重要的东西，然后，如果随着时间的推移出现了额外的错误，那么你就这样添加测试。所以，做最基本的事情，然后看看你有什么样的空气，然后在此基础上建设——这是一种反脆弱的发展方式。
因此，我们做的一些事情显然是对实际的特定 API 调用本身进行真正强大的测试，比如 get 和 POSTs 以及所有对外公开的内容。在完成这些之后，有时，根据某个特定服务被调用的频率，我们还会在部署之前使用火炮进行负载测试，作为健全性测试，以确保不会因为高负载之类的原因而随机播放。这些测试在首次发射后分阶段进行。所以这又回到了我之前所说的，先获得一些东西，然后看看你会得到什么样的错误，然后随着时间的推移使它变得更加强大，而不是立即尝试过度设计。因此，当我们开始看到负载问题时，我们开始进行负载测试，看看每秒钟我们收到多少请求。我们在两倍的数量上运行负载测试，只是为了确保我们有足够的填充。
最大限度地减少技术债务，快速行动
永远要把露营地收拾得比你发现它的时候还要干净:当你修复一个 bug 或创建一个新功能时，你将会接触到现有的代码，当你接触到它时，如果有些东西是低效的，要有意愿去思考它并重新调整代码库。
毫无疑问，确保你不会过度设计对创业公司来说总是很重要的。在工程领导中，很多时候你要*衡客户需求和工程需求，你有技术债务。有哪些方法可以让你快速迭代并*衡客户需求，而不会让你的工程团队负担过重？
杰西卡:这真是个好问题。从我担任顾问或过去合作过的所有不同的初创企业来看，这总是一个问题。就像，事情总是进展得不够快，而且总是有技术债务。减轻这种重构风险的方法是，实际上总是让露营地比你发现它的时候更干净。例如，不要花一两个 sprint 去重构某个东西，因为你知道它开始有技术债务，理想的方式是在修复 bug 的过程中，或者在创建新功能的过程中，你将接触现有的代码。当你接触它的时候，如果有什么是低效的，要有意愿去思考它并重新调整代码库。
技术债务积累的主要原因是，当你第一次开发系统时，有一些关于关系的业务假设，但是随着时间的推移，可能因为不同的特性，这些关系可能会改变。因此，即使您可能注意到了设计级别或功能级别的更改，但缺少的部分是，有时您没有在代码级别进行更改。再一次，这又回到以整体的方式思考系统——这不是说你有设计，然后你有前端，后端和系统，这实际上是一回事。就像我说的，应该有一个贯穿其中的一致的概念线索，并将其设计成这种关系的可视化表示。因此，深刻理解这种关系，并确保这在代码中得到反映，在我看来，是我们能够尽可能减少技术债务的最佳方式，这是确保您能够快速前进的方式。如果这些概念被恰当地表示，那么以正确的方式重用它们是非常容易的。所以有这样一个理想，当你甚至没有为一个特定的方法设计，去采用一个特定的被使用的方式，它应该只是工作，它有点像一个框架。这实际上是我非常喜欢苹果框架的原因之一——如果你以正确的方式使用它，它通常会起作用。然而很多时候，我认为开发人员并没有真正考虑特定方法或 API 的意图，只是试图按照他们想要的方式去做。所以我认为重要的是花时间去理解，然后在开发过程中重构，而不是在真空中重构。
非常棒的见解，尤其是关于技术债务和如何思考开发的见解。杰西卡，很高兴你能来我们的播客，希望我们能很快在洛杉矶见到你。
杰西卡:是的，当然。
关于如何与 Radar 首席执行官 Nick Patrick 一起建立 API 优先公司的播客
Ep。6:尼克·帕特里克，雷达公司首席执行官
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
在今天的节目中，我们邀请到了 API-first 定位*台公司 Radar 的首席执行官尼克·帕特里克。尼克在 2016 年加入 Radar 之前，曾在微软的 Foursquare 和 Handy 担任项目经理。
作为 Radar 的联合创始人和领导者，Nick 分享了他在如何推动增长、选择合作伙伴、更快更有信心地交付产品方面的经验，并为 API *台生态系统中的专业人士提供了许多宝贵的观点。
德瑞克·吉林，Moesif 的首席执行官是今天的主持人。
Moesif · 6. Nick Patrick, CEO at Radar
在上面的 SoundCloud 上听这一集，在苹果或谷歌上下载，或者在 YouTube 上观看。
目录
- 0:39pm 是迷你 CEO
- 2:04 初创公司以百万英里/小时的速度运行
- 3:20 与合作伙伴的燃料增长
- 4:41 重叠客户&用例最佳
- 6:41 展示您*台内部的投资回报
- 8:20 使用 Moesif 更快更有信心地发货
- 10:19 使用与新端点一致的名称
- 12:39 打包您的 API 以解决一个痛点并移动一个指标
- 14:20 关注经济买家
- 16:05 文档应该简单而完整
- 18:30 使用强制功能保持文件最新
- 20:46 做更多本地化后的 COVID
- 22:42 找到一个与你互补的联合创始人
德里奇·吉林(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络第六集。我是今天的主持人，API 分析*台 Moesif 的首席执行官 Derric Gilling。
和我一起的是尼克·帕特里克，API 第一公司的首席执行官。尼克曾在微软、Foursquare 和 Handy 担任产品职务，事实上，正是在 Handy，他遇到了他的联合创始人 Colby Berman，他们提出了 API 优先的位置*台的想法。非常高兴你今天能来，尼克。
尼克·帕特里克(雷达公司首席执行官):谢谢你邀请我，德里克。我忘了这是 APIs over IPAs，也许我应该先给自己倒一个 IPA，这样播客会更有趣。但是我忘记做那件事了。
项目经理是迷你 CEO
如果你喜欢制造东西，并且对商业感兴趣，那么产品管理是开创自己公司的良好开端——项目经理是他们产品的首席执行官。
德里奇:无忧。我们很想听听你的旅程，从产品开始，然后推出 Radar。一路上你的司机是谁？
尼克:是的，我一直对编码和构建东西很感兴趣。我小时候造过一台电脑，中学时学过编程，高中时真正迷上了科学。所以当我上大学的时候，我是生物学和计算机科学的双学位，我想获得计算生物学的博士学位。我意识到我讨厌研究，只想做点东西，也对商业感兴趣，希望有一天能开一家公司。
所以产品看起来是技术和商业的完美结合。这有点老生常谈，但你可以算是一个产品的迷你 CEO。因此，我在微软担任了一个项目经理的角色，去了商学院，最后在 Foursquare 工作，在那里我遇到了我的联合创始人克比，也是我们的首席技术官蒂姆，他在稍后加入。然后去了 Handy，那是一个早期的公司。我看到公司从 A 轮到 C 轮或 D 轮阶段，就是在那里我有了建立开发者至上的位置*台的想法。所以我的旅程从总是喜欢构建东西，总是进入技术和编码，只是一个进展。产品管理似乎是一个很好的第一步，然后最终找到了我的雷达。
创业公司以每小时一百万英里的速度运行
初创公司与任何其他公司的一个很大区别是，你必须找到自己的正确速度或流程水*，而这通常是每小时一百万英里。
德瑞克:哦，真的很高兴听到这个消息，尤其是从产品的角度来说，你在某种程度上是一个迷你 CEO。构建一个开发者至上的*台与你在微软和你在其他职位上看到的有什么不同？
尼克:我认为它在几个方面有所不同。微软显然是一家行动相当缓慢的大公司。我想我是在三年轮班周期的第三年加入的，当时他们正在开发他们的 CRM 产品，Salesforce 的竞争对手。当时，他们主要是通过收缩包装的 DVD 来销售——微软刚刚开始拥抱云。所以我认为变化的一个方面是，我变得越来越小，很明显，当你是一个两个人的创业公司，刚刚起步，你的速度是每小时一百万英里。所以我觉得一个区别就是速度。例如，我认为建立一个 API 公司和建立一个 SAS 公司与建立一个消费者公司是非常不同的。与 Handy 截然不同，我们在 Handy 建立了一个市场。因此，我认为许多相同的原则也适用于理解你的客户，构建一个伟大的产品，并找到正确的速度或流程水*。但是当然，你需要做一些事情来建立一个 API 优先的业务，这一点我们可以详细讨论。
通过合作推动增长
像 Radar 这样的 API 优先公司经常将数据发送给其他工具，因此与这些工具公司整合是有意义的，可以形成合作伙伴关系，从而推动增长。
derrick:希望深入探讨这些独特的挑战。对于那些可能正在考虑新的 API 开发者*台的 CEO 来说，API 有什么独特之处？
尼克:举例来说，我认为雷达上最有效的增长渠道与我们手边最有效的增长渠道不同。我认为当你在一家 B2C 公司工作时，推荐和优惠券是推动增长的好方法。显然，拥有优秀的产品或服务也能推动增长。关于雷达的一件事是，作为一个 API，我们可以通过我们的 API 收集数据，然后将数据发送到其他工具，其中许多工具本身也有 API。因此，有很多整合和合作的机会。这实际上是我们在 Radar 的增长战略的一个关键部分——我们插入像 Segment、Braise、Amplitude 或 MixPanel 这样的工具。位置数据是了解您的客户的关键输入，因此我们需要收集位置数据，并利用这些数据来提升体验。我认为对我们来说，最大的收获是整合的机会和推动增长的合作伙伴战略。
重叠的客户和用例是最好的
使伙伴关系起作用的关键是找到有重叠客户和用例的公司，或者组合的解决方案使开发者的生活更容易的公司。
德里奇:牛逼。谈到这些细分市场的集成，或者其他一些集成，您能否向我介绍一下在新的集成或您已经拥有的集成方面应该在哪里投资？你怎么知道他们是否在工作？
尼克:我们考虑了几件事。一个是，当有重叠的用例，有重叠的目标客户和购买者角色时，我们显然喜欢与某人合作。因此，主要消费者是希望提升产品体验的产品经理，或者希望构建一流的技术堆栈来收集和激活客户数据的开发人员，或者希望激活这些数据并进行基于位置的定位或触发活动的营销人员。因此，我认为我们应该看看他们的重叠客户和使用案例在哪里，雷达可以在哪里增加价值。同样，我们合作的*台也在增加价值。
我们思考这个问题的另一种方式是，我们显然希望让开发者、初创公司和企业尽可能容易地建立基于位置的良好体验——收集位置数据，并以正确的方式进行。因此，我们考虑集成，只是让这些体验旋转起来，让收集和处理这些数据变得更容易。如果我们可以节省一些人需要自己建立一个 Webhook，手动发送一些数据到另一个工具或将数据转发到一个数据仓库，并投入工作来处理所有这些数据，只需用一个复制和粘贴 API 密钥的交钥匙集成来代替，这对我们的客户来说非常有价值，并帮助他们更快地实现价值。因此，哪里有重叠的使用案例和目标客户，哪里就有机会让我们更容易开始收集位置数据和构建这种类型的体验。
显示*台内部的投资回报率
API *台的一个问题是，客户可能只在你的*台之外认识和衡量你的产品带来的价值。尝试将产品激活详情和投资回报可见性引入您的*台，这样您就可以看到他们在使用什么，并展示他们得到了什么。
德里奇:哦，肯定的。你知道，对一个人来说，采用一个新的 API *台越容易，对你的客户就越好，对任何人来说都是如此。另一方面，我们也听说客户的成功对于开发者*台来说是一个挑战。你如何扩展它，特别是如果你继续发展一个开发者社区，并确保每个人都得到他们需要的正确的帮助，而不使你的内部团队负担过重？
尼克:这是个很好的问题。你知道，在雷达之外发送数据的所有这些集成的挑战之一往往是激活，或者在雷达之外识别和测量价值。因此，我们正在考虑如何帮助您激活数据，并在一定程度上了解您在雷达中的投资回报。我们非常关注API 的使用是否会随着时间的推移而增长 , 你们是否会随着时间的推移扩大*台的使用。也许是上传更多的地理围栏，也许是收集更多的位置数据，如果您使用我们的位置检测产品，也许是开启新的链或类别，也许是创建新的 Webhooks 或开启新的集成。根据产品的定价方式，你可能会收取更多费用，并随着时间的推移增加这些合同。这就是我们对它的看法。我们会考虑如何利用该*台实现明显的价值和明确的投资回报，帮助我们的客户衡量它，在雷达范围内了解它，然后继续基于位置构建新的体验，并随着时间的推移使用该*台的更多部分。
使用 Moesif，信心百倍地加快运输速度
当引入新的 API 端点时，你需要了解它们是如何被使用的，它们的表现如何:什么程序在使用它们，它们的响应时间是多少，它们是否返回 200、400 或 500 等等。在产品发布速度非常重要的时代，Moesif 可以帮助您更快、更有信心地发布产品。
德里奇:肯定。说到可见性和分析，非常高兴 Radar 成为 Moesif 的客户。想听听您目前使用 Moesif 的案例是什么，以及您在哪些方面取得了最大的成功？
Nick: 我们最初是一个地理围栏*台，正如我之前所说，我们意识到有机会扩展我们*台提供的不同使用案例和构建模块。例如，一个使用雷达进行地理围栏的现有客户，当客户走进商店或你在商店内打开应用程序时，他们可能会发送推送通知，他们使用地理围栏来显示店内模式。也许当你在商店时，你展示的是忠诚度或扫描支付功能，而当你坐在家里的沙发上时，你展示的是购物功能。但他们也说，“嘿，我们为地理编码或自动完成或地点搜索向谷歌地图支付了一大笔钱，你能不能让我们搜索我们的地理围栏，或者给商店定位器供电，或者给地址自动完成用例供电。”因此，我们推出了地理编码 API，我们推出了搜索 API，我们推出了路由 API，这样我们不仅可以告诉你“嘿，你离这个地理围栏 600 米远”，还可以告诉你“嘿，你离这个地理围栏 4 分钟路程”。当我们开发出所有这些新的 API 时，我们需要非常快速地对它们进行测试，并了解它们。对于我们最早的客户，我们想知道他们如何使用它们，他们传递什么参数，他们的响应时间是多少，我们是否返回了很多 200 或 400 甚至 500，Moesif 是一个很好的工具，我们可以快速启动所有这些 API 端点，将它们提供给客户，但也可以放心地这样做，因为我们知道他们如何使用它们以及它们的性能如何。这非常有用，帮助我们在速度非常重要的这一年加快了运输速度。
对新端点使用一致的名称
开发新的 API 或端点时，确保它们与您现有的参数和实体名称一致。此外，还要检查新的端点是否可以作为基础设施，以使您现有的产品更好。
Derric: 听起来你在过去的一年里发布了很多新的 API 和端点。你能向我介绍一下你发现的使新 API 的交付更容易的流程或事情，并确保它与你的*台的其余部分一致吗？
尼克:我想起了几件事。一个是，即使在我们推出这些 API 之前，雷达也在收集和存储大量位置数据，可能是:经度，可能是设备或用户地理围栏的位置，我们有大量现成的 POI 数据、地址数据或管理边界数据。因此，我们要认真考虑的一件事是，这些 API 如何与我们现有的 API 相适应，调用什么参数，调用什么实体，我们是否确保我们对事物的命名一致。如果您使用 Radar 进行地理围栏，例如，使用地理围栏搜索 API 或搜索 API 的位置，或者做一些感觉不同和不相关的事情是否容易？所以我们试着认真考虑这些东西的名称以及它们是如何组合在一起的。
我认为我们考虑的另一件事是，有些东西可以作为 API 进行运输或产品化，也可以作为基础设施进行旋转，以使我们的地理围栏产品更好。例如，您可以提供一个地理编码 API 来将一个地址转换成一个 lat long，这可能是支持地址自动完成或存储定位器。我们还可以使用它来简化地理围栏的导入，也许您可以给我们地理围栏中心引脚的地址，而不是 lat long。因此，我们想了很多，我们如何能够旋转一些基础设施来支持这些 API，同时也使我们现有的产品更好，一举两得。
还有其他类型的战术性的东西，比如这是如何在 SDK 中暴露出来的，我们应该先把它作为 beta 版发布还是向所有人开放。什么时候我们对每个人开放感到舒服，是否有一个质量标准，或者一些我们需要首先达到的可伸缩性里程碑。因此，所有这些考虑都是为了确保我们的客户易于使用，并且从运营的角度来看，我们的产品也是可扩展和智能的。
解决棘手问题并移动指标
你的 API 应该解决一个棘手的问题，那就是移动一个度量标准。因此，要清楚你提供的是什么，什么原语是向开发者公开的，还要清楚它是如何打包的，以便它对业务购买者来说是真正有吸引力和易于理解的。
derrick:当谈到这些不同的构建模块时，你如何实际服务于你的客户，告诉他们“嘿，你不仅可以这样做，我们也可以这样做，这样这样做”？
尼克:如果你是一名开发人员，你可能只想知道那里有什么 API 端点，我可以在你的 SDK 上调用什么函数，等等。然而，如果你是一名企业领导，例如，你可能是一家大型零售商的首席数字官，或者你是一家连锁餐厅或 QSR 的首席信息官，你关心构建模块，显然你希望为你的技术团队选择最佳工具来实现它并快速移动。我们还想知道积木是如何组合在一起的。在某种程度上，您想要购买一个解决痛点的解决方案，一个移动指标的解决方案。所以我们的方法是，我们说，“让我们非常深思熟虑，清楚地了解我们的构建模块是什么，我们向开发人员公开了哪些原语，以及它们如何以真正令人信服和易于理解的方式打包，以供购买该工具的商业买家、经济买家和高管使用。这实际上是我们明年要花很多时间去做的事情。我们如何打包我们的用例，打包我们可以解决的所有事情，以一种简单和可导航的方式，但也是非常强大和令人信服的。这就是我们对两者*方的想法。
关注经济型买家
根据买家角色划分信息:对于工程师决策者来说，从自助服务、自下而上、开发优化到销售是一条直线，而如果经济买家是企业领导，那么就讲述一个关于解决业务问题的令人信服的故事。
德里奇:这带来了一个关于开发者*台的非常有趣的观点。我们经常听到这种挑战，即你总是同时与不同的受众交谈，你有开发商，然后正如你提到的，你有经济买家。开发者*台的 CEO 们有什么建议来思考这种双重性？
Nick: 我认为，如果经济型购买者是工程师，同时也是技术领导者，那么自助服务、自下而上的策略以及所有的一切都是一条直线。这并不一定意味着财富 500 强的首席技术官或首席信息官想要阅读的博客文章与个人开发者黑客马拉松或类似的事情是一样的。但是这里有更多的排列。而对我们来说，我认为我们随着时间的推移发现，至少就我们的地理围栏产品而言，这并不是说经济买家总是非技术型的，这肯定不是真的，但我们只是将两者分开，并说“嘿，让我们真正考虑开发者体验，并确保技术人员正在使用产品，或评估产品，或集成产品，拥有良好的体验。但是，我们也与业务层、经济购买者进行了交流。最终，如果经济买家是一位商业领袖，这意味着你需要在那里讲述一个令人信服的故事，也许你的增长战略应该专注于此，而不一定是来自 HackerNews 或类似渠道的开发者注册。如果这对你有用，那也没关系。
文档应该简单而完整
全面的文档可能很棒，但有时也会让人感到不知所措，所以你需要在简单和简洁与完整和全面之间找到*衡。
当谈到开发人员的体验时，你是如何组织它并把它建立成一个过程的？是否有一个拥有开发者经验的所有者，这是一种跨越雷达本身的思考方式？有时我们听说它是产品团队的一部分，有时是开发人员关系的一部分，这是一个非常模糊的角色。
Nick: 目前在 Radar，我们的产品团队是主要所有者。但是，我认为你是对的。你的登陆页面看起来像什么，他们是在和技术人员交流吗——这是一个营销问题。例如，你在黑客马拉松上出现过吗——也许那是开发者宣传或开发者布道的事情。现在，产品团队主要拥有它。
我们会考虑一些不同的事情。显然，我们会考虑开发者注册。我们也考虑激活，一旦你注册了，你是不是第一次 API 调用。您是否继续进行 API 调用，这表明您已经投入生产或将其集成到您的应用程序中。也是 NPS。一旦你开始使用这个产品，它是不是很棒，有价值，容易使用，你想告诉你的朋友吗？正如我所说，我们还考虑净收入留存。随着时间的推移，您是否在扩展您的用途并调用不同的 API？因此，我认为我们的主要关注点是使集成尽可能简单，导入地理围栏，安装 SDK——如何使其尽可能简单？这实际上涉及到文档、入职以及仪表板是否易于使用或导航。我们正在努力实现的*衡是，全面的文档可能很棒，但有时也会让人感到不知所措，因此，如何在简单和简洁与完整和全面之间取得*衡。这就是我们对它的看法，以及现在谁拥有它。
我还要说，我们组建了一个非常棒的工程团队。我们刚刚开始组建我们的产品团队，尽管作为一名产品人员，我认为我们的产品团队是比我更好的产品人员，这很有趣。因此，将一些工作从我的职责范围转移到我们的产品团队也是一个重点。
使用强制功能保持文档最新
实现一个强制功能来保持文档最新。例如，制定一个政策，只在你可以向客户推荐文档、登录页面、案例研究或指南时才回复他们的邮件。
Derric: 参考您拥有的开发人员文档，如何使其保持最新？我们总是听到一个很大的挑战，就是它过时了，或者有错误的端点，或者有拼写错误。谁拥有它？
尼克:实际上，从历史上看，我拥有它。你知道，我和 Twilio 的一位开发人员成长领导者交谈过，我认为在许多 API 优先的公司中，创始人拥有它一段时间。我认为你提出了一个很好的观点，那就是我们已经讨论了一致性和质量，你知道这适用于任何事情，不仅仅是维护文档，但是如果你有五个人接触某个东西或者十个人接触某个东西，而不是一个人，那么东西就更容易出问题或者脱节。也就是说，我有很多其他事情要做，所以我很容易成为瓶颈。因此，我们正在努力建立一个系统，在这个系统中，任何人，实际上是我们的客户成功团队、解决方案工程团队以及发布新功能的工程师和产品团队，都可以输入并说这是缺失的，或者应该添加。我们对其进行分组和优先排序。在未来，我们希望能有一个地方，任何人都可以对文档提出编辑建议，并有某种批准或审核流程。
我在细分市场与一位非常早期的产品人员交谈过，听起来这实际上是真的，但他们很早就强加了一条规则，即你不能回答客户的问题，除非你向他们发送文档的链接。所以这迫使你在去找别人之前，把它添加到文档中，或者适当地重构文档。在过去的三年里，我已经回答了 50 多次客户问题或故障排除等类似的问题，我可能应该将这些内容添加到文档中。所以我认为一些类似的强制函数也是有帮助的。
德里奇:这是一个非常好的观点。事实上，我们一直非常重视这一点，无论是文档、案例研究还是其他任何内容，都必须有一个到某个登录页面的链接，而不仅仅是复制和粘贴电子邮件的片段。
尼克:太好了。
在 COVID 之后做更多本地化工作
2020 年，物理世界变得比以往更加多样化。泰勒你的产品体验和讯息，以考虑到不同的情况在地面上。
德里奇:API 的下一步是什么？有很多新的 API 优先公司上线，特别是 COVID，你认为未来会怎样？
尼克:是的，我想我们才刚刚开始。我们认为 Twilio 对 Segment 的收购非常令人兴奋。你知道，我们参与了一个名为独立*台的市场营销活动，其中的主题或论点是，最佳客户体验是由同类最佳的*台和紧密集成在一起的同类最佳 API 推动的，而不是单一的笨重*台。显然，我们认为位置数据是一个重要的输入。有各种不同的输入来了解您的客户和建立良好的体验，但我们认为位置数据是一个关键的输入，只是还没有得到足够的利用。
2020 年无疑是有趣的一年。如果你仔细想想，物质世界比以往任何时候都更加因地而异，我们如何与它互动也比以往任何时候都更加重要。所以，想想你为客户提供的产品体验，或者想想你发送给客户的信息，实际情况因州而异，因城市而异，因国家而异，还没有足够多的人利用这一点。
因此，我认为我们将继续看到集成和协同作用，帮助您利用数据做更多事情，并更好地了解您的客户和用户。我提到整合和合作伙伴战略对我们来说非常重要，我们对今天的合作关系感到非常兴奋，但我们正在考虑如何做得更多、更深入、扩大这些合作关系，让人们更容易以周到、隐私敏感的方式收集位置数据，然后以此为基础构建产品体验。
找一个和你互补的合伙人
自己开一家公司很难。你需要能够构建你的 API 产品并销售它。确保你有做这两件事的基因。
所以我的最后一个问题是关于新毕业生和其他想在 API 团队中担任产品管理角色的人。对他们有什么建议，或者在阅读材料方面，或者他们应该看什么？
Nick: 你知道，作为我们这一方的产品团队，有一件事我们一直在做(显然我们有出色的产品人员和出色的工程师)，他们都习惯于使用出色的开发工具，他们知道障碍在哪里——你用过 Stripe，你用过 Twilio。我们应该坚持同样的标准，并且知道这个标准是什么。并真正理解开发人员如何工作，他们如何运作，他们需要什么才能成功。或者他们的非技术同行，他们正在使用您基于这些构建块构建的数据集来消费体验。你必须使用工具，你必须知道障碍在哪里，并保持同样的标准。所以我认为开发伟大的开发者工具的第一手知识(有你可以遵循的模式)是超级重要的。如果你是产品经理，我认为确实如此。
我认为，如果你在谈论成为一名创始人，我会推荐的一件事是，在 Radar 之前，我曾致力于几个失败的创业想法，我是作为一名单独的创始人做到这一点的。真的很难，有人说做不到。除非你运气好，你的开源库像病毒一样传播，这是有可能的，否则你也必须能够销售和分发。所以，找一个和你互补的合伙人或共同创始人。我是技术联合创始人，负责产品和工程，我的联合创始人克比是在 Foursquare 认识的，负责销售和业务开发。他真的很擅长研磨、安排会议、推销 SaaS，我从他身上学到了很多，这给他带来了能量。产品、工程和商业方面的东西给了我能量。因此，找一个称赞你的共同创始人，这样你就能理解构建一个伟大的开发者工具需要什么，并真正地构建它，还要分发和销售它。至少对我个人来说，作为一名项目经理，这是我建立网络和建立联系的方式，这使我几年后开始使用雷达成为可能。
德里奇:这是一个非常好的观点，你必须既生产又销售。如果你只建造，那就是一个完整的公司，如果你只卖不建，那也不是一个完整的公司。
尼克:有时你建立了它，他们就会来，但我想说的是，更多的时候，这不是真的。所以你也要弄清楚。
德里奇:嗯。酷毙了。非常感谢尼克参加我们今天的播客，我期待着看到明年的雷达会是什么样子。
尼克:谢谢，德瑞克。我想是时候用 IPA 了。所以我会的，电话一结束。
德里奇:谢谢。祝你过得愉快，假期愉快。
尼克:对。同样的。"
大型企业中成功的 API 产品管理
Ep。9:克莱尔·巴雷特，APIsFirst 的主管
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是Claire Barrett,APIs first的主管，也是战略和技术变革方面的资深顾问。在我们的播客中，她确定了确保更大、更成熟的组织成功实现数字化转型的关键问题，并探讨了为什么数字化的成熟是关键，你应该如何始终以共同的业务目标为目标，以及为什么*衡的团队更可取。
莫里斯国际基金会的 CMO 拉里·埃布林格是今天的主持人。
Moesif · 9. Successful API Product Management in Large Enterprises
在上面的 SoundCloud 上听这一集，或者在苹果或谷歌上下载。
目录
- 1:00 IT 化多语言
- 4:40 项目对产品心态差异
- 8:24 数字化转型需要时间
- 11:45 数字精明是关键
- 14:53 项目规模 60-40 法则
- 18:24 你一半的资源都在顾问身上
- 21:36 找到利益相关者的共同目标
- 26:24 *衡的队伍表现更好
- 28:53 在 API 中与女性建立技能
拉里·埃布林格(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络第九集。我是拉里·埃布林格，今天的主持人，也是 Moesif 的首席营销官，API 可观测性*台。
和我一起的是 Claire Barrett，她是战略和技术变革方面的资深顾问，在国际咨询公司和金融机构任职多年，目前是 Mehdi Mejowie 的 APIsFirst 总监。Claire 还是科技界女性的积极倡导者和[全球 API 女性]的领导者。克莱尔，欢迎来到我们简陋的播客网。我们在哪里能找到你？
克莱尔·巴雷特(APIsFirst): 谢谢劳伦斯邀请我。我今天从英国加入你们。
拉里:太好了，我很了解它。
信息技术支持的多语言
IT 支持的变革通晓多种语言的人说的是战略、业务 IT、业务架构、项目管理、规模化敏捷实践、数字化转型、组织变革和沟通。所有这些都聚集在 API 空间中。
Larry: :首先，你为什么不与我们分享一下你成为 APIsFirst 总监和 APIs 全球女性领导者的历程，也许还能阐明一路上你的驱动力是什么。
Claire: :我的专业背景是 IT 领导和管理咨询，几乎总是与正在经历变革的大型、更复杂的成熟组织打交道。
我在一个军人家庭长大，所以我去过很多地方。在我的性格形成时期，我换了学校，邻居，国家，这意味着我在新的环境中总是很自在。我认为这更像是肾上腺素激增，而不是恐惧。因此，我总是被吸引去帮助人们和组织通过变革来管理和发展，并建立允许他们做出反应的技能、弹性和文化。
我也对这个世界充满了好奇。我把自己描述成一个信息技术驱动的变革的多语者，因为我说的是战略语言，是商业、商业架构、项目管理、规模化敏捷实践、数字化转型、组织变革和沟通的信息技术语言。所以对我来说，这些都在 API 空间中聚集在一起，我在 APIsFirst 的角色与我从澳大利亚回到欧洲的行动一致，我职业生涯的大部分时间都在那里度过。
我们帮助人们和组织实现 API 的全部潜力，通常作为更广泛的组织变革的一部分。加入 APIsFirst 的同时，我们也开始与团队一起围绕 API Days 会议和他们的全球女性参与 API 计划开展工作。我有幸领导了这个小组，它是关于建立人们在公共场合说话和写作的信心和技巧。
项目到产品思维模式的差异
项目管理是将事情分成可管理的小块，不断迭代，学习并朝着目标前进，而产品管理是产品生命周期的所有权，支持产品的愿景，并为创造商业价值寻找新的市场、渠道和商业机会。
拉里::太好了。非常多样化的背景，再次感谢你今天加入我们的播客网络。所以让我们来谈谈大型组织中的产品管理。在更高复杂性的成熟组织中，你如何定义产品管理，它与项目管理有什么不同？
克莱尔::这是一个很好的问题，很多人目前都在纠结或深入思考这个问题。也许我会从我如何定义项目管理开始，或者它是关于什么的，它的本质。
项目管理有三个关键点。它是关于实现特定发起人的愿景和目标，项目经理通常与发起人的梦想和愿景有着非常密切的情感联系。其次是关于可交付成果的所有权，以及关于跨技术、人员和技能集执行变更的运行过程。好的项目经理可以拥有可交付成果，并运行过程来执行，通常不管是哪个行业或基础技术或团队类型以及他们正在解决的问题。优秀的项目领导，他们越有经验，他们习惯推动的变革范围越广，他们就越有能力解决复杂的问题，不管项目试图实现什么。第三件事是关于他们如何组织和做他们的工作:计划工作和执行计划是一个典型的咒语。如今，这是关于将工作分成可管理的小块，不断迭代，学习并朝着目标前进。这些就是项目管理的一些主题。
产品管理将有一套不同的重要的事情，他们会排名。因为他们拥有产品生命周期的所有权，所以他们看得更长远，而不仅仅是看到项目和范围的结束。他们支持 API 意义上的产品愿景。而是寻找新的市场、新的渠道、新的商业机会来创造商业价值。其次，他们非常以客户为中心。现在，从 API 的角度来看，这些客户可能是其他组织中的其他开发人员，他们可能希望创建模型，或者他们可能专注于通过 API 进行数字化和自动化的产品。在那里，产品经理与客户和产品用户的情感联系更加紧密。对于 API 来说，这是其他系统用来激发团队的潜力。对于产品管理来说，第三件重要的事情是，他们所做的决策是基于数据和事实的证据元素。
项目经理和产品经理都有很强的商业敏锐性，他们需要能够管理和推动变革，他们需要能够推动事情向前发展和推动行动，他们需要影响和沟通非常庞大和多样化的利益相关者群体。他们都有将人们聚集在一起的角色，这些人可能不一定直接为他们工作，所以他们必须能够通过影响力来运作。
但我确实认为它们有不同的侧重点和联系。我不认为你可以仅仅重新定义一个在幕后看起来有点像项目经理的角色，因为他们只是擅长组织事情和完成事情，并将其重新标记为产品经理。我认为，你需要将产品经理视为与理解业务主题有着深刻联系的人——他们是所提供功能的深度业务主题专家，他们在 API 意义上的理解水*不一定是技术不可知论者，就像项目经理可能能够跨更多领域操作一样。
数字化转型需要时间
特别是在更大、更成熟的组织中，现有系统的现代化是关于通过尝试、学习和前进来建立技能和信心——类似于在游戏中升级每一步
拉里:我认为你说到点子上了。当有特别有说服力的时刻、分析或见解时，我总是喜欢在这些播客中慢下来。产品思维如何管理满足短期优先事项的挑战，同时进行更广泛的转型？或者，换句话说，你如何在飞机飞行时重新设计整架飞机？
Claire: :因此，我认为取得这些*衡对人们来说是一个真正的问题，特别是在那些努力简化、自动化和现代化其现有系统的大型成熟组织中，同时试图寻找新的机会，如果管理不善，这些机会可能会增加环境的复杂性。那么他们是如何做到“边走边嚼口香糖”的呢？
在这一领域取得最大成功的组织能够调整级别的大小，他们的架构师能够专注于特定的领域或特定的业务和技术领域，并拥有正确的组织结构和所有权。但这也很大程度上取决于他们如何投资和管理优先排序的能力。因此，当一个人从基于项目的变更转向更基于产品的思考时，随之而来的是将长期构建和运行能力视为长期贯穿产品生命周期的能力，这与传统项目时态中的时间限制和范围限制截然不同。这当然体现在运营支出与资本支出的对比上，也体现在常规业务与变化的对比上。因此，它可以深入到组织传统上如何看待变革的核心。为了能够回应。但是，如果你有正确的态度，他们可以做实验和培养能力，他们可以把事情分成足够小的块，而不是尝试和想得太快。
这很大程度上是关于建立技能和信心，尝试新事物并从中学习，然后继续前进，这就像在游戏中升级每一步。当你提升到十几岁和二十多岁的水*时，你就可以处理更多复杂的事情，处理来自不同地方的事情。而且奖品更大，你可以和不同的人合作，比你过去想象的要多。在早期，你需要建立管理变化的技能和肌肉。
数字知识是关键
向新市场提供外部 API 对人们来说感觉非常不同，因此赞助团队和产品所有权的数字知识是产品开发成功的关键
拉里::太好了。喜欢这个定义。这很大程度上是关于最初的缓慢移动，然后建立在你所说的肌肉和技能上，你已经随着时间的推移建立起来，以真正形成大规模的变化。为了让产品在大型组织中获得成功，需要利用哪些文化和行为杠杆，应该在哪些方面投资？
Claire: :所以，如果我们特别关注 API 产品，它们确实需要一种不同于作为集成组件的 API 的思维方式。许多人可以很快理解，将 API 视为在系统之间提供挂钩以及在外部团体和组织之间提供挂钩的更好、更简单的方法并不困难。
下一步要考虑的是如何将外部化的 API 作为产品提供给尚不存在的新渠道和新市场，而不是重新设计或提供新体验，这是以新的方式向人们感觉非常不同的新市场提供产品。因此，数字知识是赞助团队的事，产品所有权是关键。有合适的适合目的的治理来支撑和支持那些 API 产品和他们周围的团队。因此，围绕安全性、可用性和数据管理的最低标准和期望非常清晰易懂。
另一方面，正如我们之前谈到的，这个项目到产品的思维模式，以及被组织中多个不同的利益相关者理解是关键。因此，这是关于建立这种能力，找到早期会产生共鸣的地方，并讲述一个可以被人们接受的故事。
那么，什么是特别的机会呢？在早期，这种机会可能不会像你提升了很多次后那么深远，那么你就可以探索更进步的工作方式。但是，到那时，你已经建立了一种势头，你已经有了工程信心，你已经有了可扩展性信心，性能信心，安全性，财务，资金安排，那些需要到位的能力。
项目规模的 60-40 法则
在数字化转型中，已经发现在较高复杂性的组织中，60%的工作投入到具有重大长期影响的项目中，而 40%的工作投入到易实现的变革中，而在较低复杂性的组织中，这一比例正好相反
拉里::是的，我在我们的客户群中完全看到了这一点。你说的实现改变粘性是什么意思，人们可以从你的研究发现中得到什么？我应该说，我是从你在 LinkedIn 上关于这个话题的精彩文章中得到这个问题的灵感的。
克莱尔::谢谢你劳伦斯。就 IT 支持的变革领导者而言，转型变革粘性一直是我的兴趣所在，因此，这些是精通技术的业务领导者、首席技术官、首席信息官、通过转型变革支持组织的顾问和经验丰富的技术专家，他们鼓励或做出的一些权衡是什么，使他们能够在建造和维修飞机的同时驾驶飞机？这些发现很有趣，而且实际上根据组织的复杂程度和规模而有所不同。
因此，有一种认识是，如果你正在推动巨大的变化，并且你正在通过 it 支持的变化镜头来看待它，那么你可能会或多或少地变得有效，这取决于你想把你的努力放在哪里，因为总有更多的事情你可以做，而不是你有足够的资源、团队、技能、资金来追求。那么你怎么选择做什么，你怎么选择以后做什么，或者不做什么？
例如，在更高复杂性的组织中，他们会将 60%的精力放在引起对正在发生的变化的关注上，他们将 60%的精力放在正在进行的新事物的大型符号上。相比之下，他们花了 40%的精力来实现我所说的那种低挂水果块的变化，所以这些事情将表明有一些变化正在发生，但它们可能不会产生真正、真正大的长期影响。而在复杂性较低的组织中，这种分裂则正好相反——实际上更像是他们会将 65%的精力放在有意义的事情上，放在唾手可得的成果或已经存在了一段时间的问题上，通过解决这些问题，他们将获得与他们的运营密切相关的员工和客户的信任和信心，然后支持一些更大的变革象征。
如此巨大的变革象征可能是围绕着一种不同的可扩展的敏捷安排的重大重组。这可能是语言的变化，例如，我听说过将一个非英语组织的国际语言变成英语。所以有些东西让人们坐起来听。
你一半的资源都在顾问身上
鉴于 API 领域的人才争夺战，几乎 50%的公司数字化转型人才来自外部顾问
Claire: :我问人们的另一个问题是，我认为它与 API 领域非常相关，在寻找 API 产品经理方面，目前存在一场大规模的人才大战，人们会在内部培养技能和能力方面投入精力和投资，可能需要更长的时间来招聘、保留和培养新的能力，这将推动他们的转型，而他们会付出什么努力来让外部人员帮助他们快速起步。此外，无论组织或行业的规模如何，他们都有超过 50%,大约 55%的精力用于内部能力建设，而将*一半(45%)的精力用于外部支持。因此，这两个选项都是合理的选择，但外部顾问都认识到组织建立内部能力的重要性，他们也认识到试图在内部建立技能的人需要能够从外部获得支持。
拉里::太棒了。我从来没有想过，建设内部能力和从外部引进能力的比例是 50/50。
Claire: :是的，只是为了获得资格，他们会将 55%的精力放在建立内部能力上，而他们会将 45%的精力放在从外部获得帮助上，以推动数字化变革。因此，人们认识到他们需要内部的长期能力，只是他们不一定有时间，他们目前没有时间，这将需要在内部建立这种能力，要么用新的数字能力重新培训现有的人，要么找到并招募这些人，他们需要外部支持，让他们领先一步。强烈期望该角色是指导和支持该功能的开发，而不是长期依赖第三方，依赖 API 空间这样的核心和基础。例如，如果你已经有了为你构建嵌入式商业模式的 API 产品，并且你把它看作是你未来的一部分，并且支持它的人拥有你长期想要的能力，那么你不把它看作是你需要外包的东西。
寻找利益相关者的共同目标
为了确保持久的变化，确定不同 API 利益相关者之间的共同目标:赞助商、变形金刚和技术专家
拉里::对。事实上，这是非常热门的话题。我们在 HealthTech 有许多新客户，有趣的是，客户越早进入，就越有可能让外部顾问帮助他们符合 HIPAA 和 HITECH 标准。但是，当与医疗技术领域的大型组织打交道时，这些组织已经有了成熟的产品，并且在这条道路上走得更远，实际上他们所有的专业知识都是内部建立和开发的。因此，我们在今天的市场上确实看到了这一点。你提出的 API 利益相关者模型是如何工作的，在这个模型中，赞助商、变革者和技术专家相互作用以执行持久的变革？
Claire: :我们使用的描述是，如果你愿意，这三个不同的社区，在今天许多正在经历转型变革的组织中，并不是组织层级的分裂。更多的是这些长者之间的角色，组织的赞助者希望实现他们承诺的战略，并希望尽快实现。不可避免地，虽然 API 可能不会在这些策略中被调用，但它们肯定是固有的，能够更快地移动，能够探索和参与新的生态系统和新类型的模型和市场。这就是长老们。变形金刚或探险者是在外面寻找新机会的人。他们可能已经将某种 API 作为产品基础，或者他们可能专注于数字化现有体验或重新想象客户旅程。第三类是技术专家，他们是 IT 领域的导航者，是工具、架构和推动者，其中 API 无疑是核心。
这些团队面临的挑战之一是，不要让他们背对着彼此站着，试图对着风大喊，而是从共享的歌单中唱歌，并在团队之间的空白空间中找到协同作用。它们确实经常有不同的起点，都正确且恰当地致力于推动这种更广泛的变化，但不一定围绕相同的优先事项。因此，所有人都专注于与他们的职能最接*的事情，这些事情将对组织产生更广泛的影响。但是这可能会在首先要做的事情之间产生矛盾。所以找到共享的 API 目标非常关键。在较低的级别，就其目标和范围机会而言，这可能相对较小，但随着组织级别的提高，这可能会跨越所有三个级别。
因此，在早期，可能只有两个团队会致力于诸如 API 之类的东西，以使流程更快地数字化。IT 团队为此开发工具，确保这些工具在内部是安全和自助的。这可能会对其他赞助商产生更广泛的影响。但接下来变形金刚可能会寻求在赞助社区的长者中引发更多的变化，开始以不同的方式思考。IT 团队实际上可能能够提供以前不存在的新的思考方式。为这三方合作创建合适的结构可以是围绕一个产品，也可以是围绕一个项目，以便为产品提供信息，对我来说，这是在每个层面都产生快速影响的秘诀之一。
*衡的团队表现更好
在性别、种族、文化、年龄、取向和能力方面更加*衡的团队比同质的团队更有创造力，也更成功
拉里::这三个不同的、非常重要的群体之间有着令人着迷的区别。所以稍微改变一下话题，转到我最关心的话题，因为我有两个女儿。请与我们分享您作为 API 社区女性领导者的经历。更好的工作场所*衡和包容对产品团队有什么好处？
Claire: :因此，人们自然希望产品团队富有创造力，反应灵敏，不仅仅考虑技术产品机会，还要考虑他们的社区和用户群的感受和情绪。因此，团队中更大的*衡自然会创造一种看待问题的更多样化的方式。你知道*衡不仅仅是性别，还包括种族、文化、年龄、取向和能力。所有这些因素将使人们能够想出更有创意、反应更灵敏的产品。
另一个关键的事情是，如果人们感到被包容，他们会更加投入，会把整个自我带到工作中，变得更加有联系。因此，包容性在提高员工参与度方面回报巨大。我个人认为，多样化的团队更能适应变化，因为人们对他人和他人的想法更开放，因此他们往往对外部环境更敏感。当然，研究表明，领导团队和董事会更加*衡的组织将更成功地应对变革。这再真实不过了。
培养女性在 API 方面的技能
全球女性参与 APIs 计划的项目通过提高公众演讲和写作技能来帮助人们建立自信
拉里::没错，说得很对，也很有说服力，尤其是在硅谷，这里的科技工作场所需要更多的包容性和多样性。因此，在这个问题上，作为 API 社区的女性领导者，你建议收听本播客的代表们可以做些什么来帮助他们的职业发展，特别是可以提供哪些项目。
克莱尔::我们开展项目来帮助人们建立自信和在公共领域说话和写作的技能。因此，我们强烈地感觉到，能够展示团队、同事和自己才能的人正在创造机会，不仅在外部，而且在内部得到认可。我们认为，当人们通过谈论他们和他们的团队正在做的事情以及这些事情如何产生影响来建立信心时，这将鼓励可能代表较少的其他团队成员站出来做出贡献。
我们通过运行允许人们在安全的空间中实践的程序来支持他们的职业生涯。例如，申请在会议上发言，我们在会议参与之前、期间和之后为他们提供辅导和支持，现在越来越多地在公共领域以书面形式提供。我们提供网络活动，我们支持 APIs 社区中的女性形象，我应该说，这是相当广泛的。去年，我们的会员增加了 150%。我们提供了五个项目。我们的成员现在来自超过 23 个国家和超过 85 个不同的组织，而且成员人数每天都在增加。
成员来自拥有 API 架构角色的大型组织，他们来自 API 管理系统供应商，他们来自初创公司，他们来自 API 领域的自由职业者，技术作家，UX。这是一个非常广泛的群体，在我们的成员中有男性、女性和非二进制的人。这是一种奇妙的方式，特别是对于那些在我们所处的这个疫情世界中不太联系的人来说，通过一种虚拟的形式来提供联系。对于世界各地的人们来说，这提供了一种真正重要的感觉，那就是成为比一个人更大的事物的一部分。
拉里::太棒了。人们应该去网上什么地方找到更多关于你的优秀项目的信息？
Claire: :所以 API 中的女性在 APIDays 的倡议页面。你可以在那里加入并了解这些项目。如果你想直接联系我，可以在 LinkedIn ，{:target = " _ blank " rel = " noo pener " }上联系我。关于 API 产品管理，作为 API Collective 的全球 API 专家团队的一员，我们将从 3 月 23 日开始实施 API 训练营计划，更多详情请参见 API Collective 的培训页面。
拉里:太棒了。嗯，我们完成了一个非常有指导意义和有帮助的笔记，提供了几个促进个人职业生涯的伟大链接。非常感谢 Claire 今天抽出时间讨论如此有趣和重要的话题。我们祝你一切顺利，并保持安全。
克莱尔::谢谢你劳伦斯。非常高兴您能来这里，我期待着 Moesif 继续取得成功。
拉里::太好了。谢谢您们。
克莱尔::谢谢
支持 1000 万开发者
原文：https://www.moesif.com/blog/podcasts/developers/Podcast-Supporting-10-Million-Developers/
Ep。13: Phil Nash，Twilio 的开发者福音传道者。
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是 Phil Nash，Twilio 的首席开发者传道者，Google 开发者专家，Twitch 的 Live Coders 团队成员。他经常在会议上发言，有时会在台上写代码，希望一切正常。
莫西夫的首席执行官德里克·吉林是今天的主持人。
Moesif · 13. Supporting 10 Million Developers
在 SoundCloud 上听这一集，在我们的 YouTube 频道上观看，或者在苹果或谷歌上下载。
目录
- 1:00 开发者福音随着成长而发展
- 3:40 Twilio 通过收购扩大规模
- 6:55 语言因产品而异
- 8:38 制定原料药标准
- 12:17 OpenAPI 辅助库创建
- 14:19 开发者想要 CLI
- 18:00 为本地开发提供无服务器*台
- 21:50 客户和开发者*台分享最佳实践
- 25:18 分段数据确保 API 隐私
- 27:20 开发者首先等于开发者同理心
- 30:19 配套开发商需要社区建设
- 35:25 远程访问使会议多样化
- 38:04 API 成功比以往更加困难
德里奇·吉林(Moesif): 欢迎来到 Moesif 的播客网络 APIs over IPAs 的另一集。我们为 API 产品经理和其他 API 专业人员提供分析。今天和我一起的是来自 Twilio 的 Phil Nash。他是 API-first 先锋公司最早的开发人员体验专家之一。Twilio 专注于通信短信，现在正在进军视频和许多其他领域。非常高兴你能来，菲尔。
菲尔·纳什(特维利奥):很高兴来到这里。谢谢你的邀请。我想指出的是，我是 Twilio 最早的开发人员体验专家之一，但我是在 2014 年加入的，我们从 2008 年就开始了。一些最早的雇员是福音传道团队的成员，我可以在他们前六年所做的大量工作的基础上再接再厉。很高兴成为团队的一员，继续他们的工作。
开发者福音随着成长而发展
随着你的产品越来越成功，你如何支持开发者？Twilio 将最初的福音团队一分为二:教育和文档，以大规模处理开发人员。
德里奇:我很想听到更多关于这个故事的内容。当你加入 Twilio 时，他们只有几百人，组建了开发人员福音团队，现在 Twilio 已经有 4500 人了。
菲尔·纳什(特维利奥):差不多就是这样。我想我们最*可能刚刚发布了更大的数字，但我们现在将坚持 4500。我们现在只是不断收购公司，而且这个数字还在快速上升。这真是一次不可思议的旅程。我加入 Twilio 的时候，2014 年公司大概有 300 人。
那是我当时工作过的最大的公司，对我来说这是一件奇怪的事情。我已经从一个从来没有超过 50 人的公司变成了一个 300 人的公司。对我来说这是个很大的地方。现在它成千上万，有时令人不知所措。这对我很好，因为我最初在伦敦办公室工作，现在我在澳大利亚。总是卫星队的一部分，只是对我来说总是感觉有点小，有点像家人。令人难以置信的是，我身后有一台巨大的机器在工作，生产我们所做的产品。
当我加入福音团队时，它正处于实际上分成两个团队的过程中，这是我们建立我们现在称为开发人员网络团队的旅程的开始。它涵盖了 Twilio 开发人员体验和 Twilio 社区体验的方方面面。当时，我们正在考虑如何组建我们的开发人员培训团队，这是一个专注于文档、文档*台以及将这类事情融入我们可以专注的实践的团队。我认为，在过去的七年里，Twilio 的建设，当然还有 Twilio 的体验，已经成为越来越多关注的焦点。就像我说的，我们已经脱离了最初的传道团队，然后有两个人从那里分裂出来，成立了教育团队，并建立了 docs *台。从那以后，他们开发了一款游戏 TwilioQuest。你看到了吗？
德里奇:我不这么认为，但听起来很有趣，我得去核实一下。
Twilio 通过收购扩大规模
为了在成长过程中更好地服务客户群，Twilio 继续通过收购增加更多产品。在一定规模下，Twilio 需要开发比他们内部处理能力更多的产品，这导致他们收购 Segment 或 SendGrid 等公司，以向客户提供更多功能。
菲尔:好的，请吧。我们很快就要发布一个新奇的新版本了。这是一个游戏，一个完整的 2D 自上而下的 RPG 冒险，它还教你如何编码和如何使用 Twilio API，以及目前其他编程语言的介绍。我们正在努力，现在也有可能建立你自己的关卡，所以我们希望看到更多的东西出来。我们已经建立了这一点，然后我们有一个更侧重于社区的团队，这种团队一直在处理社交之类的事情。现在它专注于论坛，冠军计划和类似的事情。与此同时，福音团队继续尝试去开发人员所在的世界或他们在线的地方。更有可能是在过去的 18 个月里，为了把 Twilio 的话带给他们，同时也把那段经历带回来。
同时，我们也生产了大量的产品。当我开始的时候，有语音和短信。你可以通过浏览器和设备上的移动应用打电话。从那以后，我们增加了聊天、视频和其他各种各样的附加内容，使得知识传播得相当薄。然后，当然，引入了其他公司。所以我们引入了 Auth0，增加了双因素认证和验证。我们最*引入了 SendGrid，然后是 Segment，我仍在跟进。我还不知道如何使用 Segment，但我会明白的。SendGrid 越来越好；当你一天要处理这么多邮件时，邮件发送能力并不像你想象的那么容易。所以是的，有很多这样的事情。我认为好的方面是产品，Twilio 的一切始终以开发者为先。这使我们能够一路支持和帮助开发人员，从七年前一直到今天。
德里奇:你提到收购所有这些不同的公司，这很有趣。我们是 SendGrids 的客户，我们是 Twilio 的客户，为我们的一些学习功能提供支持，我们是细分市场的合作伙伴，因此这确实与 Twilio 有着密切的联系。
菲尔:看起来是这样，我想这就是我们正在努力做的。我们注意到这些东西很好地组合在一起。我认为 SendGrid 很明显是一个我们没有的通信渠道，让 SendGrid 参与进来就是选择了市场上最好的公司。它这样做是为了成为 Twilio 的一部分。细分市场可能看起来有点奇怪，但归根结底，在所有沟通事物的背后是客户旅程和客户数据，你希望展示你与人沟通的方式。我认为这是一个令人兴奋的功能，因为所有这些都联系在一起。
语言因产品而异
如果没有适当的文档和解释,“API”这个术语可能会让人觉得是个时髦的词。Twilio 的信息汇集在一起，因为他们将产品放在同一个屋檐下。
德里奇:这让开发者福音传道成为了一个挑战吗？从仅仅谈论 SMS 和如何发送消息，相对于 SendGrid 和所有这些关于向开发者营销的不同方式。这是一个共同的过程或共同的语言吗？还是每个产品或每个领域都不同？
菲尔:这是个好问题。我认为在电梯推销中变得越来越困难，以前你可以说，“你可以发送或接收短信，拨打或接听电话。去试试吧，这是一个 API 去吧！”现在这是一个广阔的领域，你需要更长的电梯来运送这些东西。
这很难说，营销团队的费用和传播信息也是其中很重要的一部分。另一方面，我们仍在努力整合其中的一些采购。在很大程度上，Segment 会继续照顾自己，继续传递自己的信息，并与人们接触。所以现在这很容易。我们将在 10 月份的大会 Signal 上关注这些信息是如何整合在一起的，这将非常有趣，因为在那时，这是一个屋檐下的所有内容。我想我们会在那里看到一些有趣的东西。据我所知，我现在没什么可透露的。
使 API 成为标准
Twilio 如何让开发者的生活更轻松？Twilio 的开发人员体验和关系团队专注于确保 API 是标准的，并且在整个业务中具有一致的质量。
我希望听到更多关于你如何构建开发者关系的信息。如今，我们有很多不同的角色:开发者倡导者、开发者体验、开发者关系本身。这在 Twilio 是如何获得的？在职责方面，你看到哪些工作做得很好？
菲尔:这是个好问题，我会坦白告诉你。让我们退一步回到开发者体验。我认为开发者体验对所有 Twilio 都很重要，对吗？如果 API 团队没有为开发人员生产出优秀的产品，那么一切都要靠它了。其他的一切都变成了在那之上的层，让开发者的生活变得更好，更容易。有一个不属于开发者关系团队的开发者体验团队。这就是我们所说的团队，他们专注于确保这些 API 确实是标准的，并且在整个业务中具有一致的质量，现在有这么多部分。就像我说的，在开发人员关系方面，我们有一个开发网络团队，负责福音传道。这是为了社区和开发者，教育，建立 docs *台和 TwilioQuest 游戏。社区正在照看论坛。在那里，我们还有一个相对较新的企业福音团队。
我们正在将定期布道和社区活动的策略和实践推广到更大的企业。企业，有效地带领他们通过黑客马拉松，创新会议，并给这些企业与他们的开发者分享问题的机会，希望通信和 joy *台可以帮助解决。手头有 Twilio 专家。让他们坚持一两天，尝试建立他们自己的解决方案，解决他们自己的问题。我们发现，在企业内部，开发人员可能不会经常有机会做出决策。但是当你在一个很紧的期限内把一个问题摆在他们面前，在一个小团队中解决这个问题，开发人员有很好的时间来构建和发现这个问题，即使这是他们第一次使用 API。
这就是我们的企业福音团队所做的，它把 Twilio 带到那些公司。就像我说的，这种体验与社区中的常规体验是一样的，但看到企业体验让那些开发人员更加开心，这太棒了。我们还有什么？创业团队也是如此，这肯定会促进那些更新更小的公司，团队中的每个人，公司中的每个人都可能是开发者，或者至少是建设者。有人想在这个世界上生产一些东西，支持，一点点资金，一些信贷进入 Twilio 创业计划，有点帮助他们起步，这很好。这里有很多部分。
OpenAPI 帮助创建库
在 OpenAPI 规范库生成器出现之前，Twilio 根据自己的规范编写库，这是一项乏味的工作。
我一直在谈论和研究 Twilio CLI。比如说。作为一个项目，它本身来自开发人员培训团队，因此，与文档一起工作的团队。我们就像，“我们认为我们也应该有这个”。我认为，现在已经被一个开发者体验团队接管了，这很好。有趣的是，这些项目中的一些是人们希望它们存在于世界上的产物。然后把它转变成我们称之为 GA 或普遍可用的东西，这是一个不同的问题，遗憾的是，它不仅仅是 NPM 模块上的版本。当你不能处理它的时候，那里有开发人员体验团队和开发人员接口团队，他们处理所有的助手库和其他类似的东西。
助手库本身是由一个查看我们的规范的程序编写的，所以开发人员接口团队处理它的边缘部分，以及输出它的程序。我认为在 OpenAPI 规范库生成器出现之前，我们坐下来根据自己的规范编写。它也有自己有趣的事情要处理，它是一个编写我们所有库的大型 Python 程序。如果你想改变 javascript 库，这可能是一件痛苦的事情，为了修复它，你必须改变为 Python 编写 javascript。但在大多数情况下，它不再需要那么多的修复，它只是生成东西，这很好。有很多细节，很多事情都在进行中，特别关注这方面的体验。随着我们找到其他关注点，这种结构还在不断增长。
开发人员需要 CLI
命令行界面(CLI)本身是开发人员培训团队的一个愿望。Twilio 的 CLI 旨在帮助客户与 Twilio 帐户互动，而不仅仅是通过控制台中的 UI。
德里奇:那么，创建 CLI 的动机是什么，你如何衡量它的体验？我的意思是，它不像一个 web 应用程序，你可以只安装振幅或其他东西。
Phil: 没错，就像我说的，CLI 本身是开发人员培训团队的愿望。我认为作为开发人员，我们不一定喜欢经常离开键盘，给人们一个与 Twilio 帐户交互的选项，而不仅仅是通过控制台中的 UI，这是计划之一。此外，您可以将这个 CLI 作为构建过程或构建管道的一部分。这是他们想要解决的两件事。他们建立了它，他们获得反馈的一些早期方法实际上是在我们的信号会议上，比如说 2018 年，我们会让人们离开，并与他们进行适当的用户体验测试会议。比如让他们坐在早期版本的 CLI 键盘前，然后问“试试用它来实现这个吧，你是怎么做到的？”。这对于早期学习非常有帮助，但是之后如何衡量 CLI 的使用情况呢？这很难，你是对的，你不能就这么把分析搞砸了。尽管如此，我认为我们正在努力。
最糟糕的是，CLI 现在是以 NPM 模块和包的形式发布在 Homebrew 上的。我们正在尝试添加更多的打包选项，这样你就不需要安装 Node 就可以在大多数系统上运行它，我们马上就要做到这一点。NPM 装置是一种生硬的工具，用来询问人们是否在使用？人们参与其中了吗？接下来，我们正在研究如何为使用它的人工作，所以我们不得不为我们的助手库重新安排我们的用户代理字符串，所以它们都报告了更多关于它们在哪里被使用的信息。我们认为这将非常有用，因为最终 CLI 将使用节点包，但并非所有来自节点包的调用都明显来自 CLI，有很多人已经在其他地方安装了 Twilio 节点包。因此，找出哪些是从哪里来的，如果使用越来越多，这将是非常有趣的，但我们还没有完全实现这一点。
在此之上，我们还有一些层，CLI 的插件，其中一些调用 API，一些不需要。能够判断调用是否不仅来自 CLI，也不是来自节点，而是来自 CLI 之上的插件也将是其中的一部分。衡量这一点正在进行，但我们从我们的用户访谈和与客户的交谈中明确知道，人们正在使用它，并将其用于各种事情，所以我们知道它至少是有用的。我们对此很满意。就我个人而言，我自己通常不做 CLI 的核心，而是做一个更大的插件，这是我们的无服务器插件，我们喜欢称之为无服务器工具包。
为本地开发提供无服务器*台
发展实际上发生在哪里？客户希望在他们自己的计算机上开发，而不是通过隧道和 ngrok，这要求 Twilio 创建一个轻量级的无服务器*台。
再退一步，我们在 Twilio 上发布的东西之一也是一个轻量级的无服务器*台，比如 Twilio 函数和 Twilio 资产。它允许人们在我们的基础设施中托管 javascript 和静态资产，并通过功能使用它们。javascript 可以像 AWS Lambda 那样被调用。我们认为这是一件好事，因为这是另一个开发者体验的事情，在使用 web hooks 时，虽然可能是处理实时交互的最简单的方法，例如打电话，但当你开始开发时，你想在自己的计算机上完成它，突然它变得很难。
我们一直在推动，像隧道的事情和 ngrok 给我们作为其中的一部分，使之更容易。即使这样，人们仍然觉得很难，所以我们决定如果你只是写 javascript，在 Twilio 控制台中写一些东西，并让它处理你传入的 web 挂钩，那会更容易。人们当然想这么做，但是你会发现人们想把它变成一个更注重发展的事情。我们的第一个版本实际上是一个文本框，在控制台内有一点语法高亮和验证。您希望能够对其进行源代码控制，而不只是在每次保存重新部署的内容时进行源代码控制，然后设置其他部署。
我们建立了第二个版本，它有一个 API。与此同时，我和我的一个同事 Dominic Kendall 一直在开发各种不同的工具。Dominic 开发了一个叫 Twilio Run 的工具，它允许你在本地模拟函数环境。因此，我们已经从“我们需要这个远程环境，您可以在控制台上使用”发展到“但我想用它开发我自己的笔记本电脑”，所以他为此构建了这个节点包装器。他创建了这个，但是我从来不记得如何创建一个项目来使用它，所以我为它创建了一个项目生成器，这是它的前两个部分。然后无服务器团队添加了一个 API。因此，我们添加了一个 API 集，Twilio run 能够部署它，然后我们将它打包成一个 Twilio 插件，一个 Twilio CLI 插件。
在那之后，就像我说的，所有这些都变成了人们现在在做什么，人们想去哪里，因为我们正在为它建造小工具。我认为我们确实可以改善这种体验。再一次，我期待着从这些 API 调用的来源获得更多的数据，以了解这些 API 调用被使用了多少。我知道我们的一些客户肯定在使用这些东西，特别是无服务器插件，我有时不得不支持他们。几个月前，我们发现了一个有趣的 bug，这个 bug 是基于我们现在认为是发生在我们的一个依赖项中的重大变化，但不是在给我们带来一些问题的主要版本中。语义版各位，这是个很棒的东西。支持那些被这个 bug 引起问题的团队意味着我肯定知道人们在使用这个，看到这个很令人兴奋。看到更多的数据也将是令人兴奋的。
客户和开发者*台分享最佳实践
您如何确保 SDK 的健壮性和可跟踪性？Twilio 将 CLI 交给了一个团队，该团队致力于根据客户反馈改善客户体验。
当然，我很高兴你提出了用户代理字符串的概念，这个概念对于跟踪所有使用这些 API 和 get 的不同 SDK 和插件都很重要。您谈到了 CLI 之上的多个不同层。人们可以在不同的事情上对 SDK 做什么，使用这些 API 来获得正确的指标，并确保他们能够找出是否有错误？有时它可能是一个单一的 SDK 或一个你以前从未见过的奇怪用例。
菲尔:不太清楚你这个问题的意思。
Derric: 就最佳实践而言，客户或开发人员*台还能做些什么来确保 SDK 的健壮性和可跟踪性呢？
菲尔:好的，我明白了。这个问题问得好。如你所说，如果你有一个 web 应用程序，你可以在里面放一些错误跟踪之类的东西。我不认为我们有这样的东西，我们不会用 CLI 呼叫总部，除了实际的 API 调用。这并不是说我们将来可能不会这样做。那种事情很有趣。但我认为，如果出现错误，如果出了问题，那么这个东西会在终端上堆栈跟踪。我不确定这是一件坏事，当你考虑它时，产品是为开发人员准备的，CLI 是为开发人员准备的，看到堆栈跟踪希望是可以理解的。我们鼓励您在回购中提出这一问题。
开发人员在很大程度上非常愿意提出问题，告诉你问题出在哪里，有时几乎太愿意了。我认为，当我们将 CLI 交给一个致力于此并致力于改进此类事情的团队时，看看我们将如何发展会很有趣。
我总是对更多跟踪之类的想法保持警惕。如果在某些 CLI 中，您必须传递一个标志或命令才能关闭数据共享，并且如果您不知道该命令或标志，您可能已经在不知情的情况下共享了它的使用，这可能会侵犯隐私。我不太喜欢这种追踪。我喜欢用户代理的东西，因为知道东西从哪里来是一件好事，但除此之外，就像关注使用一样，我认为在制造更好的产品和侵犯他人的工作、隐私和数据之间有一条线。我不希望看到更多这样的跟踪，我宁愿它是选择加入，而不是选择退出。我们会看到的。
分割数据以确保 API 隐私
如何对 API 保持隐私意识？Twilio 就哪些数据适合各种渠道提出了建议，并就客户数据在 Twilio 中的存储方式提供了保护，以确保符合 HIPAA 和 GDPR 标准。
当涉及到跟踪 API 调用或记录 API 调用时，你会做些什么来保护隐私吗？小心您的客户数据，我相信其中一些数据是非常敏感的。
菲尔:哦，当然。这是企业与其客户之间的通信数据。
我们有关于哪些数据应该和不应该发送到各种渠道的建议，当然，你不需要输入你的信用卡号码。这不是个好主意。在 Twilio 内部，我们对这些数据的保存和事后查看方式有很强的保护。该业务的许多部分现在都符合 HIPAA，而且有大量工作要处理 GDPR 法规遵从性，这在当时对公司来说是一个巨大的提升。我认为这里最重要的事情之一是，我们对此以及我们如何尽可能地保护数据持开放态度。
以至于它是我们 API 定义的一部分，并生成到我们的文档中，以说明资源上的哪些属性被视为个人可识别信息，以及我们打算保留这些信息多长时间。什么时候到期，什么时候退出系统，这些都在文件里。当你浏览这些东西时，一切都触手可及。我认为这真的很重要，任何通过 CLI 的东西也只是调用这些 API 端点。据我所知，这是集中处理的。
开发者第一等于开发者同理心
如果你是“开发者第一”，你如何确保成功的客户体验？当开发人员是你的主要客户群时，对他们的需求感同身受是开发人员入职和客户保持的必要条件。
毫无疑问，退一步来讨论更多关于开发者体验的问题。在 Twilio，开发人员同理心是什么意思？在不同的职能部门中，它是如何使用的，或者你是如何看待它的？无论是开发者体验团队，还是作为开发者关系团队，等等。
菲尔:是的，我的意思是，我一开始就说过，Twilio 的一切都以开发者为中心，因为他们是第一批客户。我们在 Twilio 有一系列公司价值观，也有来自一家小公司的公司价值观。在我加入之前，我从未见过 Twilio 他们有一个公司价值观的清单，其中之一就是穿客户的鞋。这对我们来说非常重要，因为这不仅仅是以开发人员为中心，当然，这也是对我们所有客户的同情。包括这样一个事实，越来越多的非开发人员注册了 Twilio 账户，并试图了解他们可以用一个他们认为对交流非常有用的*台做些什么。对非开发人员角色感同身受也非常重要。但是对开发人员的同情很大程度上是我们作为开发人员处理产品的方式，我们自己尝试并使用它。我觉得真的很重要，很有用。
我认为，拥有这种开发者网络的企业，即开发者关系团队，并不致力于核心产品本身，而是倾向于或可以像产品的第一批用户一样，成为公司内部开发者的声音，至少是外部开发者的声音。因为我们不知道它是如何制造的，我们只想听到我们正在打造一个很酷的新产品，我们想听到那种体验，并自己使用它。大量的反馈，我们可以像这样给出早期的反馈。同时，它也来自上层。
首席执行官杰夫·劳森仍然是一名开发人员。他不再为 Twilio 写产品代码了，至少据我所知没有。但是他总是在建造。我想去年他一直在制作，我想，zoom cube。这是一套完全不同的按钮，你可以按下这些按钮，让视频聊天中发生不同的事情；10 年分分合合，静音，还有一个大按键挂那种东西。很高兴看到他正在寻找时间继续做一名开发人员和建设者，这也渗透到了公司的其他部门。
支持开发者需要社区建设
Twilio 如何支持其众多不同经验水*的开发人员？通过与他们的市民和专业开发人员社区合作，Twilio 能够共享信息，帮助开发人员创建更好的应用程序。
Derric: 这是一个很有意思的观点，它同时涉及到支持客户和开发人员，以及戴着他们的帽子或穿着他们的鞋子。现在的开发者不是单一的角色，对吗？我们有些人是专业的开发人员，也有些人是第一次学习编码或者使用无编码解决方案。你如何同时支持所有这些不同的开发者？
菲尔:这越来越难做到了，你说得对。我们有一系列的开发者正在使用或试图使用这个*台。实际上，我们正努力从根本上支持这一点。我之前提到过 TwilioQuest，很多 TwilioQuest 团队正在努力增加更多如何开发内容的早期阶段。我相信会有一个关于 API 的课程，不是特别是 Twilio API，而是像什么是 API 以及如何使用 API 这样的新课程。我们正试图让 TwilioQuest 进入美国的大学，试图帮助和教授编程新手。我们需要了解这一点，因为这是一项非常有用的技能，几乎适用于当今的任何角色，所以我们正在从这一点着手。在过去的几年中，我们也做了大量的工作来制作和测试可用的应用程序，人们可以在不知道代码是什么的情况下构建并安装到他们的 Twilio 帐户中。虽然，它背后有一种代码，这就是我们所说的 Twilio 代码交换。
代码交换本身是一个示例项目，其中还有快速部署应用程序。就像你点击一个按钮，填写一些细节，你现在就有了一个可以使用的 Twilio 应用程序。我们最*发布了一些关于疫苗犹豫的通知和信息。像往常一样，Twilio 有一个计划，试图在疫情期间帮助尽可能多的人接种疫苗。我们有这方面的示例，但我们也有简单的一键语音邮件。那些一次点击和即时应用程序，快速部署应用程序，它们是为我们所说的公民开发人员而存在的，这些人不一定是专业开发人员，但希望有所成就。
代码也在它的后面，如果你部署了它，你想改变它，你可以找一个开发人员来更新它。你提到了低代码工具，我认为 Twilio Studio 就是这种低代码工具。为了做一些事情，拖放界面中的一些小部件可以调用 Twilio 函数或者发送 HTTP 请求。
但是，就像能够以拖放的方式建立一个完整的沟通流程一样，这对于解放产品经理和客户方面的其他事情来说是非常好的，可以实现很多目标，甚至不仅仅是基础，而是在必须让开发人员参与之前的很多沟通流程。这真的很有用，因为作为开发人员，我们不希望一遍又一遍地做同样的事情，所以能够构建这些系统中有趣的部分，我认为也非常好。我们也非常乐意支持专业开发人员。他们想要 API 参考，他们想要库，他们也想自己去做，这很令人兴奋。我认为这也是我们现在更加关注社区团队的地方。我们有论坛和测试版，认为 Twilio 是一个十三、四岁的公司，还没有真正的社区论坛，至少一直没有第一方论坛，这有点奇怪。
我认为我们还没有一个不同的时间，但我们将重新关注这一点，以便人们可以领导，走到一起，互相帮助，从 Twilio 的人们那里获得一点帮助，然后我们也将这一点带出去。你很少会发现，或者我打算很少会发现，堆栈溢出问题标签 Twilio 也没有从我们其中一个人那里得到答案。我们随时随地为人们提供支持，无论他们想用 Twilio 做什么，还有很多其他方式，但这些是我想到的方式。
远程访问支持会议的多样性
鉴于缺乏现场活动，新冠肺炎疫情对 DevRel 有何影响？向在线会议的过渡为活动参与者和公司带来了一个独特的机会:能够在全球任何地方参加活动，这使得与会者群体比以前更加多样化。
德里奇:肯定。我喜欢一键安装或这类安装过程。电池的例子包括但可选，你可以根据需要修改，但只是尽快开始。你提到了 COVID 以及你对此的看法。我只是很好奇，自从 COVID 击中后，DevRel 有什么变化，特别是事件不再亲自发生。而且加速了吗？就接触开发者而言，它在某种程度上是有益的吗？
菲尔:是和不是。对我来说，不同的是，我大部分时间都在这里，而不是亲自出去见人。我们肯定是缺少了人，缺少了与人交谈，缺少了让人们对事物感到兴奋。另一方面，我认为它实际上也接触到了不同地方的一大群不同的人。活动、聚会和其他社区上网的方式，使得各地的人们都能够参与其中。不仅仅是那些住在合适的地方或者能在合适的时间到达那里的人。我认为这让事情民主化了很多。对于开发者关系来说，这有点困难，我想我还没有看到一个在线活动有和现场活动一样的赞助商体验。
我认为这是可以理解的，当你有一堆谈话，中间有一个间隙，人们在家看着它。他们会在休息时间去泡一杯茶或咖啡，他们不会在虚拟展台闲逛，这很好。我们必须努力找到更好的方式与人们交流。我认为我们仍然是，但这也是一个正在进行的事情。
德里奇:这是事件中非常好的一点。事实是很难建立关系网，对吗？去参加一个会议之类的活动，认识新朋友最简单的方法之一就是逛逛展台、欢乐时光和所有其他正在进行的活动，比如黑客马拉松之类的。
菲尔:没错，我会在庆功宴上全力以赴。
API 的成功比以往更加困难
进入 API 世界不再是提供问题的答案，而是作为 API *台的完整解决方案包。但是，对于 API 开发人员来说，由于有大量可用的工具，工具包将继续为构建应用程序提供灵活性。
德里奇:够搞笑吧？我的最后一个问题是关于 API 和 DevRel 的未来。接下来你会看到什么，你认为 API 会走向何方？
菲尔:这很难，我认为现在在较大的 API 公司中有很多整合。我显然是从 Twilio 的角度来说的，我们偶尔会收购其他 API 公司，但这种情况会更多一些。我觉得最*有很多回归基础的东西，像数据库和其他连接性的东西都是新的和令人兴奋的，这让我有点惊讶。我想有新的更好的基础技术在驱动这个。当然，任何试图做像数据库这样完全基础的事情的人都会不顾一切地与你的三大云运营商对抗。所以，你真的要有一个非常令人印象深刻的理由才能存在。我自己还没有和他们中的很多人打过比赛，但是我很兴奋能在某个时候这样做。
但是它的未来是什么样的呢？我认为进入 API 领域变得越来越困难，因为你需要提供太多的东西来带来与已经做了十年或更久的人所能提供的相同的体验。当然，有开源工具伴随着这种事情，这使得它更容易实现，但还有很多要考虑的。甚至我们回避的一件事是提供 UI 工具包来处理这种事情。我认为 Stripe 也非常擅长为事物提供实际的用户界面，但不仅仅是跨浏览器。
能够提供跨浏览器和 javascript 前端以及现有框架的 ui。但是必要的本地应用程序、它们的框架、它们的跨*台框架、你的颤动和本地反应等等。当你拿出这个的时候，可能会产生很多东西。我希望所有在 APIs basis 中构建新东西的人都好，因为有很多东西需要考虑和思考。尽管作为一名开发人员，我认为这是一个构建产品和构建应用程序的好时机，因为有如此多的工具可供您以您想要的方式构建。作为一个 API 公司，能够为这些人提供一切是有点困难的。
Derric: 现在有很多工具，有很多新的 API 优先或开发者优先的公司出现，这需要非常关键的技能。非常感谢 Phil 今天加入我们的播客，并期待看到 Twilio 和 Signal 接下来的发展。
菲尔:非常感谢。
德里奇:好好过。
风险投资视角下的开发者优先公司
Ep。8:泰勒·朱厄尔，戴尔技术投资公司董事总经理
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
加入我们的是泰勒·朱厄尔，他是 T2 戴尔科技投资公司的董事总经理。在此之前，他是 API 管理*台公司 WS02 的 CEO。作为一名投资者，他在 DevOps 公司投资了* 1.5 亿美元，并自称是开发工具、devops、基础设施和开发*台方面的极客。
泰勒给出了他对投资开发者优先公司的观点，大多数成功公司共有的单一特征，为什么开发者的快乐很重要等等。
莫西夫的首席执行官德里克·吉林是今天的主持人。
Moesif · 8. VC Perspective on Developer-First Companies
在 SoundCloud 上听这一集，在苹果或谷歌上下载，或者在 YouTube 上观看。
目录
- 0:37 从东亚银行到戴尔资本
- 3:17 一个万亿美元的生态系统
- 5:35 开源项目经验是关键
- 7:05 云与本地的不同指标
- 8:00 不断建立关系
- 9:51 正版开发者体验
- 12:00 针对情绪发展反应
- 13:30 开发工具每 15 年循环一次
- 16:50 蜜蜂扰乱砖块&迫击炮像 GameStop
- 20:43 格子通缉令
- 23:13 合同胜过现收现付
德里奇·吉林(Moesif): 欢迎收看 Moesif 的 APIs over IPAs 播客网络第八集。我是今天的主持人，也是 API 分析*台 Moesif 的首席执行官。戴尔技术投资公司的总经理泰勒·朱厄尔和我在一起。之前他是 API 管理*台公司 WS02 的 CEO。作为一名投资者，他在 DevOps 公司投入了* 1.5 亿美元，非常关注开发者优先的公司。很高兴你今天能来。
泰勒·朱厄尔(戴尔资本):下午好，德里克。
从东亚银行到戴尔资本
Tyler 是一名拥有 25 年企业基础架构、运营和投资经验的资深人士，他加入戴尔资本，专注于投资开发者优先的公司
德里奇:爽。首先，我想听听你从 WS02 首席执行官到戴尔资本董事总经理的故事。
泰勒:你知道，大约 25 年前，我从软件行业的一名工程师做起，然后进入一些大型上市公司的产品部门，BEA 和 Quest Software。一路走来，我也获得了经营公司的机会。你做大公司领导的事情，然后你有一些想法，你去做一些创业。我是一家小媒体公司的首席执行官，这家公司是由艾德·罗曼创办的。然后最终被 TechTarget 收购，那是在 2004 年。然后，在我第二次任职于一家大型上市公司后，我在 2011 年创办了自己的公司 CodeEnvy。CodeEnvy 是一个云 IDE，云开发人员工作区，当时它并不是一个真正的类别。我们用了五年时间发展这项业务，后来被 Red Hat 收购了。
我在 2009 年进行的投资之一是 WS02。我在董事会已经呆了好几年，那家公司发展得相当不错，创始人邀请我去当他们的首席执行官。所以我接管了公司，当了几年首席执行官。我让那家公司扩大规模并盈利，现在全球有 600 多名员工，按收入计算，它是最大的开源公司之一。一直以来，我都在以天使或风投的身份进行投资，受邀参与并投资了十几个与开发者相关的企业——Sauce Labs、WS02、CodeEnvy、InfoQ、CloudInt、APPHarbor、ZeroTurnaround 以及其他一些企业。然后戴尔来敲门。他们是一个真正受人尊敬的风险投资部门，一直在寻求扩大合作关系。他们正在寻找在企业基础设施方面拥有专业知识、曾经运营过并有投资经验的人。所以这只是一个很好的组合，然后是一个超级团队，所以我决定跨越。
一个万亿美元的生态系统
如今有 900 家由开发者主导或专注于开发者的公司在创造收入
德瑞克:看到有这样的运营经验，还有一个投资网站，甚至是你个人的天使投资，真是太棒了。我们已经注意到在 2020 年推出了这种新的开发者主导的格局，这背后的动机是什么，可以分享一些见解吗？
Tyler: 所以，我想在我职业生涯的早期，也就是 20 年前，当我开始从事开发工具和开发业务时，人们普遍认为开发人员拥有的业务是没有钱可赚的。我仍然认为这可能是很多人对此的普遍态度。因此，我一直致力于让更广泛的投资业务和技术生态系统对开发者和基于开发者的业务能够带来的价值有更强的认识。为了做到这一点，我认为很多人都没有意识到这个市场空间有多大。因此，作为我日常阅读的一部分，我一直在慢慢收集所有的产品，至少是我认为适合这种情况的基于商业的产品，这些产品由开发者主导或受开发者影响，我已经建立了十多年。我最后说，“嘿，不妨发表一下”，我敢打赌，你们这些人看到覆盖这个生态系统的公司和产品的原始数量会有很大价值。
事实证明，大约有 1200 种基于商业的产品以某种形式或方式产生收入。其中大部分可能是 900 家左右的公司，所有这些公司都筹集了风险资本，或者说，你知道，在某些情况下，他们自己也在创业。它几乎为所有这些产品带来了约 400 亿美元的年化经常性收入。因此，如果你想一想所有那些由开发者创办的企业，或者他们制造被开发者购买或被开发者大量使用的产品，仅仅是开发者生态系统的原始影响力就非常重要。现在它在市场上的价值可能超过一万亿美元。所以这只是一个练习，让生态系统的其他部分来看看这个世界，并对它有一个积极的归属感，就像我一样。
开源项目经验是关键
风险投资家通常在创始团队中寻找开源经验，即在开源项目中或围绕开源项目维护和发展社区，因为这相当于拥有商业化或经典的上市经验
德里奇:哦，价值超过 5000 亿美元，这是一笔不小的数目。当我们看着 Twilio 本身，那就是 5 亿美元。谈到创始人，你有没有注意到开发者优先的公司与更传统的销售公司有什么不同？
泰勒:你知道，开发主导的企业几乎都是由工程师创办的。那个工程师可能有也可能没有商业化经验，走向市场的经验。所以，你必须多做一点工作，帮助他们建立一个团队，能够*衡他们带来的优势。现在有趣的是，现在很多正在创业的开发者，他们可能没有商业化经验，但他们有开源维护经验。在开源项目中以及围绕开源项目维护和发展社区的许多过程，与在这方面建立一个商业组织所需的技能非常相似。因此，这方面的*衡越来越明显。你知道这是你所看到的最大的组成部分。"
云与本地的不同指标
关注与您的业务类型相关的业务指标:如果您正在构建基于云的产品，请关注 SaaS 指标，或者如果您正在构建本地产品，请关注传统的 ARR、配额覆盖率、CAC
Derric: 这是否意味着当你观察这些不同的公司时，你对收购和进入市场战略的看法会有所不同，还是说 ARR 和销售漏斗等指标大致相同？
Tyler: 适合一家企业的指标取决于他们正在建立的企业类型，并非所有企业都一样。因此，如果开发人员正在建立一个基于云的业务，是的，你可能会与 SaaS 度量在这方面的工作。但是，如果是开源业务或开放核心业务，可能会有其他指标，而不是 SaaS 指标，但与传统的 ARR、配额覆盖率、客户获取成本等类似的指标更倾向于内部销售。除了认识到这两个开源软件都是漏斗的顶端，所以还有一系列的 DevRel、开发者关系、度量标准，你也必须合并。
不断建立关系
如果你想让你的公司成功，就要在人际关系网上投资:为了工程人才，为了获得早期客户，或者为了商业发展机会，不要纠结于产品或招聘等内部问题。
Derric: 当我们看看消费者世界，Hotmail 黑客，即从 Hotmail 或从我的 iPhone 发送的东西，你有没有看到任何在开发人员领域奏效的走向市场的黑客？
泰勒:你知道，我真的不认为你能做什么来入侵。我要说的是，无论是以开发人员为中心的业务还是企业软件领域的其他业务，成功和失败公司之间的很大区别是代表创始人建立关系网和努力工作的能力——无论是与惊人的工程人才建立关系网，还是与潜在的早期客户建立关系网，还是在业务开发方面建立关系网。那些真正致力于不断建立关系的创始人往往比那些只关注产品或只关注雇佣员工、有点内省的人表现得更好。
德里奇:这是一个非常好的观点。很容易陷入产品本身，考虑开发人员的体验，但是人还是人，即使你是开发人员。所以你如何建立这些关系并向前推进总是很重要的。
泰勒:是的，我认为很少有人会对某件事产生兴趣。创新和对你正在做的事情的兴趣往往来自于人们敲开许多门，分享他们正在做的事情，然后找到拥有相同价值观的人。拥有相同价值观的人会相互吸引。但是你必须培育它，然后成长它，再成长它，接下来你知道你实际上已经有了一个合法的生意。但是，如果创始人没有这些基本的练习，他们就必须学习。
真实的开发者体验
通过将您的服务透明地融入他们现有的工作流程，提供真实的开发人员体验，而无需强迫他们学习新的东西
德里奇:肯定。当你考虑像开发者体验和对开发者感同身受这样的事情时，你实际上是如何做对的。有时，我们看到一些公司以某种方式获得了它，然后又有另一家公司不是真正的开发商。
Tyler: 关于开发者体验，这一切都归结于开发者的参与度和忠诚度，如果你给开发者一个真实的体验，他们就会给你参与度和忠诚度。所以每个人都会问“好吧，什么是真正的开发者体验”，问题是没有办法衡量它，它不科学，它是部分艺术，部分科学。但是，我可以告诉你的是，当某个东西不真实时，开发者马上就知道了。我试图尽我最大的努力去描述是什么让一些东西变得真实，它是任何一种你的解决方案，它将自己融入到一个现有的开发者工作流中。因此，如果你有一个开发人员，他们经常做一些事情，而他们正在编写代码或他们必须做的任务的另一部分，如果有一种方法让你透明地融入其中，然后仍然通过它交付你的解决方案，而不强迫他们学习其他东西，这往往是一种很好的真实体验，然后会产生很多价值。
我们看到了 Heroku，你知道 Heroku 只是为了 Git 推送，所以你已经在使用 Git，所以你只是融入其中。我们看到它与 Snyk，你仍然做一个拉请求，你不必改变这一点，但 Snyk 开始增加了许多静态分析和颠覆测试能力。即使在相对于代码的较小程度上，VS 代码使插件模型如此透明，以至于你甚至不需要知道你正在安装插件，它只是在你开始写代码时开始添加这些值，因为它可以从中推断出你想要什么。这些都是很好的例子，说明了工程师们是如何在不过度扭曲现有体验的同时增加价值的。
以情感发展反应为目标
寻找开发者的乐趣，开发者充满感情地谈论你的产品，以此来衡量你的 DevEx。你的项目有更多的贡献或下载通常只是一个良好发展的早期指标。
有趣的是，我正要问你实际上如何衡量这种开发者体验，你是对的，这很难衡量。有没有什么高层次的东西可以让你感受一下或者感受一下开发者的体验？
泰勒:看，很明显，哪些项目得到了更多的贡献者，哪些项目得到了更多的下载等等。我认为这是一个代理，也许是一个早期指标，表明那里有很好的开发者体验。但是，坦白地说，我寻求的是一定程度的快乐。如果你花 20 分钟和一个开发人员谈论某项技术，有些事情是开发人员科学地谈论的，有些事情是他们情绪化地谈论的。你在寻找情感上的。
德里奇:Vim 对 Emacs？
泰勒:那是完全不同的讨论。它们都是真实的体验，只是更像是开发人员的怪胎，因为开发人员会一直争论某些权衡，Emacs 和 Vim 就是这些权衡的化身。你知道，坦率地说，他们提倡的那些折衷方案，可以出现在分布式计算*台或区块链架构中，选择一个域，这都没关系。同样的问题以其他方式出现。我认为 Vim 和 Emacs 只是开发人员将这些争论摆到桌面上的一种简单方式。
德里奇:我想从 REST 到 GraphQL out，从无 SQL 到 SQL，我们都可以看到这一点，你总是不得不进行辩论，对吗？
泰勒:是的，他们总是要进行辩论。否则就没意思了。
开发工具每 15 年循环一次
开发工具每 15 年经历一次大规模的捆绑和解绑，Git 在 2005 年将一切都变成了分布式版本控制，现在 GitLab，一个非常固执己见的单一*台，正在不断扩展以提供工具集的一站式商店
德里奇:那么，随着所有无代码/低代码解决方案的出现，几年后我们会走向何方呢？这是否意味着开发人员的体验有所不同，它是否会发生变化，看起来会和今天一样？
Tyler: 我认为我们将在未来十年或二十年内看到开发人员工具的重新*台化，原因有几个，但这不是由 Lo-Code 驱动的。我认为 Lo-Code/No-Code 的热情实际上只是解决方案释放了开发人员和非开发人员构建一类他们以前无法构建的应用程序的能力。如果你真的需要签名和写代码，并经历一个完整的生命周期工具过程，那么这个应用程序必须非常特别，你才能投入所有的时间和精力来构建它。所以在过去的 30 或 40 年里，有一整类的应用程序，人们真的希望他们可以建立，他们只是负担不起，因为它太昂贵了，以代码结构为基础。你不需要用代码写出来的那种力量和控制。因此，我认为现在 Lo-Code 系统使你能够释放应用程序的成本，结果，它允许更多的人进行应用程序开发，因为他们不需要拥有相同的技能。我认为我们能够看到这些系统，因为现在有如此多的 API，这些 API 是可插拔的，因此是可重用的，所以这些系统可以真正地使这些东西很容易连接在一起。
就开发人员的体验而言，在过去的 50 或 60 年中，DevOps 社区经历了大量的捆绑和解绑，每一波大约需要 15 年。之前的 15 年是大规模的拆分努力，拆分发生在一个范式转变上，这个范式转变是 2005 年 Git 的引入。Git 把一切都变成了分布式版本控制，所以整个工具链真的沿着这些概念被重新发明了，我们得到了许多独立的筒仓。我们现在开始看到证据表明，所有这些将会有一个伟大的重新捆绑。GitLab 是一个非常固执己见的单一*台，它试图提供一致的工作流程。GitHub 正日益从左向右扩展，以提供工具集的一站式商店。甚至像 JFrog 和 Docker 这样的供应商，因为它们是您需要使用的所有依赖项的记录系统，所以它们可以构建真正紧密集成的广泛工作流，将所有东西捆绑在一起。所以我认为我们正走在这条大规模捆绑销售的道路上。然后，我们将经历另一次分拆，可能需要 5 到 10 年时间，这可能是由 edge 推动的。在边缘上构建应用程序的想法只是所有开发人员都必须理解一种最终一致性的形式，他们在云计算架构中不必担心这一点。我认为，我们今天拥有的大多数工具和系统都不太适合这一点，因此在这方面可能会再次进行反思。"
API 像 GameStop 一样破坏砖块和迫击炮
GameStop 的新投资者正在设计一套用于游戏发行的 API，他们正在将一家亏损的实体企业数字化改造成软件公司
德里奇:真的很想看看未来几年这里会发生什么。我们已经看到很多不同的人在 CloudFlare workers 和其他类似的东西中利用 Moesif 之类的东西。但这还只是开始。再谈一谈 API 和事物的分类，现在在 API 领域有很多工具，从关注开发者到安全性、分析，再到 API 的部署。你如何看待 API 以及你使用它们的方式在未来五年的变化？
泰勒:好的，在技术层面上，API 支持更多的协议。许多 API 都内置了实时流机制，以摆脱旧的请求/响应机制。它们都将是异步的。这将允许 API 更好地执行，当您与这些 API 交互时，您可以提取更多更丰富的数据。这将使基于消费者的应用程序更加丰富。这是技术趋势之一，也是我们将要看到的。
第二，我们看到许多企业正在成为 API 优先的企业，这就是说，他们正在破坏实体系统，他们正在通过构建一个真正丰富的 API 来做到这一点。当我们谈论这个的时候，像 GameStop 这样的东西今天上涨了 400%。都是华尔街的人。这真的很惊人，因为这家公司正在大量亏损。这是一个销售游戏的实体商店，你不再需要亲自去购买，你可以去网站下载这些东西。所以，无论如何，你知道有大量的短暂经历。但所有发生的是，有新的投资者进来说，“嗯，你知道我们将把 GameStop 变成一个全球一站式购物视频游戏数字交付”。所以它现在已经数字化了，它是一个软件公司，而不是一个实体公司。销量不断上升，你瞧，在这种狂热的推动下，股价一飞冲天。但我提到所有这些是因为他们正在谈论的是设计一套用于与游戏交互的 API，游戏的分发，然后他们将围绕这一点重组业务。因此，我认为我们将会看到更多的 API 正在颠覆这些实体企业。
我担心创业公司是否能做得很好。不幸的是，一家初创公司将不得不寻找这样一个 API 的利基领域来交付，他们将不得不交付这样一种非凡的体验，使应用程序开发人员能够变得更好。在通信、金融和内容领域，我们现在在 API 领域有一些大型供应商，这些大型供应商非常努力地简化 API 并进行集成，因为他们是批量购买，所以价格相对较低。因此，我认为某些类型的小型创业公司将很难在类似的领域竞争。他们将不得不寻找 API 创新尚未发生的新领域。
这是否意味着像垂直 SaaS 这样的东西，我们将拥有这些垂直 API，或者你认为下一代初创公司的 API 会走向何方？
Tyler: 我认为几乎所有的应用程序都将是某种基于垂直的应用程序接口，因为这是需要发生中断的地方——在旧的遗留业务流程中，这些流程还没有自动化，但可以自动化。API 只是一种简化，它在幕后实现自动化，但 API 接口只是现有流程的简化。
德里奇:我只是在等着听顺口溜“有这样的 API。”
泰勒:是的，我们可能离那不远了。
格子呢想退出
监管机构叫停格子公司收购案的公众形象是一个方便的故事。坦率地说，这笔交易花了太长时间，格子公司的高管和投资者都想退出，因为随着他们的增长，这笔交易太便宜了
说到这些 API 第一的创业公司，上周出现了一些关于 Plaid 收购和监管方面的重大新闻。这对 fintech APIs 和整个 API 生态系统会有什么影响？
泰勒:我们又回到了华尔街赌注的场景。我认为，我们所听到的公众形象，即这是一个监管问题，是一个方便的故事。坦率地说，这花了很长时间，六到九个月，50 亿美元的交易，加上他们的增长，在这个时间点上看起来太便宜了。所以我认为，在所有条件相同的情况下，格子花呢的投资者和创始人都在寻找摆脱那笔交易的方法。该公司目前很可能价值 100 亿至 150 亿美元。所以我认为它们的价值一点也没有减少，我认为这只是加强了这些东西的重要性。只会给别人火上浇油。
德里奇:对于这些 API 第一的公司来说，这是一个非常好的观点，说明了估值变化如此之快。
泰勒:是的，他们增长了 50%或 60%，在这个多元化扩张的时代，他们的价值可能翻了一番。因此，你可能会有很多买家后悔坐在桌子旁边，当时认为 50 亿美元很棒，而我们将价值 10 亿美元。但后来你意识到，天哪，我们实际上值 10 英镑。你用它做什么？
实际上，Plaid 的首席执行官发布了一篇非常有趣的文章，围绕着建立一个 API 优先的公司，有时可能需要一点时间来让事情运转起来，因为集成组件，但是一旦你被集成，它就只是指数级的增长。这是否意味着创始人应该从 API 优先公司和更传统的企业销售公司的增长角度来看待不同的事情。
Tyler: 我认为建立 API 业务的好处是你可以非常清楚地衡量参与度。如果人们正在使用你的 API，而且使用得越来越频繁，那么你就做对了。但是如果他们使用了它，又放弃了它，那么事情就不对了，你需要做更多的工作:要么界面不存在，他们不知道如何使用它，要么你没有为你在幕后做的集成提供足够的价值。
德里奇:没有接口怎么办？那你衡量的是什么，只是一个空气污染指数？
泰勒:你显然是在计量 API。你的目标可能是赚钱，所以利用这一点的应用程序的数量，并最终支付给你一些东西，是 API 在这方面如何有效的一个很好的晴雨表。
合同胜过现收现付
在计费 API 中，随用随付是一种让开发者开始开发并让人们发现你的服务的好方法，但是一旦你达到一定规模，你通常会把它变成契约化的关系
derrick:这是一个关于计量 API 的非常好的观点。说到计费，我们在过去几年中已经看到了向现收现付模式发展的巨大趋势。其中很大一部分是由 AWS Lambda 推动的，我们已经看到 Algolia 向它靠拢。当谈到这些 API 第一的公司时，你认为未来的计费将走向何方？
泰勒:我认为有很多关于现收现付模式的讨论。但是，我认为，从规模上来看，当你看到那些真正通过 API 赚了很多钱的企业时，他们的大客户实际上没有一个是按需付费的，他们是在合同中工作的。他们强迫他们购买最低消费，但也防止突发账单和计划外消费等等，所以这种限制。这符合 API 公司的利益，因为他们希望对他们将获得的收入有可预测性，而买家不希望你最终支付过高的价格，因为他们让一些流氓开发者去做一些事情。因此，我认为“随用随付”是让开发人员起步的好方法，这是让人们找到你所获得的服务的亲和力的好方法，但一旦你开始拥有一个真正的社区，并且它真正开始增长，你就会倾向于将许多这些事情转变为契约化的关系。这就是事物的自然进化。
这是一个非常好的观点，因为当我们想到这些开发者优先的公司时，在某些方面，你首先向开发者销售，试图让他们集成，我们仍然有一个你必须运行的企业销售流程。是关于两家公司同时。
泰勒:同时是的。你知道，你可以获得很多动力，然后当你需要扩展业务时，你可以考虑做一些适合扩展业务的事情。
德里奇:肯定。很酷。非常感谢你今天能来，泰勒。对于我们的听众，你还有什么要补充的吗？
泰勒:不，谢谢你邀请我。这太酷了。
德里奇:非常感谢。
与查尔斯·米勒就文档最佳实践进行播客交流
Ep。5:查尔斯·米勒，文档战略家。
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
为了帮助你避免文档成为你的 API 产品的致命弱点，我们今天的播客邀请了一位三十年的技术写作老手。查尔斯·米勒目前是达索系统公司 Medidata Solutions 的首席内容策略师。
Charles 告诉我们如何创建优秀的技术文档，什么是简明语言原则及其重要性，你应该遵循什么标准和指导方针，何时使用主动语态等等。
莫西夫的首席执行官德里克·吉林是你的主人。
Moesif · 5. Charles Miller, Documentation Strategist
在 SoundCloud 上听这一集，在苹果或谷歌上下载，或者在 YouTube 上观看。
德里奇·吉林(Moesif): 欢迎来到 Moesif 的 API 的 over IPAs 播客网络的另一集。我是德里奇·吉林，今天的主持人，也是 Moesif 的首席执行官，API 可观测性*台。
和我一起的是达索系统公司 Medidata Solutions 的首席内容策略师查尔斯·米勒。Charles 是一位多次获奖的技术作家，在他的公司领导 API 的文档创建。很高兴你今天能来。
查尔斯·米勒(Medidata Solutions): 谢谢德里奇。
德里奇:肯定。我很好奇你是如何为 API 编写文档的，作为后续，你是如何从和艾伦·金斯堡一起工作过渡到编写获奖的技术文档的？
查尔斯:嗯，那件事肯定已经过去了。我和他们一起出去过一次，所以我不想给人留下不好的印象。但是，你知道，这很有趣。你知道，这是一条漫长的道路，引导我从写下伟大的美国史诗，如果你愿意，到意识到我需要满足我家人的需求，而不仅仅是我自己的需求。
所以我的第一步是找一份工作，在那里我可以融合我对写作和技术的兴趣。所以我不得不回到学校上技术写作和编辑课。毕业后，在我技术交流生涯的初期，我花了很多时间做顾问。实际上，我断断续续做了大约 10 年的顾问。正如许多做过咨询的人知道的那样，这可能是相当有压力的。你的工作可能会持续一年或半年，然后结束，然后你不得不寻找进一步的工作。但我很幸运，我有相当稳定的工作。因此，尽管压力很大，一点点挖掘教会了我学习不同文档方法的许多途径，这种经历教会了我如何与许多不同的受众合作，并使我跟上了技术的发展。所以我去的每一份工作都能够积累关于技术的新知识，幸运的是对我来说都是新技术。所以，顺便说一句，我没有创作伟大的美国史诗，但是我能够把我的一些诗发表在两本选集里。
那么，说到你的方法和你多年来积累的知识，对于我们的听众来说，关于如何创建优秀的技术文档，什么是最重要的呢？
查尔斯:众所周知，我敢肯定，这都是时间的问题。时间是我们的敌人，有时也许是我们的朋友。但通常这是一个截止日期的紧要关头。所以根据我的经验，你拥有的越多，你的文章就越好。你有时间去调查和理解你所展示的和你所写的信息的背景。你有时间做采访，也有时间写、重写和测试你的文档。当然，主要的测试总是让文档出现在用户面前，这样你就可以衡量它的可用性。如果可以的话，你可以进行用户调查和可用性测试来获得用户的反馈。
derrick:然后谈到 API 文档的变化，我知道在 OpenAPI 规范和 Swagger 等方面发生了很多变化，自动生成和新技术在文档的主要进步中发挥了怎样的作用？
查尔斯:我在这个行业已经工作了大约 30 年，可以说发生了巨大的变化。人们可能听说过，甚至有些人知道，它已经从在 Microsoft Word 中手动创建技术内容，发展到现在为在线消费者使用内容管理系统。我们使用 Confluence 作为我们的主要部署方式。我实际上已经用文本编辑器创建了 HTML 文档，然后通过文件传输协议将它上传到门户。向你展示了我的历史。迁移到像 Confluence 这样的内容管理系统是很重要的，因为正如你所说，它帮助我们走向更自动化的方式来生成文档。这与形式和品牌是一致的。我们实际上可以在我们所有的服务、所有的产品中创造一个一致的信息，因为我们正在创造一个单一的品牌。但是，它也允许我们强加和坚持我们的写作标准，以及我们的编程标准。所以，这是我经历过的一点点历史。
德里奇:然后你能告诉我更多它的走向吗？API 文档的下一步是什么？
查尔斯:我认为下一个是数字辅助，人工智能和自然语言处理和自然语言理解的能力。我认为我们将开始看到这样的系统(我已经在会议上见过一些)，它能够接受用户的问题并返回答案。今天的答案可能是相当固定的，因为系统已经为它建立起来了。但是在很远很远的未来，我们将会谈论让人工智能数字助理滑过数据库，获得信息并能够得出语义结论，并基于该分析给出答案。我应该能够对信息进行分析，并根据它能够识别和扫描的内容得出结论。
听起来文档不仅仅是 HTML 站点上的文本。那么文档包括什么呢？
查尔斯:有时候，它是把系统或计算机需要知道的东西拿出来。有计算机可读的文档，也有人类可读的文档。所以我这边的文档，即使我们做了一些计算机可读的文档，大部分也是人类可读的。我必须能够创建可以理解和使用的文本和信息。用户需要能够几乎自动地理解信息。他们不应该扫描和解析信息来弄清楚它的意思。然后是可用性—如果他们正在处理一项任务，他们应该能够获取该信息并完成他们已经设置的或摆在他们面前的任务。
就使它可用而言，在开始一个新项目时，有没有一套你使用或遵循的指导方针？
查尔斯:嗯，我很幸运在一个我们已经定义了写作标准的组织和部门工作，而写作标准是关键。有行业标准:有 API 手册风格，有芝加哥手册风格，有微软手册风格和苹果手册风格。所以这些都是很好的起点。任何进入这个领域的人都应该清楚地意识到这些，并且对它们了如指掌。但是一个组织应该利用这些并开发自己的标准。这才是这个过程的真正开始。除此之外，还有一些标准，如简明语言原则、简明语言标准，它们真正强调了可用性和可理解性。因此，我们将这些简单的语言标准和原则融入到我们自己的标准中。这是一个很好的开始。
当然，你可以把它扩展到可用性测试中，有些公司可以奢侈地这样做。这确实需要时间，但是能够得到用户的反馈是非常宝贵的。当然，您总是向评论开放您的文档，因此用户可以提供关于信息的有用性和可用性的评论。然后进行用户调查，并根据需要输入和修改您的信息。
谈到文档，我们看到的一件事是，有时你有这么多不同的产品负责人或产品团队，你的文档在整个公司的基调可能不一致。当你谈到标准时，有哪些方法可以确保你在整个公司保持一致的基调？
查尔斯:是的，这很有挑战性。拥有这些一致的标准当然不会错。但是通常你会有，例如，商业写作标准，我们有我们的技术写作标准。有时人们认为商务写作标准不同于技术写作标准。我倾向于不同意。我教过商务写作，也教过技术写作。我不认为他们有什么不同，但是你会发现一些组织或者部门不同意。所以你必须找到底线，对我来说，这是简单的语言。使用简单明了的语言原则，并坚持这些原则，你谈论的是使信息有用，信息丰富，传达一种友好的感觉，一种透明的感觉，你尽可能清晰简洁地给他们信息。我认为，在更大的范围内，这也将开始转移到其他部门。你必须在组织内部建立一致性，所以你的内部文档应该是相同的，或者应该试图模仿你为外部受众所做的事情。你知道这是个挑战。我不会说它不是，但标准绝对是一个开始。
这是否意味着有一个拥有文档的中心团队，比如开发人员体验团队？还是应该由各个产品负责人自己决定？
查尔斯:我们有一个用户体验部门，他们维护自己的标准。我们与他们密切合作，努力将我们的标准与他们的标准联系起来。然后我们有自己的部门，即技术交流服务部，专门为我们的用户提供技术信息。这是面向用户的文档，我在这个部门工作。这是一种伙伴关系:你与开发人员有伙伴关系，你与产品管理部门有伙伴关系，你与测试部门有伙伴关系，并且每一个人都应该能够为文档提供输入。就像你说的，有时候保持所有声音的音调是很困难的。但是，这不是你不能克服的事情——这是一个挑战，这是一个障碍，但保持你的标准，遵守那些使用主动语态的原则(对我来说，主动语态至关重要),这将使你的语气经常显得非常直接和透明。
德里奇:知道主动语态比被动语态更能传达你的信息真是太好了。当涉及到使这些文档保持最新时，有时可能是事后才想到的。你如何让它们保持最新——你有旧的截图、过期的 API 规范，可能版本已经不存在了。工具已经在 OpenAPI 和 Swagger 等方面取得了长足的进步，但是仍然有很多文档已经过时了。你对此有什么最佳实践吗？
Charles: 我们使用的最佳实践，特别是对于 API 文档，我们使用 OpenAPI。所以，就像你说的，这确实有助于我们维护文档，因为什么都不会改变，除非工程师改变它，他们是 OpenAPI 的负责人。作为技术作者，我们扮演技术编辑的角色，确保编写的内容(仅限于 OpenAPI 规范中的地方)符合我们的编写标准。所以，这始终是一个与你的伙伴合作的问题。这是一个确保你的合作伙伴愿意创建非常非常好的文档来与最终用户交流的问题。
德里奇:你如何确保你是在对正确的观众说话？有时候，有些开发人员比较新手，他们只是在寻找一个入门指南，而有些开发人员非常有经验，他们想开门见山地开始工作？有许多不同类型的开发人员和不同风格的开发人员。有没有办法在这方面组织文档或实践？
Charles: 是的，例如，我们构建了我们的 API 门户，现在我将严格遵循 API 文档，我们围绕着，如你所说，能够向我们的各种受众提供信息来构建它。我们有新手(或新用户)、开发人员和非常非常有经验的开发人员。我们也有经理进来看文档说“嘿，这是什么？这个 API 要做什么？我怎么会对这个感兴趣？我能从中得到什么？”。测试人员需要能够阅读并理解它。
因此，例如，在入门指南中，入门是我们为所有级别的开发人员提供足够的信息，让他们立即开始。因此，我们提供诸如认证、授权信息、如何注册您的 API 应用程序之类的东西，以便开发人员可以尽快启动并运行。当然，我们还会提供代码片段。我们提供了进行 API 调用的示例。我认为 OpenAPI 本身，即规范，在这方面做得非常好，因为它提供了几乎所有开发人员进行 API 调用、发出请求时都需要的基线信息。因此，这也确实帮助我们能够接触到我们拥有的所有级别的用户。
那么理解你的受众，从他们如何处理信息的角度来看，是很重要的——并不是所有的开发者都以同样的方式处理信息。因此，我们让一些开发人员从真正大的全局角度来看待它，并希望从整体上对系统有一个完整的理解，这样他们就可以深入到底层，将所有东西拼凑在一起，并对他们正在做的事情有一个清晰的视图，不管出于什么原因。有些开发者只想马上上手。事实上，你的大多数开发人员都是那些想要马上开始工作并且手头有一个特定任务的人。他们希望能够完成这个任务，完成它，然后继续下一个任务。因此，我们确实提供了工作流之类的东西，我们称之为配方:如何在特定的实例或上下文中进行特定的调用——就像许多开发人员必须在我们的*台中执行特定的任务一样。因此，我们确定这些任务，然后提供带有 OpenAPI 文档链接的步骤，他们可以从中获得详细信息，以便进行调用来完成一系列任务，例如，获取用户名或类似的东西，这是非常基本的。但是我们有他们可能执行的更复杂的任务，其中完成该任务的每一个步骤仍然链接到规范中特定类型的文档。
毫无疑问，我们已经看到了更多的剧本和配方，我们完全认为这是改善开发者体验的好方法。事实上，我认为邮递员现在做了很多收集的东西，所以你可以很快开始。在帮助开发人员开始使用您的*台方面，技术作者和开发人员体验专家还应该做些什么？
Charles: 嗯，我们希望能有一个*台，让用户可以在文档内部进行调用。OpenAPI 确实提供了这一点，所以我们也在朝这个方向努力。我们希望开始实现一个论坛，以便开发人员，无论是客户还是内部开发人员，都可以提出问题并获得几乎实时的答案。然后我们可以收集这些信息并保存在一个数据库中，这样你以后的用户就可以进来询问数据库并得到一个回答。当我们走向数字辅助时，这种类型的数据库将会非常非常有用。
你有一些关于如何创建论坛的最佳实践吗，尤其是如果你是一个全新的人，而且你还没有足够的社区。你怎么确保它看起来不像是空的。
查尔斯:嗯，因为我们还没有开发出，这将是一个真正的问题。但是像其他人一样，我们要去堆栈溢出，然后从他们那里偷东西。开玩笑的。我们有很多真正优秀的开发人员，他们对客户的观点感兴趣。所以我认为，一旦我们建立并运行了一个论坛，我们可以很容易地填充用户想要知道，甚至需要知道的问题。事实上，我们现在正在努力。我们正在推进这个工作流程配方的想法。确定那些标准化的测试、目的和目标，大多数用户需要在我们的系统中工作，并在整个*台中导航。
德里奇:开发者不知道自己需要问的问题怎么办？我们之前在论坛上讨论了他们心中有一个特定的问题，或者他们何时开始，但是像他们不知道存在的新功能或新用例这样的事情呢？你从那个角度如何看待文档？
查尔斯:你知道这是一个非常有趣的问题，也是我在 API:World 的演讲中提到的问题，那是关于上下文的，你必须理解上下文。因此，作者必须了解如何以这样一种方式提供信息，即用户在阅读完你的文档后，能够提出新的问题并给出他们自己的答案。因此，这当然不是一件容易的事情，但至少在更成熟的用户文档设置中必须这样做。你必须能够理解这个*台，在我们的例子中，它是一个*台。你必须了解产品，你必须能够提供那些用户最明显、最经常询问的信息。这样他们就可以使用你的产品。
德里奇:听起来，了解背景对于知道这个人在寻找什么非常重要。这是否意味着静态文档正在被淘汰，我们正在向更加个性化或动态的文档发展？未来会是什么样子？
Charles: 我认为 dynamic docs 肯定是其中之一，但它的背景将永远存在。对我来说，有些人可能认为它是参考信息，正如我在 API:World 中介绍的那样。开发人员找到的不同类型的文档包括参考信息、配方、代码片段，但这些参考信息是概述信息，我不确定数字助理在开始时能做到这一点。这些信息必须由了解所有这些如何组合在一起以及所有这些如何工作的人来提供。这实际上是一个封装，关于上下文做什么和上下文不意味着什么。因此，必须有一个人在开始写下所有这些，并以一种数字助理可以浏览并制定答案的格式提供。所以回答你的问题，我认为书面文件至少会一直存在，直到，嗯，我的意思是，即使对于数字助理来说，它也会一直存在。我就是这么看的。
德里奇:哦，肯定的。我的意思是，你必须有你的 API 参考，对不对？我的意思是，你不能只通过语音或数字助理就拥有一切。
查尔斯:除非他们开发出能够真正创造信息、创造环境的人工智能系统，我暂时看不到这种事情发生。我的意思是也许 50 年，但是谁知道呢，自然语言理解是相当令人印象深刻的。
当涉及到文档和帮助那些数字助理时，看看 Intercom 和 Drip 做什么会很有趣。除了使用 OpenAPI 之类的东西，你还为我们的听众推荐其他工具吗？
查尔斯:嗯，我们用合流。这是一个非常强大的工具。它为我们提供了引导用户和分类信息的能力。它为作者提供了模板，他们可以使用这些模板开始生成文档。例如，我们可以为我们的开发人员提供模板，他们可以使用这些模板开始编写自己的配方。在这一点上，我作为一个技术作家与开发人员一起工作，与产品管理人员一起工作，也许与测试人员一起工作，来提出完成特定目标所需的步骤。我们现在要做的是创建一个模板，开发人员可以使用它来开始填写所需的步骤。然后，作为一名作家，我会回顾它，确保它明显遵循一些写作标准，并确保它填补了我们与观众谈论的所有漏洞——“嗯，等一下，也许这个层次的观众需要知道这个”，“那个问题的答案是什么”，或者也许“另一种观众类型需要回答那个问题”。这些是我们称之为管理信息的类型，所以我们，作为技术内容专家，不会是信息的生产者，但我们会是管理者。我们会收集信息，确保遵守我们制定的标准，然后填写客户需要知道的所有内容。
德里奇:完全有道理。就开发人员填写所有信息而言，这听起来是一个拥有标准和良好流程的好方法。但是你已经有了它应该是什么样子的标准，看起来和感觉起来是什么样子，对吗？
查尔斯:哦，当然。这就是合流。这给了我们一个机会来品牌化我们的信息，并使它在我们所有的产品中保持一致。
音频、视频等其他格式在哪里？我们看到很多人试图在文档中添加不同的东西，比如 gif 和其他东西。那也很重要吗，或者你认为那只是一种时尚？
查尔斯:我绝对不认为这是一种时尚。我觉得是未来。未来将是你拥有数字助理，然后它将与 gif 和/或视频融合，根据用户的需求和他们的背景提供信息——你在什么背景下工作，我可以提供什么样的信息来回答你的问题。所以视频将会非常重要。然后把它转换成 Gif 格式，这样你就可以浏览整个过程的一小部分，这非常非常重要。我们的最终用户文档中目前确实有视频。我们确实有计划提供关于集成以及如何使用 API 将不同产品与我们的产品集成的视频。所以这很重要，我认为这是未来的一部分。视频是非常劳动密集型的，至少现在是这样。我们必须达到这样的水*，去掉这么多的劳动强度，也许把它放到开发人员的手中。我们的一些开发人员非常擅长制作视频，我们的测试团队也是如此。因此，从某种程度上来说，能够从单一来源获取信息，比如说测试，并能够将其提供给我们的外部受众，这将是一种有趣的方式。但是，我们必须符合我们的标准，你不能随便推出任何东西。要专业，它必须看起来专业，必须有品牌，等等。
德里奇:有道理。我的最后一个问题是，如果你看到所有不同的公司都在做一些很棒的文档工作，你最喜欢的是什么，是什么让它成为如此伟大的文档公司？
查尔斯:嗯，我最喜欢的大概还是 GitHub 吧。我认为这是如此全面，他们真的进入了本质，他们回答了每个人都应该知道的问题。有人说“每个人都应该知道这一点，所以我们不会记录它”，但你不能采取这种态度，即使这是我们仍然经常遇到的态度。但是 GitHub 采用了基线方法——一个从未在我们的*台上工作过的人需要知道什么才能开始运行并执行特定的任务。这就是为什么我喜欢他们的文档。他们真的考虑了他们信息的所有分支，他们也考虑了他们不同的受众需要什么来利用他们的*台和产品。
德里奇:肯定同意。我喜欢 Github 对他们的 changelog 所做的事情。我认为看到这些年来 GitHub *台的所有更新非常酷。
查尔斯:我最*一次检查，我已经有一段时间没有检查了，但是我们的变更日志是基于他们所做的。我的意思是，它非常精简，非常简约——我们改变这个，我们添加这个，我们反对那个。然后，我们给出链接，当然，链接到资源中任何被改变的附加部分。我们的客户需要详细的信息，我们的发行说明对于我们的最终用户文档来说是相当广泛的。更糟糕的是，我们在一个受监管的行业工作，我们必须提供尽可能详细的信息，而我们的客户对他们想要多少信息非常挑剔。你知道，他们非常老练。所以我们提供所有的信息，我们有模板设置。但是，这也是我们 API 文档的最终用户信息。我们采用的标准是提供增加了什么，改变了什么，取消了什么，然后我们可能会给出一两行，一两句话，关于变化包括了什么。
有趣的是，我们实际上也是基于 Github 的变更日志，他们做得非常好，就像你提到的，直奔主题，没有添加太多的废话。
非常感谢你，查尔斯。我很感谢你在 Moesif 播客上主持节目。在我们结束之前你还有什么要补充的吗？
查尔斯:谢谢你，德里克。感谢您给我机会与您共度时光，并谈论我非常喜欢的东西，即文档。
德里奇:嗯，肯定是。文档对于帮助开发者开始并确保他们在你的*台上成功总是非常重要的。
查尔斯:一直都是。我们以客户为中心，并努力保持以客户为中心。
德里克:非常感谢你，查尔斯。祝你过得愉快。
查尔斯:谢谢你，德里克。你也是。
Jeremy Glassenberg 关于 API 产品管理最佳实践的播客
Moesif 播客网络第一集。
为 API 产品经理和其他 API 专业人员提供可行的见解。
在与 Moesif 顾问和专家 API 项目经理 Jeremy Glassenberg 的广泛讨论中，我们涵盖了当今影响 PMs 的许多最重要的问题，包括:如何实现 10 倍的结果，哪些是启用 API 的最佳工具，以及如何避免设计和启动 API 时最常见的错误。
Jeremy Glassenberg 在构建 API 和开发人员*台货币化方面拥有 11 年以上的经验。作为 Box.com 的第 20 名员工，他是他们的第一个项目经理，创建了 DevRel 团队，并将开发社区发展到超过 15，000 人。此后，他在 Edmodo、Pinn、Tradeshift、wheet 以及现在的 Docusign 担任产品领导职务。杰里米还为项目经理和初创公司提供建议和指导，目前是产品学院的首席产品管理讲师。
Moesif 的朋友 Kunal Punjabi 和 Jeremy 聊了两天。以下是他们讨论的浓缩播客。
Moesif · PM Best practices with Jeremy Glassenberg
在 SoundCloud 上听这一集，在我们的 YouTube 频道上观看，或者在苹果或谷歌上下载。
目录
- 1:22 管理 API 与应用的差异
- 6:00 标准化 API 设计的工具
- 8:50 成功产品经理的性格特征
- 14:28 如何定义 API
- 16:15API 和开发者*台的价值道具
- 20:06API 的商业模式
- 23:08 独特的 API 产品管理挑战
- 24:32 设计和启动 API 时的常见错误
- 28:28 发布 API 时什么最成功
- 32:00 发展开发者生态系统的有效策略
- 34:37 什么是开发者*台
- 37:40 确保与您的 API 向后兼容
- 40:50 说到 API，什么是 Webhooks 和 Websockets
- 44:00 API 工具从 Soap 到 OpenAPI 的演变
- 48:00 何时向第三方开发者开放你的 API
- 49:30PMs 最大的挑战
- 52:00 是什么造就了一个伟大的 PM
- 54:30 锄头达到 10 倍的成绩作为 PM
- 57:25PMs 应该读什么
Kunal Punjabi(Moesif 的朋友):在今天的节目中，我们将采访杰里米·格拉森伯格(Jeremy Glassenberg)，他能参加我们的节目，我感到非常兴奋。Jeremy 是超过 11 年的*台产品管理领导者。最*，他一直是 Pin 的产品副总裁，在此之前，Jeremy 是 Box、TradeShift 和 Edmodo 等公司的*台产品管理负责人。作为处理供应链技术的 TradeShift *台的负责人，他领导了 TradeShift 新的开发人员框架、文档和开发人员工具的设计。在处理教育技术的 Edmodo，他将 Edmodo 应用程序商店发展到 500 多个应用程序。
在此之前，他是 Box 的第一位*台产品经理，在那里他建立了他们的开发者关系团队，创建了一个超过 15，000 名合作伙伴开发者的社区，并参与了 Box *台的构建和货币化。杰里米非常感谢你能来。
杰里米·格拉森伯格(专家产品经理):很高兴来到这里，库纳尔。
库纳尔:太好了。Jeremy，我今天想花一些时间讨论一些主题:*台和 API 产品管理，我们还会谈到一些关于组织行为的故事和元素，然后我们最后会总结一些建议，这些建议是你必须给其他想要实现我们都在追求的 10 倍成果的产品和增长专业人士的。听起来不错吧？
杰里米:是的。对我来说听起来不错。
管理 API 和应用程序的差异
从本质上来说，*台产品管理仍然是产品管理，因此 API 应该通过应用适当的产品流程，为开发者社区的实际用例而设计。项目经理经常进行大量的 A/B 测试，迭代产品，但对于 API，他们需要比应用程序更密切地关注向后兼容性。
Kunal: 所以，我很高兴你能来。我将从头开始，所以让我们开始吧。我们的第一个问题是，管理*台产品与管理消费者或企业产品有什么不同？
Jeremy: 是的，我首先要强调的是，*台产品管理的核心仍然是产品管理。所以，在讨论不同点之前，我想强调一下相似之处。很多时候，人们对待 API 的方式是不同的，与产品的其他方面太不同了。有时候，他们相信“让工程师为工程师构建它”，而不是工程师不应该参与设计，甚至不应该被设计驱动——在 Stripe 这样的地方，API 只是由工程师设计的。事实上，在 Stripe 需要产品经理之前，他们有 300 多名员工。但是，他们仍然在应用产品过程。很多时候，我看到一些公司认为这只是一个技术挑战，“我们需要为工程师建造一些东西，让我们把它交给我们的工程团队，不要提供任何背景。”我们看到的是，工程师们采用公司内部已经有的任何 API，把文档贴在上面，并认为它会工作。这是多年来我们看到这么多 API 失败的首要原因，它们不是为其开发人员社区的实际用例而设计的。我们实际需要做的是，尽管这是为工程师设计的，但它仍被视为产品问题。只是你的客户碰巧更懂技术。如果你应用正确的产品流程，我们会做什么？开发者社区将会开发什么样的应用呢？我们希望他们开发什么样的应用？那些开发者将会是谁？你如何让开发者社区的成员尽可能容易地构建这些应用呢？因此，我们以客户为中心，逆向工作。
我们一直看到的是，为外部开发人员社区设计的 API 与那些内部 API 并不完全相同。现在，在应用适当的产品流程后，事情有所不同，这是因为客户是不同的，客户是技术型的，所以我们正在构建的将是不同的产品。第一，UX 和 UI。好吧，API 没有那么多的 UI 组件，尽管在设计好的文档、好的开发者门户时，用户体验确实很重要。这就是为什么我们现在看到很多团队，在 Stripe 这样的地方，除了 API *台产品管理之外，还有一种叫做“开发者体验”的东西。
此外，在 API 产品管理领域，迭代的风格将会有所不同。我认为对于任何开始从事 API 工作的产品经理来说，理解这一点是最重要的。在产品管理的世界里，我们必须试验，我们必须重复，进行 A/B 测试，做出许多小的改变并看到结果，如果这些不起作用，就恢复它们或继续在它们的基础上构建。在 API 的世界里——是的，我们想要迭代，我们想要试验——但是我们必须更加小心向后兼容性。API 中的小变化会产生大影响，它们可能会破坏很多应用程序，也可能会破坏少量非常重要的应用程序。这些集成工作的方式，开发人员与 API 交互的方式，比你仅仅在面向消费者的产品界面上工作更敏感。
所以基本上:A)还是把这个当做产品问题，但是 B)理解 API 产品管理的规则，尤其是向后兼容性。这又回到了开发者的同理心，只是理解如何以一种可以迭代的方式为长期设计你的产品，但这种方式仍然不同于你在其他任何地方所做的，在那里你只专注于 UI 产品。
标准化 API 设计的工具
为了更容易地创建和使用 RESTful APIs，围绕 OpenAPI 模式标准化您的设计。
很有道理，杰里米。您能告诉我们您使用什么工具来实现 API 设计的标准化，从而更容易地创建 API 供开发人员使用吗？也许这包括设计 API 的框架，开放 API 规范，或者可以自动生成这些东西的服务。
杰里米:API 中存在向后兼容性问题。这使得 API 设计不同于产品的其他领域。你设计 API 是为了向后兼容吗？有很多方法可以构建 API，这样您就可以进行某些调整，添加可选的输入参数，在不破坏现有应用程序的情况下增加输出。我们必须设计您的 API，以便您可以随着时间的推移进行调整。我们发现，有一些标准有助于 RESTful API 架构，现在还有 GraphQL，这是另一种设计标准，这些 API 是为这些类型的标准设计的。
它们在两个方面有所帮助:1)确保你设计的 API 具有很好的可伸缩性，2)设计一致的 API，不仅在你的公司内部，而且在其他公司设计 API 时也是如此。现在我们有了基于 RESTful 标准的 API，其他工具集成起来就更容易了。所以我们看到这些连接器像 IFTTT，Zapier，Mulesoft。实现与这些服务的集成和连接器要容易得多，即使它们提供不同的功能，它们都是在某种一致的标准下完成的。
现在，为了构建 REST，基本上成为 RESTful 设计标准的是 OpenAPI 模式。它基本上是一个定义文件:什么是函数名，什么是输入，什么是输出。让我们确保输出是一致的，并且如果您在该模式中定义您的 API，有许多围绕它构建的工具。因此，很容易从模式中生成好的 API 文档。生成一些基本的 API 库也很容易，如果你想要 JavaScript 库，Pipl 库，那么你可以给开发者社区一些入门代码。当您拥有该模式时，您可以自动生成它。
我非常强调使用 OpenAPI 模式，它已经成为 RESTful 架构的事实标准。对于那些正在考虑 GraphQL 的人来说，我不认为我们会有太多的时间来谈论它，但 GraphQL 是用这种模式推出的。只要在它的基础上构建，它将帮助你很好地设计你的 API，然后让你更容易地启动所有这些有助于一个良好的开发者生态系统的东西。
成功项目经理的性格特征
与其他团队成员跨职能合作最有效的产品经理是积极主动的——他们征求他人的反馈，并给出*衡的评估。
库纳尔:牛逼。在与项目经理和其他跨职能团队成员一起工作时，你会遇到哪些不同类型的性格特征？你发现哪些是最有效的？
Jeremy: 当我看到产品经理时，你的互动风格实际上有一个范围。我们已经讨论过无效的经前综合症。据我所知，最没效率的项目经理是容易被说服的项目经理，他们在销售部门有事情时，公司的目标只是推动销售。或者从经理那里得到一些东西，他们只是做他们被告知的事情。
顺便说一下，作为几个初创公司的第一个产品雇员，我强调，作为初创公司的第一个项目经理，你的工作是支持你的创始人的愿景。支持愿景并不意味着构建他们要求你构建的所有东西，而是意味着质疑、批评愿景，有时甚至直截了当地说“不”。你有责任去执行，你可能实际上来自你自己的研究数据，表明这不是正确的想法。
光谱的一端是这种易受攻击的，它们非常友好，但是很容易就能击败它们。有人会提出一个想法，如果他们是个性很强的人，个性很强的人会赢。在光谱的另一端，我看到这个被曲解了，推土机总理。做任何必要的事情来完成某事的人，他们会在这个过程中留下毁灭的痕迹。我还发现推土机人格与自我有关。自我与同理心没有关联，因此这些推土机式的项目经理更有可能推动他们自己的想法，他们认为很酷的想法，而不是基于真实的数据，他们会迫使公司走向错误的方向。
我们在中间的东西，你开始进入甜蜜点。我最喜欢的是我所谓的积极主动。这意味着你真的在努力从其他人那里获得反馈。不一定是共识，不一定是对所有人说“是”。但是你想要积极地从每个人那里得到反馈，你非常愿意倾听别人的意见。有时，你说“不”，有时你不等待别人的许可。总是有“你是请求许可还是乞求原谅”，在积极主动的范围中间，你让人们知道你要做什么，你给他们一定的时间来回应和挑战你。如果他们没有回应，默认情况下你会采取行动，因为你必须采取行动。你不能让他们因为不回应或不优先考虑这件事而拖延，但你要确保他们知道你要做什么，如果有问题，他们可以选择来找你。
还有一个我注意到了。我过去只说有易受攻击的，推土机的和主动的，但是我还看到了一个。我称之为进取型，在这种情况下，这个人确实有好的想法，他们确实倾听别人，他们有高度的同理心，但他们在交流中有点挣扎，也许他们在推动一些比他们应该做的更难的事情。他们可能会无意中打断谈话，他们可能只是有一点点敏感，他们很难接受批评。所以，他们并没有努力，但他们可能仍然有点难以获得反馈，与人互动，他们可能会比他们应该做的多一点。
我要强调的是，如果你雇佣了经前综合症患者，就要小心了。要么培训他们，如果他们无效，就把他们调离，他们不应该成为项目经理。推土机-全力开火。如果他们是低年级学生，给他们一个机会，但如果他们是高年级学生，他们正在做，不要处理他们，因为你可能正在处理自恋。如果他们有攻击性，试着减轻他们的担忧，这可能是一件不舒服的事情，或者试着去适应它也没关系。你可以和它一起工作，但理想的是有人是积极主动的。
库纳尔:这很有道理。出于好奇，您在该系列中处于什么位置？我发现每个人都在不同的时间轮班，那么你觉得自己最适合哪一个呢？
杰里米:有时我可能是个容易被说服的人，有时我可能是个好斗的人。随着我培养了更多的客户同理心，并告诉自己“不要只做我认为很酷的东西”，随着我学会了不要只做高管告诉我的事情，即使这是一个好主意，我设法让自己进入了主动范围。我确实认为，随着你积累经验，随着你越来越擅长一项工作，要想取得成功，就要越来越积极主动，并保持在这个范围内。
真的没有理由变得软弱或好斗。当你处于积极主动的范围内时，你可以根据所处的环境灵活地做出反应。有时你真的在确保你在听别人说话，有时另一端有很强的个性，你必须通过更努力地反击来显得更有侵略性，但这实际上不是侵略性，这是积极应对不同情况的一部分。
定义 API
API 是让一些东西与其他东西交流的东西
Kunal: 所以，我们都使用过 API，但是如何定义 API 呢？
杰里米:是的，我的父母仍然很难理解我到底是做什么的。简单地说，我认为 API——通常我关注的是 web API——API 是让一些东西与其他东西交流的东西。让我们更深入地了解一下，API 是代码和应用程序相互通信的一种方式。所以，当我去 www.gmail.com 时，发生的事情是浏览器去谷歌，谷歌发送数据，我的电子邮件信息，以及如何创建一个界面的信息——HTML 和 JavaScript 和 CSS——我可以看到。
这是一种方式——HTML 和所有这一切——是一种把计算机的东西翻译成我能看到的东西的方式，当我从 Gmail 上请求信息的时候。API 是一种格式，通过这种格式，应用程序可以访问 Gmail 并说，“我需要这些信息”，它以应用程序可以理解的形式提供这些信息。但这一切都是为了让应用程序能够互相交流。
我举一个更简单的例子，我通常只进入一个移动应用程序，我说“你有没有使用过一些不是由脸书开发的应用程序，但它显然与脸书有关？”就是这么做的，API 是脸书让其他应用程序与脸书交互的方式，这样你就不必直接与脸书交互了。我的意思是，除了直接与脸书互动。
API 的价值主张
在开发一个 API 之前，确保你有一个明确的商业理由，比如:启用新的第三方功能、扩大客户获取规模或增加粘性。
Kunal: 对。API 或开发者*台的价值主张是什么？你提到*台有许多商业模式和价值道具，你能谈谈吗？
Jeremy:API 可以在很多方面给公司带来好处。我们已经谈过——Box 有三种方式为我们带来客户，提供我们自己无法构建的功能，同时让客户能够将 Box 与他们拥有的所有东西联系起来。
在 Edmodo 的案例中，它是关于通过让第三方教育应用程序开发商来增强教育体验，这些开发商试图将应用程序放在教师手中，然后允许教师更容易地将应用程序带入家庭作业和课堂。有时候是粘性，有时候是追加销售，有时候是带来新客户。有很多型号。不过，在开始构建 API 之前，了解它们是什么是很重要的。
我曾经拒绝了一家独角兽初创公司的邀请，这家公司对 API 非常感兴趣——一半的副总裁、首席执行官和首席技术官。他们都准备好投资 API，并说他们已经承诺了——原因是什么？因为，如果我们不构建 API，我们将无法保持竞争力，我们将会失败。有一次，我在面试过程中遇到了销售副总裁。销售副总裁非常兴奋，我说，“那么 API 的用例是什么？”干瞪眼。我问“好吧，让我换一种说法，有哪些情况是——”因为这是一家消费者销售驱动的公司，它是一家依赖于客户直接收入的 BDB 公司，所以我问——“那么，有哪些情况是你因为错过了什么而无法达成交易——你无法解决客户遇到的这个问题，而你认为这个问题可以通过与合作伙伴整合来解决？”不多。
但是你知道，Box 只有不到 20 个人，用例、价值主张早就摆在那里了。但是即使在独角兽公司，它也不存在。他们试图构建 API，因为他们认为这很酷。我没有接受邀请，我很高兴我没有。我不会说是谁，但 API 没有走远。我在那里面试过几次，每次都有不同的人在运行开发者*台。每次，我都会分享一些我认为好的用例的想法，我会发现它们要么已经推出，要么即将推出，他们真的没有任何其他用例。
最后，几年后，当我再次在那里采访时，他们基本上说，尽管我不想分享他们的名字，所以我必须小心他们是谁，但这至少是数千万用户，一个非常大的公司，从逻辑上讲，他们需要一个*台，但他们评估了这个*台，并根据他们正在构建的东西，他们说他们需要一个 API。但是用例相当小。少量的用例非常重要，它们产生了大量的收入，但他们意识到他们不需要一个大规模的*台，他们随着时间的推移逐渐明白了这一点。
所以，你确实需要认真考虑什么时候推出一个*台是有意义的？我实际上说，在这里保守地玩，不要做，直到你看到一个关键的机会——要么带来新的客户，粘性，需要完成销售交易，知道这解决了你知道你的客户有一个问题。
API 的商业模型
在 Jeremy 工作的公司，API 的商业模式是提供一个*台，作为公司已经提供的面向客户服务的补充。在开发者至上的公司中，商业模式是将对 API 本身的访问货币化。
Kunal: 有道理。你发现哪些商业模式可以建立在 API 之上？我们讨论了价值主张和有价值的重要用例，这在您投资于 API 堆栈中的*台之前非常重要，但从中可以得出哪些商业模式呢？
Jeremy: 如果要我总结我所经历过的这些情况，这些都是*台对公司已经提供的某种面向客户的服务的补充。Box 提供了一个界面，移动应用程序可以上传文件、下载文件、组织和协作。Edmodo 是供教师与学生互动的，它有一个界面。这些 API 是对核心产品的补充。
在这些情况下，商业模式之一只是满足客户需求，获得新客户，为客户解决问题。是的，Box 有某种形式的 rev-share，但对我们来说更大的事情是通过第三方解决我们自己的客户问题。他们在其他时候测试货币化。在我离开后的某个时候，他们实际上变得非常有创造力，并鼓励开发人员建立集成。他们有一个 rev-share，他们基本上是说，如果一个高付费客户大量使用某个应用程序，不管该客户是否直接来销售并在后来添加了集成，Box 都会为付费客户使用该应用程序支付 rev-share。
在 Edmodo，这种模式更像是一种货币化游戏，他们希望教师或管理人员为这些应用程序付费，然后 Edmodo 和合作伙伴之间会有收入分成。市场既是为了增加粘性，让我们的教师积极使用该产品，也是一种追加销售，让教师和管理员有理由通过购买这些第三方应用程序来为 Edmodo 付费。
通过与合作伙伴分享收入，有一些直接的货币化。现在有些时候，你可以直接收取 API 使用费用。当我们让客户构建供内部使用的应用程序时，Box 确实对 API 的使用收费。在 Twilio 和 Stripe 这样的公司，产品基本上是一个 API，他们要做的只是对实际的 API 使用进行收费。然后我们谈到了那里，在*台角色的几十种商业模式中有 4 或 5 种商业模式，但希望这能让你对如何做有一些初步的了解。
独特的 API 产品管理挑战
项目经理需要是技术型的，并拥有开发人员的同理心。
Kunal:Jeremy，在 API 方面，产品经理面临的独特挑战是什么？
Jeremy: 我想我们已经讨论过一些了，但我首先要说的是，把这当成一个产品问题。这就是我认为一些 API *台可以独一无二的地方，因为它们必须是技术性的，但它们仍然必须具有客户同理心。这也是我在这里看到很多产品经理失败的原因。有时候他们很擅长于客户同理心，但是他们没有开发者同理心的经验。有时他们有技术方面的经验，但这还不够。
我见过很多构建的 API，它们有 RESTful 架构，但是它们仍然不是为外部社区的需求而设计的。所以，最重要的是把这当成一个产品问题，我认为剩下的就是要真正注意向后兼容性的挑战。了解 RESTful API 架构和 OpenAPI 规范将非常有帮助——这些是指导您的工具。
最好更深入一些，并从其他经验中了解:需要注意什么，以确保您的 API 将随着您需要扩展 API 端点、添加到端点以及基本上随着时间的推移继续增强您的 API 而扩展。
启动 API 的常见错误
启动 API 时的错误包括:为 API 提供的上下文太少，将功能基于内部 API 或移动应用程序，以及遵循“设置好就离开”的心态。
你看到人们在设计和启动 API 时最常犯的错误是什么？
Jeremy: 我们之前讨论过开发人员的同理心。我是如何在实践中看到这一幕的。第一个是，“让我们让工程师为工程师制造它。”把它交给工程师，不要给他们上下文。工程师们正在研究其他的东西，想着“我该怎么做？好吧，我们已经有了一堆 API，可能还有一个针对我们内部 API 的 OpenAPI 规范…所以，让我们做一些好的文档，让开发人员可以注册 API 密钥，然后启动它。”
这样你就有了一堆基于内部用例的 API。那些内部用例是什么？可能是根据你的数据库设计的。这就像一个产品经理说，“好的，这是我们需要建立的，让我们先去设计数据库，然后在数据库上加上一个界面，并假设它会工作。”这就是魔笛手应用程序的情况。
我看到的下一个错误是，他们说，“好吧，我们有一个用于我们构建的移动应用程序的 API，让我们向公众开放这个 API。”这比仅仅基于您的数据库启动这些内部 API 要好，因为至少它是基于某种外部用例的。那个移动应用是面向客户的，但它只是一个用例实验，非常有限。因此，它会工作得好一点，但仍然不会工作得那么好。
如何成功地做到这一点就是思考，“我们需要社区提供哪些应用？”并逆向工作。我写了一些博客，用来为可编程网络写一些东西，在那里我回顾了他们将要发布的 API。我可以告诉你，一些受欢迎的公司发布他们的 API 只需要看一眼，这是一个获取一些内部内容，在那里添加文档，然后发布的例子。我会采访这些公司，并确认他们正在这么做。他们在想什么？“哦，这只是一个 MVP，我们将得到反馈。”
产品经理知道 MVP 不是一个坏产品，它是一个最小化的产品。你可能已经计划出了更好的东西，一个长期的计划，并且你认为这是我们开始的地方。把我们的内部 API 和文档放在那里，这不是那样做的，这不是 MVP，然后他们想知道为什么会失败。他们也有这种哲学，你在产品管理的其他地方看不到，这种“设置它，然后忘记它”的事情。整个想法是，你不再需要业务发展，你可以让这个东西自助服务。他们还认为这与“如果你建造了它，他们就会来”相一致当谈到 API 时，我逐字逐句地听到“如果你构建了它，他们就会来”。
我们知道它在产品管理的任何其他地方都不起作用。你不能只建造你认为可行的东西。也许你是按照产品流程打造的，你还是要适当推出。事实上，如果我们真的看看这句话的出处，“如果你建造了它，他们就会来”。这是一部名为《梦想之地》的电影，在这部电影中，他们实际上带来的是白袜队球员的鬼魂，他们实际上接受了贿赂，输掉了一场世界职业棒球大赛。这是一部很棒的电影，但当你仔细想想，即使是在那部电影中，“如果你建造了它，他们就会来，”那里的哲学并没有真正带来你通常想要的那种客户。
发布 API 的最大成功
要想让你的 API 真正成功，离客户非常*，这样无论你在构建什么，都会符合他们的需求。
Kunal: 好了，我们已经讨论了用 API 发布*台的失败之处。在发布 API 和*台方面，什么对你的成功贡献最大？
Jeremy: 这又回到了开发人员的同理心。我想我可以在 Box 分享一个好故事，在这里我只是被迫做正确的事情。我最初没有应用好的产品过程，我们很幸运，合适的环境出现了。当我加入 Box 时，我专注于支持某些类型的合作伙伴集成。在 Box 有一个挑战，他们需要设定正确的目标。有一段时间，我们的目标是尽可能多地获得合作伙伴。这与获得真正创造价值的合作伙伴并不一致。我从事这些工作是因为我认为所有这些合作关系都很酷，这与销售团队产生了一些摩擦。他们越来越沮丧；当他们有明确的客户需求时，他们正在为这些集成花费时间。我没有完全理解“不要受销售驱动”，但我要说的是，盒子销售团队不希望公司受销售驱动，他们确实相信公司受销售影响，我们应该听取他们的反馈。
在与销售人员发生摩擦的这段时间里，我接到了一个客户电话，想帮助他们解决一些他们认为可能会出现 API 的问题。它最终变得非常重要，比我们意识到的还要重要。这是当时公司历史上的一个非常大的客户，他们要求一些非常一次性的功能。
销售团队实际上正要对这笔交易说不，因为他们明白不值得强迫工程部门构建真正定制的东西，只是为了完成销售而一次性完成。他们不希望公司如此受销售驱动。他们正要对这笔交易说“不”。我说，“嘿，这完全是你的决定，但要确保所有选项都在那里”基于他们实际尝试做的事情，定制的东西，“我认为如果我们构建几个我们知道其他客户可能会想要的管理 API，我们要求他们构建和维护其他真正定制的东西，并宣传这样做符合他们的利益，因为如果他们需要更新，他们可以自由地这样做。我们也许能够做到这一点，而不需要实际做任何我们必须为他们维护的事情。”这就是这场对话的开始，非正式地成为一个销售工程过程。
突然成为公司的销售工程师，这是我不想做的。我无法忍受，有时我真的很沮丧。但回过头来看，这是我职业生涯中最棒的事情，因为它迫使我培养了对客户的同情心，并与客户走得很*。从那里，应用适当的产品过程，并说继续前进，我们在 API 上构建的任何东西都与我们客户的需求保持一致。
在 Box 的例子中，在早期，花了一点时间和很多对这个*台有不同意见的人讨论，这是值得做的。我直接为客户解决问题，随着 Box 获得更多的数据驱动，我可以拿出数字向他们展示我们有一个小团队，我们正在创造价值，我们是销售过程中不可或缺的一部分，这可以证明进一步扩展*台是正确的，但同样是基于客户真正想要的。
发展开发者生态系统的策略
为了让您的开发人员*台成功，请在设计时牢记既定目标，将其构建为自助服务，并提供模范支持。
Kunal: 很有道理。发展开发者生态系统最有效和最无效的策略是什么？
Jeremy: 首先，了解用例，这可以追溯到开发人员的同理心。你想要什么样的应用程序？目标是什么？这是为了获得新客户吗？这是关于货币化，你想有一个应用市场吗？然后相应地设计一切。下一部分，对 Box 和 Edmodo 来说，是理解开发者关系。
正如 John Musser 在 10 大清单中指出的，“开发人员不能忍受的 API 工作”，第 8、9 和 10 项是关于 API 设计的。1、2 和 3 是关于支持文档和沟通。我在拳击馆学到的。在早期，我们的 API 不是 RESTful 的，它们没有遵循普遍推荐的设计准则。API 产品本身存在很多问题。我们可以通过构建一些解决方案来解决这个问题，根据开发人员的反馈，我们知道这些解决方案对开发人员很重要。此外，当开发人员有问题时，我们会积极响应。
很多时候，开发人员在试图构建我们的一个竞争对手之后来到 Box，我不会说是哪些竞争对手。他们会在最初听说一个竞争对手后来到 Box，然后说，“我们希望与你更多地合作，因为你实际上回答了我们的问题。”
我记得有一次，在一个星期天的 4 点钟，一个开发人员找到我，抱怨我们的 API 的设计。这很少见，因为我们构建了这些 API 库和工具来覆盖 API 本身的一些限制。但在 4:30 之前，他收到了我的一封邮件，说:“谢谢你的邮件，我们完全理解。是的，我们知道某些 API 不是 RESTful 的，这更像是 API 的风格，我们正在努力改进它。这需要一些时间。但与此同时，人们一直在研究我们的 API 库，这已经成功了。”那个开发者回应，只是完全惊讶。他没有和我们争论，他只是非常直接地和我们说话，他只是对在周日的 30 分钟内得到回复感到非常惊讶。
我总是说设计开发者*台原则上是自助式的，但实际上，开发者关系和开发者支持对*台的成功至关重要。
什么是开发者*台
当其他人建立了运行在你系统上的新业务时，你就创建了一个开发者*台。
Kunal: 公司如何把 API 变成开发者*台？你需要做的步骤是什么，你如何知道你是否应该这样做？一旦你开始做了，你怎么知道你已经达到了呢？
Jeremy: 我想我们已经讨论过用例，确保你只在真正需要的时候才构建 API，并相应地设计这些 API。或者我可以说，这实际上是一个*台，而不仅仅是 API。公司从 API 开始非常普遍，允许一个移动应用程序集成，但那真的是一个*台吗？
我想问你如何定义一个*台，尤其是一个开发者*台。这个词在过去十年中被频繁使用，在硅谷是一个相当流行的流行语。我有自己的定义，开发者*台并没有真正的官方定义。我可以说，它的核心是成为一个*台，应用程序可以完全建立在你所提供的基础上。
如果你只有 API，其他人正在构建应用程序，在其他地方运行它们，他们在连接，他们集成的方式是一个简单的功能，你有 API。当你开始看到一个完全基于 API 构建的产品时，就像 Box 的情况一样。侧边栏中的桌面应用程序不断与 Box 同步，并为客户提供特定信息，这是一个完全依赖 Box 的产品。
是因为科技是依赖的吗？还是业务有依赖性？我认为更重要的是，你有一个开始在你的*台上运行的业务，以及完全在你的*台上工作的产品。不过我有一个捷径，如果你有一个非常好的系统可以让应用程序集成到你的界面中，那么你可能已经有了一个可以在你的 UI 中运行的*台。虽然，我认为真正清晰的定义是，当你建立了它，新的业务被创建并在你的系统上运行。这真的是我最喜欢的关于建立一个成功的开发者*台的事情之一。
我的前两个真正开始建立产品团队，开发者关系团队，培训开发者倡导者成为创造这些工作的产品经理，并帮助人们开始他们的职业生涯。但也看到合作伙伴真正成功，企业形成，人们实际上创建了在你的*台上运行的公司，允许这些企业发生。否则这些商机永远不会出现。
确保 API 向后兼容
修改 API 时，尤其是终止 API 时，要遵循严格的时间表
库纳尔:这很有道理。当公司推出新版本的 API 时，你有什么建议给他们？您谈到了向后兼容性和突破性的变化，但是当您是一家推出 API 的公司时，如何确保向后兼容性和*稳过渡呢？
Jeremy: 从一个小的战术层面谈到向后兼容性，这可能是一个完整的演讲，如何确保你实际上有向后兼容性。我认为，如果您从输入或输出中删除任何内容，可能会中断通话。很明显，删除一个功能，会破坏一些东西。如果你改变一个函数的名字，那将会破坏程序。如果你改变输入，输入的名字，或者改变输出的名字，这将会破坏 API 中的一些东西。
如果你正在添加一个 API，添加一个新的端点，这可能是好的。如果您要添加一个新的可选输入参数，没问题。如果开发人员已经在使用那个 API，他们就不必使用那个输入。如果您向输出中添加了新的内容，但没有改变输出的结构，这可能也没问题。你不太可能打碎任何东西。尽管添加输出有一些注意事项，但是我们不要在这里深入讨论。
当你从根本上改变一个 API 时，警告，可能会有向后兼容性的破坏。有时候你不得不这么做。有不同的方法来处理它。如果这是一个安全问题，我说他们可以证明做更多的努力“我们需要立即打破这个东西。”当这种情况发生时，我还会查看有多少开发人员在使用它。如果它只是一个端点的输入，一些小众的东西，也许是更少的开发者。你也许可以直接向他们伸出手，说，“嘿，你能在接下来的 14 到 30 天内做出改变吗？”
如果它不是一个安全的东西，而且它是一个流行的 API，我是一个日落的大倡导者，贬低 API。因此，你基本上可以说，“我们有了一个新的 API 端点。所有现有的开发者，基本上你的 API 密匙都是在某个日期之前创建的。你可以使用这个 API，它将留在我们的文档中，并声明它已被否决，任何新开发人员加入并创建一个新的应用程序。您必须使用新的端点，不允许使用过时的端点。它们在某个特定日期被弃用，这意味着只有在该日期之前创建的应用程序才能访问它们。”
我也给出了免责声明，特别是当涉及到 B2B APIs 时，如果你想完全创建一个新版本的 API，从 V1 到 V2，而不仅仅是在这里或那里改变一个端点。假设您将需要维护旧的 API 至少三年。我看到一些公司在一年内就开始尝试。有时候是，但不是在 B2B 软件的世界里，它总是需要三年时间。
Webshooks Websockets 和 API
Webhooks 是事件发生时对端点的调用。Websockets 是具有大量活动的事件的信息流。两者都比不断轮询 API 来查看事件是否发生更有效。
Kunal: 有意思。现在让我们来谈一点技术问题。说到 API，什么是 Webhooks 和 Websockets？
Jeremy: 我鼓励人们在构建和设计 API 时，跳出框框思考。我是嵌入式集成的狂热爱好者，我可能很快会写一些关于这个主题的东西，比如如何让第三方安全地定制你的界面。另一个非常重要的领域是考虑 webhooks 和 websockets。这些基本上是对你的应用程序的实时通知。
我喜欢解释的方式是，如果我在采访中被问到，“你如何向一个 5 岁的孩子解释网络套接字？”对一个 5 岁的孩子来说可能不是，但是你有没有打过电话，打给西南航空公司。我喜欢西南航空，他们是所有航空公司中客户服务最好的。他们是第一个这样做的人。你打电话给他们，但此时没有代理，所以你不得不等待。现在，除了西南航空很少有 60 分钟的等待时间，对他们来说就像 5 或 10 分钟，他们与众不同的是，他们不会让你等待，只是听 10 到 15 分钟非常烦人的音乐，他们只是说“给我们你的电话号码，我们会给你回电话。所以，你不要坐在那里听，投票:他们准备好了吗？他们准备好了吗？他们准备好了吗？相反，西南航空会让你知道他们准备好了。那是一个网钩。这是一个反向 API。
在 Box 的例子中，我们有某些集成需要知道文件何时被上传到 Box，然后采取相应的行动。他们是怎么做到的？一种方法是轮询，它基本上不断调用我们的 API，可能是我们的更新 API，来查看 Box 中正在发生什么事件。“最* 10 秒内有更新吗？没有。好吧，让我 10 秒钟后打电话，现在有上传吗？”让你和你的伙伴不得不这么做对你来说是低效的。相反，webhook 是一个合作伙伴拥有一些服务器端点的地方，在那里他们让你知道上传何时发生。他们可以说，“我们正在尝试锁定，我们希望在 Box 中启用 webhook 来上传事件。”当上传发生，你有一个帐户，我们打电话给他们的 API，让他们知道上传发生。
Websockets，如果你好奇的话，基本上就是一个流。根据我们要寻找的事件类型，这可能比轮询或 webhooks 更有效。Webhooks 更多的是用于偶然事件发生时，我们应该让你知道那已经发生了。Websockets 可以是我们知道将会有很多活动需要我们观察。所以我们会一直听下去。这也被称为长期轮询。这是一种更有效的方式来保持对正在发生的事情的持续访问。
Kunal: 像聊天界面什么的。
杰里米:是的。
API 工具从 Soap 到 OpenAPI 的演变
自 Soap 以来，API 已经走过了很长的路，从 XML 发展到 JSON，然后，在短暂地涉足 API Blueprint 和 RAML 之后，围绕 OpenAPI 模式进行整合。
Kunal: 明白了。什么是 Swagger 和 API 蓝图？对于一个有兴趣构建自己的 API 并向第三方开发者开放 API 的公司，你有什么其他的工具推荐吗？
Jeremy: 我刚刚意识到，事实上已经有一段时间没有人问我 API 蓝图的问题了，但是我们现在可以回顾一下 API 定义的历史。API 一直在进化。以前有个东西叫 Soap，是个很重的 API。没有人喜欢再使用它，但是偶尔你会在遗留的企业软件中看到它。
不过，Soap 的一个优点是他们有一个叫做 WSDL 的东西，它是定义 API 的模式。您可以使用它来自动生成代码库，以便与 API 进行交互。我们走向休息，那里一切都更简单。事情有点混乱。
有一种叫 WADL 的东西，没人用。这是一种尝试定义类似于 WSDL 和 Soap 的 REST APIs 的方式。它飞得不是很好。随着 API 也从 XML 发展到效率更高、更受欢迎的 JSON，它在几年前很快超过了 XML。随之而来的还有狂妄自大。
我们又尝试了一次，因为灵活的 REST APIS 仍在回归 RESTful API 设计，一种一致的结构设计，而 Swagger 是设计这些的模式——使用 JSON 的 RESTful 格式。Swagger 也有竞争者:API Blueprint 和 Mulesoft 有一个叫 RAML 的东西。有一段时间我用 API Blueprint 而不是 Swagger。我一直认为 Swagger 真的是最好的，但有时，API Blueprint 通过一些社区开发者，有一种自动创建真正好的 API 文档的方法。
但是在这一点上，所有这些实际上都合并到了 OpenAPI 规范中。这基本上是下一代 Swagger，但他们称之为 OpenAPI，所以它真的是新标准。在过去，你可能会听到人们提到 RAML、API Blueprint 或 Swagger，但这基本上都是因为每个人都同意将 OpenAPI 作为官方标准。其中，除了 OpenAPI，还有其他工具可以使用。有许多工具可以生成文档。这让您可以做 Stripe 多年前做过的事情—三栏式文档。谷歌一下我说的“三栏 API 文档”一旦有了 OpenAPI 规范，就很容易生成它。
除此之外，我还见过很多不同的工具。APIMatic 专门基于该文档构建 API SDKs。有像 Apiary 和 Postman 这样的工具可以帮助创建 OpenAPI 规范。随着时间的推移，如果我们使用其他工具，如 Kong，他们正在构建自己的开发人员门户框架。
很多这样的工具允许你导入一个 OpenAPI 规范并自动生成文档，以及其他功能。实际上，我还没有看到孔关于这个框架的最新文章。据我所知，孔还在进步。我预计随着时间的推移，这个框架将构建您自己的开发人员门户，能够利用 OpenAPI 规范，自动管理核心产品的所有这些方面，以制定一个成功的开发人员计划。
何时向其他开发者开放 API
Kunal: 谢谢你的洞察力。我不确定我们是否已经解决了这个问题，但是一个公司应该在哪个阶段考虑构建并向第三方开发者开放它的 API？
杰里米:我们确实谈了一点。我在这里强调的是，当你清楚地有一个用例，并且你能看到有需求的时候，就去做。要么你觉得你可以接触到能给你带来客户的开发者，要么你看到客户有你自己无法解决的需求，然后构建这些 API 就开始有意义了。
对于不同的公司，这发生在不同的阶段。对于 Box 来说，这在早期是有意义的。我也和独角兽公司合作过，即使是 10 亿，100 亿，也没有意义。我咨询过的一些公司，他们刚刚突破了十亿美元大关。他们刚刚开始调查这件事，也许他们对这个游戏来说有点晚了，但不是那么晚。这没什么，他们更有信心，我们可以了解客户的需求，并说，“是的，你现在肯定处于这样一个阶段，如果你根据现有客户的需求构建 API，也许这是一个过渡到企业的软件和软件解决方案，它在企业中更有意义。现在，实际建造和发射这些设备开始变得有意义了。”不要因为觉得 API 很酷就进去开始构建。
PMs 面临的最大挑战
Kunal: Jeremy，让我们深入了解一下你的背景，谈谈你对其他项目经理的建议。当你开始一个新的产品角色时，你已经做过几次了，你发现他们最具挑战性的是什么，你是如何让他们通过这个挑战的？
Jeremy: 项目经理需要很好地进行有效沟通，而不仅仅是推动自己的愿景，从正确的人那里获得反馈。我见过的每个公司都有不同的流程，但更重要的是不同的文化。尽早认识尽可能多的人很重要。我鼓励那些已经面试过的人，在他们给我工作之前去面试更多的人。我想确保那些人认识我，我认识他们，并且我们认为我们会有一个良好的关系。
对于工程师来说，不同的工程个性。当我在 TradeShift 工作时，我与旧金山、丹麦和中国的工程师一起工作。丹麦非常直接，他们不粉饰太*。旧金山有点像糖衣。中国，在中国文化中，他们比在美国粉饰得多。非常间接的交流方式，你必须意识到这一点。你还必须意识到，有些工程师不喜欢产品经理。哪些工程师会更坦率地告诉你他们的担忧，哪些会不舒服，会成为好士兵，但在不舒服时不会分享？哪些人真的会因为不想和项目经理一起工作而耍花招？
你还必须确保与销售人员有良好的沟通渠道。如果你在 B2B，你就和客户成功在一起，和那些从客户那里得到反馈的人在一起。我学到的一个小秘密是，当你在一个有几百人的公司时，销售部门的某些人，客户成功部门的某些人，更擅长整合反馈并与你分享。不一定是管理职位。有些人只是更乐意与其他团队交流，你必须知道这些人是谁。他们将会是你更好的沟通来源，来跟上正在发生的事情。
什么是伟大的项目经理
是的，我也看到了。这很有道理。你已经提到了这一点，但是在你看来，怎样才能成为一个优秀的产品经理呢？显然，沟通是其中的一个关键部分，但是他们有什么共同的品质，他们在你工作过的这些不同的公司中是共同的吗？
Jeremy: 是的，我们已经讨论了客户同理心和成长心态方面，我认为我们可以在这里深入探讨。我要说的是，你不再需要工程师和 MBA 的结合了。它确实有帮助，因为拥有商业技能和技术技能是好的，但还有更多。
我将产品管理技能分为两个方面。有增长思维，和客户同理心。我强调，不管你来自什么样的背景，你都必须有这样的背景。你必须拥有这两者，你必须在这两方面都很出色。接下来是实用技能。我说有一些事情是所有项目经理都必须擅长的，然后在这些技能中有一两件是你必须擅长的。这涉及到设计技能、技术技能、沟通技能和商业意识。你必须具备最起码的能力，能够相当好地沟通，有足够的技术知识，以便能够与工程师交谈，有足够的设计意识，以便能够与设计团队合作。然后，你必须在其中一个方面表现出色。
这就是为什么，在我们组建产品团队时，我们知道背景多样化很重要。我们现在有来自不同背景和教育背景的人，因为拥有专门从事前端工作的人会有所帮助。一名前设计师，他不仅知道如何进行设计，而且真正了解设计一个好的 onboarding 界面的最新知识和可用性，总体设计前端。
那些从事 API 和面向开发人员的工具工作的人，有一个有工程背景或计算机科学背景的人是很好的，这样他们不仅知道如何与工程师合作，而且他们真的知道如何设计更具技术性的东西，偶尔是代码和原型。这就是你开始多元化团队的地方。也许有那些在管理工具或定价决策方面更有经验的人，他们可能是更多的企业项目经理，那些有 MBA 或商业背景的人。你必须在所有这些方面都很好，但你必须有你的专长，有些人说是超级能力，这只是在其中一个支柱方面很棒。
如何实现 10 倍的成果
Kunal: 很有道理。Jeremy，你有什么建议给其他想要达到我们都想要的 10 倍成果的产品经理和专业团队？作为一个产品经理，尤其是在*台产品管理方面，怎样才能做到超级成功？
杰里米:我在商学院的一位教授罗伯特·凯利写了这本书，或者说他与人合著了这本书《培养明星员工》他教了很多与成长思维相适应的秘诀，关于什么是明星，以及他们在职业生涯中的位置。人们不是从明星演员开始的。你的第一份工作通常不会做得那么好。
我想说，如果你有成长的心态，你会经历几次失败并从中学习。但实际情况是，在人们职业生涯的某个时刻，他们会不断成长，然后突然变成明星。大多数人都没有达到这一点。发生的事情是，他们已经学到了某些东西，他们弄清楚了某些事情，如何更有效地工作，如何更有成效，如何更有效地沟通，以及如何更好地执行。
我们谈论了很多这些事情，比如交流的需要，一些战术上需要注意的事情。我要说的是，1)有成长的心态，有同理心，放下自我，学会如何更快地学习。简单来说，关于发展明星员工，我认识的项目经理已经有了 10-15 年的良好职业生涯，他们升职了——他们都学会了如何更快地学习。
当我进入产品管理领域时，并没有太多关于项目经理实际上是什么的信息。这些年来，我从培训非工程 MBA 的人身上看到了真正需要的东西，也看到了 Slack 上的社区分享博客和时事通讯，这就是一个好的产品经理。会议形成，产品学校和其他新兵训练营和培训课程形成。
现在，我们终于有了以前没有的所有信息，因此人们不得不艰难地学习。他们必须学会如何更快地学习，尤其是随着技术的进步。我发现这是非常重要的，这符合成长的心态。我失去了我的思路，还有一件事，我真的想强调，从战术上来说，实际到达那里。所以，最重要的是不断学习，跟上新兵训练营、博客、播客。请继续努力学习，因为社区中会有更多有用的东西。
读什么
作为一名初露头角的产品经理，请关注 Lewis Lin 的《产品经理访谈》中的最新问题，以及 Nir Eyal 的《成功产品的实用性/游戏化技巧》。
Kunal: Jeremy，你最*在读什么书，或者文章，或者博客文章，让你印象深刻？
最*，我在读 Lewis Lin 写的关于产品经理面试实践的最新文章。我在这个领域已经有一段时间了，面试也有了很大的发展。几年前，我们曾经问过估算问题，“一架飞机能装多少个高尔夫球？”我们越来越倾向于行为访谈。实际上，根据我 11 年的经验，我已经确定我需要更多的练习。在这两种情况下，这对准备未来的面试非常有帮助，而且对更好地理解产品感也很有帮助。
除此之外，我还关注播客、博客和时事通讯。我发现产品经理总部非常有帮助。我不断从设计专家那里了解到，尤其是在客户入职方面，已经有了相当大的发展。这就是我一直关注的。
基本上，年前 iOS 刚推出的时候。有一个很大的推动，使注册流程尽可能简单，因为你不想在注册期间下车。但是，我们会看到你有很多用户注册，你必须看看管道的其余部分。用户可以注册，你需要他们活跃，回来成为活跃用户。可用性专家进行了大量的实验和更新的研究。他们尝试不同的事情，看看什么是创造一个更健康的入职流程的有效方法。另一本书我可以推荐，Nir Eyal，我认为他在这本书之后写了一些新的东西， Hooked 。那是我强烈推荐的一个。
库纳尔: 坚不可摧。
Jeremy: 是的，因为我们从 Hooked 上看到的，这是一个很好的体验来源，也是一个很好的用户体验知识来源。我记得在游戏化的时代。人们认为我们应该让一切都像游戏一样，Nir Eyal 最终站出来解释说，“不，这不是让一切都像游戏一样，这是关于从游戏行业中吸取可用性知识。”
他知道自己，习惯创造可以是一件好事；它可能非常危险，他看到它已经被滥用。我知道他在写一些关于如何真正创造习惯而不是上瘾的新东西。他对此非常强调。作为一个有同情心的开发者，我对此很重视。
有书籍问世，仍有来自社区、文章、博客和播客的内容，还有课程内容。我一直在产品学校教书。我觉得这是个很棒的新兵训练营。我也一直和卡内基梅隆大学保持联系。现在，作为他们 MBA 项目的一部分，他们在 MBA 之外又增加了一个产品管理硕士项目。他们正在尝试，但这是一个很有趣的尝试，有可能创造一个专业。我知道斯坦福也有一门课程，是关于产品管理的。
在新兵训练营的世界里，也就是现在的学术界，有很多选择来学习更多关于产品管理的知识。我当然鼓励每个人真正看看这些。那里有很多机会找到适合你需求的教学方式。
很好，非常感谢你，杰里米。很高兴和你在一起。人们在哪里能找到你？
杰瑞米:你可以在 LinkedIn 上找到我，也可以随时查看我的咨询公司，它是 APIStrategist.com 的。
库纳尔:牛逼。再次感谢你杰里米。很高兴与你交谈。
杰里米:谢谢，和你聊天也很愉快。
库纳尔:牛逼。
与 API 布道者 Kin Lane 的播客
Ep。3:空气污染指数布道者金·莱恩
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
今天，我们非常高兴地邀请到了《邮差》的首席传道人 Kin Lane 。在过去的十年里，他一直在帮助组织思考他们的 API 生命周期，优化他们的业务流程。在他著名的博客网站 API 布道者上，他仍然是一个多产的作家。
Kin 分享了他对 API 治理的看法，关于弃用和版本控制的指导方针，以及他在 Postman Collections 中看到的有趣的实现，等等。
德瑞克·吉林，Moesif 的首席执行官是今天的主持人。
Moesif · Kin Lane, the API Evangelist
目录
- 0:20 金·莱恩进入阿皮斯的路径以及是什么让他成为邮递员
- 3:11API 有多普遍
- 6:25 在整个公司范围内标准化 APIs】
- 8:07 确保大型公司与初创公司的 API 治理
- 9:32 DevEx 大于文档
- 12:18 测量开发者激活和成功
- 16:58 如何评价 DevRel
- 19:50 什么是 APIOps
- 22:25 版本控制指南
- 28:37 HTTP 头非常重要
- 29:55 了解你的顾客，这样你就可以交流变化
- 32:12 针对安全漏洞强制升级
- 34:18 厌倦了支持多个客户端库
- 36:08 稳定您的 API 生命周期
- 40:02graph QL 有市场吗
- 43:48 有什么好的 API 资源吗
【德瑞克·吉林(Moesif): 欢迎来到 Moesif 的播客的另一集。我是德里奇·吉林，今天的主持人，API 分析*台 Moesif 的首席执行官。加入我的是 Kin Lane，他也被称为 API 布道者，是 API 的资深成员，目前是 Postman 的首席布道者。很高兴你今天能来，肯。
肯·莱恩(邮递员):谢谢你邀请我。感激不尽。
为什么是 API 福音传道者的邮递员
Kin 在 2010 年创立了 API 布道者，作为他咨询业务的代言人，帮助组织思考他们的 API 生命周期。到 2019 年，Postman 是他表现最好的工具之一，因此很适合他，他现在在那里处理他真正渴望的问题。
德里奇:一头扎进去。我很好奇，你是怎么进入 APIs 的，是什么把你引向了 Postman？
Kin: 所以从历史上看，我是一名数据库人员，我将在这里与自己约会——1988 年是我的第一份工作。如此之快，互联网出现了，我正在构建数据库驱动的 web 应用程序。大约在 2006 年，我负责 SAP 在北美的活动，从聚会到 50，000 人的 Sapphire 旗舰活动。我开始以一种新的方式使用亚马逊 API 来扩展基础设施。我以前从未以这种方式使用过 API。大约在同一时间，我开始收到做更多移动应用程序的请求，当时我工作的公司负责 SAP 在北美的所有活动，我们接手了谷歌的所有活动。因此，当我在 2008 年和 2009 年运行 Google IO 时，我被要求开发更多的移动应用程序，然后我为 Google 运行的最后一个应用程序是在他们发布第一款 Android 手机的那一年。
因此，我看到了 web APIs 所扮演的角色，到 2010 年，我开始了自己的咨询生涯，API 布道者就是我的代言人。然后我花了十年的时间帮助组织思考他们的 API 生命周期，以及如何优化和更有效地做事。到 2019 年，Postman 是我工具箱中性能最好的工具之一，当我问人们使用什么工具时，Postman 是每个人的首选。
因此，当谈到真正应用我在过去十年中学到的知识，并在 API 生命周期中遇到困难时，Postman 真的是我可以去工作的地方的首选。老实说，我有一个女儿正在读大学，所以我需要一份工作，以前的工作并不能支付大学学费，我现在有点喜欢有医疗保险。我开始解决我真正想解决的问题，我开始实践我过去十年来一直宣扬的东西。所以很适合。
API 有多普遍
所有主流公司现在都意识到他们应该做 API。API 无处不在，在我们的个人和商业生活中，它们隐藏在我们所接触的一切事物之下。
德里奇:牛逼。在 Moesif，我们是 Postman 的超级粉丝，甚至在我们的上一家公司也是——伟大的产品和伟大的 UI。有趣的是，在 API 和开发者关系中出现了所有不同的角色——开发者体验、产品管理、开发者关系等等。它会变得很模糊。这一切意味着什么——这些不同的角色是什么，在 Postman 是如何组织的？
Kin: 谈到 API 生命周期，我想说越来越多的人参与到对话中。对我来说，这是 web APIs 或 RESTful APIs 如此成功的原因之一，因为它们更简单，技术性更低。最简单的形式是一个 URL，带有一堆任何人都可以使用的查询参数，所以使用起来简单多了。
当你有一个像 Postman 这样的工具，允许你在不写代码的情况下进行 API 调用，这就开始打破传统 IT 和业务之间存在的一些门道。我们刚刚开始看到越来越多的人加入到对话中来，他们有大量的问答和测试人员需要实际测试 API。我们也开始看到更多的业务利益相关者站出来，希望获得来自 API 管理和分析的意识，要求仪表盘和更多关于他们用来推动业务的 web 和移动应用背后的 API 关键部分的见解。
我们真的看到，随着 API 生命周期的扩展和增长，API 不是我们问的“我们应该做吗”，而是所有主流公司现在都意识到他们应该做的事情。事实证明，向业务利益相关者开放这一层意识非常重要。我们看到销售团队作为我们迎合的角色出现。根据 Postman 发布的 API State 报告，我认为上次有* 13，000 人填写了它，我们只是看到更多这样的角色出现。我们还看到，在 Postman 内部，我们看到越来越多的营销人员使用 Marketo 的 API 或使用 Salesforce APIs 结合 Postman 的集合来提取数据，以了解正在发生的事情。
因此，API 无处不在，它们在我们个人和商业生活中接触到的一切事物之下。我认为越来越多的人开始意识到这个事实，他们需要工具来帮助他们理解这个在我们脚下展开的世界。但也在快速成长、快速变化和发展。
在您的公司内标准化 API
邮递员的收藏让每个人都朝着同一个方向划船。通过建立一个 API 调用，将其保存为一个集合，然后在其他利益相关者之间共享，您真正开始标准化人们如何交谈、交流和解决问题。
当然，当谈到像邮递员集合这样的事情时，你见过哪些更有趣的事情，或者当不同的公司尝试和实现新的 API 时有哪些更有趣的惊喜。
一旦你有了一个运行一组测试的集合，你就可以开始以一种标准化的方式*等地度量一个组织中的所有 API。因此，人们开始不仅考虑测试，还考虑治理，这揭示了同一组织中不同的 API 是如何不同的。该公司可能是 Adobe 或微软，但他们如何在每个团队中构建 API 变化很大，我不认为人们总是能看到这一点。一旦你开始标准化、保存集合、运行测试、共享它们以及跨团队合作，你开始看到一些奇怪的事情出现。我认为人们真的意识到我们并没有像自己想象的那样朝着同一个方向前进。
因此，当你能够建立一个 API 调用，将其保存为一个集合，然后在其他利益相关者之间共享，并说“只需点击运行，看看你会得到什么，”你就开始真正标准化人们如何交谈、交流和解决问题。我想说，人们并不总是意识到每个团队对待 API 的方式有多么不同，这些跨组织的差异让很多人大开眼界。
如何进行治理
为了让人们坚持合规，你必须投资于培训、教育和围绕治理的反馈循环，否则你最终会发现人们并不真正关心你
derrick:你认为在大公司和小公司的 API 治理上有什么不同吗？
金:嗯，我想说这更多的是人类的一面。当你在一个较小的公司，你想做治理，你有更少的表面积，更少的人参与其中，所以有时更容易制定。但是，随着团队数量和 API 数量的增长，这变得更加人性化——你必须四处走动，教育人们什么是 Postman，什么是 OpenAPI，以及如何使用 OpenAPI 来定义你的合同。哦，接下来是你如何使用 Postman 来测试、监控和执行那些 API 调用，以一种我们可以报告治理的方式。
我想说，最大的区别实际上只是投资于人力培训、教育、研讨会和围绕治理的反馈循环。否则，你最终会发现人们并不真正关心，人们很反感，说“嘿，我们不想这么做”，因为我们没有给出任何关于什么是治理、为什么治理、那些测试是关于什么以及报告是什么的反馈。因此，团队越大，你就越需要围绕为什么要治理、治理是什么以及治理的演变来展开讨论。因为如果你得不到团队的支持，事情将会变得非常困难。当你的公司规模较小时，这就容易多了。
DevEx 不仅仅是文档
文档和门户都是赌注。接下来是对你自己的 API 消费进行分析、使用和洞察，但你的目标应该是通过提供对开发社区中其他人正在做什么的洞察，使之成为一种共享的体验。
德里奇:肯定。继续下一个领域，这是关于开发者体验的。你会听到很多关于开发者同理心的说法，但是首先成为开发者意味着什么呢？
哦，是的。我认为开发者体验肯定始于围绕你的 API 的门户和文档，但是为他们提供分析、使用和对他们的 API 消费的洞察。早期的 API 管理实际上是为提供商开发意识，在它前面设置一个速率限制，测量它，然后提供分析，以便您了解您的 API 是如何被使用的。那些内化了这一点并真正关心他们的开发人员的人，也与他们的开发人员分享这一点——那种意识，那种洞察力，他们的那一小块馅饼。因此，给开发者一个仪表板、分析和见解，以便他们可以提高他们的使用，了解他们在使用什么，或者他们没有使用什么，或者他们的应用程序是否非常健谈。然后分享其他开发者在做什么，类似行业的人在做什么？与其他开发人员相比，我的使用情况如何？因此它成为了一个共享的开发者体验。
所以这不仅仅是“嘿，你的文档很棒，”我作为一名开发人员通过你提供给我的仪表板获得了这种意识，但我也感觉我是社区的一部分。我看到其他人是怎么做的。我可以改进我的应用程序和消费。我可以让它们不那么啰嗦，因为我正在从 API 中抽离出来。但是，哦，看这里，有一群开发人员在使用 web hooks。我甚至不知道网钩。因此，我想说的是，API 带来的洞察力和意识的社区共享，API 管理带来的洞察力和意识，并确保他们关注，这为他们的世界提供了价值。
然后我会说你有一些可操作的目标来激活它们。那么，如何通过更好的和不断改进的开发者体验来激活和增加开发者的参与度呢——通过向他们提供更多的见解和理解。
衡量开发人员的积极性和成功
在测量激活之前，我们需要定义什么是*台和 API，以及*台和基于*台的应用。我们衡量和报告的内容，以及我们如何激励和推动开发人员前进，会因您是在构建移动应用、web 应用、widget、物联网应用还是在进行类似 iPaaS 的集成而有很大不同。
德里奇:爽。说到激活，有没有方法来衡量开发者的激活，开发者的成功是什么样的？
金:是的，我的意思是那真的很难，因为我一直在推动这个想法。例如，当我注册成为 Twitter API 的开发人员时，我必须注册并说，哦，这是我正在构建的应用程序，给你一个标题和描述，然后 Twitter 才会给我密钥。大多数时候我不知道我在建造什么。尤其是作为 API 传播者的我，我通常不会构建一个 app，我通常只是踢踢轮胎，写一个故事，了解什么是可能的。所以应用程序的范例从来都不适合我。但我也可以说，我是一片特殊的雪花，在这种情况下，我尝试了许多不同的 API，但从未开发过应用程序。但即使对于那些正在构建应用程序或应用程序概念的人来说，我只是在构建一个集成，我只是希望 Twitter 数据在谷歌表单中。我只是希望能够整合我每天依赖的 SaaS 服务，以帮助理解这一点。
所以我认为，在我们能够交付合适的开发者体验之前，在我们能够开始真正有效地衡量之前，什么是应用的概念需要发展。如果有人只是在做一个类似 iPaaS 的集成，那么与我正在构建一个移动应用程序、一个 web 应用程序、一个小部件或一个物联网应用程序相比，这些指标将会有很大的不同。因此，衡量标准的类型，我们衡量和报告的内容，以及我们如何激励和推动开发人员前进，这种体验将会有很大的不同。我想说，这又回到了实际使用我们 API 的人的角色上。是铁杆后端开发人员在开发移动应用程序，还是 it 业务人员在寻求更好地协调和连接他们经常使用的系统？因此，我认为人们必须开始真正理解什么是应用程序，或者这是否适用，我们是否应该将应用程序的概念抛之门外。我们应该让用户注册，然后开始玩东西吗？我认为这是我对许多 API 感到沮丧的原因之一。
如果我在 Twitter 上，我必须去 developer.twitter.com 的一个单独的区域，当然我可以验证并注册我的 Twitter 帐户，但我仍然必须在那里创建应用程序并获取我的指标。总是在另一个地方。如果你使用像 Cloudflare 这样的解决方案，他们会做得很好，我作为一个 Cloudflare 的用户登录到页面上的每个控制面板小部件的后面，不是每个人，但大多数人，在底部角落有一个 API 按钮，我可以用键抓住 API 调用。要调用 API，我只需获取它，复制并粘贴到 Postman 或其他中，然后点击 send。我的帐户不是独立的；我的钥匙没有分开。因此，我认为开发者体验的概念需要与应用程序体验或*台体验相结合，我们需要迎合的整体*台体验是什么，以使人们使用 API。我认为，一旦我们克服了当前关于什么是*台与 API、*台与基于*台构建的应用程序的概念中的这种摩擦点，我认为你将会看到全新的使用类型出现，以及为人们测量和创造体验的新方法。
德里奇:这是一个非常有趣的观点，在这种情况下，它不是关于拥有单一的开发者体验，而是实际上更像是一种思维方式。它嵌入在应用程序中，不管你是哪个团队的成员。
Kin: 是的，这种想法会更符合你的商业目标。太多了，太频繁了，API 是完成的次要项目，我们选中了那个框。它与整体核心业务目标不一致，因为它是在这里完成的，你可以在这里链接到它。不，它应该是我们的*台体验和集成的一部分，像 Zapier 这样的 SaaS 集成是司空见惯的。用 API 实现低代码/无代码自动化是很常见的，这不符合边栏中关于什么是开发人员体验的叙述。它应该只是你的整体*台用户体验。
如何评价 DevRel
开发者关系应该通过将你的 API 和开发者周期转化为解决现实世界商业问题的东西来衡量，并在这个过程中为我们带来客户
那么，如果我是开发人员体验团队的一员，应该根据什么来评判我呢？是收入，还是别的什么？
Kin: 难说。为了收入，你很快就会惹怒一群人。根据你的开发团队，你很快就会把他们惹毛。也许这是导致与整体业务目标不一致的原因之一，作为开发人员，我们是这些特殊的雪花，不会让我们销售。
但是我们也需要支付我们的薪水，公司必须赚钱，否则我们都会失业。所以我认为我们需要开始一个更诚实的对话。但是，我想最终对我来说，我希望他们是 DevRel 或福音传道者，或者任何介于两者之间的群体，我希望我所产生的影响能被衡量。所以这将是我讲述的故事，博客帖子，网络研讨会，白皮书，案例研究，诸如此类的东西。因此，我应该被衡量的故事和这些故事的影响，我衡量高触及。
在 Postman 中，我必须报告的一个 okr 是我添加到 Postman 网络的收藏数量。现在，这可能看起来非常邮差专用，但这不是因为邮差收集对我来说是一个商业价值的衡量标准，以及我们为什么要这样做。第一个总是“这是完整的 API 参考集合”，这是所有可能的东西。这是非常好的开端——也非常无聊。下一个系列始终是一个更加 DevOps/APIOps 的业务工作流系列。好的，如果这是一个电子商务 API，这是第一个引用集合——所有的端点。但是，下一步是搜索产品，将其添加到购物车，检查购物车，获取发票。好的，我想要完成所有这些步骤的集合，并且作为一个独立的集合。因此，正是这些第二代和第三代系列开始了解商业价值是什么，以及我们为什么要这样做。
所以，这些是我认为 DevRel 应该衡量的东西。我如何将我们的 API 和开发周期转化为解决实际问题的东西，一个真正的业务用例，然后为我们带来客户。所以“给我们带来客户”可以与我们分离，让我们感觉温暖和模糊，就像 DevRel 人在我们的小泡泡里一样。但我认为，在此之前的行动仍然必须存在，我们必须对此负责。
APIOps 定义
APIOps 是与 API 相关的任务的组合，用于创建您的企业功能版本，这是您日常工作中切实可见的东西
derrick:这提出了一个关于 APIOps 的非常好的观点，试图将它与商业价值结合起来。但是所有这些不同的术语是什么意思呢，APIOps，API Observability，还有一些其他的说法。
Kin: APIOps 对我来说只是 DevOps 的一种延伸，devo PS 是我们一天中为了完成工作而必须做的一些小的增量事情。它建立数据库，索引数据库，推送代码，CI/CD，作为 CI/CD 的一部分运行测试。所以，把所有这些任务分解开来，看着它们，然后作为一名开发人员说，这是我一天需要完成的事情。
随着您之前谈到的角色的扩展，DevOps 对他们来说是什么样的呢？如果我是一名 QA 测试人员、分析师、销售人员或营销自动化支持人员，我每天需要完成哪些小任务。如果你从事市场营销，Salesforce 的 Marketo 是我依赖的*台之一。但是我需要完成的那些功能性的小事情是什么呢？回到我所说的参考资料，Marketo 的参考资料是您可以使用 Marketo *台做的所有事情的完整菜单。APIOps 或 DevOps 是我们如何将一个或多个 API 调用组合成在我的日常工作中实际可见的东西。
作为一名开发人员，一直到这些其他的业务角色，对我来说最关键的部分是定义它们是什么，因为这成为你的企业能力的一个版本——这是你每天能够完成的。将它们定义为集合，使它们可执行、可用和共享，我可以说“嘿，看，我在 Salesforce 和其他公司之间建立了这个很酷的新工作流。”我可以捕捉到它，然后与团队成员分享，并说“嘿，这样做。”然后，他们可以进行调整，使其为他们的世界服务，这是一种运营级别的协作。我认为这是橡胶在未来十年真正要遇到的问题。
版本指南
关于版本化有很多观点，从根本不像网飞那样做，到 OpenAPI，你需要在语义上对你的代码、集合和文档进行版本化。无论哪种方式，版本化都归结为拥有一个策略，实现交流，并确保，根据您的受众，您以正确的方式交流变更管理计划。
我真的很喜欢从协作的角度来看，如何让更多的人使用这些不同的 API 和各种集合。但在某种程度上，我们必须摆脱它们——所有这些产品都有一个生命周期。在弃用指南和版本指南方面，你见过哪些好东西，人们通常在哪里搞砸了？
就 API 生命周期而言，版本控制是艰难的。有很多关于如何做的观点，甚至有很多关于不做的观点，认为你根本不应该做——版本控制不好。对我来说，版本管理只是真正开放和诚实地对待变化。这是关于改变管理和有一个计划。如果你的计划实际上不是对你的代码或者你的 API 集合，或者你的文档进行语义版本化，那很好，但是要有一个计划，并传达它，展示它如何实际上允许你更快地移动，产生更少的摩擦。如果你只是把它扔在那里，说我们不版本化是因为我们不想，然后你没有变更管理计划，那不是你想要走的路。两种方式我都见过。我知道网飞在没有版本控制的情况下做得很好，他们有一个完全不同的策略。如果你想了解更多，你可以收听他们的工程博客。
语义版本控制是一种主导，实际上有一个策略，定义什么是变化，然后如何在团队内部沟通，然后在外部与我们的消费者沟通。对我来说，这才是版本控制的核心。这不是做这件事的技术细节，而是我们有一个计划，我们围绕它进行沟通，当我们谈论它时，人们理解我们在说什么。
OpenAPI 具有语义版本控制，是稳定这种交流的方式之一。这是第一版的合同，这就是我的意思，这就是你将要得到的。当我们进入 1.2 版本时，这是你将得到的，这是我的意思，这是你将得到它的时间表。然后，你要就变化传达期望:“好吧，我们现在是第 12 版，第 9 版将会消失，因为我们只支持 X 个版本。“所以真正有意义的不是语义版本化，而是我可以告诉你什么是版本 9，什么是版本 10、11、12、13。我可以有效地传达版本 9 将被弃用的时间框架。
我该怎么和你交流呢？许多拉斯特法里教徒和相信使用网络的人认为，版本应该在 API 的头中，而不应该在 API 的路径中。现在，如果你真的在这个空间工作，你会意识到不，实际上你遇到的大约 70%的版本都在这条路上，这就像违背了拉斯特法里教徒所信仰的一切和从 API 神那里流传下来的经文。但问题是许多开发人员不知道头文件的存在，所以他们甚至不知道在头文件中寻找版本。因此，围绕变化的交流中断了。当它在路径中时，它就在你的面前，很容易理解，也很容易在主要版本之间导航。这表明了沟通的重要性，这也是变革管理的关键所在。我们可以说，“嘿，你在这个版本上；嘿，我在这个版本上；嘿，你需要换到这个版本。”如果你看看 Stripe，当你第一次进行 API 调用时，他们会把你绑定到一个版本。这就是你现在的版本。这就是人们上船时的心态——你使用的是这个版本，这就是你的条纹环境。别搞砸了。我在那个环境下工作，直到我说我想去另一个版本。因此，版本控制实际上就是制定一个策略，实现交流，并确保根据您的受众，您以正确的方式交流这些东西。
你还可以做其他事情，比如你可以传递一个日落标题:我们什么时候会反对这个，然后随着时间的推移，这个标题可以用来以不同的方式传达这个信息。我看到人们在版本控制方面最大的损害和问题是他们没有交流，没有计划。如果你正在发布一个 API，你应该有一个弃用日期:我计划支持我们刚刚创建了 18 个月的这个版本。大多数 API 不会这样做，所以它可以永远存在。但是通常发生的事情是因为我们从来没有沟通过这个 API 可能会在下周消失，因为我从来没有真正沟通过它什么时候会消失，或者它会存在多久，所以我保留下周让它消失的权利。我认为这种交流的中断是我们在这个领域看到的最大的罪恶。
HTTP 头非常重要
最聪明的博士工程师往往不知道 HTTP 头。每个人都应该参加 HTTP 的课程，学习头部、查询参数和主体参数。
德里奇:完全同意，传达任何反对意见或版本变更的信息真的很重要，尤其是你提到的，将它添加到 URL 中。现在有了像网钩这样的东西，它就在你的面前。有时这些标题可能会被埋没，而您看不到标题。
金:我总是惊讶于我职业生涯中遇到的那些超级聪明的博士级程序员，他们不知道头文件。我永远不会因为不知道这一点而说某人愚蠢或愚蠢，因为我们周围有太多的事情发生，我不认为每个人都上过 HTTP 课程。他们在做 C++，他们在做核心的东西，他们只是从来没有真正了解过网络和 HTTP 是如何工作的。当我终于明白时，我就像“哦，哇，好吧，现在我知道了。”但是有很多人非常聪明，非常有能力，但是就是不太明白 HTTP 头是什么，里面有多少。它与查询参数或主体参数有什么区别。我不认为人们对此有太多的认识，应该为人们提供更多的培训和研讨会。
KYC，这样你就可以交流变化
作为变革管理沟通的一部分，你需要有一个很好的逻辑步调来来回回地漫步。如果你知道谁是你的客户，并且经常与他们交谈，那么你就可以快速前进。
一个 API 产品经理应该在多大程度上推动某人升级到下一个版本或者新的 API？如果这些弃用标头被埋没了，还有什么其他的通信方式呢？
Kin: 这是它超越 API 技术并进入商业领域的地方。有一次，我正在为一个打印 API 设计新版本。在最老的版本上，我们只剩下五个用户，所以让我们把他们都赶走。他们四个人去了。第五个人每周一早上提交一份价值 500，000 美元的打印作业。我们没有强迫他们进行版本和切换。建造它的人走了，他们不知道如何切换它。整个公司这一周的印刷量取决于这个，它是 50 万美元。你猜怎么着？我们不再强迫他们。你知道，像这样的事情超出了技术控制范围。但是我想说，作为变更管理沟通的一部分，你需要有一个良好的逻辑步调，向前漫步，向后延伸。“嘿，我们有没有落下任何人。嘿，你们在后面。你需要什么来理解未来并继续前进？”
不要支持太多的 API。看看 Salesforce，他们仍然支持他们所支持的第一个 API。他们赢了。那是 20 年后的事了。我是说，你想这么做吗？所以，这又归结为沟通。你只需要知道谁是你的消费者。实际上，这归结于 API 管理层以及分析和感知。如果你不知道你的消费者是谁，你也从来没有和他们交谈过，那么你很可能无法推动他们前进得太快。但是如果你知道他们是谁，并且经常与他们交谈，你可能会前进得很快。
针对安全漏洞强制升级
通过致力于提供一个强大而完整的*台开发套件/SDK，您可以确保您的代码不那么脆弱，并且您的客户不必担心集成问题。通过向你的消费者提供更多的资源，你对他们如何前进有更大的发言权。
德里奇:肯定同意那里。在做出这样的重大决定之前，你需要了解谁受到了影响，以及对你的客户和你的业务有什么影响。有时，如果存在安全漏洞或类似问题，我们不得不强迫人们使用新版本。什么时候该由提供商来说“嘿，我对我的客户的集成负责”并真正让他们升级到下一个版本？你怎么能强迫它发生呢？
Kin: 你必须就如何允许整合做出决定。这应该是超媒体的承诺之一，当你发布新版本时，你不会因为他们是版本不可知的而破坏你所有的客户。他们有一组可以遵循的链接，他们知道在 API 调用中寻找下一个和上一个链接。我实际上并不局限于下一个，例如/V3/这实际上归结于你如何设计你的 API，然后你如何让你的消费者设计和开发他们的集成。
如果你给他们提供健壮的、做得好的 SDK，他们不需要写很多代码，你的代码就不会那么脆弱，你就能更好地控制人们应用程序中的代码。这不仅仅是 SDK，它还是一个*台开发套件。如果你向你的消费者提供更多的资源，你将对他们如何前进有更大的发言权，因为你已经掌握了这些集成细节的所有权。然后你就可以说“嘿，这不会破坏什么，我们要前进到第八版，你们都要来，哦，等等，除了你，因为你做了你自己的小定制。”但是希望您可以通过为人们提供更多的集成资源来最小化这些资源池。
厌倦了支持多个客户端库
使用 OpenAPI 的 code gen piece，您可以更快、更快、更一致地自动生成、提炼和清理各种语言的客户端库。你的文档和整体开发将会更好。
Derric:open API 改变了这一切吗，尤其是在 SDK 设计和交流变化方面？
Kin: 是的，这真的是，我会说这是我最*看到许多主要提供商转向 OpenAPI 的症结所在——这是因为代码生成功能。他们厌倦了支持 10 种不同的编程语言 SDK，这些都是手工开发的。他们已经意识到，如果他们只是适当地投资于他们的 OpenAPI，自动生成、自动提炼和清理，那么这就成为 API 生命周期的核心真理。那么你的文档和你的整体开发者体验会更好。但是，它确实推动了代码生成的发展。您可以更快、更快、更一致地生成各种语言的客户端库。然后你还可以获得其他一些集成，这样其他 iPaaS *台，如 Zapiers，就可以为你的*台获取你的 OpenAPI，然后你就有了一个集成，你就进入了 iPaaS 的集成页面。与其他 SaaS 提供商一样，如果他们想将你添加到他们的集成页面，他们不必等待你这样做，他们只需抓取你的 OpenAPI 就可以做到这一点。当谈到可能的集成时，这只是增加了比赛场地，它们都依赖于该合同，即 OpenAPI 真理。它们并不都是定制的代码，定制的开发在你前进的时候会崩溃。
稳定您的 API 生命周期
在不久的将来，API 将需要 OpenAPI 和契约驱动。通过一个完整和健壮的 OpenAPI 定义，你可以做文档、模拟、测试生成、安全扫描、代码生成、可发现性和合规性。
德里奇:不，肯定是。当谈到像 OpenAPI 这样的东西时，看到 API 领域的变化和不同的工具非常令人兴奋。但是 API 的下一步是什么呢？在过去的半年里，很多东西都发生了变化。
Kin: 对我来说，还是老样子。我看到 Salesforce、Twilio、Dropbox 和 Twitter 都采用了 OpenAPI 驱动的 API 生命周期，原因我们刚刚谈过。所以我要说的更多的是，就像人们意识到我们不只是因为我们需要医生而炫耀，我们实际上已经意识到炫耀不再是规范了。我们在做 OpenAPI，我们在做 docs，我们在做 mocks，我们在做测试生成，我们在做安全扫描和模糊化，我们在做代码生成。我们真的是先在 API 上投入所有，这意味着我们必须在开发任何东西之前有一个合同。这个合同推动着我们 API 生命周期的每一站，现在已经很好的定义了。那是下一个十年。我已经这样做了 10 年，我意识到这一切都没有我们希望的那么快。所以这真的是最大的一块。
我想说的是，其中的新元素将围绕可发现性，这意味着现在您可以找到所有的 API，因为您已经为它们定义了一个契约。现在，您实际上可以做到合规，并且可以一致地扫描所有 API。API 提供者会要求在 API 投入生产之前，必须有一个完整且健壮的 OpenAPI 定义，然后才能将任何东西推送到管道中。所以我会说这真的是未来，我知道人们讨厌我这样做，因为这不是超级酷，而是稳定你的生命周期，使它开放 API 和合同驱动。
但话虽如此，我要说的是，随着这种成熟，人们意识到我们需要做 webhooks，因为我们已经有了一些成功的 API，人们正在拉很多。因此，为了减轻基础设施的负担，我们将发布一些 webhooks。哦，顺便说一下，我们可能还应该做一个 Pub/Sub，NATS 或卡夫卡，或其他一些 TCP 相关的东西。扩展你的 API 工具箱，不仅仅是 REST，还有 GraphQL，Pub/Sub，使用 web sockets 或者 gRPC。我想说，下一步是真正承认它是一个多样化的 API 工具箱，而不仅仅是 REST。这仍将是王，top，它将是任何做 API 的人的门户药物，它将是我们 API 操作的基础，但根据您的消费者和您正在做的应用程序和集成的类型，您可能需要一个数据更密集的 GraphQL API，并让您的开发人员对查询有更多的控制。如果你是重度 B2B 用户，你可能会选择一些性能稍高的 gRPC APIs。但是，我们仍然需要所有与 API 管理相同的基本东西。我们仍然需要分析、速率限制和对所有这些层的洞察。我们仍然需要测试，嘲笑，文档。因此，我们需要在 API 生命周期中实现相同的停止，只是未来真的不会只是 HTTP/1.1，它可能会是 HTTP/3，它可能会是 TCP，它可能会是 MQTT，如果它不仅仅是 deviced IoT 的话，那多样化的工具箱真的代表了未来。
GraphQL 有市场吗
GraphQL 不能替代 REST。如果您的消费者正在快速构建某些类型的移动响应应用程序，并且他们真正理解您的底层数据模型，那么 GraphQL 提供了一种更加灵活敏捷的方式来获取数据和内容。
我们真的很高兴你提到了 GraphQL。企业中最令人兴奋的领域。GraphQL 面临哪些挑战？是不是每个人都应该采纳的？听起来有时这就像是 SQL 与非 SQL 的争论。还是对每个应用都有意义？
Kin: 所以，它是否是每个人都应该采用的东西——不。它是否是一个关键的工具，在一些人的工具箱里——是的。GraphQL 最大的挑战是它的定位和销售方式。它被定位为 REST 的替代品。不是的。不能代替休息。这不是一个适用于所有 API 的 API 模式。现在，如果你有一群已知的消费者，他们正在快速构建某些类型的移动响应应用程序，他们真正理解你的底层数据模型，见鬼，是的。给他们一个 GraphQL 端点，然后离开他们。让他们做他们最擅长的事。所以，如果这是一个数据项目与这些类型的设置，是的。如果你有已知的用户，这是必须的。但是，看看 Github 现在在做什么，他们最*对 OpenAPI 做了一个真正的大推进。我认为他们仍然会讲一些故事，解释为什么他们会加倍使用 OpenAPI 和 REST API，同时仍然支持 GraphQL。我想我们会听到很多教训。
它应该是您多样化 API 工具箱的一部分。我想说 GraphQL 的一些其他挑战是，我希望创建者能够更多地接受 HTTP 标准。我同意我们需要一个标准化的查询模式。HTTP 不应该是一个独立的东西，因为这样你就要开始用 GraphQL 解决其他关于缓存和性能的挑战。许多解决方案都是以专有的方式完成的，比如使用该供应商的工具，然后缓存就会神奇地为您完成。这也应该是一个 HTTP 标准——其中有很多缓存解决方案。所以真的，这些是一些挑战。但在正确的情况下，如果你知道谁是你的消费者，GraphQL 将允许你更快地构建东西，在如何获取数据和内容方面更加灵活和敏捷。所以这肯定有它的位置。
derrick:完全同意当涉及到像缓存这样的东西时很难，我们已经有了相关的标准，现在 GraphQL 打破了一切。即使是状态代码，我也不确定为什么我们不能使用我们已经有的相同的 HTTP 状态代码。
亲戚:是啊。但这就是当你没有真正拥抱网络或理解它时会发生的事情。这类似于我们之前讨论的标题读写能力。许多人认为网络是理所当然的，认为它实际上带来了多少工作、多少投资和多少成果。在他们开始构建这些新的解决方案之前，他们应该花更多的时间去理解网络，并且说，“哦，这就是状态码存在的原因。”回到我所说的关于变更管理，状态代码是关于沟通的，它们是关于沟通好的和坏的事情，以及是谁的错和规模。我们已经解决了这些问题，让我们不要重新发明轮子。
有什么好的 API 资源吗
你可以快速了解 API 的最佳规范空间包括 API 布道者、Nordic APIs、Matt Reinbold 和 James Higginbotham 的时事通讯，以及 Postman API 网络
德里奇:完全同意。当谈到教育和进入 API 的时候，对那些希望在 API 或开发者关系领域开始职业生涯的大学毕业生有什么建议？
Kin: 嗯，我有偏见，但当然你应该从 APIEvangelist.com 的开始。除此之外，Nordic API是一个获取 API 空间信息的好地方。我有一个叫做 API 知识中心的聚会。实际上我应该把它作为一个横幅放在 API 布道者的主页上。我想这个星期我会这样做。这是该领域资源的综述，列出了所有顶尖的 API 博客。有一些 API 时事通讯。我朋友 Matt Reinbold 就有一个。詹姆斯·希金波坦还有一个。所以搜索一些 API 时事通讯，如果你用谷歌搜索的话，它们都会出现。这些会让你跟上正在发生的事情，给你一个很好的故事综述。但实际上，我们正在努力投资 Postman *台，让新开发人员加入进来。所以 Postman API 网络，里面有相当多的 API。我有一个公共 REST API，它就像 100 个不同的 API，不需要认证，所以它们真的很容易使用。每个话题都有一个:如果你喜欢书，如果你喜欢猫，如果你喜欢狗。我有一个关于比特币的，还有一个关于查克·诺里斯笑话的。因此，无论你对什么感兴趣，都有一个免费的公共 API public，你可以试一试，看看它到底是怎么回事。它很容易与邮递员一起使用。我正试图为船上的人们创造更多这样的收藏。
我给大学生做了很多演讲，试图说服他们为什么 API 很重要，为什么它会影响他们的职业生涯。所以我正在建造更多这种类型的收藏，展示“嘿，你要进入考古学，这是给你的收藏。”"嘿，你要去做会计了，这是给你的礼物。"进入公共政策管理，这里有一个给你。“所以我一直在做更多的工作，但在邮递员网络中有一小部分会让你接触 API 的世界，帮助你了解它。但是，也就是说，这是我们在这个领域应该做得更好的事情——创建一个更规范的空间，在那里您可以快速了解 API。历史上，它是可编程的网络，但它不应该也不需要成为引领我们走向未来的目的地和来源。我想说它仍然代表着过去的 15 年，而不是未来的 15 年。所以我们需要做得更好。
德瑞克:我一定要看看查克·诺里斯的笑话。那看起来很有趣。非常感谢你今天加入我们。我们总是乐于听到您对 API 空间和 API 生命周期的见解。祝你过得愉快。
金:是的，你们知道在哪里可以找到我。如果你需要做更多，请告诉我。
迈克·阿蒙森的播客
原文：https://www.moesif.com/blog/podcasts/api-product-management/Podcast-With-Mike-Amundsen/
Ep。4:迈克·阿蒙森，作家兼演说家
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
本周我们邀请到了著名作家兼演说家迈克·阿蒙森。他是一位多产的 API 作家，最*发布了他的新书，名为设计和构建伟大的 Web APIs:健壮、可靠和弹性。当他不写作时，Mike 帮助公司利用 API、微服务和数字化转型中的机会。
Mike 分享了他的观点，关于为什么组织在三个层次上考虑 API，AWS 的 Werner Vogel 如何反对，API 自动化工具的未来是什么，以及许多更有见识的见解。
德瑞克·吉林，Moesif 的首席执行官是今天的主持人。
Moesif · Mike Amundsen, author and speaker
在 SoundCloud 上听这一集，在苹果或谷歌上下载，或者在 YouTube 上观看。
目录
- 0:32 罗伊·菲尔丁博士解决的问题
- 3:00 API 先等于 KYC
- 5:15 如何最好地首先构建 API
- 8:16 如何构建你的 API 团队
- 12:25 你的 MVP 应该关注什么
- 14:36 用 API 减少定制构建
- 16:52 低码无码带来什么
- 19:00API 自动化准备好了吗
- 21:20 我应该衡量哪些指标
- 25:48 可观测性与监控
- 29:56 为不可预知的事物设计
- 35:54 内部 API 通常缺乏弹性
- 39:04 与沃纳·沃格尔一起反对 APIs】
- 46:09 COVID 加速 API 自动化
德里奇·吉林(Moesif): 欢迎来到 Moesif 的 APIs over IPAs 播客网络的另一集。我是德里奇·吉林，今天的主持人，也是 Moesif 的首席执行官，API 可观测性*台。和我一起的是迈克·阿蒙森，著名的作家和演说家。他创建了 API 学院，并且是 20 年前第一批加入 API 的人之一。他目前为一些公司提供咨询，帮助他们利用 API、微服务和数字化转型机会。很高兴今天有你在这里”
迈克·阿蒙森(作者&演讲者):很高兴和你在一起，德里克。和你谈话很愉快。
罗伊·菲尔丁斯博士解决的问题
Roy Fielding 2000 年的博士论文以介绍 REST 而闻名。但是，它也有助于解决构建 SaaS 产品时的缩放和定制问题。
德里奇:牛逼。自从发现 Roy Fielding 的博士论文介绍 REST 以来，您已经做了相当长一段时间的 API 了。过去 20 年最大的变化是什么，你是如何进入 API 的？
迈克:第一个问题包含了很多内容。我应该说，实际上我并不是自己创办了 API 学院。我想确保我向马特·麦克拉蒂和罗尼·米特拉发出了呼喊。我们三个是这个小组的最初的创始人，他们对这个小组的最初设计和成功有很大的帮助。所以我想对他们大喊。学院只是我在整个 API 世界中经历的其中一步，也是我所做的一些早期工作的参考。
我一直致力于创建基于网络的系统。我之前一直在使用微软工具，使用 SOAP 服务和远程程序以及所有这些东西来做这件事。一切都很好，一切都很顺利，但是我遇到了扩展问题。我实际上是在做一个早期的软件即服务类型的实现，但是无法按照我想要的方式扩展它。所以我四处寻找，拼命寻找可以工作的东西，无意中发现了菲尔丁的论文。他写于 2000 年。他最初在 1998 年写了一篇文章并向微软展示了一些东西，但我直到 2003 年或 2004 年才接触到它。它帮助我解决了眼前的问题，这些问题最初与规模有关，最终与定制有关。所以我找到菲尔丁的方式是出于绝望——最初，我去找他，他为我解决了一些问题。然后随着我读得越来越多，你正在读一篇 175 页的博士论文(我没有博士学位，我甚至没有计算机学位，所以这对我是一个挑战)，但是随着我读得越来越多，它开始变得越来越有意义。我可以开始实验了。他谈到的越来越多的东西帮助我解决了眼前的问题。这就是我进入 Fielding 领域的真正方式——我在寻找解决方案，它帮助我解决了一些问题，然后教会我如何寻找解决其他扩展和定制问题的方法——这是我生活中的两大难题。
API 首先等于 KYC
API first 实际上是要知道你将为你的客户——开发者——解决什么问题。在您指定任何东西之前，了解他们的问题是什么，他们将发送什么数据，他们将通过接口传递什么数据。
德里奇:很高兴听到这个消息。API 领域正在发生许多新的事情，包括业务方面和工程方面。什么叫 API 优先，API 驱动？那里有什么不同？
迈克:是的，那里也有很多东西。所以，让我们从 API 优先的概念开始。我在我刚刚完成设计和构建伟大的 Web APIs:健壮、可靠、有弹性的书中提到了这一点。我第一次了解 API 首先是从卡斯·托马斯那里。卡斯写道，当你首先考虑界面时，你是在为人们解决问题，理解那些人是谁，他们的问题是什么，然后这将有助于你构建界面。如果我没记错的话，在那个时候，Kas 并没有像我们想象的那样谈论 web APIs，他真正想的是类库、函数、模块的接口，以及你给开发者的东西。所以他也确实在考虑开发者优先。他在想，你要帮助开发者解决问题。
现在，我经常使用的另一个 API 优先版本，我想很多人都很熟悉，来自于 API 倡导者 Kin Lane。我想 Ken 最*刚刚参加了这个播客，所以我想你已经和 Ken 谈过这个问题了。但这个概念是，在你去构建一个应用程序之前，在你去构建一个网站之前，在你去构建一个模块之前，先构建一个界面。建立接口要做什么；它在解决什么问题，你在发送什么数据，它在传递什么数据。一旦你首先有了 API，这是一个基础元素，然后你就可以添加移动应用程序、网络应用程序或桌面应用程序，而不会有太多的中断，因为它们都是在那个界面上运行的。
所以我认为这是我很快想到的两个版本，对我来说，这两个版本都与了解你的观众，了解你的目标观众，知道他们的问题是什么有关——这就是你要解决的问题。这有点像你建造它，他们会来。相反，理解他们的问题，为他们构建一个伟大的产品，我认为这对我来说是一个思考 API 优先的好方法。
如何最好地首先构建 API
如果你想建立一个 API *台，首先要建立工具。建立人们想要的工具，确保工具可以交互，你会在这个过程中获得你的*台——不要试图先建立一个*台，因为你要在黑暗中做太多的决定。
对于那些正在向 API 优先策略迁移的组织来说，你有什么建议给他们吗，特别是如果他们是这个想法的新手？
迈克:是的，这个技巧就是关注目标受众。我和人们交谈的方式是，如果你解决了他们的问题，他们会喜欢你的产品，他们会喜欢你的 API。现在，他们是谁非常重要。如果是您自己组织内部的开发人员了解您的对象模型和业务模型，并且都拥有计算机科学学位，那么您设计 API 的方式将与您组织外部从事人力资源领域工作的人员大相径庭。他们将面临一系列非常不同的问题，理解也非常不同，因此您需要解决他们的问题。我认为这是一个非常重要的因素。
许多组织认为 API 是分层次的，他们认为它们是基础的、中间件和用户界面。很长一段时间以来，我们一直被教导这一点，但这只是到目前为止有效。只要这是真的，那就意味着你有三种不同的观众。受众是基础团队、中间件团队和 UI 团队。但是当团队必须解决所有这些事情时，他们有时经常这样做，他们必须有一个 UI 和中间件，他们负责数据，那么 API 看起来就会不同。所以了解你的观众——从你的观众开始，我认为这非常重要。
我会自告奋勇做一些我刚刚真正开始思考的事情。我最*在计算机械协会(ACM)上读到一篇文章，这篇文章是关于对 Verner Vogel 的采访，他真的被认为是亚马逊网络服务 AWS 部分的建筑师或大师。他有这个伟大的洞察力，他们从早期就开始了——他说他们的目标是构建工具，而不是*台，我认为这是一个非常有见地的评论。所以这是我跟企业公司谈的一个挑战。他们想要“我们想要一个服务*台”的概念。我们想要一个即插即用的*台，”这是一个非常合理的要求。但是当你在建造它的时候，你不是先建造一个*台，而是先建造工具，让工具成为一系列互动的一部分，然后这个*台就出现了。我想这是我将传递给任何企业的另一条建议，尤其是如果你正在内部构建:构建人们想要的工具，确保这些工具可以交互，并且你将在这个过程中获得你的*台。不要试图先搭建*台，因为你要在黑暗中做太多的决定。所以我认为构建工具，而不是*台，将是我的新口号之一。
如何构建你的 API 团队
在组建你的 API 团队时，遵循相反的康威方法:专注于手头的问题，组建你需要的团队来解决眼前的问题。不要想得太远。
德里奇:哦，这真是一种有趣的看待方式。我喜欢它。我的意思是，着眼于为这个 API 的单一用例构建，而不是整个*台做什么，它看起来只是一堆不同事情的混合，但它并没有真正解决我的单一用例。这也提出了一个不同的观点，对于正在组建新的 API 团队的组织来说，你如何设置它——它是一个单一的*台团队，还是一群专注于单个产品的团队？
迈克:对，那真的很好。我希望我能做得更好。我的伙伴 Ronnie Mitra，我提到过他是 API 学院的创始人之一，在这方面做得很好。他在名为的演讲中谈了很多关于团队的事情，比如对人员*台进行编程。这实际上是理解人们如何互动的概念，这涉及到 Mel Conway 关于你的软件反映你的组织和所有这些其他元素的事情。
但我认为思考这个问题的一个非常重要的方式是，你想弄清楚你当前的团队正在做什么，并首先帮助解决这些问题。不要想得太远。不要试图过多地组织或策划你的新团队将会是什么样子。其中一个非常普遍的说法是所谓的反向康威，你可以说，“嗯，我想要这种软件。所以让我继续前进，创建团队。”那是做这项工作的新团队。组队实际上是相当困难的一步。我们大多数从事 IT 行业的人，我们擅长硬件，我们擅长软件，我们不擅长湿衣服。我进入这个行业是因为我不擅长与人打交道，我认为那就是我。所以我尽量不要太热衷于尝试改造人类。我试着找出你的问题，你要做什么。
所以，当你开始这个过程时，只要把注意力集中在手头的问题上。正前方是什么。我认为任何正在经营一家企业的人，无论你是处于创业阶段还是处于中间阶段，或者你正处于某种成熟阶段，专注于手头的问题通常是最大的挑战，也是最大的问题。当你变得足够大和足够成熟时，你可以开始改变你的视野——你可以把视野移开。我不知道这对你们来说是不是这样——你们已经有一段时间了，你们可能经历过一些同样的事情。但是我觉得，专注于你的问题是什么，得到你当时需要的团队。
我从与初创公司合作中学到的一件事是，当你处于组织的不同阶段时，你会雇用不同的人，因为在这个阶段，我需要在工程方面非常优秀的人。在这个阶段，我需要一个真正擅长产品管理的人。在这个阶段，我需要真正擅长增长管理的人。就像你雇佣不同的人。所以你的团队会改变。所以不要为了适应软件而对你的人做太多的工程设计，因为那一系列的问题会一直变化。我不知道这是否接*我们最初谈论的内容，但这就是我现在的想法。
对于工程来说，这是一件非常重要的事情，你不能过度设计，尤其是在创业阶段。
Mike: 这同样适用于工具，而不是*台——不要太兴奋，只要得到最小可行产品(MVP)就行，这是 AWS 的另一件事，我认为这太不可思议了。回到 S3 水桶，他们真的创造了超级简单的东西，只是为了看看是否有人对它感兴趣，看看它是否可行。然后他们以此为基础。俗话说得好,“行之有效的复杂系统被证明是从行之有效的简单系统开始的。如果你建立一个复杂的系统，你永远不会让它正常工作。你总是从一个简单的系统开始。”所以我认为这贯穿了商业产品、IT 工程和一切的整个经历
你的 MVP 应该关注什么
把你的产品推出去，只专注于你的核心功能——尽可能地外包出去，只要有意义:让别人来做你的用户管理、计费解决方案和账户管理。
derrick:如果我要创办一家 API first 公司，我真正需要的那些组件是什么？我是否需要计费、网关，有很多不同的工具。
迈克:我现在和一些公司合作，他们也在为同样的事情而努力。他们从事工程已经有一段时间了。他们的产品已经过几次验证，但现在他们想升级，他们想 SaaS 升级。因此，所有这些定价和计费管理以及用户管理对他们来说是一种打击，他们意识到，“我们刚刚花了一年半的时间来构建这套工具，现在我们是否必须再花一年的时间来构建一系列其他工具，才能真正实现规模化？”所以最*给我留下深刻印象的一件事是，有很多很多*台可以在这些初始阶段帮助你:用户管理*台、定价*台、stripe 和所有这些东西，所以我开始看到越来越多的人，特别是初创公司说，“你知道吗，在开始的时候，我会让别人来处理这些事情。有人要做我的用户管理，有人要做我的账单，有人要做我的账户管理。如果它扩展到对我很重要的程度，那么我可以把它带回家。我喜欢这种态度。对我来说，这让我想起了汤姆和玛丽·波*斯，他们把精益带到了软件运动中。我听到玛丽反复说的一句话是“把决定推迟到最后负责任的时刻”。“不要提前决定。同样，这就像，不要过度工程化。所以现在我看到这些创业公司说，你知道吗，我会让别人来处理计费，我会让别人来处理用户管理，我可以在以后决定我是否要承担这项工作。但不要马上接受。所以我再次思考，专注于你的核心，专注于你的产品，只要有意义，就尽可能多地外包出去。当它不再有意义时，现在也许你有时间投资它。我看到人们就是这么做的。
使用 API 减少定制构建
我们越来越接*这样一个阶段，我可以把一项服务放在价值链的任何一个位置，每个人都自动工作，这就是产品管理。API 企业正在从这种定制的工程实践转变为这种以产品为中心、消费者驱动的企业。这将是未来建立业务的一种非常强大的方式。
derrick:对我们来说也是一样——当我们考虑我们的账单时，我们直接去找 Stripe，他也在使用 API。这只是一个巨大的传递图，想想很有趣。
迈克:这实际上是一个很好的思考方式。就是这种不断修改，不断增长的图表。
您最初的问题之一是发生了什么变化。当我第一次开始做这个的时候，很多关于 API 的东西都是工艺。一切都是定制的。我要创建这个 API，你要为 API 创建一个客户端，我们真的很高兴。随着时间一年一年地过去，我们开始远离定制版本/定制版本/定制版本。支付管理就是一个很好的例子。20 多年来，我们一直将此作为自动化服务。在 API 流行之前，ATM 工作得非常好。这是一个相互作用的系统网络，你可以把自动取款机放在任何地方，把它插入网络，它已经知道如何交流，因为所有的标准和所有的流程都已经存在，商业模式已经存在，可以提取百分比，预付现金和所有其他东西。这是一个非常成熟的网络，可能是 40 年前的网络机器，也可能是 60 年代的。因此，这是一个非常成熟的服务网络，它具有预构建的 API，可携带正确的信息。
我们刚刚到达那个阶段，我们可以说“我想插入 Stripe”，或者“我要插入其他人”或者“我要插入这个用户管理部分”我们还没有到这样一个阶段，我可以把一项服务放在价值链中间的任何地方，每个人都自动工作，这都是关于产品管理的。还有很多工程，但我认为我们越来越接*了。对我来说，这非常令人兴奋，因为这将使这个行业从定制工程实践转变为以产品为中心、以消费者为导向的企业。我认为这将是未来发展业务的一种非常非常强大的方式。
低码无码带来了什么
使用低代码/无代码、集成*台或类似工具，将复杂的工程部分自动化，这样您就可以专注于那些无法自动化且能带来更多价值的部分，例如设计——我们如何与人类互动。
德里奇:哦，听到这个消息真是太好了。这对 API 来说是一个巨大的冲击。对于像无代码解决方案、集成*台之类的东西，我真的很好奇，想知道它们在未来会走向何方。你认为 API 是如何改变或推动这一点的？
迈克:我又听到了很多关于低代码/无代码的说法，这是一种循环。如果你在这呆的时间够长，你就看不到我的白头发了，因为我刮了胡子，但你又开始看到类似的循环。我认为我看到 RPA 再次出现，这是流程自动化的东西，RPA + AI，有点像 RPA 3.0。所以我认为我们一次又一次地经历这些循环，对我来说这非常令人鼓舞，一点也不令人沮丧。
我想我们发现:我可以自动化更多，我可以安全地自动化另一部分。就成本管理和质量控制而言，自动化使项目成为焦点。我们在精益中进行的许多自动化处理的整个想法实际上来自于对 TQM，即全面质量管理的渴望——这是一种每次都做同样事情的想法。DevOps 的整个想法，编写所有这些脚本，是为了每次我做一个构建时，它将可靠地完全相同。因此，我们可以自动化的部分有助于我们专注于需要创造性干预的部分。
我不认为我们会在自动化设计方面做得很好，因为设计是我们人类互动的地方。无论是 API 优先、开发者优先还是消费者优先，但我们可以自动化大量的连接器，我们可以自动化大量从 A 到 b 的价值链。我认为这是我们将会看到的很多情况。
低代码/无代码正在摆脱繁琐的工程设计，所以我可以专注于消费者，所以我可以专注于输入和输出，目标，我希望这些信息出现在哪里，以及我希望如何为我的目标受众修改这些信息。对我来说，这非常令人兴奋。
API 自动化准备好了吗
办公自动化已经在很大程度上取代了打字员和编辑。如果文字处理的工作方式是我必须在编写文档之前设置一些配置，那就是现在的 API。我们还没到那一步。
当然，即使在企业中，我们也看到许多非工程师和非技术人员在尝试 API。我认为 Postman 发布了一份报告，表明现在大多数人都不是技术人员，但他们仍然熟悉 API，并且正在使用它们。是什么阻碍了业务团队在企业中的广泛采用？
迈克:嗯，我不太确定。这是一个非常好的问题。我认为我们正处于自动化的风口浪尖，但这并不容易。想想电子表格在 80 年代和 90 年代改变办公室的方式。它从根本上改变了办公室。想想文字处理和所有其他种类的东西改变办公室的方式。我们过去有很多打字员、编辑和接电话的人。我做过一段时间的会计，我们计算数字，我们是会计，我们手工做这些事情。电子表格和文字处理等诸如此类的东西完全消除了这一点，改变了办公室。对于 API 来说，我们还没有到那种程度的改变。它还没有完全自动化。你绝对不需要再有一个 CS 学位来真正使用一个 API。但是，你仍然需要知道大量的编程知识。我不需要知道任何编程来做电子表格，做文字处理，或者类似的事情。
可以这样想，如果文字处理的工作方式是我必须在编写文档之前设置一些配置，这就是现在的 API。我必须做一些配置和设置一些其他事情，然后我可能最终开始工作。但是有了文字处理器、电子表格和幻灯片之类的东西，我什么都不用做，这些都为我做好了——魔法在幕后发生。所以我们还没到魔法阶段。所以我认为，阻碍我们前进的是在这个过程中不断降低门槛，让门槛越来越低，这样我们才能让生产率越来越高。这是一件极具挑战性的事情，但如果我想想未来几年将会发生什么。我觉得这才是真正的重点。
我应该衡量哪些指标
度量标准或目标可以被认为是形成了一个三角形:机器基础设施的稳定性度量标准，解决业务问题的软件处理度量标准，以及管理传统业务问题的真实业务度量标准。
这绝对是一项非常具有挑战性的任务，我们看到越来越多的产品经理发布 API，他们不仅从技术的角度来考虑这个问题，也从非技术用户的角度来考虑这个问题——他们如何尽快启动并运行他们的 API *台或 API 产品。但这带来了一个不同的问题，如果我运送的是 MVP，那是一个 API 产品，我们应该考虑哪些指标或 KPI，以及在整个生命周期中这些指标和 KPI 是如何随时间变化的？
迈克:我在 API 交通管理中谈到过这个问题，这是我为奥莱利写的一本小书。你有 KPI 和 okr，这种相互*衡。okr 是英特尔提出的另一个想法，即“你的关键目标是什么，而你的关键衡量标准是什么。”因此，我认为目标是一种三角形的衡量方式:你有机器基础设施类型的指标(你如何管理，你的目标是什么，仅仅是基础设施级别的稳定性)，你有软件处理工作流类型的东西(我如何实际使用基础设施来解决眼前的业务问题，对此有一套不同的指标)，然后你有真正的业务，独立于电子产品(无论你是运输集装箱还是运输软件，你都有一个真正的业务)。每一个都有自己的目标和衡量标准。
因此，从我认为我们最了解的基础设施方面来说，我非常熟悉谷歌所说的 LETS，这是延迟错误流量和饱和度的首字母缩写，这也是谷歌在 SRE 编程和网站可靠性工程中谈论的很多内容。所以你基本上是在谈论延迟，出错需要多长时间，我产生了多少错误或者我运行了多少错误，总流量是多少。哪里流量好，哪里流量差，我系统的饱和度是多少——我是不是到了一个点，再不做点什么就要崩溃了。因此，从基础架构的角度来看，我认为这可能是一些非常好的指标，我们在这方面非常擅长。我们在每台机器、每个操作系统和每台机器中都内置了各种指标，我们可以对其进行监控。
现在，当你转向业务方面或软件方面，流程方面，我们在这方面做得相当好。这就像你的公司，这是一个很好的例子，我们可以开始说“我的网络流量是什么，我的请求是什么，网关上发生了什么”以及所有其他类似的事情。这些确实是故事的关键要素。所以现在我想弄清楚什么是我的入口点，什么是我的出口点，什么是我的停留时间，关于我的软件的事情。我的软件做得怎么样，我是否做了很多交易，我是否有很多废弃的购物车，诸如此类。这些是我认为我们大多数人都熟悉的关键指标。他们对我们构建的软件非常定制。
最后，是真正的生意。在商界，衡量标准几个世纪以来都是一样的。我们有现金流，我们有收入，我们有生产力，我们有人才。我从 A 到 b 需要多长时间。我需要多长时间把一个新功能放入系统。就功能和产品管理而言，这是我的前置时间。所以我认为每一种都有它的理由。对于我们这些在业务流程空间的中间件工作的人来说，我必须知道什么对帮助业务成功、帮助他们的底线、帮助收入是重要的。提高生产力。从商业的角度来看，我必须确保我与每个人沟通，那些非常非常重要的关键因素。
所以我觉得真的各不相同。我们了解基础设施。我们需要非常内省，我们需要在中间件方面和软件过程方面增加很多可观察性。然后，我们需要让企业更好地将这一点传达给团队的其他成员。这些就是我认为我在这个领域看到的挑战。
可观察性与监控
可观察性是指能够从你获得的数据中推断出事情，而监控是指基础设施要素。可观察性确实需要引领一个面向行动的时刻，在这个时刻，机器根据信息而不是人来行动。
derrick:我真的很喜欢你从不同的用例以及不同的团队的角度来看待这个问题，他们可能需要访问类似的信息，但也有所不同。谈到像 API 可见性这样的东西，我们最*看到了许多不同的术语，我们有监控、可观察性、分析，所有这些都是什么，你如何比较它们？
迈克:是的，我们在网上有一些有趣的帖子。可观察性和监控得到了这样的答案，嗯，这就像问数据和信息之间的区别。好像每个人都有这种高压手段。我真的认为，如果你仔细想想，整个可观测性的历史都来自于系统控制，控制系统。这真的来自于我们的大部分技术都来自于我们在 60 年代的太空计划。他们试图弄清楚“我如何理解系统内部发生了什么，我们如何理解这个复杂的软件和这个来回运行的动态系统内部发生了什么。”所以，对我来说，当我说可观察性时，我实际上是在说观察的能力，看的能力。这意味着我要添加许多遥测技术，软件中的遥测技术，我们刚才谈到的那种东西——有多少人点击了这个功能，有多少人关闭了购物车，有多少人初始化了一个文档，有多少人批准了一件有意义的事情。然后试图以某种一致的方式去观察。
50 或 60 年前有很多关于清单文化的讨论，即“我通过清单学习”的概念我们今天在 DevOps 做的很多事情实际上都是基于清单文化——浏览清单:你在这里是红色，你在这里是绿色。在过去的几年里，我越来越多地看到仪表板文化。所以我们不仅仅是在做事，我们也在看东西。所以我看到了这些大仪表板。当我走进他们的办公室，他们的主房间告诉他们到底发生了什么。那就是可观察性。所以可观察性使得从你得到的数据中推断事情成为可能。我认为这就是数据和信息的所在。简而言之，我的逻辑是，监控通常指的是那种基础设施元素。可观察性通常是指在我提到的第二组中正在发生的事情，即业务流程。但是，特别是对于像谷歌、脸书、微软和 AWS 这样的超大型组织，他们需要对他们的基础设施有大量的可观察性，因为这就是他们要卖的东西。因此，他们必须了解其基础架构的运行状况，以及随着时间的推移会发生什么变化。
现在，我想看到的，也是我在 AIOps 的新话题中看到的一些，人工智能 Ops 的想法，是将你在可观察水*上获得的信息转化为行动。我们进行监控的方式，我们今天进行观察的方式常常是灯灭了，一些人必须弄清楚发生了什么，启动另一台机器或解决一个问题。我更希望看到的是解决方案的自动化。所以，当事情失去*衡时，你有这种我们在*衡中工作的事情的自主性，当他们失去*衡时，系统自动旋转事情。我们今天可以做到这一点，这就是许多集群管理的全部内容——设置指标，然后让人们自动加速和减速。所以，我认为对我们来说，可观察性真的需要引导到那种面向行动的时刻，现在你实际上正在创造可以被行动的信息，如果可能的话，由机器而不是人来行动。我就是这么想的。
为不可预知的事物设计
设计一个伟大的 API 环境实际上就是设计一个即使人们在这个过程中犯了错误也能保持运行的系统。最终你会真正开始自然地保护自己免受恶意行为的侵害——你将拥有一个有弹性的、自力更生的系统。
德里奇:我真喜欢监控和可观察性之间的差异。对我们来说，我们一直注意到的一件事是，当你考虑交易数量时，你如何附加用户组件，客户组件，以了解谁在访问它，他们如何访问你的 API。但这带来了一个完全不同的观点，它围绕着 API ops 以及拥有一个好的 API 策略意味着什么。各种组件是什么？可观察性是其中的一部分吗？还有别的吗？
迈克:你知道，我不是很确定。我要把它翻回来，说“这对你意味着什么，API ops？”对你来说那是什么样的世界，因为我刚刚开始理解这一点，我对正在发生的事情没有很好的感觉。你们现在有一种 API 操作方法吗？如果有，那对你们来说意味着什么？
德里奇:我们仍然相信这是一个不断发展的范畴。正如我们讨论 API 产品一样，大规模交付 API 以及弃用或淘汰 API 需要哪些不同的操作方面。这就是你开始谈论 API 生命周期的地方。当涉及到 API 操作本身时，你有诸如可观察性、API 安全性、API 管理之类的东西。您可能会添加一些关于计费的其他组件，您如何实际确保人们在他们的层级内，或者不超过费率限制。围绕 API ops 有这么多不同的组件，就像当我们想到一个网站时，拥有 DevOps 或某种类型的 it 基础架构意味着什么。
迈克:这实际上很有道理。因此，至少对您和您的组织来说，它们都是围绕着运营、管理、持续和维护的。这是一种释放后的时刻。有一个完整的环境，在 API 被创建之后，在它被成功构建之后，有一整套的事情需要你去处理，一直到随着时间的推移而废弃、修改或改变的想法。
我认为这可以追溯到简单的软件知识，SDLC。我们都知道，那句格言是什么“软件 80%的努力和成本实际上花费在发布之后，而不是之前，它是在维护中。”因此，我认为 API ops 的这个想法可能是试图弄清楚这些类别是什么，我必须处理的这些事情是什么。我认为 API 比大多数已发布的软件更具挑战性，因为 API 经常会产生依赖性。有人依赖你。他们正在对这个系统做出改变或有不健康的方面，或者许多管理选择会影响你从未见过的人。所以，这是一个更复杂，更动态的系统。我认为这又回到了我们之前讨论的系统控制理论。
德里奇:肯定。我们已经看到了这一点，甚至在我们自己的客户群或我们交谈过的人中，如果你正在部署一个网站，有一种方法可以登录。也许你有几种不同的登录方式。当您部署一个 API 时，您实际上无法控制他们可能使用该 API 的不同集成和用例。那么，如何缩小这个范围，并确保出现一些疯狂的性能问题或会导致整个系统崩溃的问题呢？
迈克:是的，我知道。我经常使用的一句话，尤其是在这个 API 领域，“本质上，你正在构建一些东西，供你永远不会遇到的人使用，来解决你从未想过的问题。”这就是 API 的含义。人们会以各种疯狂的方式使用它。这是来自谷歌的 Hyrum Wright 的 Hyrum 定律:“无论你做出什么样的承诺，你的 API 的每一个方面都会成为某人的致命依赖。”就像，即使改变你说过可能会改变的事情也会让某人心烦意乱。因此，这一领域面临着巨大的挑战。
如果我思考更广泛的系统理论系统，Donella Meadows 那种思考，你所做的是你不阻止其他人做事情，你在其他人做事情的时候幸存下来。复杂系统即使在故障模式下也能保持运行。即使它们的一部分不能正常工作，它们也能以某种方式保持运行。因此，设计一个伟大的 API 环境实际上就是设计一个即使人们在这个过程中犯了错误也能保持运行的系统。最后，尤其是当你考虑安全问题时，你会想到信用卡管理和资金管理、资金流动的方式，你实际上开始保护自己免受恶意行为或某种类型的意外行为的侵害。所以你有这些不同的层次。因此，你真的必须在早期设计这种弹性，即使发生了不好的事情，我们仍然会没事的。你必须保护自己免受一路上可能会遇到的失败。我喜欢这本书，书名是《释放它》，作者是迈克尔·尼加德。Michael 有这种关于能力模式和稳定性模式的方法。能力模式帮助你解决问题，稳定性模式帮助你渡过难关。他有整整一个系列在忙着，有七八个。
所以我认为，当你架构、设计并开始构建自己的 API 时，你是在参与创建一个有弹性的、有点自力更生的模型的过程。这又是一个超级挑战，但我认为我们已经看到 AWS、谷歌和微软这样的人在做，这就是他们正在做的事情，他们在大多数情况下做得很好。
内部 API 缺乏弹性
构建强大的内部 APIs 避免相互依赖，独立构建，像对待第三方公司一样对待他们。
德里奇:是的，这实际上提出了一个有趣的观点。当我们考虑 API 以及断路器和节流的速率限制时，有时当您的 API 是公共的时更容易部署，因为它暴露在互联网上。人们可能会滥用它，不管是有意还是无意。内部 API 呢？你们的流程一样吗，有区别吗？有时候，你可以创建这些人为的依赖，或者认为你可以访问所有的东西。
Mike: 所以我会再次回到 AWS 的例子，因为他们谈论了很多关于贝佐斯如何告诉每个人你必须通过 API 访问，你不能再直接访问数据库的故事。这些都是试图模拟你在网络中的距离，但是供内部使用。我告诉人们的一件事，尤其是在大型企业中，是“把其他 API 当作第三方产品，把它们当作外部公司来对待。”你看不到里面，你只能看到它们的界面。我有很多组织，他们基本上通过像 OpenAPI 规范库或 AsyncAPI 库这样的库来管理接口，你真的不能越过接口看。你不知道他们的数据模型是什么，你什么都不知道。所以这可以帮到你很多。当你在内部时，你可能会陷入这种困境，没有意识到你对某人的数据模型或某人的处理模型有多么致命的依赖，如果他们改变它，它会变得多么糟糕。
因此，当人们想要让他们的组织升级到更像微服务或 API 之类的东西时，我告诉他们的第一件事就是开始在内部系统的所有其他部分之间保持距离。对待数据服务就像你不控制它们，你不拥有它们。当你设计一个服务时，不要设计数据模型，只需说“我需要下面的”，让别人让数据层为你决定(这要回到我们关于基础、中间件和 UI 的层)。无论是在关系数据库、对象数据库、文档数据库中，无论是在一个地方，还是在本地或外部托管，这都是他们的问题。这是我需要你给我的。如果你开始像对待外在事物一样对待它们，那么你很早就开始建立更多的弹性和自立。这并不容易，因为我工作过的许多美国组织的关键效率，不是他们的有效性，而是他们的关键效率，是他们几十年前就已经决定了，他们不必每天都决定。因此，当他们想要创建这种相互依赖的*台时，就会面临一系列新的问题。那就是你必须开始增加一些距离，即使这有点像一个虚假的距离。
沃纳·沃格尔反对 API
AWS 的负责人说“API 是永恒的，而代码不是。”因此，当放弃一个 API 时，本质上是放弃代码。
德里奇:这是一个很好的观点，你不能只是访问数据库，你真的需要那些真正的限制，就像它是一个外部公司一样。关于这些内部 API 的变更管理，我如何处理变更管理呢？如果我需要弃用某项服务，丢弃某些东西，我应该遵循哪些好的做法？
迈克:嗯，有一些，其中大部分都是为了让我们了解 HTML、HTTP 和 TCP/IP 之类的东西。所有这些已经存在了 30 年、40 年，TCP/IP 案例已经存在了 50 年，它们仍然在工作。但是它们已经发生了很多变化。这些变化都基于一些基本规则，这些规则是我在书中谈到的事情之一:你不能拿走任何东西(一旦它在那里，它就在那里)，你不能改变某些东西的意义(你不能说这个字段过去是指用户总数，但现在是指总页数)，每个新的变化都必须作为一个可选元素来完成。所以你不能在以后提出新的需求。这就是 HTTP、HTML 和 TCP 几十年来的工作方式。这也是我们能做的。
所以第一件事是，你不能收回。沃纳·沃格尔说“API 是永恒的，而代码不是。”我们倾向于反过来思考这个问题，至少我过去是这样。但是如果你认为 API 是永恒的，你会做得更好。但与此同时，你仍然需要做你所说的事情。总有一天你会反对的。你知道吗，我们不像以前那样经常使用 gopher 是有原因的。没人在乎。所以你必须面对它，而你面对它的方式是通过反对，而不是简单地拔掉某人的脾脏，你只是停止使用它。所以你必须有一个过程。
我在我的 YouTube 频道上做了一个关于整个过程的视频短片。本质上，你所做的是:当你不得不改变一些基本的东西，当你不得不打破一些东西(比如有一个新的规定，你在一个受管制的行业工作)，你所做的是，你叉。你真的叉它。现在我有了这个永远不会向后兼容的新东西，它必须单独管理。这是你前进的第一步。现在你在某处有了一个分支。每个人都知道，在开源项目中，当你放弃的时候，你就放弃了，当你不能让事情继续工作的时候，你就放弃了。这很有道理。在某种程度上，你将不得不反对这种做法，以某种方式摆脱这种做法，实际上你将不得不让人们从一种形式转向另一种形式，或者你将不得不让人们去其他地方，以其他方式解决他们的问题。所以你需要给人们一些引导时间，就像你在任何开源项目中做的那样。准备时间，取决于范围、范围、参与人数，准备时间可能是几年。
Salesforce 有一套流程，他们每四个月发布一次，他们在发布 42 或 43，他们支持发布 22 或 23，他们支持大约 20 个发布。因此，随着人们不断前进，他们支持这种做法。最终你会摆脱它，你所做的就是，像任何好的开源项目一样，你需要找到人来接管它。你需要放弃代码。如果你不再关心这个，把代码交给你的客户，说“你知道吗，你可以自己运行这个。”如果你不能放弃一个代码，因为涉及到知识产权之类的东西，那就有点乱了，放弃接口吧。记录接口，发布 OpenAPI 规范，给世界上的每个人，告诉他们“你知道吗，你也可以运行其中的一个。”最后，如果有人有数据存储在你这里，你必须给他们一个机会恢复他们的数据，给他们一些退出计划，一些结帐选项，一些外卖。最后把界面放上去，直接重定向到 410 Gone。HTTP 里有个东西叫 410 走了，意思是不仅不在这里，而且永远不会回来了。所以去找点别的吧。所以，我经常安排一个 410 乱世，带有一个指向开源项目的指针，或者一个指向接口的指针，或者一个指向替代服务的指针，或者类似的东西。所以肯定有一个过程，就像其他产品一样。
想想轮胎，想想车轮，想想汽车零件，我们也在做同样的事情。你可以买到 1957 年雪佛兰的汽车零件。有人把它藏在某个地方了。他们不再生产这些产品了，但是他们在哪里生产，这是我们在 it 领域必须做的事情。
德里奇:你如何确保自己没有任何问题？自从 COVID 上市以来，我们看到了*台迁移和向新网关和呼叫解决方案迁移的创纪录步伐。但是很容易出现人为失误，过早关闭服务。
迈克:是的。做到这一点无疑是一个挑战。我想 Twitter 已经经历过几次了，他们会告诉人们“我们将在年初关闭我们的服务。”我想他们大约四年前就这样做了，我曾经记录过。到了年底，他们所做的就是测试，比如关掉一个小时，看看是否有什么东西坏了。这就是你可能会遇到的情况。有时候你会碰到这种情况。我可以把我的系统设计得有弹性，但我不能把你的系统设计得有弹性。所以肯定会有问题，肯定会有像 57 雪佛兰这样的情况，我不得不自己动手制作这个零件，因为没有人再提供它了。你总是会遇到这种事情，但我认为这种交流“我们会反对这种做法”的过程然后在这些时候，人们可以试着做一些事情，他们可以分开，去做另一个版本。如果你运行网关服务，你知道你是否有流量。你知道如果你的终端上有流量，你就要弃用。所以你可以完全控制正在发生的事情，至少在入站端是这样。这样你就可以开始和别人交流了。现在在一个匿名的世界里更难了，就像一个开源项目。但是，你可以采取一些步骤。
你永远不会万无一失——傻瓜太他妈的聪明了，他们总是想出新办法来把我们搞砸。但是你可以给很多准备时间，然后你可以遵循那种负责任的折旧模式，这至少给了人们另一个选择。这就是我的建议。
COVID 加速了 API 自动化
越来越多的机会出现，降低了创建和维护 API 的门槛。RPA 3.0、AIOps 和其他软件正在不断地自动化 API 生命周期中的许多元素。
德里奇:我喜欢这样，尤其是在反对的时候。这是我们在 Moesif 非常接*的一个难题，只要想想那个过程和自动化整个流程。作为我的最后一个问题，就他们应该阅读、学习和跟进的内容而言，你想给最新一代的产品经理一些什么建议？
迈克:哇。我可以提供这个。我可以告诉你我在读什么，我看到了什么，我认为如果你是一个好的产品经理，这会给你一些想法。老实说，我不是一个很好的产品经理。我经常在草丛中迷路。我迷失在技术细节中。但是好的产品经理通常能在我的杂草中找到一些强大的东西。
我看到很多人关注这种新的自动化方法，我认为这将对我们产生很大影响。不管你叫它 RPA 3.0，还是 AIOps 或诸如此类的东西。已经持续了很长时间了。但是，再一次，以这个最新的疫情为例，在过去的一年中，很多事情都得到了加速。这个想法是关于我如何能更加自动化，并在我和系统之间建立一个距离。所以人们会寻找这种低代码/无代码。他们会寻找将事物联系在一起的能力。他们将会寻找越来越多的机会来降低门槛。
我看到了一些非常有创意的工作，实际上是监控你的 API 流量，以便为你自动创建像 OpenAPI 文档和文档这样的东西。用它作为验证工具。你的组织有非常复杂的审批系统——你必须有一个 OpenAPI 规范，才能获准进入网关。现在，他们正在使用这些人工智能工具来实际查看您正在运行的服务是否符合您提交给注册中心的那套规范。因此，这是一个利用智能来保持一定距离并创造一些更有弹性和更稳定的系统的想法。捷克共和国有一家公司，我现在记不起名字了，它实际上是在做实时协商的客户端和服务器应用程序。这实际上表明，“哦，你用的是这个版本的 API，这是 OpenAPI 规范。我要把我的看涨期权调整为看跌期权，你要接受这些输入。”现在，这又一次拉开了自动化的距离，创造了更大的弹性。因此，它不只是生成代码，它实际上是在实时调整这些协商的元素。所以我看到越来越多这样的事情。这是另一个层面的自动化。
在可观察性和管理方面，我看到了更多的关注和更多的问题，关于什么是可观察的，什么是不可观察的，以及如何将其转化为行动，就像我们之前谈到的那样。所以我认为所有这些都是非常非常关键的。最后，我认为最重要的是，你在讨论中提到了这一点，那些试图解决自己问题的产品经理、业务主管越来越多地寻求预建软件，无代码或低代码软件，在那里我可以将事情联系在一起。我开始看到越来越多的人在 API 领域谈论试图让 API 构建和 API 发布更具视觉或直觉体验。不再是打字体验了。所以我看到更多的视觉工具，更多的连接工具，对我来说，这是另一件非常非常重要的事情。当你开始降低建立联系的门槛时，你就开始增加建立更多联系的可能性。现在我可以有更多的顾客了。现在，我可以通过网络发送更多的信息，而花费的钱和我用来开发一个定制应用程序的钱一样多。因此，我认为，如果有什么不同的话，我认为产品领域将更多地走向这种自动化，更多地走向自我修复或自我依赖，这意味着我们越来越接*那种真正的价值链自动化，在这种情况下，我可以将我的 SaaS 产品放在价值链的中间，而不会破坏它，增加价值并在交换中获得一些回报。那将会是一套奇妙的新的产品和服务，你可以自动即插即用。我很想去看看。
德里奇:然后你可以根据价格实际决定你想用哪个 API，可能是实时的。我们走着瞧。
迈克:当然。完全正确。谷歌有一个系统，他们的广告竞价系统完全是超媒体驱动的机器人，就像“我会出价这个，我会出价那个。”我给你举个例子。很多年前，当我在管理电话交换机时，有各种各样的计划来做城市间的短程服务或硬线服务。我可以根据时间和距离得到不同的价格和不同的折扣。所以我写了一个程序，说“如果有人想打电话到 100 英里以外的地方，我要使用这项服务，因为我有这个费率，因为今天是星期六，我要使用这项服务，但是星期五我要使用这项服务。”所以我们要照你说的做。最终我们都将拥有同样的界面，以同样的方式工作。我将能够开始根据价格和对我的价值建立联系。所以这次交易将会非常非常重要。我们可以开始关注质量交付、便利性和所有其他方面，在各种其他市场，这对于原料药来说也是一样的。
德里奇:嗯，很高兴听到这个消息。谢谢你今天加入我们的播客，迈克。
迈克:德瑞克，和你聊天很愉快。我们很快会再聊的。谢了。
德里奇:非常感谢。
Okta 关于开发者体验最佳实践的播客
Ep。2: Okta，DevEx 的最佳实践
Moesif 的播客网络:为 API 产品经理和其他 API 专业人士提供可操作的见解。
今天加入我们的是来自身份和访问管理服务公司 Okta 的两位高级管理人员，考虑到所有在家工作的情况，你可能已经在使用他们了。
在一次滚动讨论中，我们涵盖了产品经理和 DevEx 最佳实践，包括:通过同情心&不仅仅是同理心，让开发人员成功，如何结束 API 的生命，为什么讲故事对整个公司很重要，DevEx 世界中的不同角色是什么，等等。
来自 Okta 的 Albert Chen 是他们的高级产品经理，专注于 API 程序的开发经验。他也是旧金山的产品库聚会小组的联合组织者和演讲策展人。
和他一起的还有 Adam Trachtenberg ，他是 Okta 负责开发人员体验的工程副总裁，他还负责确保开发人员在 Okta *台上拥有最佳的开发人员体验。
德瑞克·吉林，Moesif 的首席执行官是今天的主持人。
Moesif · Developer experience best practices with Okta
目录:
- 01:00Albert 和 Adam 是如何进入开发者体验的
- 04:35 发展同理心对你来说意味着什么，Okta 是如何处理的
- Okta 如何组织和区分开发人员体验中的不同角色
- 15:25 在 API 中有如此多的移动部分，如 onboarding 流程、针对不同语言的 SDK 等，作为一名项目经理，您如何确定产品路线图的优先级
- 20:32 谈到价值实现时间等指标，您实际上是如何衡量开发人员的体验的？在 Okta，什么被视为开发人员的成功
- 24:25 有哪些方法可以减少开发人员的摩擦
- 开发者之爱:如何确保你的开发者对你的产品满意
- 你如何处理版本控制
- 37:40 我们还没有看到的 API 的下一步是什么
- 45:52 远程工作对 API 和开发者*台有何影响
- 给想进入开发者关系的应届毕业生的建议
德里奇·吉林(Moesif) :非常感谢你加入我们今天的播客，欢迎来到 Moesif 播客网络的另一集。对我们来说，我们为 API 产品经理和其他专业人士提供可操作的见解。我是德瑞克·吉林，Moesif 的首席执行官，我是今天的主持人。加入我们的是 Okta 的两位高级管理人员，Okta 是一家身份和访问管理服务公司，您可能已经在使用它了，尤其是在家里工作的时候。
Albert Chen 是他们的高级产品经理，主要关注 API 程序中的开发人员经验。他还是旧金山 Product Tank MeetUp Group 的联合组织者和发言人。
此外，我们还有 Adam Trachtenberg，他是 Okta 负责开发人员体验的工程副总裁，他还负责确保开发人员在 Okta *台上获得最佳的开发人员体验。
亚当·特拉滕伯格(Okta): 嘿德里奇。很高兴来到这里。我们很高兴今天能聊天。
非常高兴你能来这里。也就是说，你知道，我想听听高层次的概述。你是怎么进入开发者体验的？
陈阿尔伯特(Okta): 当然，我可以先走。因此，我开始了我的产品管理职业生涯，从事治理、风险和法规遵从性方面的工作。我第一次尝到了为什么有*台需求的滋味——有许多企业软件，许多工具，一切都需要互操作。我在医疗 IT 和互操作性方面花了一些时间，由于政府合规性的原因，让 API、协议和标准相互交流也很重要。因此，在我的最后一次工作中，我实际上是作为*台 API 产品经理加入*台合作伙伴，试图让他们使用我们的*台 API 来利用功能。这种情况延续到了我目前在 Okta 的工作，作为一名开发人员体验产品经理，帮助各种规模的开发人员使用我们的文档、工具和 SDK 来尝试解决他们的痛点和问题。
对我来说，这很有趣。很多很多年前，我有一个新的开始，这将会使它过时，因为网络服务是 FTP 压缩的。csv 文件，我认为，可能是由大型机每天生成的。这始于 95 年。每天我都会看到在美国和加拿大播出的所有电视节目，或者更准确地说，我会看到第 14 天，然后是所有的变化。即使是这么简单的事情，你也会意识到你有很多我们今天仍然存在的问题。比如如果它不能准时到达呢？如果它损坏了呢？如果他们因为有新的信息需要处理而想要更改它，该怎么办？就像我们谈论的所有关于 API 的事情一样，围绕版本可靠性标准。那是 25 年前的总统，现在只是形式不同而已。因此，通过这一点，我开始获得了对开发人员的同情和怜悯，因为我将看到我将不得不经历的事情。在那之后，当我的创业公司倒闭时，我开始使用我学到的很多东西。所以，我是 PHP 的早期 LAMP Stack 用户，最终为 O'Reilly 写了几本书，帮助开发人员解决 PHP 的问题。这让我在易贝的*台上找到了工作，奇怪的是，他们当时有一个非常大的*台。这就像有了商业的易贝和亚马逊，当时，亚马逊网络服务只是为了帮助你从 Amazon.com 买东西而存在。他们后来改变了方向，做了很多事情，但开始看到在帮助开发者福音营销方面发生了什么。在过去的 10 年里，我在 LinkedIn 做了很多事情，为开发者和入职者积累经验，并真正看到了正在发生的事情。现在我已经做了四周左右的秋田犬了。对 Okta 来说是新的，但对带来我全方位的开发者体验感到非常兴奋。在我从事工程和产品营销宣传、技术写作的地方，我发现你需要从整体上考虑一切，以便提供良好的体验。完成这些角色并戴上这些帽子有助于洞察开发人员需要做什么。
德里奇:肯定。有很多关于开发者同理心的讨论。你如何创造这些真实的关系？俄克拉荷马州是如何处理的，这对你来说意味着什么？
Adam: 我会说得更笼统一些，因为我是 Okta 的新员工，Albert 可以带来任何 Okta 特有的有用的东西。所以对我来说，这实际上不仅仅是同情，而是怜悯。所以，我把同情心定义为同理心加行动。所以共情是“哦，我真的很抱歉，我给了你一个不好的经历，”句号。这不太好，对吧。那么，为了帮助开发人员获得成功或者没有痛苦，我需要做些什么呢？所以这就是我关注的。这又回到了一个非常简单的观察，即编程很难。这很难，当你在自己的*台上构建时，这真的很难，这在理论上是确定的。如果你不改变它，每次你运行它的时候，它的行为应该还是一样的。但当你在云*台或其他人的基础设施上构建时，它可能会表现得不一样，你不知道这是你的错，还是互联网的错，还是因为提供商已经改变了。这使得编程变得非常非常困难，因为你总是试图追踪这个 bug 或者构建它，并且理解发生了什么。因此，如果你有这样的观察，那么它是关于我需要向开发者提供什么东西、工具和信息来使他们的体验尽可能容易？理解，我们做什么，你为什么应该关心，你如何开始，你如何扩大规模，当事情发生变化时你如何支持这一点(这可以是任何事情，从我们有一个 bug，你有一个 bug，或者我们实际上因为版本控制和其他方面故意破坏你)，一个人如何获得支持。老实说，没人想到的最难的部分是如何关闭一个 API，生命的终结。我们*台的生命周期是怎样的，开发者应用的生命周期是怎样的，以及它们之间的相互影响。然后通过它，你可以真正思考你需要做些什么来帮助别人拥有一个好的开发者体验。
Albert: 问题是，我们如何看待 Okta 的开发者体验。我还会更笼统地回答这个问题。我喜欢把我的工作想象成这样的类比。我们这些 90 年代在网上购物的人可能还记得他们第一次在任何网站上经历购物车的经历。这太可疑了。你必须输入一堆字段，如果你按回车键，他们会让你重新开始。这是一次非常非常糟糕的经历。现在他们写了一些关于这方面的书，比如注册时表单应该如何表现的通用设计原则是什么，当你试图买东西时表单应该如何表现，所有这些都是为了提高转化率。在我看来，开发者体验就像是 20 年前 UX 对于用户体验的意义。从自私的角度来看，这很好。作为这个领域的产品经理，这是我的工作保障。作为一名产品经理，我的大部分工作是讲故事，并试图向不从事技术行业、不熟悉程序员的人解释，开发人员处理的事情是什么。我觉得我讲的很多故事只是在向其他人、其他利益相关者证明，他们的经历很重要。是的，它们是技术性的，但 API 或 CLI 是界面，“I”是指界面，这个界面需要圆滑、优雅、流畅，没有摩擦，就像网络上的任何其他体验一样。因此，我觉得对我来说，开发人员的体验是能够讲述开发人员遇到的棘手问题，并与人们如何看待标准 UX(我们在消费者世界中将其视为赌注)进行比较。
德里奇:牛逼。很高兴看到更多的客户体验水*，并将其应用到开发人员方面。当谈到开发人员体验时，许多不同的角色都会接触到它，从开发人员关系到下放经验丰富的工程师，还有 API 产品管理，甚至有时它是模糊的——它仍然是一个新的发展中的领域。DevEx 对你来说意味着什么，你实际上是如何区分这些不同的角色的，你是如何在 Okta 组织开发者体验团队的？
Albert: 嗯，在 Okta，我们有开发人员在我们称之为领域的经验，领域只是我们对 scrum 团队集合的内部术语。我们想说的是，开发者体验就像是我们作为一个开发者友好、开发者第一的*台和公司应该做的事情的卓越中心。但是我认为没有 API 产品经理这种东西，每个特性和功能的产品经理都必须从一开始就考虑 API。当他们写 prd 或 one pagers 时，当他们执行时，当他们衡量一个特性的成功时，然后将反馈反馈到产品和路线图中。所以在 Okta，我们有各种各样的开发者体验工程团队。我们也有一个开发人员关系，或福音传道，团队去参加会议，谈论新的工具，并显示可怕的新方法，建立在*台之上。我们还有一个支持团队和各种走向市场的职能部门，全部致力于 to DevEx。因此，这是俄克拉荷马州的当务之急。
Adam: 我认为最关键的是 Albert 之前所说的，所有的产品经理都是 API 产品经理。如果你有一个团队在你的产品体验上附加了一个 API，那么它就不是一个真正的一等公民，这将创造一个不合格的开发者体验。很久以前，当我在易贝的时候(我在 2010 年离开)，通过 API 发布的房源比在网站上发布的还多。其中一些是易贝编写的第一党工具，一些是外部工具。因此，在某些时候，你会和产品经理讨论他们是如何看待 API 的。我会告诉他们，“你知道，除非你有一个 API，否则你永远不会有超过 50%的采用率。从逻辑上讲，你应该先构建 API，然后再构建 web 组件，因为这实际上会给你一个更大的市场。”人们会问“什么？”因为不是每个人都有这种想法。但是，随着事情的发生，人们对 API 重要性的看法开始发生转变。正如我所说，这是十多年前的事了。随着时间的推移，你已经看到许多公司都在继续这样做。
哦，我真的同意这一点，尤其是每个产品经理都必须把这些 API 当作一等公民来考虑。这不仅仅是把它委托给一个团队或其他什么，这更像是一种全公司的文化。
亚当:是的，我们曾经讨论过人们如何使用手机短信。等等，你手机应用的流量比你桌面应用的流量大。一切都颠倒了。每个人现在都成了移动 PM。我认为 Albert 在谈论这种转变，用户体验/开发者体验，就像现在我们不再有移动项目经理，我们只有产品经理。随着这种情况继续发展，你将不再有 API PMs，只有产品经理，或者 API 工程团队，只有工程团队。这是意料之中的事，公司就是这样做生意的。
我喜欢这个类比，我认为 LinkedIn 上不再有移动项目经理这个角色了。你只需要知道手机。
亚当:对。我记得当我开始时，有一个移动团队，他们在我们的 API 上构建移动应用程序。在某些时候，有人会说，等等，我们可以看到趋势。我们将有超过一半的流量来自移动设备，此时产品和工程部门会问自己，“如果我们有一个为少数人服务的庞大团队，然后有一个大部分流量都在那里的小团队，那就反过来了。”那么公司必须从不同的角度思考他们如何做生意。然后在公司里也有类似的觉醒，围绕着他们对 API 的看法，以及这对他们做生意和制造产品意味着什么。
艾伯特:对公司领导层来说，这是一个艰难的转变。我明白了。从领导的角度来看，如果你想让你的 API 做得更好，你说让我把那些责任和痛点隔离给一个团队会更容易。你是 API 团队。你们是*台团队。问题是，整个产品工程组织的其他人在做什么？每当一个 scrum 团队开发出一个新的端点或者更新了任何关于*台功能的东西，那么这个团队的角色就是在事后做出反应并解决问题吗？对于许多初创公司来说，这是一种负担不起的奢侈，他们在你的路线图中没有足够的带宽来花四分之一的时间来填补缺失的公共 API，或者更新发布时没有做的文档。所以我认为，从初创公司到企业，公司的领导层开始明白，你需要在每个 scrum 团队内部固有地建立这一点，或者至少比一个负责确保你对开发人员友好的团队更加分散。
德里奇:肯定。谈到您的产品路线图，您如何区分不同 API 特性的优先级？说到 API，有很多不同的东西:不同语言的 SDK、onboarding 流程等等。你对此有合适的流程吗？
Albert: 从高层次来看，Okta 的工作方式是，我们有团队专门开发 SDK 和工具，用于我们需要支持的各种语言的 10 多种不同路线图，以进行资源的认证和管理。他们工作的很大一部分实际上是消除理解每个 API 的需要。所以拥有 API 是最起码的，拥有所有公共 API 并不意味着你是开发者友好的，它只是意味着你拥有所有可能发布的东西。DevEx 对我们的很大一部分意义是试图了解我们可以从一个新开发人员那里移除多少复杂性和内容。就像他们不想了解你所有的端点；对他们来说，什么都知道并不是一种荣誉；他们完成了他们的用例并继续他们的一天，这是一种荣誉。所以，他们越少考虑 Okta 越好。对我们来说，产品和工程的另一面是几乎所有与 SDK 和工具无关的东西。这涉及到入职 UI、文档、演示、内容路线图、增长黑客、社区关系，确保我们有一个良好的支持 SLA 和其他一切。
亚当:是的，我也认为它有点像水*和垂直。水*方向是我们希望放置的提升开发者体验的系统和*台，例如改善文档体验、改善入职体验，以及你希望如何看待 SDK。您可以这样做并对其进行优化，但这是基于 API 的静态快照。但事实是，当你这么做的时候，你公司的其他人正在构建新产品，或者改进他们的产品，这意味着那些 API 需要转换。它可能是一个全新的 API 它可以改变一个 API，只是新的特性；它可能以向后不兼容的方式改变了一个 API 它可能是改变一个 API，因为有了新的版本，你实际上正在摆脱它。这些都是垂直流程，所以当你在思考这个问题时，你需要重新安排优先顺序。开发人员体验团队真的在推动水*部分，这就像为每个人提高船，让它成为更好的体验。他们也是一个优秀的中心，在内部指导团队如何，随着他们的产品的发展，这意味着他们的 API 也在发展，如何适应开发者的体验，特别是那些试图做一个由 API 支持的用例的人。这意味着他们需要如何改变他们的代码，从意识到如何改变，到实际上停止使用向我推出的旧代码。
derrick:完全同意这一点，尤其是降低复杂性，让你加入新*台。我喜欢这样的说法“电池是包括在内的，但也是可选的”，你可以尽快开始使用，但当你准备好使用这些高级功能时，它们就在那里。酪你不会想立刻暴露所有这些的。
来自 Perl 社区的一句话是“简单的事情应该是简单的，困难的事情应该是可能的。”现在我总觉得 Perl 的一切都很难，但那是我自己的语言问题。我仍然认为，作为一名开发人员，我只是想做一些公司*台提供的核心内容，我应该让它变得容易，看看这是否会解决我的价值——我能很快获得价值。但是随着我的成长和成熟，我想做所有其他更复杂的事情，这是否意味着我必须放弃这个*台，因为它不能和我一起成长？或者，是的，现在我已经看到了它的价值，我想投入时间去实现它，我将能够与这个*台一起成长，因为它支持我所有的复杂需求。从某些方面来说，这也是我如此喜欢 Okta 的原因。这就像是，“嘿，你需要四个 9 的正常运行时间、SLA 和商业保证吗？”，我们可以为您提供。如果您需要，因为它是企业级的。或者你可能会说，我需要签署一份基本有效的经验，并且确实需要我去做。好吧，我可以从这方面着手，然后随着我的应用程序成熟，或者我已经在企业内部销售了这款应用程序，我们希望扩大规模，我可以转向我需要的更商业化、企业级的功能和支持。我认为这非常非常重要。
Derric: 确实如此，说到价值实现时间等指标，您实际上如何衡量开发人员的体验，以及 Okta 认为什么是开发人员的成功？有时，这很难实际测量和量化。
艾伯特:我认为像其他公司一样，如果你是上市公司，最终的衡量标准是股价，如果你在赚钱。关于 Okta 的一件事是，是的，我不打算说谎，这对我们很重要，我们确实希望通过支持开发人员来使我们的公司在财务上取得成功。但是，实际上不止如此。我们的使命是成为开发者事实上的身份标准。因此，我认为像 Twilio 或 Stripe 这样的公司，作为通信标准或支付标准，已经做了大量的铺垫工作，不只是像“是的，我们想从开发者身上赚钱”，而且他们实际上真的很关心构建很酷的工具，以及人们喜欢在他们的应用程序和产品中使用的东西。Okta 分享了一个使命宣言和愿景:我们实际上希望人们喜欢我们建造的东西。这就是我乐于从事这些工作的原因。这不仅仅是一天结束时的数字，它实际上是我们与开发者在开源 SDK 中评论的个人交互。他们说“嘿，也许你们应该试试这个”，然后我们这样做，然后他或她笑了。这是老生常谈，但它是我们自己的最终用户。一些团队中的一些项目经理整天都在处理真正的后端问题，我也是这些团队的一部分，有时我的角色非常繁重，但我认为成为每个开发人员应用程序的身份标准的使命声明是激励我的一件事。
Adam: 我真的在想，有人来到你的网站，他们可能有工作需要完成。我的意思是，他们可能会说“嘿，我对身份认证非常感兴趣。我想了解 OAuth 2、SAML，我真的想在此基础上扩大规模。”这很好，但也有很多人在开发应用程序，需要有自己的身份。它需要好，需要现代，需要安全，需要值得信任，需要有丰富的经验，我不想花时间去做这些。我想专注于解决我的 app 的核心问题。不超过他们想搞清楚托管-他们喜欢，我只是建立了一切，我可以使用 AWS 或 Azure。或者我可以使用 Stripe 进行通信。这是你的事情，我们应该能够为你找到一个更好的，更优越的体验，用更少的时间，这样你就可以完成你的工作。所以，当我思考这个问题的时候，我意识到:这是我们能做的，为什么它很重要，我如何能让你快速起来，这样你就可以像这样，这个东西很有效，我可以测试它，并在我的应用程序中看到它。然后，就你的观点而言，我必须考虑开发人员如何考虑构建应用程序，以及他们需要做哪些定制，以便使它成为他们需要的体验，并可以在生产中启动它并推出。如果你真的通过这些用例，那么这真的有助于你思考你的指标，然后你的漏斗。然后，当你这样做的时候，你真的在努力思考开发人员如何设想成功，Okta 如何设想成功，这些必须重叠。然后，我们如何跟踪人们的旅程，以确保人们按照他们想要的速度前进。我们不会增加任何摩擦力，也不会尽可能地消除摩擦力。
derrick:有没有某种方法可以减少这种摩擦，让开发者在你的开发之旅中进入下一步？
Adam: 你总是在观察是什么让人们前进，以及他们在哪里赶上。这可能是简单的事情，就像不是说“然后这些是你需要配置你的应用程序的部件”，然后某人必须去三个屏幕，你能把它们放在一个屏幕上吗。或者，我们甚至必须去那里，可以自动配置样本和 SDK，以预填充该数据。你总是可以做很多小事来消除摩擦，我认为你需要真正采取渐进的、迭代的、实验性的方法来做这件事。然后还有更大的事情，比如，“嘿，这是不是一个人们真正需要的新功能，可以让他们的生活变得不同？”这两条路你都要走——阶跃函数的大变化是什么，然后你如何沿着这条路优化所有的小变化。这些事情中没有一件会有太多的摩擦来阻止某人去做，但是突然之间，当你看到所有这些变化的复合效应时，它真的在 DevEx 中做出了巨大的根本改进。
艾伯特:经常是被成千上万的剪纸弄死，所以不是这个闪亮的特征才是解决一切的灵丹妙药。我认为非常认真地对待漏斗非常重要，每个漏斗阶段都有非常清晰的进入和退出标准。因此，如果你有一个专用于注册的路线图项目，在你做出改变后，你最好能够查看你的注册漏斗统计数据，并确切地知道这如何影响或不影响改变。老实说，就像你可以有一个假设:如果我们做这个更新来更好地注册和加入，我们会看到更多的开发人员激活，如果没有，重要的是不要忽略它，而是深入调查，看看为什么你的假设是不正确的。看看你能做出什么调整，下一步该怎么做。因此，非常像任何其他用例开发人员或与开发人员无关的其他项目管理。
Adam: 我们喜欢把开发者产品当做产品。所以，你带着同样的心态将任何产品推向市场，你需要带着同样的心态。甚至可能会有更多的复杂性，因为这些受众是谁，并且开发者通常就像一个中介，他们为别人构建一些东西，所以这就像是一个渠道产品，而不是你直接给他们。但是，你需要所有你需要的技能，仅仅是构建一个普通的产品，甚至更多。
如果你说，“哦，好吧，我是个工程师，所以我是个开发者，所以我可以做我想做的事情。”事实上，即使你是一名工程师，你也很少是自己的客户。我曾经有一个 SVP，他在 Silicon Graphics 开发调试器，所以也许，在那种情况下，他真的是他自己的终端客户，他不需要 PM，他可以自己开发。但是，大多数情况下，你真的需要像对待其他产品一样对待它，事实上更是如此，因为它们是非常复杂的产品。
德里奇:很棒的观点。很容易让一群工程师去解决一个产品问题，而没有真正从客户体验和换位思考的角度去思考这个问题。一旦这些开发者被整合，下一步是什么？你如何支持他们，确保他们快乐？有很多关于开发人员的爱和确保你能让这些人对你的产品满意的谈论。
艾伯特:反馈有很多向量。开发人员没有的一个反馈媒介是在电话中的大量时间。他们不想和你通电话。他们不希望有预定的电话来谈论他们的感受，除非你是为了一份额外的有偿工作而招募他们。例如，我们有自己的开发论坛，我们监控堆栈溢出，我们有产品内工具，我们使用 Pinto 在适当的时候征求反馈，我们有一种方法在我们的开发*台上提供反馈——如果人们想自己做出改变，他们实际上可以提交 GitHub pull 请求。显然，我们所有的 SDK 和工具都是开源的，所以人们可以给我们发送问题。因此，所有这些都要考虑在内，并融入到路线图的制定过程中。因此，我们有不同的团队负责所有这些渠道，我们试图把他们都拉到一起，这样我们就可以鸟瞰正在发生的事情。
Adam: 我同时认为，这么说有点刻薄，但开发者之爱也可能是——有人进来，他们发现我们解决了他们需要解决的问题，他们能够解决这个问题，然后继续他们的生活。如果有新功能出现，他们仍然需要检查 Okta 的，但他们不会花大量的时间来照看它。我认为我们都建立在这样的*台上，你会说，“哦，那个东西又坏了”或“他们有一个向后不兼容的升级”，或者有一个信号，然后你会对此感到紧张。然后他们会给你反馈，你需要表现出爱并问“告诉我为什么这会导致痛苦。”
我认为也有很多来自稳定的爱。管理期望，这样你就知道什么时候事情会发生变化，你的计划中会有一个通知，剩下的时间它就会起作用。对吗？所以，就像，你不需要考虑电话或电，有一个期望，它只是工作。你不需要你的能源公司的爱，因为它在管理你需要它做的事情。我认为，当我们达到这一点时，它们会变得更加实用。这是你拥有的身份工具，你可以设置它，集成它，不要忘记它，因为正如我所说的，这个世界总是在变化，总有你想要利用的新事物和新功能——使注册体验更加无缝，更加安全，减少客户的摩擦，这很重要，但你需要*衡大量的反馈，以构建一个解决人们需求的伟大产品。所以那些不需要亲密关系的人实际上完全可以接受。就像，他们只是在生意上很成功。结果，我们在事业上取得了成功。
德里奇:我完全同意这一点。有趣的是，当你想到一个面向开发者的产品时，你不得不考虑版本控制、弃用和诸如此类的事情。说到消费者应用程序。我不认为我曾经担心在我的 Mac 上下载最新版本的 Dropbox，并且“哦，我的天哪，所有的东西都会坏掉，我的文件会消失”，这种情况不会发生。你是怎么处理的？有什么好的流程或好的建议可以让你和我们的观众联系起来吗？
Adam: 我认为版本管理最重要的事情是告诉人们期望什么，以便管理他们的期望，并确保您有正确的沟通渠道，这样他们就能真正获得您的更新。这听起来真的很愚蠢，但我在*台公司看到过很多次他们做出改变，但我不知道，或者一个开发者不知道这种改变即将到来。他们说，“嗯，我们给每个人都发了邮件”，“哦，那是一个旧地址，我没有检查那个邮箱”。然后你尽了最大努力，但这让你完全害怕“哦，我的上帝，如果我做了这样的改变，当我们谈论任何关于更新的事情时，有多少人会得到这样的信息。在某些方面，你真正需要做的最基本的事情是，即使你不打算在一年或两年或三年内拥有向后不兼容的东西，也仍然要管理和设定预期:“每三个月或每六个月，我们会发布一个公告，告诉你有什么变化，这是你应该如何检查它，这是如何通知你的。“或者，您可以依靠您集成的任何东西来获得一年或两年的稳定和支持。然后人们知道“哦，已经过了几个月了，我最好去看看其他所有的变化是什么，因为我知道我将进入保修期。“仅仅是这一组基本信息就给了你很大的回旋余地，因为你可以做所有其他的最佳实践，但是如果有人不知道正在发生变化，然后措手不及，他们的应用程序崩溃了，其他的都无关紧要。然后，显然你可以谈论很多关于语义版本控制和变化，以及所有其他关于如何做到这一点的好东西，但我经常觉得，即使只是钉那些基础，也只是把你放在正确的位置上。因为它围绕着沟通和管理期望，这是你开始这种关系所需要做的。
Albert: 我想补充一个战争故事，当时我是一名广告技术项目经理，我们必须处理脸书的营销 API。而且版本控制得非常好。他们设定期望。有一个遗留版本。有一个最新版本。有一个边缘版本。感觉一年好几次，还是消防演习。所以我认为我们之前谈到的那部分缺失的是一些同理心。是的，你可以设定期望，让一切都有正确的版本，但是如果你对你的客户想要的和需要的东西听不进去，这仍然会非常痛苦。脸书是脸书，他们不在乎，他们可以发号施令，他们只是想做什么就做什么。对于我们其他人来说，我们必须对开发者的需求多一点同情心。
亚当:我认为脸书可能会在意，只是从优先级的角度来看，如果你是一名广告技术项目经理，你会说，“如果有一个东西坏了，我需要确保我的脸书的 API 在我的谷歌或 LinkedIn 的广告技术 API 之前工作。所以他们确实得到了一些奢侈品。当我在易贝的时候，我们有一个从一些旧的，超级随机的“我们只是编了一些 API 或者一堆 XML 帖子”到 SOAP 的主要版本迁移。这再次证明了它有多古老。至少这个版本是标准定义，很多标准和如何做到这一点，但我们已经让两个 API 并行运行了一年多，如果不是更长的话。然后我们给了一年，也许是 18 个月的时间让人们迁移过来。也许 12 个月后，soap APIs 中只会出现新的东西，然后再去做，因为这真的没什么关系，这是很大比例的商业行为。有趣的是，我经常发现从旧 API 迁移过来的最大障碍是使用你的 API 的内部应用。你可以与你所有的关键合作伙伴和开发人员一起工作，让他们继续工作，但总有一些内部应用程序会说“哦，我们没有收到消息”或“我们有其他更重要的事情。”像你这样的高级管理人员只是专注于这一点，你会说，我不敢相信我做了这么多工作来关闭系统，而我仍然有一个随机的内部应用程序在运行。我发现就是那些，或者集成了操作系统的。我真的有 Mac OS 10 中的 API。你与苹果的版本迁移对话与你可能与其他任何人的对话都非常不同。
德里奇:这是一个很好的观点，当你有一个 API 时，你不仅有外部合作伙伴和开发者，你还有这些内部服务等等。开发人员的体验是不同的，还是遵循相同的流程和入职体验？
亚当:我觉得要看情况。老实说，在我以前的公司经验中，他们可以访问所有的 API。这是因为，虽然正确的通信方式是通过 API 网关，但由于它们是内部应用程序，因此它们显然可以访问内部应用程序可以构建的任何内容，这必然不同于您可能提供给第三方公司的内容。通常情况下，他们有相同的 API，但它有几个额外的功能，或者他们有一个仅供自己使用的 API。因此，这些审查流程会有所不同，但最终，就像仍然使用相同的一组基础架构、相同类型的 API、相同类型的网关一样，只是他们可能会获得更广泛的内容，并且可能会有不同类型的控制或治理或审查流程，这些流程在某些领域可能会更强，但在其他领域可能会更弱。我在第一方、第二方和第三方 API 上都有，你们有不同的处理方式。
稍微转换一下话题，在过去几年里发生了很多变化。回顾几年前，我认为 Twilio 是一家价值 5 亿美元的公司，现在它的价值是 300 亿到 400 亿美元，这看起来很疯狂。API 的下一步是什么，我们还没有看到的是什么？
亚当:我认为，无论好坏，Twilio 和 Stripe 验证了一个并非所有人都愿意押注的假设。当 Twilio 开始的时候，有很多人会说，“哦，我知道为什么它会有价值，但是我认为它的总市场是 X，X 是 Twilio 今天市值的十分之一或百分之一。很多人说，“是的，我记得杰夫和我本来可以投资或使用 Twilio，我认为他们会很好，但我从来没有真正看到这个市场需求如此之大。这种你可以直接接触开发者的渠道是一种有效的营销渠道。我的意思是，Atlassian 可能是更早就开始这样做的公司，开发了一些应用程序，但对于 Twilio，我不认为人们真的相信这个假设。但现在成功已经得到了验证，似乎至少人们会说“哦，我要成为 x 的 Twilio，”有一段时间人们会说“我要成为他们自己市场的 EBay”。现在我看到许多公司，许多初创公司认为他们将成为视频的 Twilio/Stripe，或者正在发生的一些其他方面，以及非常具体的开发者*台和工具。类似于 AWS 和 Azure 已经证明了那些类型的云事物，所以其他人可以说“哦，我可以做其他直接的开发者服务，然后我可以销售。”你肯定是从商业的角度来看的。我认为这非常有趣，因为这真的让这个行业变得更加成熟，最佳实践和模式将开始出现，这意味着什么。然后，这将迫使那些不是开发者的公司也开始改善他们的开发者项目，因为外部的东西，也就是人们对开发者在云*台上构建的期望的限制，正在不断提高。你会有几个，几个公司，这将是世界级的例外，就像许多事情将是世界级的，然后你会像，哦，“现在我落后了”，人们会选择退出。
Albert: 我觉得另一个值得关注的有趣现象是低代码/无代码开发或构建的出现。你会看到很多公司和*台都非常倾向于此。我想我最喜欢的是扎皮尔。Zapier 有成千上万的系统集成商在制造连接器，做一些复杂的事情，比如 IFTTT 之类的。我最*参加了 Slack 开发者大会，我检查了他们的工具，如果你想构建一个 slack bot，你真的不需要成为一名开发者——他们有一个 WYSIWYG UI，允许你将 if/then 语句拖放到他们的 UI 中。然后你可以通过复制并粘贴到 URL 来分享它。
Okta 也在做类似的事情。我们有一个工作流引擎，旨在帮助 IT 管理员完成基本的配置和生命周期管理使用案例，他们可能是技术人员，也可能不是。所以感觉大多数公司都想成为一个*台。大多数*台都希望对开发者友好。但是，有趣的是看到用户角色是如何在其中变形和变化的，是的，也许你没有计算机科学或编程背景，但是你知道 REST API 的基本功能和工作原理。您可以看到一个名称空间。你可以看到一个方法参数，并知道如何把这些东西拼凑在一起。如果你明白这一点，那么当你看到一个低代码环境来构建东西、应用或集成时，实际上你真的需要一个开发人员来编写代码，或者你只是想完成一些事情。所以我认为这很有趣。我看到许多公司加大了对低代码/无代码工具的投资，这似乎是一个增长的趋势。
亚当:这太神奇了，也许不是每个人都能看到这一点，但人们用微软 Excel 构建的东西。作为一个非常低代码/无代码，我们将做一些公式和计算，它给你一些图形和其他工具，然后他们可以在上面做 Visual Basic，我想“真正的程序员”会笑，但最终有很多人用 Excel 解决了很多复杂的业务问题，基本上是作为他们的数据库和 UI 数据库工具，任何人都可以学习、使用和分享，这是一个巨大的市场。想想 Excel 本身对微软的实际价值，更不用说 Office 套件的其他部分了。那里有市场。这很难挖掘，因为你必须达到正确的抽象层次，但 Albert 在让人们更容易解决他们的问题方面非常出色。就像 heck 一样，如果我仍然是技术人员，老实说，如果我可以拖放它，可能不会有什么编译器问题，或者我不会引入一个 bug，因为我相信我的编译器可以编译东西。差不多就是这样。比如说，如果我把它连接起来，做我想要的逻辑，那就可以了，我不需要去想它。再说一次，它是关于让简单的事情变得简单，让困难的事情变得可能。也许在某个时候我需要跳出所见即所得，写我自己的自定义函数或其他部分，但是如果我不需要，即使我可以，也许我不需要。我很乐意这样做，完成我的工作，继续我的生活。然后，我可以专注于更多更高价值的业务。
即使是我们这些 SaaS 的工程师，有时我们也会忘记我们真的是来解决业务问题和满足业务目标的，而不仅仅是为了编码而编码。如果有什么东西可以让它变得更容易，不管是 Zapier 还是 Airtable，那么也许这就是正确的路线。没有理由去重新发明轮子。
亚当:这让更多的人能够自己去解决自己的问题。如果你一定要我帮你解决问题，那就没有我能解决自己问题的能力了。这就是所有这些低代码/无代码的情况——每个人都可以成为工程师，或者更多的人可以解决以前需要程序员做的事情。过去，你会打字吗，你会使用 Office 吗，你会使用互联网吗，这些都是技能。这些是赌桌赌注。随着我们进入信息工作者和知识管理领域，从事这些工作的许多人将会提出“你能配置系统吗，你能运行报告吗，你能自己获得数据吗，你能解决这些更高层次的问题吗”。为了做到这一点，我们需要带来工具，这样每个人都可以成功。这是超级授权，我认为这是它最奇妙和令人兴奋的地方。
新冠肺炎，或者说 2020 年很多事情都变了，这对 API 和开发者*台有影响吗？你认为 2021 年会是什么样子？
亚当:嗯，这对我个人有帮助，因为我在湾区住了 15 年，去年因为家庭原因我搬到了明尼阿波利斯。随着公司变得更加友好，因为 COVID 所做的事情，这意味着他们实际上更愿意谈论那些不住在办公室 30 分钟内的员工。所以你看到的是，它为人才打开了世界，变得更加全球化。你可能仍然会被时区和语言所左右，也可能不会——也许你会有一篇“追随太阳”的文章。所以我认为越来越多的是，无论是为人们搭建*台的公司的员工，他们首先是远程的，Okta 越来越认同我们的动态工作和在我们所在的地方会见员工的概念。或者你意识到现在一个开发者可以在你的*台上构建，它可能总是来自世界各地，但是现在这些来自世界各地的人实际上可以为世界各地的公司工作。*台正变得越来越强大，因为你可以使用它们的客户和人群将继续扩大。
艾伯特:我认为从远程工作的角度来看，显然 COVID 对这个世界并不好，但它促进了许多在 COVID 之前已经远程的人们之间更健康的互动，以及我们今天的情况。所以大家都一样。这有点像均衡器。
我的最后一个问题是，对于希望进入开发者体验或开发者关系领域的大学毕业生，有什么建议吗？我知道现在有很多经济上的不确定性，但科技领域总是有亮点。你对这些新毕业的大学生有什么建议吗？
Albert: 我大学毕业的时候都不知道什么是产品经理。顺便说一句，我超级看好新一代。我喜欢我看到的关于他们行动主义的媒体。如果我在 18 岁到 21 岁的时候对自己说，我希望我能花更多的时间去了解现有的各种行业和业务，无论是科技还是其他。我只是没有充分考虑现实世界，没有考虑这些公司试图解决的问题。如果有一个年轻的 Z 世代的人知道他们想进入科技行业，他们可以越来越早地开始他们的教育。网上有很多资源可以学习设计、研究、产品管理、人机交互等等。这些在 10 年前都不存在。因此，我对这些即将加入市场的专业人士的素质既嫉妒又乐观。
我的建议是了解商业，了解他们如何赚钱。有多少年轻人真正了解谷歌和脸书到底是如何赚钱的？他们真的明白他们的商业模式是什么吗？理解商业模式可以让你更接*这些公司试图解决的问题，这让你更好地了解是什么驱使你，是什么让你对他们试图解决的问题充满热情，以及你想象自己在这些问题和解决方案空间中的位置。
对我来说，这是一个常数，技术技能很重要，但实际上，拥有软技能或非技术技能的人也非常强大。它可以像技术交流一样简单。我们不断地与团队一起构建东西，因为工作人员越来越分散，交流实际上变得越来越困难，所以为了有效，仅仅严格地谈论工程-是的，我需要你能够编码，但这是基本的-你需要能够做的还有很多。如果你有一个学习文学并且会编码的人，那么这实际上有时会比一个只会编程的人更强大。这就像古怪的老建议。
当我在大学的时候，那是很久以前了，那时还没有网景，马克·安德森正在推出 NCSA Mosaic 的东西。我记得我有一个朋友在微软实习，最后没有电子邮件，微软内部有电子邮件，你可以在那里互相发消息。但是他们必须去走廊尽头的电脑前查看电子邮件。当时大学里每个人都在用。然后在离职面谈时，他们会说，“是的，有一种东西叫电子邮件，我们一直在用它，也许微软应该搭上那辆火车。”就在微软的“互联网，我们懂了，我们继续前进”之后不久但是你会意识到现在的大学生首先是云。对我来说，亚马逊并不存在——我必须运行我自己的机器。我认为我已经适应了软件开发的新思维，但这仍然是对我最初范式的改变。就像电子邮件改变了人们，互联网改变了比我早 20 年的人一样。所以他们越是会提出这样的问题，“是的，现在每个人都是这样做的。”这些是对动态扩展、按需、良好体验等的期望。学校里的每个人都是这样建造东西的，这些是我们想要的水*设置。如果您的公司没有做到这一点，我们需要想办法帮助您实现转型和增长。我认为，能够将这种新鲜、现代的观点引入公司，并不断推动它们继续前进，也是非常有价值的。因此，你能够清楚地表达这一点，并展示你如何从第一天起就通过引入这一观点和推动公司以及获得公司将帮助你成长的东西来做出贡献，这是一种双赢。所以这是一个需要经常思考的问题，因为我认为如果你身处其中，你不会意识到这是一个不同的观点——每个人都是如此。我们当然是这样做的，这就是我们的做法。但是，你需要认识到这是非常新的，分享和阐明它对其他公司来说是非常有价值的。
德里奇:完全同意。有趣的是，现在大学生已经可以访问 Azure AWS 帐户，创建无服务器功能，这是他们唯一知道的事情。这就是事情向前发展的方式。随着越来越多的大学毕业生进入职场，云计算和 SaaS 有很多机会。
亚当:没错。
德里奇:嗯，酷。非常感谢亚当和艾伯特加入我们今天的播客。对 Okta 的开发人员体验以及寻找什么和如何看待开发人员成功有着非常深刻的见解。
艾伯特:总共。谢谢你们邀请我们，非常感谢。
亚当:非常感谢。再见。
2018 年夏季 API 使用状况报告
API 分析简介
对于任何数据驱动的工程师来说，最困难的事情之一就是回答“这些数字好吗？”我们淹没在来自各种 SaaS 工具的数据中，但有时我们只想知道什么是正常的范围。
例如，您可以调查一段时间内 API 的*均延迟，但是您如何针对 API 的“标准”度量进行基准测试呢？
欢迎来到【2018 年夏季 API 使用状况报告。我们分析了数十亿个 API 调用，以指导您构建正确的 API，并为您提供一个可以考虑的基准。
API 类型的度量标准
编程语言 API 开发者
下图是 Moesif 客户使用的 SDK 或语言。
编程语言 API 开发者
虽然 NodeJS 仍然是由 express 和 Reach 等框架的丰富生态系统驱动的构建 API 的无可争议的国王，但真正让我们惊讶的是 Python 在 2018 年变得多么受欢迎。越来越多的工程师正在发布 Python APIs，这可能受到最*机器学习热潮的推动。Scikit-learn、PySpark 和 TensorFlow 是非常流行的 ML 框架，它们允许任何人从 Pickle 或 ProtoBuf 文件创建模型，然后可以通过简单的 REST API 发布该模型。事实上，我们已经在 Moesif 发布了一些使用 Python 和 Flask 的推理 API。
按内容类型的 API 调用
我们保留了类型和编码，以便对谁设置编码部分进行细分。如果没有设置，今天的大多数框架将尝试使用 UTF-8。
按内容类型划分的 API 百分比
GraphQL 流行吗？
虽然 GraphQL 受到了很多压力，但我们也看到许多开发人员对迁移到 GraphQL 犹豫不决。与此同时，2018 年将是 GraphQL 的一年，新的开放 GraphQL APIs 的发布数量正在加快。
使用 GraphQL 的 API 百分比
什么是 Moesif？ Moesif 是最先进的 API 分析*台，被数千家*台公司用来改进他们的 API 和客户指标。Moesif 为您喜爱的语言提供了开源中间件和 SDK。
API 性能指标
保命普遍吗？
Keep Alive 是服务器调用其他服务器以保持 HTTP 连接对未来调用开放的常用技巧。这减少了后续调用的延迟，例如 API 服务器与数据库服务器的通信。
虽然保持活动在服务器对服务器中非常有益，但是在有许多客户端，但是每个客户端仅发送几个或仅一个请求的应用中，服务器将浪费资源来保持从不重用的连接打开。
按连接划分的 API 调用百分比
API 调用的*均延迟
请记住，一些 API 是同一网络上的服务器到服务器调用，或者是为非常低的延迟而设计的(如我们的收集 API ),它将具有单位数毫秒的延迟。
*均 API 调用延迟直方图
我们看到 28%的 API 调用在 500 毫秒内完成。然而，延迟有一条长尾。潜在的缺陷是没有配置超时(有些库有 60 分钟的超时)或数据库索引问题。
结束语
如果您对某个特定指标感兴趣，请告诉我们。只要可以，我们总是愿意分享更多的数据。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
产品更新:保存的工作区，用于跟踪和共享您的 API KPIs 报告
介绍保存的工作区
我们很高兴地宣布 Moesif 中的一个新功能:保存的工作空间！
保存的工作区允许您将在 Moesif 中构建的报告保存到自定义仪表板中。保存查询时有 3 个选项:
归我所有
您是否每天都运行某些报告来监控特定指标？利用保存的工作区，您可以创建自己的私人仪表板，显示对您最有价值的信息。此功能旨在节省您的时间，同时保持共享工作区整洁有序。
与团队共享
Moesif 专注于为公司提供成功所需的数据。现在，您可以在保存的工作区中创建团队仪表板，确保组织中的每个人都可以访问相关信息。
推出新功能并希望跟踪采用率？创建一个保存的工作区，并允许您的产品、工程和客户成功团队成员访问，以监控此功能对升级和保留的影响。
公开分享
您是否正在与外部合作伙伴合作，并希望直接与他们分享 KPI？通过保存的工作区，您可以与组织外部的团队共享链接，这样双方都可以获得准确的绩效快照。具有访问权限的合作伙伴只能看到您直接与他们共享的工作区，使他们保持最新状态，而您的报告的其余部分是私有的。
你怎么想呢?
我们一直在努力让 Moesif 对*台团队来说更棒。我们的许多新功能都是基于您的反馈，我们总是希望听到您的体验，以及您希望看到的功能。
四月产品更新:以太坊 Web3 和 GraphQL API 支持，异常可视化，自定义分类规则
在过去的几个月里， Moesif 团队不断推出新功能来帮助您的 API 调试和监控需求，包括将我们的核心*台支持扩展到 Ethereum Web3、JSON-RPC 和 GraphQL APIs、异常检测和可视化、丰富的警报以及更多定制。
对 GraphQL 的支持
Moesif 现在有了对 GraphQL 的原生支持。Moesif 会将您的 GraphQL 操作解析成其各自的组件，以便您可以应用 REST APIs 已经提供的所有强大的分析。GraphQL 将生成已定义查询的大部分责任从服务器转移到了客户端。GraphQL APIs 可以从客户端接收成百上千个不同的查询模式，因此增加了使用 Moesif 等强大的 API 分析工具来了解 API 行为的必要性。
支持以太坊网站 3
像 GraphQL 一样，我们对区块链和 DApps(去中心化应用)的增长感到超级兴奋。然而，即使是区块链应用程序也需要对智能合约和区块链的交互进行强大的监控和分析。
Moesif 现在通过监控应用程序与 Web3 API (JSON-RPC)的交互来支持构建在以太坊之上的 DApps。
查看 Moesif 关于以太坊 Web3 API 支持的文档
指标异常可视化和丰富的警报
我们大大改进了异常检测和监控。您可以轻松查看最*异常的摘要，并为每个跟踪的指标绘制图表，如下所示:
异常警报现在丰富了可视化，让你有一个更好的概览。该图表包含在发送给所有渠道的警报中，包括电子邮件、Slack 和 SMS。
自定义分类规则/脚本
如果您不喜欢 Moesif 用于分类错误的默认逻辑，您现在可以创建一个自定义的 Javascript 函数来定义您的分类逻辑。选择中的任何字段
结束语
还有许多其他改进，包括:
- 更高级的搜索过滤器，包括否定过滤器。
- 误差汇总分析
- 对云代理的改进
- 许多 UI 改进
我们还修复了许多错误:
- 即使第三方 cookies 被禁用(Safari 中的默认设置), Moesif 现在也能工作
- 云代理现在可以处理超长 URL
- 门户网站 api 和培训的正常运行时间改进
- 精确的事件计数和会话计数报告
- 更快、更准确的警报电子邮件，同时避免虚假警报
- Moesif-express 现在可以正确保存用户了
我们一直在努力让 Moesif 变得更好，更棒。这些功能中有许多是基于您的反馈，但是我们总是希望从您那里听到更多您想看到的功能。
Moesif 是最先进的 API 分析*台。成千上万的*台公司利用 Moesif 进行调试、监控和发现见解。
产品更新:API 分段、跟踪和桶过滤器、数据导出等。
原文：https://www.moesif.com/blog/announcements/features/Product-Updates-Trace-And-Bucket-Filters-Export/
Moesif 团队很兴奋地宣布了一系列客户一直要求的新功能。
动态过滤器:
现在，您可以通过任何字段(包括自定义元数据和自定义 HTTP 头)过滤和分段 API 数据。Moesif 根据您的数据动态智能地生成这些过滤器。
类似地，我们修改了 dash UI，使其数据密度更大，即使在显示大量数据时也是如此，同时使分类桶(一起分析的错误)和错误跟踪更容易搜索、过滤和排序。
表格视图和数据导出
对于 API 搜索和用户搜索，您现在可以选择想要以方便的表格格式查看哪些列。我们还添加了将数据导出到 CSV 或 JSON 文件的功能，以获得更大的灵活性。
细分分析
现在，您可以使用分段视图根据任何自动生成的字段来分析数据。您可以在条形图、折线图、饼图等中可视化您的数据。像表格视图一样，您可以将您的细分分析导出到 CSV 或 JSON。
结束语
我们一直在努力让 Moesif 变得更好，更棒。这些功能中有许多是基于你的反馈，并且总是喜欢听到你想看到什么功能。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
工作证明与利益证明解释得像我五岁一样
原文：https://www.moesif.com/blog/blockchain/beginner/Prrof-of-Work-vs-Proof-of-Stake-like-I-am-five/
嗯，我们看到很多在线论坛要求一个“解释-喜欢-我-五”的工作证明和股份证明的文章。所以这是我的尝试。
工作证明
假设幼儿园里有一群孩子，他们维护着一叠叠的积木玩具，他们都有同一叠积木的复制品，他们想确保所有的积木都按同样的顺序摆放。
有人想在木块上加一个新木块，木块会发给所有的孩子，还有一道数学题。所有的孩子都试图解决数学问题(采矿)。解决该问题也验证了该块是有效的。然而，解谜的唯一方法是蛮力和运气。第一个解决的人会得到一颗糖(采矿费)。一旦数学难题解决了，就很容易验证解答是否正确。如果超过 50%的孩子验证了这个积木是正确的，那么他们都会把这个积木放在积木的顶端。从而确保只添加一致同意的块(共识)。
如果一个坏孩子想把坏积木(或替换好积木)插入堆栈中，他必须说服/贿赂超过 51%的孩子跟着做，和在积木上为每个积木重做所有的数学智力题，这可能是非常昂贵的。工作证明阻止了坏演员对区块链的篡改。
利害关系证明
在上面的工作证明中，一个缺点是每当需要添加一个新的块时，所有的孩子都非常努力地工作，希望能够幸运地成为第一个解决它的人。大多数孩子只是在浪费时间和精力，因为如果他们不是第一个解决问题的人，他们的工作就会被扔掉。
在赌注证明中，当有人想添加一个新的木块，每个人都做验证工作，每个人挑选一个孩子作为“验证者”，验证者决定木块是否有效，如果有效，每个人都添加到他们木块的顶部。
那么如何选择验证器呢？每个想成为验证者的孩子都会把糖果放进一个共享的水池里。这叫做他们的赌注。这个小组随机选择验证者，但是对那些投入更多糖果作为赌注的孩子来说，被验证的可能性更高。假设鲍勃放了 10 颗糖果，爱丽丝只放了 5 颗，那么鲍勃更有可能被选中。(取决于实现方式，其他因素可能会影响概率，例如 Bob 拥有那些糖果多长时间，而 Charles 也放了 10 颗糖果。)
如果 Bob 被选为验证者，他成功地验证了新块，他将获得额外的糖果作为费用(这通常要少于押金)。一段时间后，在没有发现不良活动后，他的股份(或存款)将被退还给他。
我们如何防止坏孩子插入坏块(或者替换好块)，或者我们如何信任 Bob 这个验证者批准坏块？在此期间，如果 Bob 被批准的坏块发现，他的 10 颗糖果的存款将被取走。
Moesif 是最先进的 API 分析*台，支持 Web3 JSON-RPC、GraphQL、REST 等。成千上万的*台公司利用 Moesif 进行调试、监控和发现见解。
准备就绪，产品引领增长
原文：https://www.moesif.com/blog/customer-success/api-strategy/Ready-Set-Product-Led-Growth/
产品导向型增长(PLG)的迅速崛起，改变了科技领域的商业模式。特别是有一个领域找到了难以置信的沃土，那就是 API 驱动的公司。这部分是因为 API 驱动的公司提供了一个易于采用的高度可定制的*台。以产品为导向的顶级成长型公司 Twilio 和 Stripe 经常被列为 API 领域的杰出人物，因为它们的突破性方法和极高的估值。
这些公司增长战略的核心是 客户 API 使用 。它正在推动各个层面的业务，从收购和保留，到扩张。在以产品为导向的增长模式中，客户可以免费试用产品，自己实现价值，而不会被锁定在销售周期中。这是一个简单的概念，但它颠覆了传统的企业销售。
随着产品导向型增长战略的兴起，业务团队正在重新构想他们的增长框架，并寻找新的工具来更好地支持和发展他们的客户。目标是建立一个免费客户注册渠道，然后将他们转化为高付费客户。
为了正确实施产品导向的增长模式，创新团队希望 Moesif 能够提供强大的业务洞察力，帮助他们了解客户如何与他们的 API *台进行交互。Moesif 的*台允许业务团队帮助更活跃的用户、扩大客户收入和阻止客户流失，从而使业务团队能够获得客户驱动的 API 使用洞察。
Moesif 和您的产品导向型增长战略的一个很好的起点是监控您公司的免费试用版。通常，免费试用客户会经历一系列产品使用里程碑。这些里程碑通常表明客户已经达到了一个新的价值点，比如 1 个 API 调用或 1，000 个 API 调用。一旦你的客户达到一个确定的产品里程碑，Moesif 可以用一个自动警报通知你的销售团队，让团队知道有一个很好的潜在客户。这使得你的销售团队能够在合适的时间接触到你的免费试用客户，将他们转化为付费客户。
从那里，Moesif 将能够帮助您检测哪些帐户即将达到其计划的使用上限。通常，以产品为导向的成长型公司有一个分级定价模式，如“支持企业成长”计划。监控你的客户的账户使用情况将使你能够识别出那些正在快速成长并且已经成熟可以扩张的公司。
例如，明智的做法是联系一个在第一周内就花光了每月信用额度的“增长客户”。有了必要的 API 使用指标，您的业务团队可以为您的客户提供正确的上下文信息，帮助引导他们进行追加销售。
Moesif 对短期峰值的识别也可能是您的客户达到新产品里程碑的另一个关键信号。例如，使用量的峰值可能表明客户刚刚发布了一个新特性，拥有了大量自己的新客户，或者只是以不同的方式使用您的*台。当客户行为和 API 使用发生巨大变化时，获得警报是至关重要的。这将帮助您的业务团队在客户生命周期的关键时刻接触到他们，使您的团队能够提出适时的产品建议，推动收入增长。
最后，以产品为主导的组织需要监控客户 API 的使用情况，以帮助防止客户流失。业务团队需要意识到“曲棍球棒”增长何时向下翻转，因为这发出了重要信号，表明客户的价值感已经减弱，或者他们遇到了意想不到的障碍。无论是哪种情况，你的业务团队都必须在你的客户跳槽之前介入。例如，联系一个 API 使用量下降了 2 倍的客户对您的业务团队来说是有益的。这将使您的业务团队成为值得信赖的顾问，为您带来相关的客户级别信息，最终有助于防止客户流失。
随着 PLG 改变 API 驱动的公司开展业务的方式，API *台团队正在迅速尝试适应和现代化他们的增长战略。幸运的是，Moesif 可以通过强大的客户 API 使用洞察来帮助填补空白，从而帮助加速客户激活、扩大客户收入并防止客户流失。如果你想实施一个 API 产品导向的增长战略，你可以在 Moesif 注册一个免费试用。
减少集成您的 API 的客户的反馈循环
我们都记得曾经有过一次使用*台服务的不愉快经历。也许我们遇到了一系列重复出现的错误，或者*台不可靠并不断崩溃。这方面的经典例子可能是早期的苹果地图。在任何情况下，这些经历的共同主线是因宝贵时间的损失而产生的挫败感，从而导致与产品的关系受损。
谢天谢地，在 API 的世界里，面向客户的团队已经注意到了这一点。公司现在投入大量的时间和资源来消除*台瓶颈，以确保他们的客户体验是可靠和高效的。
然而，对于这些 API 驱动的公司中的大多数来说，当了解他们的客户在哪里挣扎以及他们收到的特定类型的错误时，这在很大程度上仍然是一个被动的过程。简单地说，这个过程依赖于公司的最终用户在他们的 API 出现问题时通知他们的支持团队。
这种等待客户报告*台错误的被动过程会导致有害的结果，这会对内部和外部团队产生负面影响。
对于内部团队来说，这可能会产生一种混乱感，从一个消防演习冲到下一个消防演习，几乎无法保持清醒。例如，当一个内部团队得知一个有问题的端点导致他们客户的应用程序失败时，它通常需要与多个支持团队协调，这些团队必须以闪电般的速度做出快速修复。可以想象，这会产生内部疲劳，并阻止您的客户成功团队建立信任和扩展您的客户用例。
响应式支持流程的效果当然也能在客户层面感受到。如上所述，当第三方 API 遇到性能问题时，可能会导致整个服务失败。在这种情况下，您的客户会感到愤怒，这是可以理解的，他们认为您没有投资正确的技术资源来提供可靠的合作关系。这可能会导致您的客户在其他地方寻找类似的服务，或者开始构建您的工具的内部版本。
API 驱动的组织遭受被动支持过程的一个关键原因是，他们局限于服务器端发生的错误，而没有考虑到他们的客户 API 使用如何有助于他们*台的整体可靠性和性能。
在 API 世界中，集成的服务器端和客户端都可能发生错误，因此 API 支持团队需要一个多视角的优势来深入研究基础设施指标和客户 API 使用指标，以消除*台错误。要了解更多信息，请参见每个*台团队都应该跟踪的 15 个 API 指标。
例如，您的一个客户可能设置了一个错误的集成，这可能会无意中导致 API 使用量激增。这可能会导致可用性问题，从而降低其他客户群的性能，并导致 503 错误。反之，API 使用的下降可能是煤矿中的金丝雀，预示着您的一个端点即将出现技术问题，最终可能会影响您的整个客户群。在这两种情况下，简单地坐着等待最终结果不会让你从客户那里获得任何好感。
由于知道 API *台中的错误和缺陷会导致重大挫折，面向客户的团队必须不惜一切代价减少反馈循环。实现这一目标的最佳方式是实施 API 监控解决方案，为您提供自动警报并跟踪客户旅程的每一步，以便您可以在客户受到负面影响之前采取行动。
请在下面的评论中告诉我们，您收到了哪些关键 API 指标的警报，或者您希望在未来看到哪些关键 API 指标。
结束语:
希望提供出色客户体验并消除*台瓶颈的公司应该向 Moesif 寻求帮助，深入了解他们的用户对您的 API 做了什么，以及为什么他们的体验会受到影响，而无需花费数小时进行手动日志搜索。此外，Moesif 使支持团队能够通过获得及时的自动警报来防止未来的消防演习，从而扩大他们的客户成功工作。
针对参数和查询字符串使用的 REST API 设计最佳实践
当我们设计 API 的时候，我们的目标是让我们的用户在我们提供的服务上拥有一定的权力。虽然 HTTP 动词和资源 URL 允许一些基本的交互，但经常需要提供额外的功能，否则系统会变得太麻烦而无法使用。
这方面的一个例子是分页:如果我们的数据库中有数百万篇文章，我们不可能在一次响应中将每篇文章都发送给客户。
实现这一点的一种方法是使用参数化。
什么是参数化
一般来说，参数化是一种请求配置。
在编程语言中，我们可以从函数中请求返回值。如果函数不带任何参数，我们就不能直接影响这个返回值。
API 也是如此，尤其是像 REST APIs 这样的无状态 API。罗伊·菲尔丁雄辩地说:
所有 REST 交互都是无状态的。也就是说，每个请求都包含连接器理解请求所需的所有信息，独立于之前的任何请求。
在 HTTP 中，有许多方法可以向请求添加参数:查询字符串、POST、PUT 和 PATCH 请求的主体以及头部。每个都有自己的用例及规则。
添加所有参数数据的最简单方法是将所有内容都放在主体中。许多 API 都是这样工作的。每个端点都使用 POST，所有参数都在主体中。这在遗留 API 中尤其如此，这些 API 在十年左右的时间里积累了越来越多的参数，以至于它们不再适合查询字符串。
虽然这种情况经常发生，但我认为这是 API 设计中的一种边缘情况。如果我们一开始就提出正确的问题，我们可以避免这样的结果。
我们想要添加什么样的参数？
我们应该问自己的第一个问题是我们想要添加什么样的参数？
也许它是一个参数，是 HTTP 规范中已经标准化的头字段。
有很多标准化的领域。有时我们可以重新发明轮子，把信息添加到另一个地方。我不是说我们不能用不同的方式。例如，从 REST 的角度来看，GraphQL 做了一些我认为疯狂的事情，但它仍然可以工作。有时候使用已经存在的东西会更简单。
以Accept标题为例。这允许我们定义响应应该采用的格式，或媒体类型。我们可以用这个来告诉 API 我们需要JSON或者XML。我们也可以用它来获得 API 的版本。
还有一个Cache-Control头，我们可以用它来阻止 API 向我们发送带有no-cache的缓存响应，而不是使用一个查询字符串作为缓存破坏者 ( ?cb=<RANDOM_STRING>)
授权也可以被视为一个参数。根据 API 授权的细节，授权或未授权可能导致不同的响应。 HTTP 为此定义了一个Authorization 报头。
在我们检查了所有默认的头字段之后，下一步是评估我们是否应该为我们的参数创建一个定制的头字段，或者将它放入我们的 URL 的查询字符串中。
我们什么时候应该使用查询字符串？
如果我们知道要添加的参数不属于默认的头字段，并且不敏感，我们应该看看查询字符串是否适合它们。
顾名思义，历史上使用查询字符串是为了查询数据。有一个<isindex> HTML 元素可以用来向服务器发送一些关键字，服务器会用一个匹配这些关键字的页面列表来响应。
后来，查询字符串被重新用于 web 表单，通过 GET 请求向服务器发送数据。
因此，查询字符串的主要用例是过滤，特别是过滤的两个特例:搜索和分页。我不会在这里赘述，因为我们已经在本文中解决了它们。
但是正如 web 表单的重用所示，它也可以用于不同类型的参数。RESTful API 可以使用 POST 或 PUT 请求将表单数据发送到服务器。
嵌套表示的参数就是一个例子。默认情况下，我们返回一篇文章的普通表示。当一个?withComments查询字符串被添加到端点时，我们内联返回该文章的评论，因此只需要一个请求。
这样的参数应该放在自定义标题中还是查询字符串中，这主要是开发人员的经验问题。
HTTP 规范声明标题字段有点像函数参数，所以它们确实被认为是我们想要使用的参数。然而，在这种情况下，向 URL 添加一个查询字符串会很快完成，并且比创建一个客户头更明显。
这些字段充当请求修饰符，语义相当于编程语言方法调用的参数。
在所有端点上保持相同的参数更适合于头。例如，每个请求都会发送身份验证令牌。
高度动态的参数，尤其是当它们仅对少数端点有效时，应该放在查询字符串中。例如，每个端点的过滤器参数都不同。
额外收获:数组和映射参数
经常出现的一个问题是如何处理查询字符串中的数组参数？
例如，如果我们想要搜索多个名字。
一种解决方案是使用方括号。
/authors?name[]=kay&name[]=xing
但是 HTTP 规范规定:
由 Internet 协议文字地址(版本 6[RFC3513]或更高版本)标识的主机通过将 IP 文字括在方括号(“[”和“]”)中来区分。这是 URI 语法中唯一允许方括号字符的地方。
HTTP 服务器和客户端的许多实现并不关心这个事实，但是应该记住这一点。
提供的另一个解决方案是简单地多次使用一个参数名:
/authors?name=kay&name=xing
这是一个有效的解决方案，但是会导致开发人员体验的下降。通常，客户端只是使用一种类似地图的数据结构，在添加到 URL 之前经过简单的字符串转换，这可能会导致覆盖以下值。在发送请求之前，需要进行更复杂的转换。
另一种方法是用,字符分隔值，这在 URL 中是允许的。
/authors?name=kay,xing
对于类似地图的数据结构，我们可以使用.字符，它也允许不编码。
/articles?age.gt=21&age.lt=40
还可以对整个查询字符串进行 URL 编码，这样它就可以使用我们想要的任何字符或格式。应该记住，这也会大大降低开发人员的体验。
什么时候不应该使用查询字符串？
查询字符串是我们的 URL 的一部分，我们的 URL 可以被坐在客户端和 API 之间的每个人读取，所以我们不应该将密码之类的敏感数据放在查询字符串中。
此外，如果我们不认真对待 URL 的设计和长度，开发者的体验会大打折扣。当然，大多数 HTTP 客户端允许 URL 中的字符长度为五位数，但是调试这样的字符串并不令人愉快。
因为任何东西都可以被定义为资源，所以对于大量使用参数的情况，有时使用 POST 端点可能更有意义。这让我们可以将主体中的所有数据发送给 API。
我们可以把它设计成一个资源(比如 search-resource)，而不是向查询字符串中有多个参数的资源发送 GET 请求，这可能导致一个很长的不可调试的 URL。根据我们的 API 需要做什么来满足我们的请求，我们甚至可以用它来缓存我们的计算结果。
我们将向我们的/searches端点发送一个新的请求，它将我们的搜索配置/参数保存在主体中。返回一个搜索 ID，稍后我们可以使用它来获得搜索结果。
结论
与所有最佳实践一样，作为 API 设计者和架构师，我们的工作不是遵循一种方法作为“最佳解决方案”，而是找出我们的 API 是如何被使用的。
最常见的用例应该是最容易完成的，用户应该很难做错事。
因此，从一开始就分析我们的 API 使用模式总是很重要的——我们越早获得数据，如果我们搞乱了我们的设计，就越容易实现改变。Moesif 的分析服务可以帮上忙。
Moesif 是最先进的 API 分析服务，被数以千计的*台用来衡量其客户的使用模式。
如果我们走一条路，因为它更容易掌握或更容易实现，我们必须看看我们从中获得了什么。
由于嵌套资源可以用来使 URL 更可读，如果我们嵌套太多，它们也会变得太长而不可读。参数也是如此。如果我们发现自己创建了一个包含大量查询字符串的端点，那么最好从其中提取另一个资源，并在主体内部发送参数。
针对子资源和嵌套资源的 REST API 设计最佳实践
当我们开始设计一个 API 时，会出现许多问题，尤其是如果我们想要创建一个 REST API 并遵循 REST 核心原则:
- 客户机-服务器体系结构
- 无国籍
- 可缓存性
- 分层系统
- 统一界面
这个领域中经常争论的一个话题是资源的嵌套，也称为子资源。
- 为什么有人会窝他们的资源？
- 首先，它们是一个好主意吗？
- 我们应该把我们的资源藏起来吗？
- 我们应该什么时候嵌套我们的资源？
- 如果我们嵌套我们的资源，我们应该记住什么？
由于这个决定会对你的 API 的许多部分产生相当大的影响，比如安全性、可维护性或可变性，我想就这个主题进行一些阐述，希望它有助于做出更有教育意义的决定。
首先，我们将研究嵌套资源的原因。之后，我们将讨论导致嵌套资源出现问题的原因。
为什么
让我们从中心问题开始:为什么要使用嵌套资源设计方法？
我们为什么要使用这种方法:
/posts/:postId/comments/:commentId
/users/:userName/articles/:articleId
在这个问题上:
/comments/:commentId
/articles/:articleId
这种方法的主要原因是可读性；嵌套的资源 URL 可以传达一个资源属于另一个资源。它给出了层次关系的外观，就像文件系统中的目录一样。
这些 URL 传达的关系意义不大:
/books/:bookId
/rating/:ratingId
比这些网址:
/books/:bookId
/books/:bookId/ratings/:ratingId
我们可以直接看到我们请求的评级属于特定的书。在许多情况下，这可以使调试更容易。
我说出现层次关系是因为底层数据模型不一定是层次的。例如，在 GitHub 上，一个用户可以向多个存储库贡献代码，一个存储库可以有来自不同用户的贡献。这是一种多对多的关系。
/users/:userName/repos
/repos/:repoName/users
如果您只知道其中一个端点，这看起来可能是一对多的关系。
其他更技术性的原因是嵌套资源的相对 id或上下文。
例如，房子都有门牌号，但它们只限于它们所属的街道。如果你知道房子的门牌号码是 42，但你不记得街道，这对你没有多大帮助。
/street/:streetName/house/:houseNumber
另一个例子是文件系统中的文件名。如果在数百个不同的目录中有数百个这样命名的文件，仅仅知道我们的文件名为README.md是没有用的。
/home/kay/Development/project-a/README.md
/home/kay/Development/project-b/README.md
如果我们使用关系数据库，我们经常为所有的数据记录使用唯一的键，但是正如我们所看到的，对于其他类型的数据存储，比如文件系统，情况不一定如此。
嵌套的 URL 也很容易操作。如果一个层次结构被编码在一个 URL 中，我们可以删除 URL 的一部分来沿着这个层次结构向上爬。这使得具有嵌套资源的 API 的导航更加简单。
总而言之，我们希望使用嵌套资源来提高可读性，从而提高开发人员的体验，有时我们甚至不得不使用它们，因为数据源没有给我们一种方法来仅仅通过 ID 来识别嵌套资源。
为什么不
既然我们已经讨论了为什么我们应该使用嵌套的原因，那么讨论另一方面也很重要:为什么我们不应该嵌套我们的资源呢？
虽然筑巢有时是必要的，不可避免的，但它通常是一个我们应该记住的有特定成本或危险的选择。
让我们一个一个来看。
潜在的长 URL
我们之前了解到嵌套资源可以使我们的 URL 更易读，但这不是一个确定的赌注。
特别是在资源之间有许多关系的相当复杂的系统中，嵌套方法会导致相当长且复杂的 URL。
/customers/:customerId/projects/:projectId/orders/:orderId/lines/:lineId
如果我们使用长字符串作为 id，这个问题会变得更加棘手:
/customers/8a007b15-1f39-45cd-afaf-fa6177ed1c3b/projects/b3f022a4-2970-4840-b9bb-3d14709c9d2a/orders/af6c1308-613f-40ff-9133-a6b993249c88/lines/3f16dca9-870e-4692-be2a-ea6d883b9dfd
因此，当我们开始沿着这条路走下去时，我们有时应该后退一步，看看我们是否仍在实现提高可读性的目标。
根据经验，最大嵌套深度是 2。有时候深度三也可以。例如，如果我们的 id 简短易读。
/author/kay-ploesser/book/react-from-zero/review/23
_ 什么是 Moesif？ Moesif 是最先进的 API 分析服务，被数以千计的*台用来了解您的客户如何使用您的 API 以及他们使用最多的资源。
冗余端点
一般来说，使用嵌套资源不如只使用根资源灵活。
例如，如果我们有一个多对多的关系。存储库有多个贡献者，但是每个用户也可以贡献给不同的存储库。
如果我们想用嵌套资源实现这一点，我们必须为这个关系单独创建两个端点
/user/:userName/repositories
/repositories/:repositoryName/contributors
如果我们想在没有嵌套的情况下实现这一点，我们可以为贡献定义一个根资源，它还允许在 URL 中使用过滤器参数。
/contributions?userName=:userName&repositoryName=:repositoryName
参数是可选的，所以我们也可以用它来获得所有的贡献，我们可以对它进行PUT和POST来改变和创建关系。
虽然这似乎不是一对多关系的问题，在一对多关系中，关系的一部分不能有多个连接，但我们仍然可以在某个点上希望搜索嵌套资源在其父资源中的所有记录。
所以当有了这个终点:
/mothers/:motherName/children
我们仍然希望得到所有母亲的所有孩子，并为此创建一个新的终点
/children
冗余的端点也增加了我们的 API 的表面，虽然我们的资源关系的更多可读的 URL 对于开发者体验是一件好事，但是大量的端点却不是。
多个端点增加了 API 所有者记录整个事情的工作量，并使新客户的加入更加麻烦。
返回相同表示的多个端点也可能导致缓存问题，并可能违反 RESTful API 设计的核心原则之一。
这个问题可以通过 HTTP 重定向来解决，所以所有的表示都从一个中央根资源返回，并且可以被缓存，但是仍然需要代码来实现它。
它还可能违反另一个核心原则，即统一接口。
当客户端拥有资源的表示(包括任何附加的元数据)时，它就有足够的信息来修改或删除服务器上的资源，前提是它有这样做的权限。
如果表示不包括关于嵌套的信息，并且我们没有根资源来直接访问它；我们不能创建、更新或删除它。
多个数据库查询
如果我们向下遍历关系图，而不是使用一个唯一的标识符(如果存在的话)从资源中检索一个表示，我们需要检查在 URL 中实现的关系是否成立。
以获取嵌套注释为例
/blogs/X/articles/Y/comments/Z
- 有 ID 为 X 的博客吗？
- 我们去问问 DB 吧！
- 我们 ID 为 X 的博客有 ID 为 Y 的文章吗？
- 我们去问问 DB 吧！
- 我们 ID 为 Y 的文章有 ID 为 Z 的评论吗？
- 我们去问问 DB 吧！
获得所有博客的所有文章的所有评论也是一个问题。
- 查询所有博客
- 查询每个博客的每篇文章
- 查询每篇文章的每条评论
这个 API 设计的 N+1 查询问题给了我们很大的打击。
如果我们的注释只有一个根资源，我们可以查询它，并在需要时加入一些过滤参数。如果注释有全局唯一的 id，我们可以直接查询它们。
/comments/Z
/comments?before=A&after=B
安全性
如果我们共享资源的链接，URL 中编码的所有数据都有可能暴露给第三方，即使他们无权从我们的 API 请求表示。
当在互联网上通过 HTTP 请求任何东西时，中间用户会记录 URL，所以这些链接甚至不需要在社交媒体等上主动共享。
例如，此图像链接:
/users/:userNaimg/:imageId
如果我们在某个地方分享它，我们这些人就会知道我们有一个特定名字的用户，他们在我们的服务上上传了图片。
如果图像链接是一个根资源，这样的信息是不明显的。
/images/:imageId
更改 URL
如果我们的关系改变了，它们被编码到的网址就不再稳定了。
有时这可能是有用的，但更多的时候，我们希望保留我们的网址，这样旧的链接就不会停止工作。
例如，这种所有者-产品关系:
/owners/kay/products/1234
/owners/xing/products/1234
如果产品可以作为根资源访问，那么谁拥有它并不重要。
/products/1234
正如我之前提到的，如果关系经常变化，我们也可以考虑将关系本身视为一种资源。
/posessions?owner=kay&product=1234
使用这种方法，我们可以通过一个端点改变关系，但是通过不受这种改变影响的自己的根资源直接链接我们的其他资源。
包裹
那么，这一切的要点是什么呢？
我们是否应该嵌套我们的资源？
有时这是无法避免的，因为数据源根本没有给我们任何其他选择，但如果我们有选择，我们应该考虑所有的利弊。
如果数据是严格的层次结构，没有太深的嵌套，并且关系不经常改变，我会选择嵌套资源。
对于开发者体验的胜利来说，不利因素并不太大。
如果数据容易发生关系变化，或者一开始就有非常复杂的关系，那么维护根资源甚至考虑完全不同的方法(如 GraphQL)会更容易。
更多的端点，正如嵌套场景所暗示的，更复杂的端点意味着要编写更多的代码和文档。这不会导致技术或知识方面的可行性问题，而通常只是开发和维护成本的问题。因此，即使我们知道如何做到这一点，而且安全性或可缓存性也不是什么大问题，我们也必须问问自己，它是否给了我们任何竞争优势。
REST API 设计:过滤、排序和分页
原文：https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/
无论 API 是公共的还是内部使用的，API 设计正在成为 API 产品策略的核心支柱。良好的 API 设计可以改善任何 API 程序的整体开发体验(DX ),并且可以提高性能和长期可维护性。
但是，没有标准或官方的 API 设计指南。RESTful 只是一种架构风格。有许多关于 api 设计的初学者 API 指南随时可用，如本指南和本指南。然而，我们没有找到很多关于更高级的过滤和分页的 api 指南，这激发了我们发表这篇文章。
过滤
URL 参数是向 REST APIs 添加基本过滤的最简单方法。如果您有一个作为待售商品的/items端点，您可以通过属性名进行过滤，例如GET /items?state=active或GET /items?state=active&seller_id=1234。然而，这只适用于精确匹配。如果你想做一个范围，如价格或日期范围？
问题是 URL 参数只有一个键和值，但是过滤器由三个组件组成:
- 属性或字段名称
- 操作员如 eq 、 lte 、 gte
- 过滤值
有多种方法可以将三个组件编码到 URL 参数键/值中。
LHS 括号
对操作符进行编码的一种方式是在键名上使用方括号[]。例如，GET /items?price[gte]=10&price[lte]=100将查找价格大于或等于 10 但小于或等于 100 的所有商品。
我们可以根据需要拥有任意数量的操作符，例如【LTE】【GTE】【存在】【regex】【之前】**【之后】。
LHS 括号在服务器端解析起来有点困难，但是为客户端提供了更大的过滤值灵活性。不需要不同地处理特殊字符。
利益
-
方便客户使用。有许多查询字符串解析库可以轻松地将嵌套的 JSON 对象编码到方括号中。qs 就是这样一个自动编码/解码方括号的库:
var qs = require('qs'); var assert = require('assert'); assert.deepEqual(qs.parse('price[gte]=10&price[lte]=100'), { price: { gte: 10, lte: 100 } }); -
易于在服务器端解析。URL 参数键包含字段名称和运算符。易于
GROUP BY(属性名，操作符)而无需查看 URL 参数值。 -
当 operator 作为文本筛选条件时，不需要对筛选值中的特殊字符进行转义。当过滤器包含用户可能设置的附加自定义元数据字段时，尤其如此。
下降趋势
-
可能需要在服务器端做更多的工作来解析和分组过滤器。您可能需要编写一个定制的 URL 参数绑定器或解析器来将查询字符串键分成两个部分:字段名称和操作符。然后您需要
GROUP BY(属性名，操作符)。 -
变量名中的特殊字符可能很难使用。您可能需要编写一个定制的绑定器来将查询字符串键分成两个部分:字段名称和操作符。
-
难以管理定制的组合过滤器。具有相同属性名和运算符的多个筛选器会导致隐式 and。如果 API 用户想用过滤器来代替。即查找价格低于 10 或高于 100 的所有商品？
RHS 冒号
与括号方法类似，您可以设计一个 API，让操作员使用 RHS 而不是 LHS。例如，GET /items?price=gte:10&price=lte:100将查找价格大于或等于 10 但小于或等于 100 的所有商品。
利益
- 最容易在服务器端解析，尤其是在不支持重复过滤器的情况下。不需要自定义绑定。许多 API 框架已经处理了 URL 参数数组。多个价格过滤器将位于同一个变量“价格”下，该变量可以是序列或映射。
下降趋势
- 文字值需要特殊处理。例如，
GET /items?user_id=gt:100将被翻译成查找用户 id 大于 100 的所有项目。然而，如果我们想找到所有用户 id 等于 gt:100 的项目，因为这可能是一个有效的 id，该怎么办呢？
搜索查询参数
如果需要在端点上进行搜索，可以直接使用 search 参数添加对过滤器和范围的支持。如果您已经在使用 ElasticSearch 或其他基于 Lucene 的技术，您可以直接支持 Lucene 语法或 ElasticSearch 简单查询字符串。
例如，我们可以搜索包含术语红椅子且价格大于或等于 10 且小于或等于 100: GET /items?q=title:red chair AND price:[10 TO 100]的商品
这样的 API 可以允许模糊匹配，提升某些术语，等等。
利益
-
API 用户最灵活的查询
-
后端几乎不需要解析，可以直接传递给搜索引擎或数据库(只是要注意净化输入的安全性)
下降趋势
-
对于初学者来说，开始使用 API 更难。需要熟悉 Lucene 语法。
-
全文搜索并不是对所有资源都有意义。例如，模糊性和术语提升对于时间序列度量数据没有意义。
-
需要 URL 百分比编码，这使得使用 cURL 或 Postman 更加复杂。
什么是 Moesif？ Moesif 是最先进的 REST API 分析*台，被成千上万的*台用来了解您的客户如何使用您的 API 以及他们最常用的过滤器。Moesif 拥有流行 API 网关的 SDK 和插件，如孔、 Tyk 和 more 。
页码
大多数返回实体列表的端点都需要某种分页。
如果没有分页，一个简单的搜索可能会返回数百万甚至数十亿次点击，从而导致额外的网络流量。
分页需要隐含的排序。默认情况下，这可能是项目的唯一标识符，但也可以是其他有序字段，如创建日期。
偏移分页
这是最简单的分页形式。Limit/Offset 在使用 SQL 数据库的应用程序中变得很流行，SQL 数据库已经将 Limit 和 Offset 作为 SQL SELECT 语法的一部分。实现限制/偏移分页只需要很少的业务逻辑。
极限/偏移分页类似于GET /items?limit=20&offset=100。该查询将返回从第 100 行开始的 20 行。
例子
(假设查询按创建日期降序排序)
- 客户请求最*的项目:
GET /items?limit=20 - 在滚动/下一页，客户发出第二个请求
GET /items?limit=20&offset=20 - 在滚动/下一页，客户发出第三个请求
GET /items?limit=20&offset=40
作为一条 SQL 语句，第三个请求如下所示:
SELECT
*
FROM
Items
ORDER BY Id
LIMIT 20
OFFSET 40;
利益
-
最容易实现，除了将参数直接传递给 SQL 查询之外，几乎不需要编码。
-
服务器上的无状态。
-
不管自定义的 sort_by 参数如何，都有效。
下降趋势
-
对大偏移值无效。假设您执行一个偏移量为 1000000 的查询。数据库需要从 0 开始扫描和计数行，并跳过前 1000000 行(即丢弃数据)。
-
向表格中插入新项目时不一致(即页面漂移),当我们首先按最新项目排序时，这一点尤其明显。考虑以下按 Id 降序排序的情况:
- 查询
GET /items?offset=0&limit=15 - 表中增加了 10 个新项目
- 查询
GET /items?offset=15&limit=15第二个查询将只返回 5 个新项目，因为添加 10 个新项目会将偏移量向后移动 10 个项目。要解决这个问题，客户机确实需要为第二个查询GET /items?offset=25&limit=15偏移 25，但是客户机不可能知道其他对象被插入到表中。
- 查询
即使有限制，偏移分页也易于实现和理解，并且可以用于数据集上限较小的应用程序中。
键集分页
键集分页使用上一页的过滤器值来获取下一组项目。这些列将被索引。
例子
(假设查询按创建日期降序排序)
- 客户请求最*的项目:
GET /items?limit=20 - 在滚动/下一页，客户端从先前返回的结果中找到 2021-01-20T00:00:00 的最小创建日期。然后使用日期作为过滤器进行第二次查询:
GET /items?limit=20&created:lte:2021-01-20T00:00:00 - 在滚动/下一页，客户端从先前返回的结果中找到 2021-01-19T00:00:00 的最小创建日期。然后使用日期作为过滤器进行第三次查询:
GET /items?limit=20&created:lte:2021-01-19T00:00:00
SELECT
*
FROM
Items
WHERE
created <= '2021-01-20T00:00:00'
ORDER BY Id
LIMIT 20
利益
-
与现有的过滤器一起工作，无需额外的后端逻辑。只需要一个额外的限制 URL 参数。
-
即使在表格中插入新的项目，也能保持一致的排序。按最*的优先排序时效果很好。
-
即使失调较大，也能保持一致的性能。
下降趋势
-
分页机制与过滤器和排序的紧密耦合。强制 API 用户添加过滤器，即使没有过滤器。
-
不适用于低基数字段，如枚举字符串。
-
当使用定制的 sort_by 字段时，对于 API 用户来说很复杂，因为客户端需要根据用于排序的字段来调整过滤器。
对于具有单个自然高基数键的数据，例如可以使用时间戳的时间序列或日志数据，键集分页非常适用。
寻找页码
寻道分页是键集分页的扩展。通过添加一个 after_id 或 start_id URL 参数，我们可以消除分页与过滤器和排序之间的紧密耦合。由于唯一标识符天生具有高基数，所以我们不会遇到像按低基数字段(如状态枚举或类别名称)排序那样的问题。
基于 seek 的分页的问题是，当需要自定义排序顺序时，很难实现。
例子
(假设查询按创建日期升序排序)
- 客户请求最*的项目:
GET /items?limit=20 - 在滚动/下一页，客户端从先前返回的结果中找到最后一个 id“20”。然后使用它作为起始 id 进行第二次查询:
GET /items?limit=20&after_id=20 - 在滚动/下一页，客户端从先前返回的结果中找到最后一个 id“40”。然后使用它作为起始 id 进行第三次查询:
GET /items?limit=20&after_id=40
Seek pagination 可以提炼为一个where子句
SELECT
*
FROM
Items
WHERE
Id > 20
LIMIT 20
如果通过 id 进行排序，上面的例子工作得很好，但是如果我们想要通过电子邮件字段进行排序呢？对于每个请求，后端需要首先获取标识符与 after_id 匹配的项目的电子邮件值。然后，使用该值作为where过滤器执行第二次查询。
让我们考虑一下查询GET /items?limit=20&after_id=20&sort_by=email，后端需要两个查询。第一个查询可以是 O(1)查找哈希表，以获得电子邮件枢纽值。这被输入到第二个查询中，只检索邮件在我们的 after_email 之后的项目。我们按照电子邮件和 id 这两个列进行排序，以确保在两个电子邮件相同的情况下排序稳定。这对于基数较低的字段至关重要。
SELECT
email AS AFTER_EMAIL
FROM
Items
WHERE
Id = 20
SELECT
*
FROM
Items
WHERE
Email >= [AFTER_EMAIL]
ORDER BY Email, Id
LIMIT 20
利益
-
分页逻辑与过滤逻辑之间没有耦合。
-
即使在表格中插入新的项目，也能保持一致的排序。按最*的优先排序时效果很好。
-
即使失调较大，也能保持一致的性能。
下降趋势
-
相对于基于偏移量或基于键集的分页，后端实现起来更复杂
-
如果从数据库中删除项目， start_id 可能不是有效的 id。
Seek 分页是一个很好的整体分页策略，也是我们在 Moesif 公共 API 上实现的。它需要在后端多做一点工作，但确保不会给 API 的客户端/用户增加额外的复杂性，同时即使在较大的寻道中也能保持高性能。
整理
像过滤一样，排序对于任何返回大量数据的 API 端点来说都是一个重要的特性。如果您要返回一个用户列表，您的 API 用户可能希望按照最后修改日期或电子邮件进行排序。
为了支持排序，许多 API 都添加了一个 sort 或 sort_by URL 参数，该参数可以将字段名作为值。
然而，好的 API 设计能够灵活地指定升序或降序顺序。像过滤器一样，指定顺序需要将三个组件编码成一个键/值对。
示例格式
-
GET /users?sort_by=asc(email)和GET /users?sort_by=desc(email) -
GET /users?sort_by=+email和GET /users?sort_by=-email -
GET /users?sort_by=email.asc和GET /users?sort_by=email.desc -
GET /users?sort_by=email&order_by=asc和GET /users?sort_by=email&order_by=desc
多列排序
不建议使用排序和顺序不配对的最后一种设计。您最终可能允许按两列或更多列排序:
SELECT
email
FROM
Items
ORDER BY Last_Modified DESC, Email ASC
LIMIT 20
要对这种多列排序进行编码，您可以允许多个字段名称，例如
GET /users?sort_by=desc(last_modified),asc(email)或者
GET /users?sort_by=-last_modified,+email
如果排序字段和排序没有配对，则需要保留 URL 参数排序；否则，什么样的排序应该与什么样的字段名配对就不明确了。然而，许多服务器端框架一旦被反序列化为映射，就可能无法保持顺序。
您还必须确保为任何缓存键考虑 URL 参数排序，但这将对缓存大小造成压力。
结论
良好的 API 设计是开发人员体验(DX)的重要组成部分。API 规范可以比许多底层服务器实现更持久，这需要考虑 API 的未来用例。
REST vs GraphQL APIs，好的，坏的，丑陋的
原文：https://www.moesif.com/blog/technical/graphql/REST-vs-GraphQL-APIs-the-good-the-bad-the-ugly/
自从被脸书引入以来，GraphQL 作为 REST APIs 的替代者，已经在 API 世界掀起了一场风暴。GraphQL 修复了 API 开发者和用户在 RESTful 架构中发现的许多问题。然而，它也带来了一系列需要评估的新挑战。因为 GraphQL 不仅仅是 REST 的进化替代品，这篇文章将深入探讨每种技术的优缺点以及 GraphQL 何时对您的应用程序有意义。
历史
在 RESTful APIs 之前，我们有 RPC、SOAP、CORBA 和其他不太开放的协议。许多 pre-REST API 需要复杂的客户端库来通过网络序列化/反序列化负载。与今天的 RESTful APIs 相比，一个根本的区别是 SOAP 是通过 WSDL (Web 服务描述语言)使用正式契约强类型化的。这可能会破坏互操作性，因为即使取消 32 位整数限制来接受 64 位整数也意味着破坏上游客户端。SOAP 不是一个体系结构，而是一个完整的协议实现，包括安全性、错误处理、ACID 事务等。有些复杂性是由于 SOAP 中包含了许多抽象层。例如，SOAP 能够在 HTTP、TCP、UDP 等上运行。虽然协议实现提供了很多抽象，但是客户机和服务器之间的应用程序和数据层的严格约定在两者之间产生了紧密的耦合。
RESTful 架构是在 2000 年作为一种更简单的方式引入的，它只使用普遍存在的 HTTP 协议来实现机器对机器的通信，而不需要以无状态和无类型的方式添加额外的层。这使得系统能够松散耦合，并且对系统之间(比如公司之间)的契约变更更加宽容。
今天休息
REST APIs 已经成为公司部署 API 和开发*台的事实标准。REST 的美妙之处在于，使用别人的 API 的开发人员不需要任何特殊的初始化或库。请求可以简单地通过通用软件如 cURL 和网络浏览器发送。
REST 使用标准的 CRUD HTTP 动词(GET、POST、PUT、DELETE ),利用 HTTP 约定，以数据资源(HTTP URIs)为中心，而不是试图对抗 HTTP。因此，拥有资源api.acmestore.com/items的电子商务可以表现得类似于拥有资源api.examplebank.com/deposits的银行。两者都可能需要在那个资源上进行 CRUD 操作，并且更喜欢缓存查询(也就是说，GET api.acmestore.com/items和GET api.examplebank.com/transactions都将被缓存)。新 API 的第三方开发者只需要推理数据模型，剩下的就交给 HTTP 约定，而不需要深入研究成千上万的操作。换句话说，与 SOAP 相比，REST 与 HTTP 和 CRUD 的耦合更紧密，但是提供了松散的数据契约。
休息的问题
随着越来越多的 API 投入生产使用并扩展到极致，RESTful 架构中出现了一些问题。你甚至可以说 GraphQL 介于 SOAP 和 REST 之间，各取所需。
服务器驱动的选择
在 RESTful APIs 中，服务器创建一个资源的表示来响应客户端。
然而，如果客户想要一些特定的东西，比如返回一个用户的朋友的朋友的名字，他们的工作是工程师。
休息时，您可能会看到这样的内容:
GET api.example.com/users/123?include=friend.friend.name&friend.friend.ocupation=engineer
GraphQL 允许您以更简洁的方式表示这个查询:
{ user(id: 123) { friends { friends(job: "engineer") { name } } } }
获取多个资源
GraphQL 的主要好处之一是使 API 不那么繁琐。我们中的许多人都见过这样的 API，其中我们首先必须先GET /user然后通过GET /user/:id/friend/:id端点分别获取每个朋友，这可能导致 N+1 个查询，并且是 API 和数据库查询中众所周知的性能问题。换句话说，RESTful API 调用在最终的显示形式形成之前被链接在客户端。GraphQL 可以通过允许服务器在单个查询中聚合客户机的数据来减少这种情况。
更多深度分析
而 API 分析对 GraphQL apis 也是一个不利因素，因为那里几乎没有工具。支持 GraphQL APIs 的工具可以提供比 RESTful APIs 更多的查询洞察。
GraphQL 的问题
贮藏
缓存内置在 HTTP 规范中，RESTful APIs 能够利用它。与缓存相关的 GET vs POST 语义被很好地定义，使得浏览器缓存、中间代理和服务器框架能够遵循。可以遵循以下准则:
- GET 请求可以被缓存
- GET 请求可以保留在浏览器历史记录中
- GET 请求可以加入书签
- GET 请求是幂等的
GraphQL 不遵循 HTTP 规范进行缓存，而是使用单个端点。因此，开发人员有责任确保为可以缓存的非可变查询正确实现缓存。必须为缓存使用正确的密钥，这可能包括检查主体内容。
虽然您可以使用像 Relay 或 Dataloader 这样理解 GraphQL 语义的工具，但这仍然不能涵盖像浏览器和移动缓存这样的东西。
减少无共享架构
RESTful APIs 的美妙之处在于它们很好地补充了无共享架构。例如，Moesif 有一个api.moesif.com/v1/search端点和一个api.moesif.com/v1/alerting端点。公开地说，这两个端点看起来就像两个不同的 REST 资源。但在内部，他们指出了隔离计算集群上的两种不同的微服务。搜索服务是用 Scala 写的，提醒服务是用 NodeJS 写的。通过主机或 URL 路由 HTTP 请求的复杂性比检查一个 GraphQL 查询和执行多个连接要低得多。
暴露给任意请求
虽然 GraphQL 的一个主要优势是使客户端能够查询他们需要的数据，但这也可能是有问题的，尤其是对于组织无法控制第三方客户端查询行为的开放 API。必须非常小心地确保 GraphQL 查询不会导致代价高昂的连接查询，这会降低服务器性能，甚至会造成服务器 DDoS。RESTful APIs 可以被约束以匹配所使用的数据模型和索引。
查询的严格性
GraphQL 消除了在 API 之上定制查询 DSL 或副作用操作的能力。例如，Elasticsearch API 是 RESTful 的，但也有一个非常强大的 Elasticsearch DSL 来执行高级聚合和度量计算。这种聚合查询可能更难在 GraphQL 语言中建模。
不存在的监控
RESTful APIs 的优势在于它像网站一样遵循 HTTP 规范。这使得许多工具能够探测一个 URL，例如api.moesif.com/health，如果不正确，它将返回 5xx。对于 GraphQL APIs，除非您支持将查询作为 URL 参数放置，否则您可能无法利用此类工具，因为大多数 ping 工具不支持 HTTP 和请求主体。
除了 ping 服务，很少有 SaaS 或开源工具支持 API 分析或对 API 调用进行更深入的分析。客户端错误在 GraphQL API 中显示为 200 OK。预计会出现 400 个错误的现有工具将无法工作，因此您可能会错过 API 上发生的错误。然而与此同时，给予客户更多的灵活性需要更多的工具来捕捉和理解 API 的问题。
什么是 Moesif？ Moesif 是最先进的 REST 和 GraphQL 分析*台，被数以千计的*台用来衡量您的查询执行情况，并了解您最忠实的客户正在使用您的 API 做什么。
结论
GraphQL APIs 可能是令人兴奋的新技术，但是在做出这样的架构决策之前理解权衡是很重要的。一些 API，比如那些只有很少实体和跨实体关系的 API，比如分析 API，可能不适合 GraphQL。而具有许多不同域对象的应用程序，如电子商务，其中有商品、用户、订单、支付等等，可能能够更多地利用 GraphQL。
实际上，GraphQL vs REST 就像比较 SQL 技术 vs noSQL。在某些应用程序中，在 SQL Db 中建模复杂的实体是有意义的。而其他只有“消息”的应用程序，如高容量聊天应用程序或分析 API，其中唯一的实体是“事件”，可能更适合使用像 Cassandra 这样的东西。
被拯救的群体:什么，为什么，如何
原文：https://www.moesif.com/blog/technical/api-analytics/Saved-Cohorts-The-What-Why-And-How/
能够根据用户或公司的行为或特征对他们进行分组是非常有用的。在 Moesif 中，我们有一个名为保存队列的功能，可以让你做到这一点。保存的队列可以帮助企业推动营销活动和其他销售计划，帮助工程师和客户成功团队管理持续的问题，以及许多其他用例。
什么是保存的队列？
保存的群组实质上是符合特定标准的用户或公司的分组。当条件满足时，用户或公司可以被添加到群组中。当用户或公司不再符合群组定义时，他们将被从群组中移除。为了在 Moesif 中使用保存的群组，您必须启用用户和/或公司跟踪。该功能不适用于匿名用户或公司。
在 Moesif 中，用户群组将从保存群组中添加或删除个人用户。当试图识别个人或组何时出现问题或错误、新用户或其他特定分组时，这可能很有用。例如，对于客户成功团队来说，知道新用户何时遇到特定错误可能是有用的，比如在尝试访问 API 时出现 HTTP 401 未授权响应。可以创建群组来跟踪符合该条件的所有用户。
一个公司群组类似于一个用户群组，除了它将一个公司内的所有用户视为一个单独的单元。回到我们之前的例子，我们可以建立一个公司群组，它将监控收到 HTTP 401 未授权响应的公司。这意味着该公司内接收到符合该标准的响应的任何用户将意味着该公司被添加到群组中。根据你试图从你的数据中获得什么样的洞察力，同时使用用户和公司群组可能是有用的。
什么是群组通知？
除非你经常刷新你的群组列表，否则当一个新的用户或公司被添加到你已经建立的特定群组时得到通知可能是有用的。为此，您可以使用群组通知。使用群组通知将允许您准确知道新用户或公司何时符合特定标准，而无需持续手动监控您的群组列表。
群组通知支持多种不同的渠道，可以在创建新群组时创建，也可以添加到现有群组中。支持群组通知的渠道包括电子邮件、Slack 或自定义网络挂钩。有了几个选项，就可以灵活地将通知传递给团队中最有效的渠道，如果需要，甚至可以传递给多个渠道。当用户或公司被添加到群组中时，选定的渠道将会收到通知，以帮助您的团队了解情况。
为什么使用保存的群组？
使用保存的群组对于查看在产品使用方面具有相似特征或趋势的用户分组非常有用。保存的群组可用于报告目的，也可用于快速查看哪些用户属于您概述的特定细分市场或标准。在 Moesif 中，除了报告或查看群组成员，我们许多最强大的功能都是由拯救的群组驱动的。例如，像行为电子邮件和治理规则这样的功能是通过使用群组来实现的。
对于行为电子邮件，当用户被添加到群组时，他们可能会自动收到一封电子邮件。一个简单的例子是，当用户第一次调用 API 或注册您的*台时，您可以自动向他们发送电子邮件，作为入职电子邮件流程的一部分。对于遇到特定错误的用户，您也可以这样做。通过为他们创建群组，当他们遇到特定的错误情况时，您可以向他们发送电子邮件。
就像上面的行为电子邮件场景一样，使用监管规则，需要创建一个群组，概述您可能想要阻止的特定行为。一个很好的例子是，如果你有一个货币化的 API，并希望阻止过期发票的用户。您可以简单地创建一个群组来添加发票过期 7 天以上的用户。一旦用户加入这个队列，治理规则可以向用户返回一个 HTTP 402 Payment Required 状态，包括一个请求体，告诉用户支付他们的发票。
群组也可用于动态采样。通过将流量与保存的群组相关联，您可以选择定制或减少 Moesif 中记录的流量。通过这样做，您可以确保最重要的流量被记录在 Moesif 中，同时排除不太重要的流量。您可能希望确保 100%返回错误响应的调用都进入 Moesif，而只对 20%的成功调用进行采样。为此，你只需为每种情况建立一个保存群组，作为你抽样标准的一部分。
正如您所看到的，Moesif 中的群组不仅仅是简单地用作报告工具，还可以在*台中驱动一些非常棒的功能。
如何在 Moesif 中创建保存的群组
现在，您已经了解了什么是保存的群组以及它们可以做什么。让我们简单看看如何建立一个用户群。首先，您需要导航到 Moesif 中的用户屏幕。
在此之后，我们将建立一个标准。在这个例子中，我将过滤过去几个月中至少收到 5 次 HTTP 401 未授权响应的用户。看起来会像这样:
现在我的过滤器已经创建好了，我将点击屏幕右上角的创建群组。
在这里，输入您的群组名称，然后点击模式右下角的创建群组按钮。
您也可以点击接收群组通知来设置此时的通知。或者，您也可以在群组创建后再进行设置。
现在，您将看到群组已经创建。通过点击屏幕右侧的条目，您可以利用一些其他功能，如和 治理规则 。您也可以通过此面板配置群组通知。
**
如果您需要编辑或想要在未来查看群组，可通过左侧导航上的用户群组菜单项获得。
如果你需要创建一个公司团队，也应该采取同样的步骤。你可以按照同样的步骤创建 __ 公司群组 _ _ 进入公司屏幕，而不是我们上面做的用户屏幕。
试试吧！
有兴趣为自己尝试一下保存的队列？如果你已经注册了 Moesif，只需登录并按照上面的说明操作，或者查看我们的指南即可。如果您是 Moesif 的新用户，今天就注册一个帐户并解锁我们所有的高级功能，包括行为电子邮件和治理规则，它们都由保存的群组提供支持。**
HIPAA 兼容 API 分析的安全代理
原文：https://www.moesif.com/blog/technical/compliance/Secure-Proxy-for-HIPAA-Compliant-API-Analytics/
在 HeathTech 应用程序中，通常情况下，你会处理私人或健康相关的数据。这需要遵守法规，例如美国的 HIPAA。这些法规迫使您以一种明确定义的方式处理敏感数据，因此只有特定的人可以读取这些数据，如果他们读取了这些数据，应该将其记录下来以供以后审计。
为了符合 HIPAA，必须在您的公司和应用中实施技术和管理保护措施。技术安全措施通常会导致更复杂的软件架构。因此，在开始之前，确保 HIPAA 合规性的额外工程开发工作是必要的，这是一个好主意。或者，你可能属于不遵守 HIPAA 安全的四种情况之一。
在的配套文章中，我们解释了如何构建符合 HIPAA 的 API。在本文中，我们将深入探讨如何使用安全代理来保护您的健康数据和您的应用 HIPAA 投诉。在我们的文档部分给出了关于如何使用 Moesif 专利安全代理的完整说明。
不使用 HIPAA 存储健康数据？
根据定义，如果您的客户在将数据发送给您之前对其进行加密，您就不知道该数据的内容。这导致了可信的否认。如果没有加密密钥，您在自己端存储和处理的数据对潜在的攻击者来说毫无价值。
这可以通过安全代理来完成。
安全代理是您和客户之间的 API 服务器，但位于客户的数据中心。离开客户数据中心的数据会被加密，然后发送到您自己数据中心的 API。
对于加密，代理使用只有您的客户知道的密钥。如果有人窃取了您的加密数据，没有您客户的加密密钥，他们就无法读取这些数据。
如何构建一个安全的代理？
第一步是构建一个服务器，作为您自己的 API，但可以由您的客户在内部部署。然后，API 的客户端将与该代理通信，而不是直接向 API 发送请求。
接下来，在将所有客户端数据发送到实际的 API 之前，将它们加密到正确的级别。因此，您的代理需要使用客户提供的加密密钥，而您永远无法访问这个密钥。
正确的加密级别取决于您的 API:
- 获取一个简单的键值存储 API。它只是将所有内容存储在请求正文中，在发送之前加密整个正文就足够了
- 对于任何更复杂的事情，您的代理需要以更复杂的方式处理加密。
以 Moesif API 分析为例。Moesif 的 API 接收事件并计数。如果这个 API 可以为每个请求接收多个事件，那么您必须独立地加密请求中的每个事件名，而不是一次加密整个请求体——否则，API 将无法理解该请求。但是由于事件名称被加密，Moesif 不知道事件是什么。与健康有关吗？是网络游戏里的吗？
最后，当您的客户想要读取数据时，您需要解密数据。因此，代理需要一种向客户显示明文数据的方式。
安全代理示例
我已经创建了一个 GitHub 库来说明安全代理的实现。它包含三个部分:一个分析 API 服务器、一个代理 API 服务器和一个客户端。
免责声明:这只是一个基本的例子，在这个例子中，我使用了一个我实际上没有审计的加密库。如果你建立你自己的系统，你将不得不独立地做那部分研究！
说完这些，让我们看看系统的三个部分。
分析应用编程接口
我从存储库中提取了分析 API 的基本部分。API 是用 Node.js 和 Express 框架构建的。
const eventStore = [];
api.post("/event", ({ body }, response) => {
eventStore.push(body.event);
response.status(201).json("201 - Created");
});
api.get("/results", (request, response) => {
const results = eventStore.reduce(
(results, event) => {
if (!results[event]) results[event] = 0;
results[event]++;
return results;
},
{}
);
response.status(200).json({ results });
});
api.listen(9000);
有两个端点，一个将接收事件并将其存储在数组中，另一个端点将计算每个事件的接收频率，并将这些总和发送回客户端。这里只是一些基本的东西，数据被接收，一些处理被完成，结果被发送到客户端。
分析 API 客户端
接下来，让我们看看客户端实际上是如何使用分析 API 的。同样，我从库中提取了重要的部分。
async function logEvent(event) {
return axios.post(
"http://localhost:9000/event",
{ event }
);
}
async function getResults() {
const response = await axios.get(
"http://localhost:9000/results"
);
return response.data.results;
}
await logEvent("plaintext-event-a");
await logEvent("plaintext-event-a");
await logEvent("plaintext-event-a");
await logEvent("plaintext-event-b");
await logEvent("plaintext-event-b");
const results = await getResults();
客户端将带有事件字符串的 JSON 对象发送到 analytics API，该 API 监听端口 9000。它最后还会获取结果。
运行示例
如果我们在添加了日志记录的情况下运行这个示例，我们会看到以下内容。
[Client ] Sending event: plaintext-event-a
[Analytics] Received: plaintext-event-a
[Client ] Sending event: plaintext-event-a
[Analytics] Received: plaintext-event-a
[Client ] Sending event: plaintext-event-a
[Analytics] Received: plaintext-event-a
[Client ] Sending event: plaintext-event-b
[Analytics] Received: plaintext-event-b
[Client ] Sending event: plaintext-event-b
[Analytics] Received: plaintext-event-b
[Analytics] Sending results: {
'plaintext-event-a': 3,
'plaintext-event-b': 2
}
[Client ] Results: {
'plaintext-event-a': 3,
'plaintext-event-b': 2
}
客户端将其事件发送到分析 API，分析 API 将其保存在事件存储中。最后，客户端获取结果，这是一个包含每个事件总和的 JSON。
我们看到分析 API 获得了事件的明文名称。如果事件包含健康相关数据，分析 API 必须符合 HIPAA。例如，这些事件可以跟踪一个人服用特定药物的频率。
安全代理 API
让我们看看这个系统的安全代理是什么样子的。
注意:在示例项目中，所有系统都在 localhost 上运行，但是为了使安全代理有效，它必须在您客户的数据中心内部运行，虽然您自己的公司不需要符合 HIPAA，但是您的客户必须符合。但是如果他们一开始就在处理与健康相关的数据，他们可能已经在处理了。
api.post("/event", async ({ body }, response) => {
const event = cryptoStore.encrypt(body.event);
const res = await axios.post(
"http://localhost:9000/event",
{ event }
);
response.status(res.status).end(res.data);
});
api.get("/results", async (request, response) => {
const {
data: { results },
status,
} = await axios.get(
"http://localhost:9000/results"
);
const results = Object.keys(results).reduce(
(results, encryptedEvent) => {
const event = cryptoStore.decrypt(encryptedEvent);
results[event] = results[encryptedEvent];
return results;
},
{}
);
response
.status(status)
.json({ results });
});
api.listen(9999);
像在分析 API 中一样，在安全代理中有相同的两个端点。对于客户端，它们的行为就像分析 API 的端点一样。这里唯一的区别是，安全代理 API 端点将在将事件名称转发给分析 API 之前对其进行加密和解密。
这样，安全代理 API 就像分析 API 的替代物一样。客户端不知道它的实现，可以像以前一样简单地向代理发送事件并获取结果。
我在这里选择的加密细节是事件的名称。当安全代理从分析 API 或客户端接收到 JSON 结构时，它会传递 HTTP 状态代码、求和并保存这些结构。
运行示例
如果我们运行添加了日志记录的示例，并且代理位于客户端和分析 API 之间，我们会看到以下输出:
[Client ] Sending event: secret-event-a
[Proxy ] Received event: secret-event-a
[Analytics] Received event: 23c06d46723cd...
[Client ] Sending event: secret-event-a
[Proxy ] Received event: secret-event-a
[Analytics] Received event: 23c06d46723cd...
[Client ] Sending event: secret-event-a
[Proxy ] Received event: secret-event-a
[Analytics] Received event: 23c06d46723cd...
[Client ] Sending event: secret-event-b
[Proxy ] Received event: secret-event-b
[Analytics] Received event: 604c04290177e...
[Client ] Sending event: secret-event-b
[Proxy ] Received event: secret-event-b
[Analytics] Received event: 604c04290177e...
[Analytics] Sending results: {
'23c06d46723cd...': 3,
'604c04290177e...': 2
}
[Client ] Results: {
'secret-event-a': 3,
'secret-event-b': 2
}
在日志中，我们看到安全代理充当中间人。它接收带有客户端名称的事件，但是分析 API 接收加密的字符串。它不知道事件名称是否包含游戏分数或药物摄入信息。
在 API 分析的例子中，与 Moesif 一样，API 不知道跟踪哪种 API。唯一的要求是相同类型的所有事件都有相同的名称。这足以将它们关联起来并计算出结果。
结论
如果您的 API 不需要识别它处理的数据类型，安全代理是规避 HIPAA 遵从性的一个方便的解决方案。
您的客户自带加密密钥，并在自己的数据中心部署安全代理。HIPAA 相关的要求不再与你有关，因为你现在有可信的拒绝权；您永远不知道您正在处理哪种数据，因为所有数据在离开客户网络之前都是加密的。你也从未接触过加密密钥。
自助式定制 API 控制面板允许您轻松跟踪和共享关键 API 指标
上个月，我们发布了新的仪表板功能。现在是时候用你自己的仪表板来讲述你的故事了。
通过拖放操作轻松创建-清晰说明关键指标-在团队和合作伙伴之间安全共享
用你的数据讲一个故事
我们的一个金融科技客户过去常常通过他们所谓的“记录直觉”来决定定价策略、产品变化和用户界面修改。他们会对市场和客户有所了解，可能会与特定用户交谈，然后做出重要的改变。
确保您与数据一起前进
一旦他们整合了 Moesif，他们就开始根据实际数据做出决策。一夜之间，他们可以轻松跟踪关键的 API 指标，监控公司的 KPI，并深入调查客户问题。他们还发现了许多以前不明显的东西，例如我们监管的东西的漏洞和合规性缺陷。
我们的金融科技产品经理的仪表板由一系列工作区组成，包括每日活跃用户(DAU)、整合漏斗、HTTP 状态请求、KYC 产品使用、最活跃用户、最*的 API 错误等等。下面的图 1 显示了他们的仪表板。
图一。金融科技客户仪表板的展示
工作区讲述单一的故事，而仪表盘则完整地描述了产品的性能。对于我们的金融科技客户，集成漏斗工作区总结了客户如何加入*台，注册，确认他们的电子邮件，然后触发 API 调用——他们客户的端到端生活。通过将其与相邻工作区的 KYC 产品进行配对，他们能够看到该产品的表现如何——有多少 KYC 用户在使用实时版本，而不是通过试用交易。通过引入 HTTP 状态，可以确定错误的数量——200 个状态代码对非 200 个状态代码。因此，在一个仪表板上，他们能够看到谁是他们的客户，他们是如何集成的，以及他们正在经历什么。
创建自定义仪表板
工作区和仪表板
类似于 Google Drive，Moesif 的仪表板可以被认为是一个驱动器中的文件夹，而工作区是填充该文件夹的文档。一旦工作区被配置，它就可以被保存到一个仪表板中，如图 2 所示。
图二。将工作区保存到仪表板中
通过将多个工作区保存到仪表板中，您可以将它们相互关联，并设计您的叙述。
排列仪表板
可以通过拖放在仪表板中重新定位工作区。按照您想要的方式创建您的工作区，并按照您希望人们阅读它们的顺序放置它们。
图 3。通过拖放重新排列
仪表板层次结构
仪表板可以嵌套在多达三层的层次结构中。只需拖动子仪表板的名称，将其嵌套在父仪表板下，就可以创建子仪表板，如图 4 所示。
图 4。仪表板的层次结构
共享仪表板和工作区
创建一次。分享很多。
一旦您配置了每日或每周仪表板，就可以轻松地与同事分享。当您需要按月或按季度向管理层报告时，您只需按日/周进行设置，而无需创建不同的仪表板。
工作空间可以是私有的，也可以在团队、组织甚至外部公司的合作伙伴之间共享。例如，在故障排除期间，可以使用我们的自定义链接功能与关键客户共享特定数据。
通过单击 Share 按钮，然后选择“Shared With”下的选项，可以设置工作区的共享权限，如下面的图 4 所示。工作区可以在您的团队内部共享，通过唯一的链接与公众共享，或者设置为私有以便只有您可以查看。通过配置过滤器，可以将访问进一步限制到特定的用户 id、公司 id、时间段等。
图 5。共享选项
仪表板在您的组织中自动共享。一旦创建了实时仪表板，它将与您的团队和经理共享，这样每个人都可以掌握最重要的 KPI。
数据范围和刷新率
仪表板会实时更新，因此您永远不必担心会看到过时的数据。刷新率可以在右上角设置为“不刷新，15 秒，60 秒或 5 分钟”，如图 6 所示。同样在右上角，可以通用地设置日期范围，然后应用于仪表板中的工作区。
图 6。设置日期范围和刷新率
三大要点
Moesif 的仪表板允许您用数据讲述故事，与同事和合作伙伴分享，并掌握最重要的 KPI。立即部署并做出更明智的决策。
我们的金融科技产品经理最后说一句话:
“当我查看我的实时产品控制面板时，我可以快速识别趋势。我可以看到按产品划分的国家/地区、他们正在进行的请求类型、按产品划分的其他请求以及他们针对每种产品得到的错误类型。太牛逼了。”
创建 API 第一公司
原文：https://www.moesif.com/blog/developer-platforms/self-service/Starting-an-API-First-Company/
你开发了一个惊人的 API 产品。太棒了。但这只是你旅程的开始。创办一家 API 优先的公司会给你带来一系列独特的挑战。基于 Moesif 自己创建 API 优先公司的经验，我们在下面分享了一些见解，以帮助您避免一些陷阱，并充分利用摆在您面前的机会。
“API 优先”对不同的人有不同的含义。然而，出于本文的目的，我们指的是将 API 作为主要产品发布并通过向其他企业出售其 API 来赚钱的公司。
创办一家以 API 为先的公司有什么独特之处？
当你开始一个 API 优先的公司时，你是在向开发者销售你的产品(B2D)。这是 API 优先业务和传统企业业务之间的关键区别之一。你既不是 B2C 公司，也不是 B2B 公司——你在这两者之间占据着一个独特的位置，有着自己的一系列挑战。
这意味着一些传统的销售线索挖掘和销售行动手册并不总是适用。你是在向一群开发人员销售产品，他们大多以对传统的销售和营销工作反应迟钝而闻名。同时，软件的购买也比以前分散了很多。单个开发人员在选择使用哪些工具或 API 时有很大的自主权。更多的购买力现在由发现和集成你的 API 的个人开发者决定。
这意味着你的走向市场(GTM)必须与接触和销售给开发者相一致。一个流行的策略是首先找到开发者，让他们支付象征性的费用(比如每月 50 美元)。这需要有一个强大的内容和集客营销策略来吸引开发者。了解为什么内容是开启开发者至上营销战略的关键。
一开始，你需要推动发现，并在开发者自己的地盘上与他们接触。在这方面，内容是你的朋友，所以是时候把你自己定位为你特定领域的权威了。你需要展示你的专业技能，同时用开发者自己的语言与他们交流，表明你理解他们的沮丧，并支持他们找到真正的解决方案——其中一个最好是你的产品！
如果不掌握您的自助服务采用和激活渠道，采取强硬手段，招募完整的销售团队，可能会产生糟糕的结果。你需要让开发者以他们自己的方式和速度来测试你的产品。做好这一点，你就可以在公司发展的适当阶段增加销售。
客户发现
你可能是作为一名工程师出身的创始人创办了这家公司，这可能会让你熟悉问题/解决方案领域。然而，你的经历只是众多经历中的一个。执行适当的客户发现以了解每个客户的痛点以及是什么让他们采用像您这样的 API 是很重要的。不同的客户根据规模、行业和技术有不同的需求。虽然让开发人员一开始就加入一个调用可能很棘手，但如果他们首先开始看到价值(比如测试您的 API 或阅读一段有价值的内容)，这是可行的。获得产品反馈的最好方法之一是花大量的时间通过支持票和相关的电话来了解你的第一批客户，帮助他们起步和运行。
对于首席执行官/联合创始人来说，在创建最初的 MVP 时处理最初的支持票而不是授权是非常有价值的。你的一些最佳客户发现将来自这里，包括对客户使用你的产品并从中发现价值的具体方式的杰出见解。因此，与早期采用者联系可以为您提供关于用例、痛点等的大量信息。这些见解对于发展你的新兴企业将是无价的。
学习销售知识
一个初创企业的创始人必须在成长的过程中学会一点东西——关于金融和法律，关于人力资源，关于营销和销售。你可能是一名工程师，但你也必须接受一大堆其他商业学科，包括销售。
开发者优先(或产品导向的增长)并不意味着零销售人数。你仍然需要帮助客户起步和运行，并使他们成功。首席执行官/联合创始人应该进行最初的销售拜访，因为他或她最了解产品和用例，至少在大约十个客户落地之前是如此。那些早期的销售讨论对于直接了解潜在客户对采用你的 API 有什么问题或异议是非常有价值的。此阶段不一定需要正式的销售流程。然而，你应该专注于创建一个稳定的合格的开发人员注册并试用这个 API。我们说有资格，因为确保你的营销策略以有购买潜力的组织中的开发者为目标非常重要。
当你开始一家 API 优先的公司时，在销售方面要记住的另一件事是，你需要让开发者很容易地试用你的产品。通过提供一个开发人员可以用信用卡支付的廉价入门计划，您减少了开发人员开始使用您的 API 的时间。使其过于复杂或过于昂贵会大大延长您的销售过程，因为这可能需要许多利益相关方的批准。例如，利用点击服务条款，而不是需要法律审查的冗长的 SaaS 协议。不要昂贵的概念验证或试点，利用自助式试用，这样开发人员可以按照自己的节奏开始运行。这也意味着你的销售过程可能不会参与进来，直到他们表明意图或者测试你的 API。
寻找资金
当你开始一个 API 优先的公司的时候，你要做的事情中最重要的一件就是寻找资金。API 优先的公司可以有很好的单位经济性，不需要大量的启动资金，但是你仍然需要一个结构化的方法，就像任何销售过程一样。
当你想筹集资金时，从你现有的职业关系入手。比起一个完全陌生的人，你更容易从那些已经了解你的人那里获得投资。许多技术专业人士喜欢天使投资，这是风险投资之前的一个很好的起点。天使投资者是投资他们自己的钱的人，但是你必须确认他们是被认可的。当然，创业公司天生就有风险。永远不要接受那些可能会因为彻底的损失而受到严重影响的人的钱。驾驭天使投资人的最好方法是进行一次非正式的咖啡约会。没有甲板，没有正式的球场。只谈你的问题/解决方案空间，衡量是否有共同利益。
通常，天使投资者可以在一次会面或几封跟进邮件后结束投资。一旦你决定瞄准风险投资，根据阶段的不同，会有一个稍微复杂一点的尽职调查过程。天使(或种子前)资金可以帮助你雇佣一些关键角色来建立一个初始的 MVP(最小可行产品)
创建产品愿景
当开始你自己的 API 主导的公司时，拼图的最后一块是创造你的产品愿景。如果没有一个，你将冒着构建一大堆不利特性的风险，并以一个令人困惑的解决方案而告终。
爬行、行走、奔跑的方法可以很好地实现这一点。例如，考虑一下你可以先做什么，比如一个 API 和一个函数。在此之后，你可以考虑一些额外的功能，在中期内将它变成一个更大的产品。最后，你如何把你的产品变成一个更大的赢得客户和市场的*台。这种方法意味着您可以从拥有单一 API 逻辑地转移到添加补充的 API 和特性，从而为您的*台创造更多价值。一个清晰的愿景和计划会帮助你顺利到达那里。
此外，确保你公司有一个包含你的愿景的使命宣言。这有助于确保您的产品和营销路线图符合这一愿景。虽然一家公司的使命会随着时间的推移而改变，但它应该在任何给定的时间被公司很好地理解。当你提出新的产品特性时，问问你自己:这是否符合我们公司的愿景？此外，调查哪些功能缺失阻碍了你实现愿景。
构建和迭代产品
如果你的领域有多个参与者，你很容易被“竞争”所困扰，对你的想法变得过于保密。最糟糕的是，你可以在没有任何客户验证的情况下，秘密地构建一个完整的 API *台。API 优先业务的伟大之处在于，API 就像乐高积木。不要一次构建并发布所有功能，而是让客户拥有一个最小可行产品/最小可行*台(MVP ),它可能只是一小组 API。您可以在以后添加额外的 API 来扩展功能。对于另一家公司来说，完全改变其产品策略并复制你的整个愿景是非常困难的。不如拥抱竞争，看看你能创造出什么样的创新伙伴关系。
也请记住，许多科技创始人喜欢写博客。这意味着你不仅可以跟上你所在行业的其他参与者的技术发展，还可以跟上他们在业务运营和文化发展方面愿意分享的任何东西。当你处于自己创业的早期阶段时，其中一些见解可能会特别有帮助。
快速决策
当你开始你的 API 优先公司时，你将有一大堆的决定要做。根据这些决定的巨大影响将它们分类有助于集中你分配多少时间来做这些决定。
例如，你应该花更多的时间规划你的后端架构还是你的产品信息？对前者的更改可能很难实现并且范围很大，而对后者的更改可以很快推出。思考这个决定的含义是一个很好的指南，可以让你知道这个决定值得你投入多少注意力。
进一步的灵感
创建一个 API 优先的公司是一个学习的过程。如果你在寻找更多的灵感，这个关于如何与 Radar 首席执行官 Nick Patrick 一起建立一个 API 优先公司的播客是一个很好的开始。
Moesif 的启动程序改善了开发人员的旅程
使用 Moesif 加速您的成长
有兴趣将您的产品带入下一个发展阶段，但缺少衡量标准？我们知道，作为一家初创公司，公司都非常专注于将产品推出市场。今天的创始团队不想(或不需要)创建他们自己的用户管理、计费或其他分析工具。通过与同类最佳的提供商建立伙伴关系，初创公司可以利用这些分析工具，而无需浪费工程人力来创建内部工具包。为了成功地改进和迭代你的 API 驱动的产品，重点需要放在你的业务的正确度量上。发布 API 产品的特性是不够的；理解开发人员的旅程并深入了解客户的 API 调用对于全面理解产品的使用非常重要。这看起来令人畏惧，但是 Moesif 简化了洞察收集过程。找到合适的产品/市场对可持续增长至关重要，但了解你的市场始于正确的指标和分析。
创业公司 Symbl.ai 细化产品策略，增强 DevEx
Symbl.ai 想要深入挖掘开发者之旅，在不构建自己的分析*台的情况下改善他们的体验。Symbl.ai 为开发者提供 API，使用机器学习算法分析语音和视频对话。Symbl.ai 专注于上下文智能和定制跟踪器，允许实时或异步处理和转录对话。因为 Symbl.ai 在发现 Moesif 时工程资源有限，他们一直以来都优先考虑新产品功能，而不是构建内部分析仪表板。当寻找外部供应商时，他们发现没有多少选项可以处理 API 的独特复杂性。
随着 Symbl.ai 将注意力集中在开发人员体验上，他们转向 Moesif，以获得客户对其 API 使用的更完整的描述，从而为开发人员创造最佳体验。通过 Moesif 推动增长，Symbl.ai 在种子阶段就开始使用 Moesif，并从初创公司成长为企业合作伙伴。在公司产品发布和 470 万美元的种子融资一年后，他们还在首轮融资中筹集了 1700 万美元。
“当你是一个小公司时，很难将 20%的持续工程努力集中在为自己建造仪表板上。”苏尔比·拉索尔，首席执行官&联合创始人
Moesif 允许公司通过数据驱动的见解来优化开发人员的旅程。Moesif 不需要在内部构建 API 监控系统，而是允许实时集中 API 洞察，并根据您的特定业务 KPI 进行调整。通过 API 调用的粒度信息可视化客户使用情况，Moesif 用户可以看到从第一次 API 调用/第一次 Hello World (TTFHW)的时间到首选端点的任何信息。
为了帮助 API 驱动的公司加速发展和了解他们的用户，Moesif 成立了一个启动项目。针对新的 API 优先或支持 API 的初创公司，启动计划是开发者深入了解其产品和客户使用旅程的独特机会。
作为 Moesif 创业计划的一员，您将获得大量资源，帮助您取得成功并发展您的业务。获得专门的实践支持和培训，以确保 Moesif 是用于分析 KPI 和指标的有用集成。以下计划适用于新的、渴望创业的公司:
适用于成长中的初创企业扩大产品导向型增长
6 个月内享受专业计划 40%或更高的折扣:
- 公司成立不到 4 年
- 筹集的资金不超过 400 万美元
- 少于 15 名员工
Pro plan 包括 10 名团队成员访问 Moesif *台，每月 500 万次活动，等等。参见计划。
为新成立的公司寻找适合市场的产品
有资格享受 6 个月增长计划 60%的折扣:
- 公司成立不到两年
- 筹集了不超过 10 亿 2M 的资金
- 少于 10 名员工
成长计划包括 3 名团队成员访问 Moesif *台，每月 100 万次活动，等等。参见计划。
如果你有兴趣了解更多关于 Moesif 的启动项目，请发电子邮件给 partners@moesif.com 或填写表格这里。Moesif 期待与有前途的初创企业合作，帮助他们充分利用数据，加速增长。
为 GraphQL APIs 构建身份验证和授权的步骤
在构建 API 时，将所有数据提供给互联网上的每个人通常不是一个好主意。出于业务原因，我们需要检查谁是付费客户，出于安全和隐私原因，我们需要限制对系统部分的访问。
我们已经写了一篇关于 REST APIs 的认证和授权的文章。
在本文中，我们将深入 GraphQL 的 auth 主题。
身份验证和授权的区别
这两者经常与单词 Auth 混为一谈，例如在中，“我们需要给我们的系统增加认证功能。”
虽然这两个主题相互交织，但它们涵盖了不同的方面。
认证是关于知道谁想用我们的系统做些什么。
我们可以通过用户名/电子邮件和密码登录或者 GitHub 或脸书等社交网站来解决这个问题。
授权就是要知道他们被允许对我们的系统做什么。
这个问题更加复杂，因为它深深依赖于我们的业务案例。虽然不明显，但授权是业务逻辑，应该如此对待。
认证、授权和图表
我们将这个逻辑放在 GraphQL APIs 的什么地方呢？
graph QL 创建者的意见是“将授权逻辑委托给业务逻辑层”。除了创建【充分水合的用户对象】而不是将身份验证令牌传递给我们的业务逻辑之外，他们对身份验证没有任何强烈的意见。
这是什么意思？我们的商业逻辑在哪里？我们将在哪里创建这些用户对象？
GraphQL 系统的结构
GraphQL 系统的结构如下图所示:
在左边，我们有不同类型的中间件，它们将一些逻辑应用于我们所有的请求。
在中间我们有 GraphQL 引擎，它计算出如何在 GraphQL 模式的帮助下将我们的 GraphQL 查询翻译成对正确解析器函数的调用。在大多数框架中，比如 Node.js 的 Express framework，GraphQL 引擎也被实现为中间件。
在右边，我们有不同类型的解析器函数，它们将 GraphQL 引擎连接到我们的业务逻辑。当查询相应的数据类型时，GraphQL 引擎会执行解析器。
业务逻辑可以是一个整体系统或一堆微服务。
将身份验证集成到 GraphQL 中
为了授权请求，我们需要在业务逻辑中访问当前用户的身份。这要求我们将认证逻辑放到一个地方，为我们所有的请求执行。如果我们看上面的图，这使得中间件——我们系统的一部分——成为了它的完美位置。
这种方法的另一个好处是:它完全独立于 GraphQL，因此我们可以重用我们的 REST 技能并重新应用它们！
如果您需要更新 REST 认证技能，请阅读我们之前的文章。
将授权集成到 GraphQL 中
为了理解这一点，让我们来看一个简单的中间件实现、一个 REST 资源处理函数和一个 GraphQL 解析器函数。对于这个例子，我将在 Express 框架和 Apollo 服务器上使用 Node.js。
首先，我们的业务逻辑:
const getMessage = (id, user) => {
const message = dataStore[id];
if (message.recipient.id === user.id) return message;
if (message.sender.id === user.id) return message;
throw new Error("no permission");
};
它通过 ID 从内存存储中加载一条消息。如果用户是该邮件的收件人或发件人，则允许他们阅读该邮件。否则，我们抛出一个错误。
二、认证中间件:
const authMiddleware = (request, response, next) => {
const token = request.get("authorization");
const user = loadUser(token);
if (user) {
request.user = user;
next();
}
response.status(401).end();
};
它从请求头中加载一个令牌，并使用它来加载当前用户。如果成功了，它会将这个用户对象添加到请求中，以便以后使用。
现在，让我们看看 REST 的实现。
expressApp.use(authMiddleware);
expressApp.get("/message/:id", (request, response) => {
try {
const message = getMessage(request.params.id, request.user);
response.end(message);
} catch (e) {
response.status(403).end({ error: e.message });
}
});
首先，我们用我们的authMiddleware；这确保了我们的request在端点处理程序中有一个user对象。
然后，我们定义一个函数，调用该函数向我们的/messages/:id端点发出 GET 请求。它使用我们的request的id参数和user对象加载一个带有我们的业务逻辑函数的message。
当一切正常时，我们得到message并可以将它发送给客户机。如果不是，我们将 HTTP 状态设置为403(禁止)。
getMessage函数在user对象的帮助下处理授权。它不在乎它从哪里来。
接下来，让我们看一个 GraphQL 实现，这里是用 Apollo 服务器创建的。
expressApp.use(authMiddleware);
const { ApolloServer, gql } = require("apollo-server-express");
const typeDefs = gql`
type Query {
message(id: String!): String
}
`;
const resolvers = {
Query: {
message: (parent, args, request, info) =>
getMessage(args.id, request.user)
}
};
const server = new ApolloServer({ typeDefs, resolvers });
server.applyMiddleware({ app: expressApp });
中间件的使用在这里保持不变。所以认证不需要改变。
然后我们使用apollo-server-express模块定义一个简单的 GraphQL API，它只有一个带有message的Query类型。
然后我们定义我们的解析器函数，它看起来几乎与 REST 示例中的一样。
解析器得到四个参数，第三个是我们已经从 REST 实现中知道的request。因为我们的中间件使用这个对象来附加user对象，所以我们可以像以前一样将它传递给我们的业务逻辑。
GraphQL 引擎解析了查询中的id参数，并将其存储到第二个参数中，因此只有它的位置不同。
我们的业务逻辑函数处理授权，与 REST 实现中一样。
这里的区别在于 GraphQL 不知道 HTTP 或者它的状态代码。如果它可以处理一个查询(即使结果为空)，它将只使用200。
我们的业务逻辑抛出的错误将被放在响应体中的一个errors数组中，客户端可以在那里以某种方式进行处理。
我们的响应 JSON 的message将被设置为null，这允许我们用部分数据来响应客户的请求。例如，如果消息位于 GraphQL 响应树的深处。
{ "data": { "message": null }, "errors": [ { "message": "no permission", ... } ] }
什么是 Moesif？ Moesif 是最先进的 REST 和 GraphQL 分析*台，被数以千计的*台用来衡量您的查询执行情况，并了解您最忠实的客户正在使用您的 API 做什么。
客户端中的处理
既然我们已经讨论了 API 中的身份验证和授权，我们还应该看看客户端。
客户端身份验证
如果我们采用基于令牌的认证，这是目前最主要的，我们首先需要获得这样一个令牌。我们可以用两种方法做到这一点。
授权令牌检索
- 我们为注册和登录创建额外的 HTTP 端点
- 我们为注册和登录创建了 GraphQL 变体
额外的 HTTP 端点将整个身份验证过程从 GraphQL API 中分离出来。就像服务器端的中间件方法一样。如果进行身份验证的服务不同于我们的 API，并且我们只需要来自它的令牌，这就更好了。
GraphQL 变体感觉更加完整，但在我们的 API 中需要更多的特例，因为我们需要让用户以某种方式访问它们，而无需经过身份验证。
在我看来，第一种方式风险较小。我们可以在 GraphQL API 中专注于我们的核心竞争力，并为未来保持灵活性。
令牌存储和放置
令牌需要和 GraphQL 请求一起发送给我们的 API。
为此，我们需要决定在哪里存储令牌，以及在请求的什么地方放置令牌。
存储方式有两种， localStorage 和HTTP cookie。
当存储在localStorage中时，我们可以通过 HTTP 头发送令牌。当我们将它存储在 cookie 中时，我们会自动将其与 cookie 一起发送。
这与 REST APIs 相同，两种变体各有利弊。我不会详细介绍，但是你可以在我们的 REST auth 文章中读到。
阿波罗客户端示例
让我们看一个简单的 Apollo Client 例子，它是一个用 JavaScript 编写的独立于 UI 框架的 GraphQL 客户端库。
import { ApolloClient } from "apollo-client";
import { HttpLink } from "apollo-link-http";
import { ApolloLink, concat } from "apollo-link";
const httpLink = new HttpLink({ uri: "/graphql" });
const authMiddleware = new ApolloLink((operation, forward) => {
operation.setContext({
headers: {
authorization: localStorage.getItem("token") || null
}
});
return forward(operation);
});
const client = new ApolloClient({
link: concat(authMiddleware, httpLink)
});
这里我们使用localStorage /header 变量来存储和发送令牌。
Apollo 客户端有一个网络层叫做 Apollo Link 。这用于使不同的协议可插拔。一个链接被实现为中间件，正如我们在 Express 示例的后端中看到的。
在这个例子中，我们将 HTTP 中间件配置到我们的 GraphQL API 端点，然后创建一个定制的中间件/链接用于身份验证。
两者都被插入到ApolloClient构造函数中，所以它们在我们发送的所有 GraphQL 查询中都被执行。
客户authMiddleware在每个请求之前查看localStorage,并将authorization HTTP 头设置为它找到的令牌。
在这里，我们已经看到了将身份验证排除在 GraphQL 之外的好处。我们可以对 HTTP 端点进行一个简单的fetch调用来注册或登录，并在开始创建 GraphQL 客户端对象之前将收到的令牌存储在某个地方。
反之亦然。如果我们想注销一个用户，我们可以丢弃 GraphQL 客户端对象，而不需要以某种方式改变它。
客户授权
如果我们正确地设置了身份验证，API 现在知道我们就是我们所说的那个人，但是仍然有可能我们想要查询不允许我们访问的数据。
在客户端，像在后端一样，授权是业务逻辑，所以我们需要考虑在特定的情况下做什么。
我们有一个 UI，发送一个大的 GraphQL 查询来一次性获得所有数据，现在它返回一些字段和一些错误。
Apollo 客户端库为此定义了三个错误策略，我们可以为每个或所有请求设置其中一个。
这些策略定义了我们也可以在定制客户端中使用的行为，或者在没有任何特定 GraphQL 库的情况下直接使用的行为。
- 如果响应中出现任何 GraphQL 错误，我们认为它失败了，并将其丢弃，就像发生网络错误一样。
- 我们忽略响应中的所有错误，并尝试按原样使用数据。
- 我们尝试将响应中的 GraphQL 错误与返回的数据结合使用，向用户展示我们所能做到的最好，并在旁边显示错误，以便他们知道为什么会缺少某些部分。
结论
身份验证和授权是 API 设计中非常重要的主题，但是正如本文所示，一旦我们理解了 HTTP APIs 的身份验证基础，我们就可以在 REST 和 GraphQL 上重用我们的技能，而无需做太多的更改。
理解授权是业务逻辑也很重要，它通常完全是为特定的软件产品定制的。这意味着它应该被推到我们代码库的边缘，这样就可以很容易地找到它，并且不会在很多地方重复出现。
2018 年夏季 API 使用状况报告
原文：https://www.moesif.com/blog/reports/api-report/Summer-2018-State-of-API-Usage-Report/
API 分析简介
对于任何数据驱动的工程师来说，最困难的事情之一就是回答“这些数字好吗？”我们淹没在来自各种 SaaS 工具的数据中，但有时我们只想知道什么是正常的范围。
例如，您可以调查一段时间内 API 的*均延迟，但是您如何针对 API 的“标准”度量进行基准测试呢？
欢迎来到【2018 年夏季 API 使用状况报告。我们分析了数十亿个 API 调用，以指导您构建正确的 API，并为您提供一个可以考虑的基准。
API 类型的度量标准
编程语言 API 开发者
下图是 Moesif 客户使用的 SDK 或语言。
编程语言 API 开发者
虽然 NodeJS 仍然是由 express 和 Reach 等框架的丰富生态系统驱动的构建 API 的无可争议的国王，但真正让我们惊讶的是 Python 在 2018 年变得多么受欢迎。越来越多的工程师正在发布 Python APIs，这可能受到最*机器学习热潮的推动。Scikit-learn、PySpark 和 TensorFlow 是非常流行的 ML 框架，它们允许任何人从 Pickle 或 ProtoBuf 文件创建模型，然后可以通过简单的 REST API 发布该模型。事实上，我们已经在 Moesif 发布了一些使用 Python 和 Flask 的推理 API。
按内容类型的 API 调用
我们保留了类型和编码，以便对谁设置编码部分进行细分。如果没有设置，今天的大多数框架将尝试使用 UTF-8。
按内容类型划分的 API 百分比
GraphQL 流行吗？
虽然 GraphQL 受到了很多压力，但我们也看到许多开发人员对迁移到 GraphQL 犹豫不决。与此同时，2018 年将是 GraphQL 的一年，新的开放 GraphQL APIs 的发布数量正在加快。
使用 GraphQL 的 API 百分比
什么是 Moesif？ Moesif 是最先进的 API 分析*台，被数千家*台公司用来改进他们的 API 和客户指标。Moesif 为您喜爱的语言提供了开源中间件和 SDK。
API 性能指标
保命普遍吗？
Keep Alive 是服务器调用其他服务器以保持 HTTP 连接对未来调用开放的常用技巧。这减少了后续调用的延迟，例如 API 服务器与数据库服务器的通信。
虽然保持活动在服务器对服务器中非常有益，但是在有许多客户端，但是每个客户端仅发送几个或仅一个请求的应用中，服务器将浪费资源来保持从不重用的连接打开。
按连接划分的 API 调用百分比
API 调用的*均延迟
请记住，一些 API 是同一网络上的服务器到服务器调用，或者是为非常低的延迟而设计的(如我们的收集 API ),它将具有单位数毫秒的延迟。
*均 API 调用延迟直方图
我们看到 28%的 API 调用在 500 毫秒内完成。然而，延迟有一条长尾。潜在的缺陷是没有配置超时(有些库有 60 分钟的超时)或数据库索引问题。
结束语
如果您对某个特定指标感兴趣，请告诉我们。只要可以，我们总是愿意分享更多的数据。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
10 个 API 产品经理面试问题
API 产品管理是一个新的角色，初创企业和企业都在寻找这个角色来构建和管理一个新的 API *台。你如何识别和雇佣摇滚明星？鉴于 API 是非常以开发人员为中心的，你不应该仅仅着眼于找到最好的项目经理，而是要找到那些对 API 充满热情并帮助开发人员的人。排名不分先后，以下是 API PM 面试问题列表:
1.你最喜欢的开发人员是谁？为什么是你的最爱？
一个好的产品经理有一双敏锐的眼睛，能够发现添加到流行的 API 产品和 devtools 中的小设计决策，以及添加它们的原因。对于任何 API 产品来说，Onboarding 都是最重要的流程之一，因为很多时候，在集成 API 之前，用户不会收到任何价值。向候选人强调为什么特定产品的入职流程会成功，以及你会对其做出哪些改进。
2.如果你需要选择一个单一的北极星度量标准，它会是什么 API 产品？
一个经验丰富的 API 产品经理可能已经看到了在漏斗指标(如页面浏览量和注册量)之上调整产品组织而不考虑产品参与和保留的后果。一个 API 产品的大北极星指标可以是每周活跃令牌或首次 hello world 的时间。
3.你如何优先考虑你的特色路线图？
一个糟糕的答案是简单地跟随销售组织所说的重要的东西。由于不一致，相对于产品愿景而言，销售目标可能过于短期。寻找一个采取研究导向方法的候选人，利用多种输入，如市场趋势、来自潜在客户和现有客户的定性和定量反馈、当前的销售重点和缺陷挤压。
4.你如何处理 API 特性的弃用？
与消费者应用程序不同，API 产品在中断任何功能时都需要仔细规划。几乎总是，最好的答案是不要引入任何突破性的变化，永远不要删除一个字段。例如，您的 API 响应有一个名为name的 JSON 字段，您想将它分成first_name、last_name和username。然后，正确的方法应该是添加新字段，同时保持旧字段继续前进。
在极少数情况下，如修复安全漏洞或淘汰整个产品，需要进行重大更改。你应该跟进求职者如何处理这种情况。这可能包括向访问 API 的开发人员发送个性化电子邮件，详细说明他们正在使用的版本以及他们上次访问过时 API 的时间。其他策略包括限制用电，在非工作时间，如周日下午 1 点，短时间关闭功能。
5.为什么 API 版本控制很重要？你如何给一个 API 版本化？
如果没有版本控制，任何变更都可能被认为是破坏性的变更，并且打破了在公共契约上工作的想法。寻找对如何版本化以及基于 URL 的版本化与利用 HTTP 头之间的差异有强烈意见的 pm。他们也应该接受其他想法，因为版本控制是非常固执己见的。项目经理应该熟悉 semvar 的好处，以及沟通非破坏性变更和 API 全面检修的方法。
6.请告诉我您处理重大故障的时间。
这总是一个好问题，因为总理可能处于重大问题的前线，必须理性行事，保持沟通渠道畅通。项目经理是如何让客户知道这一事件的？他们是否只让企业客户知道，而不关心那些免费试用的客户？他们只是发送了一封普通的电子邮件，还是利用数据来锁定那些受 API 错误或中断影响的客户，以及每个客户是如何受到影响的。
7.你如何划分开发者社区？
有很多方法可以细分开发者社区，用于营销、群组分析和其他分析。除了公司规模等典型的公司人口统计数据之外，要寻找的一个关键因素是以开发者为中心的属性。一个 API 产品经理不仅要熟悉常见的编程语言，还要知道它们在商业中是如何使用的。比如 Java 和。NET 在更传统的企业中更受欢迎，而 Node.js 在 React 和单页应用社区中更受欢迎。
8.创建开发人员文档的一些最佳实践是什么
过时和混乱的文档是任何产品经理或开发人员社区的开发人员关系经理生存的祸根。在这里，您正在寻找在保持以客户为中心的同时自动生成一些文档的方法。他们熟悉 OpenAPI spec 和 Postman Collections 之类的工具吗？他们喜欢用 Markdown 这样的开放工具编写文档，还是用 Zendesk 这样的特定帮助台软件编写文档？他们如何处理 GitHub README.md、API reference 和位于公司域上的开发者文档中可能存在的重复信息？是否有不同类型的文档记录了目标人物角色？
9.你如何知道客户是否从你的 API 中获得了价值？
这是一个更普遍的问题，你会跟踪哪个 KPI？提问。一个好的项目经理会讨论利用分析来衡量 API 使用情况的重要性，以及哪些端点正在推动收入。不产生收入或维护成本过高的端点应该被废弃或调整，以更好地解决真实的业务用例。项目经理是否已经有了他们希望在开始工作后跟踪的关键指标的意愿列表？推广 API 提高使用率的方法有哪些？
10.你如何为一个典型的[电子商务、支付等] API 建模？
数据建模是产品经理的核心专长之一。在创建新的端点以及如何连接或查询数据时，他或她应该将客户放在心上。做到这一点的最佳方法之一是通过一个示例设计练习，如设计一个电子商务 API，其中:
- 可以创建/列出项目
- 可以编辑物品的价格
- 可以对项目出价或下订单。
- 可以执行地理本地搜索来查找终端用户附*的项目
这里的目标是看看候选人将如何对数据建模，将创建什么端点，API 用什么来响应。根据角色的不同，您还可以进一步了解这将如何在 SQL 或 noSQL 数据库中建模。
10 个开发者关系面试问题
越来越多的公司正在从传统的企业销售心态转变为开发者至上的心态，以推动产品的采用。销售电话和演示不起作用，因为开发人员不想被推销。相反，该*台需要被采用，就像消费者采用手机游戏或电子商务应用程序一样。然而，开发者也不太接受脸书的广告，这些广告可能对那些游戏和电子商务应用有用。
启动新的开发人员关系计划有助于推动开发人员的采用并建立更好的关系。然而，由于开发人员关系是一个较新的角色，所需的技能和职责比销售和工程等已确立的角色更加模糊。这篇文章概述了招聘开发人员关系经理时需要注意的事项。关于开发者关系的概述，首先阅读什么是开发者关系？。
目标
因为开发者关系对于任何与开发者社区互动的人来说都是一个包罗万象的角色，所以你应该在面试任何候选人之前列出你的主要目标。一些开发人员关系角色专注于社区参与和开发人员宣传。他们的主要目标是提高知名度，这需要他们在会议上发言，授权有影响力的人，并参与他们的社交社区，如 Twitter 或 Reddit。其他 devrel 角色专注于产品管理和开发者体验。他们的主要目标是*台的采用和使用，这需要他们迭代 onboarding、文档，并且可能拥有公共 API/SDK。
不管是什么角色，开发人员关系经理都需要清晰地交流，并清晰地阐述深入的技术主题，以便开发人员容易理解。很多时候，devrel 是你公司的形象代言人，无论是个人还是网络。
这些问题
1.说说你见过的最好的开发者体验，为什么是最好的？
最好的开发者关系经理也曾多次建立在其他*台和 API 之上。他们已经看到了什么是伟大的开发者体验，什么会出错。开发者关系团队对他们最喜欢的工具和产品有强烈的看法并不罕见。
2.衡量开发者体验的好的北极星指标是什么？
一个有经验的开发者关系经理可能已经看到了在不考虑产品参与度和保留度的情况下，将指标与漏斗指标(如页面浏览量和注册量)的顶部对齐的后果。devrel 的大北极星指标包括周活跃代币或首次 hello world 时间。
3.你最喜欢的开发人员是谁？为什么是你的最爱？
一个好的开发者关系经理有一双敏锐的眼睛，能够发现添加到流行的 API 产品和 devtools 中的小设计决策，以及添加它们的原因。对于任何 API 产品来说，Onboarding 都是最重要的流程之一，因为很多时候，在集成 API 之前，用户不会收到任何价值。向候选人强调为什么特定产品的入职流程会成功，以及你会对其做出哪些改进。
4.创建开发人员文档的一些最佳实践是什么
很多时候(但不总是)，开发人员关系团队负责保持文档更新。对于那些必须创建和维护文档的人来说，过时和混乱的文档是生存的祸根。在这里，您正在寻找在保持以客户为中心的同时自动生成文档的方法。他们熟悉 OpenAPI spec 和 Postman Collections 之类的工具吗？他们喜欢用 Markdown 这样的开放工具编写文档，还是用 Zendesk 这样的特定帮助台软件编写文档？他们如何处理 GitHub README.md、API reference 和位于公司域上的开发者文档中可能存在的重复信息？是否有不同类型的文档有目标人物角色？
5.你在集会或会议上发言过吗？哪一个？你是怎么选择这个话题的？
参加会议和在会议上发言都是任何开发者关系战略的关键支柱。你要找的人不仅是一个优秀的沟通者，而且对帮助开发人员充满热情。主题应该是演讲者感兴趣的，适合听众的，与公司相关的。
6.开发者*台有什么有趣的新兴趋势？
优秀的开发人员关系经理会及时了解与他们社区相关的新兴趋势和新闻。开发人员关系经理应该熟悉 GraphQL 等新技术，以及开发人员正在构建的 AWS Lambda 等最新*台。通过这样做，他们可以向他们的开发者社区提供教育和建议。
7.为什么 API 和 SDK 版本控制很重要？你如何给一个 API 版本化？
如果没有版本控制，任何变更都可能被认为是破坏性的变更，并且打破了在公共契约上工作的想法。寻找对开发人员关心的问题感同身受的候选人，即使这意味着支持为过时版本的 Java 工作的遗留 SDK。不是每个开发者都可以投资升级到最新的 SDK 和框架。他们还应该熟悉 semvar 的好处，以及沟通非破坏性变更和 API 全面修改的方式。
8.你如何处理 API 特性的弃用？
与消费者应用程序不同，API 产品在中断任何功能时都需要仔细规划。几乎总是，最好的答案是不要引入任何突破性的变化，永远不要删除一个字段。例如，您的 API 响应有一个名为name的 JSON 字段，您想将它分成first_name、last_name和username。然后，正确的方法应该是添加新字段，同时保持旧字段继续前进。
在极少数情况下，如修复安全漏洞或淘汰整个产品，需要进行重大更改。你应该跟进求职者如何处理这种情况。这可能包括向访问 API 的开发人员发送个性化电子邮件，详细说明他们正在使用的版本以及他们上次访问过时 API 的时间。其他策略包括限电，即在非工作时间(如周日下午 1:00)短时间关闭功能。
9.你如何划分开发者社区？
有很多方法可以细分开发者社区，用于营销、群组分析和其他分析。除了公司规模等典型的公司人口统计数据之外，要寻找的一个关键因素是以开发者为中心的属性。一个 API 开发者关系经理不仅要熟悉常见的编程语言，还要知道它们在商业中是如何使用的。比如 Java 和。NET 在更传统的企业中更受欢迎，而 Node.js 在 React 和单页应用社区中更受欢迎。
10.你将如何为公司创造一个真实的声音？
DevRel 实际上是社区和你的工程和产品团队之间的纽带，当各方之间有真正的联系时，它工作得最好。开发者经常被营销和销售推广弄得疲惫不堪，所以创造一个真实的声音是至关重要的。寻找建立真正关系的想法，例如通过超级相关的内容来增加价值。或者，随着更多的 DevRel 移动到网上，只与一两个人一起创建微型活动，这样更容易与网络研讨会、播客或诸如此类的人建立融洽的关系。
开发 API 的最佳免费 REST API 调试工具
当我们开发 Moesif API 分析*台时，我们需要创建和使用许多 API。其中一些是支持我们各种服务的内部 API，而另一些是外部 API，如我们的支付提供商或认证服务。来自内部和第三方的信息。当然，我们在自己的 API 上使用自己的 API 分析来“吃你自己的狗粮”，但我们也使用许多其他工具，其中许多是免费的。我们认为我们应该分享一些我们真正喜欢并在开发和使用 API 时经常使用的最佳方法。虽然这篇文章关注的是开发，但请期待后续的文章，讨论在生产中交付可靠 API 的最佳工具。
这篇文章按照用例组织了各种工具。
发送 API 请求
大多数 web 开发人员都需要在某个时候发送 API 请求。无论你是一个移动应用开发者，测试后端请求还是开发和运行你自己的服务。当然，您可以通过将 URL 直接放在浏览器中来发出 GET 请求，但是浏览器可能会通过本地缓存进行阻止，所以您真的不知道是什么在攻击您的服务器。此外，浏览器有严格的安全策略，防止改变诸如原始标题或 URL 大小限制之类的东西。
邮递员
最受欢迎的 HTTP 客户端之一是 Postman 。它有一个非常漂亮的 GUI 界面，非常容易使用，不管你是刚开始使用 RESTful APIs 还是一个专家。存储了过去通话的历史记录，以便您可以快速重新发出它。Postman 甚至包括一些不错的功能，比如自动完成标准的 HTTP 头，支持和呈现各种有效载荷，从 JSON 到 HTML，甚至是 multipart。
卷曲
如果你喜欢基于命令行的工具， cURL 非常快。cURL 包含在大多数*nix 发行版中，这使得它成为任何人登录远程主机的便利工具，而不必担心安装定制工具。鉴于 cURL 的广泛安装基础，您可以依赖 cURL 构建测试和部署脚本，而不必担心被局限于单一供应商。
在浏览器中捕获 AJAX 调用
鉴于 web 应用程序中的 API 是前端和后端之间的接口和契约，当出现问题时，知道哪一方违反了该契约是有用的。如果您的 web 应用程序不能正确地从后端加载数据，您可能要做的第一件事就是检查 API 请求和响应是否有任何异常。
Chrome 开发者工具
大多数桌面浏览器都包含某种类型的开发者工具，比如 Safari 的网络开发工具、 Chrome 的 DevTools 和 Firefox 的开发者工具。这些工具默认包含在浏览器中，使您能够快速检查 API 调用。
从非浏览器应用程序捕获 HTTP 请求
从非 web 应用程序中捕获 API 请求可能具有挑战性，因为您没有丰富的浏览器开发工具来检查 API 调用(不包括额外的编排)。许多解决方案需要使用反向或正向代理来拦截和记录 HTTP 流量。
Moesif API 分析
Moesif 是我们自己的 API 日志分析和分析服务，也有免费计划。Moesif 使您能够实时跟踪来自您自己或第三方 API 的实时 API 流量，并让您深入了解 API 上发生的事情。Moesif 与 Postman 等其他工具连接，以重放任何 API 调用。除了 API 日志分析和调试之外，Moesif 还提供产品洞察，告诉您最佳客户与流失客户使用 API 的不同之处。
查尔斯代理
Charles Proxy 是一个非常受欢迎的免费工具，但它并不托管在云中。你必须安装这个软件，并在你自己的机器上安装和运行它。Charles Proxy 的工作原理是将所有本地机器的流量作为 HTTP 代理路由通过它。您还可以在电脑上打开一个端口，并将您的 iPhone 或 Android 设备配置为通过 Charles 发送流量。只要记得在你的电脑上停止查尔斯时，在你的智能手机的设置中禁用代理。否则，您的手机将无法连接到互联网。因为所有 web 流量都将通过 Charles 路由，所以您可以利用过滤器只记录对特定域或主机的请求。查看配置 Charles 了解更多信息。SSL 证书会导致额外的复杂性，因为代理需要成为中间人并破坏 SSL 隧道。您可以在您的设备上安装 Charles SSL 证书。
SandroProxy
SandroProxy 就像安卓的查尔斯。如果您正在进行调试，并且没有可用的桌面和局域网，这可能会很有用。你也可以把它连接到 Chrome 开发工具上。
游手好闲的人
Fiddler 类似于 Charles，它在本地机器上设置代理。你必须下载并安装软件。
重播捕获的 API 请求。
偿还捕获的请求使您能够重现之前创建的相同流量。这对于在不同的主机上重放(比如在您的本地开发机器上重放生产流量模式)或者验证修复是否已被纠正是很有用的。
邮递员拦截器
邮递员拦截器提供了一种捕获 API 调用并重放它们的方法。但是，Postman 拦截器只能捕获 HTTP 请求数据。它无法捕获 HTTP 响应。主要焦点是重放请求，而不是记录调试。
共享 API 请求数据
如果您正在与一个团队一起工作，您通常希望与团队的其他成员共享捕获的 HTTP 跟踪，或者使他们能够重放一个场景，而不必手动模拟 API 请求。
虽然你可以打开 Chrome Developer 的工具，复制并粘贴其中的数据，与你的团队分享，但这样做很麻烦。
ApiRequest.IO
一个由我们构建的免费工具，我们无耻地推广它。Api 捕获 Chrome 扩展从任意网站捕获所有 AJAX 调用，然后存储在云服务 apirequest.io 中。该服务创建了一个共享工作空间，可以通过一个模糊的 URL 与其他人共享 30 天。有点像分享谷歌文档链接。
什么是 Moesif？ Moesif 是最先进的 API 分析*台，被成千上万的*台用来了解你最忠实的客户在用你的 API 做什么，他们如何访问它们，以及从哪里访问。Moesif 为您喜爱的语言提供了开源中间件和 SDK。
模拟服务器
如果您正在编写针对 API 进行测试的客户端代码，通常需要模拟 API 服务器。然而，有时 API 服务甚至还没有开发出来，或者启动和运行起来很复杂。在这些情况下，您可以使用模拟服务器，它在核心将一些预定义的 JSON 转发回请求者。
JSON 服务器
JSON 服务器是一个开源的 moch 服务器，你可以在你的机器上克隆和运行它。
JSON 占位符
如果您不想在本地运行自己的模拟服务器，可以使用托管服务，比如 JSON 占位符。
模仿不同的 HTTP 响应
JSON 服务器和 JSON 占位符 API 调用总是用 200 OK 响应。如果您想测试您的客户机如何处理不同的 HTTP 错误响应，您可以设置一个更复杂的模拟服务器来提供这种灵活性。
httpbin
Runscope 的 httpbin 在他们的网站上提供托管服务，或者你可以克隆他们的 T2 开源回购协议并运行你自己的服务。httpbin 为从 gzip 编码的响应到像照片这样的二进制数据提供了模拟端点。
Mocky.io
和 httpbin 一样， mocky.io 是开源，也有托管版本。Mocky 比以前的工具更加灵活，因为它允许任意的响应体和状态代码。如果您需要将某些特定的 JSON 返回给您的客户机，这一点很重要。它还支持各种各样的内容类型，如文本/xml、多部分和 HTML。此外，您可以设置预定义的延迟，如?mocky-delay=100ms。这是伟大的测试超时条件或当添加加载指标到一个网站。
开挖隧道
如果您正在开发一个 webhook 来处理来自第三方 API 或服务的回调，那么如果您想要本地调试，您将需要启用这些云服务来调用您在本地机器上运行的 API，除非您想要通过打开您机器上的端口并获得静态 IP 来解决费用和潜在的安全问题。这些隧道服务将请求转发到您的本地主机，而不需要您打开端口。
ngrok
ngrok 是最受欢迎的一款。主机名是临时的，随机生成的，但是如果你想要一个永久的主机名，他们会提供付费服务。对于大多数用例，免费版本已经足够了。要使用 ngrok，您需要做的就是用 ngrok 提供的 URL 替换 webhook URL，然后运行本地代理。
JSON 工具
代码美化
代码美化了的 JSON 查看器，可以漂亮地打印，将 JSON 转换成 XML 和 CSV，等等。
JSON Lint
JSON Lint 是一个 JSON 验证器和重新格式化器。
JSON 生成器
JSON 生成器创建随机生成的 JSON，该 JSON 是有效的或者基于您可以上传的模式。这有助于生成大量的测试数据。
JWT.io
如果您正在使用一个使用 JSON Web 令牌进行身份验证的 API，您将需要快速解码 base64 并查看令牌内容。JWT.io 是 Auth0 提供的一个免费服务，它就是这样做的。
要了解更多关于 JWT 如何工作以及 JWT 如何与不透明令牌相比较的信息，请查看我们关于 RESTful APIs 认证和授权的指南。
性能试验
有相当少的付费性能测试服务，这是有意义的，因为设置性能测试需要做更多的工作。因此，免费服务往往涉及更多的工作，尤其是对于托管服务，它可能是资源密集型的。
阿帕奇 Jmeter
Apache Jmeter 是一个开源工具，用于对你的 API 进行负载测试。
Loader.io
Loader.io 是一个对 API 进行负载测试的工具，可以快速产生大量流量。
克-奥二氏分级量表
许多 API，尤其是支持单页面应用的私有 API，利用跨源资源共享来安全地对不同的域进行 AJAX 调用。
莫夫·CORS
CORS 的 Chrome 扩展。我们自己的扩展由 Moesif 创建，每周有超过 17，000 名用户使用。它可用于规避或更改本地测试和调试的 CORS 限制。
我们读者的其他建议
我们欢迎读者的建议，包括您使用的工具或您构建的工具。如果我们错过了你最喜欢的工具，它可以帮助你更好地使用 API，那么请在下面留下你的建议或者给我们发消息。
以下是 ExtendsClass 团队的建议:
摘要
一旦 API 投入生产使用，寻找有用工具的后续文章。Moesif 有一个 API 分析*台，一旦你的 API 上线，这个*台就非常有用。请随意试一试。
构建企业 API 分析*台的成本
原文：https://www.moesif.com/blog/financial/procurement/The-Cost-of-Building-an-API-Analytics-Platform/
相对于从第三方供应商购买，决定是否雇佣和构建 API 分析*台可能是一项艰巨的任务。你不仅需要调查投资回报率，你还必须驾驭政治，可能会遇到不是这里发明的综合症，以及其他问题。从长远来看，通过购买像 Moesif 这样的现成解决方案，您的产品和工程团队将能够专注于他们最擅长的事情:构建客户喜爱的产品。
构建 API 分析*台的初始成本
构建 API 分析系统的成本取决于数据量和功能复杂性，但可以分为三个方面:
- 数据处理基础设施
- 可视化、报告和集成
- 安全性和合规性特性
数据处理基础设施
设计和构建一个能够进行数千万或数亿次 API 调用的系统并不容易。它需要投资于高可用性数据收集、数据管道和聚合以及安全存储数据的良好架构。需要注意性能，以确保您的分析系统不会降低 API 的速度或导致停机，从而导致收入损失。
从我们所见，API 分析系统最常见的需求是每月处理 2500 万个 API 调用，每月 1 亿个 API 调用，每月超过 10 亿个 API 调用。随着分析系统扩展到更高的容量，它的成本很容易超过 100 万美元。
| 月成交量 | 需要团队 | 构建时间 | 基础设施的建造成本 |
|---|---|---|---|
| 2500 万次 API 调用 | 6 个人 | 13 周 | $154,296 |
| 1 亿次 API 调用 | 13 个人 | 26 周 | $668,616 |
| 10 亿次 API 调用 | 19 人 | 33 周 | $1,240,302 |
每个团队成员的成本基于一名数据工程师的全国*均工资，2020 年 2 月在 Glassdoor 上为 102，864 美元/年。
可视化、报告和集成
除了数据量，初始成本还取决于谁在利用报告，以及数据是否真正可操作。是否只有少数工程师会使用分析系统，并乐于通过原始 SQL 进行查询，或者您是否期待其他用户？许多寻求实现 API 分析系统的工程领导者希望整个公司的决策者能够访问数据，包括产品、营销、支持和客户成功。除非分析系统具备即使非技术用户也能实现自助访问所需的基础架构，否则数据团队仍将成为瓶颈，减缓决策和实验速度，从而导致市场份额流失。这可以包括可视化工具，使团队能够创建和试验他们自己的仪表板和指标，还可以包括与 Salesforce、HubSpot 和 Segment 等工具的连接器，以使数据具有可操作性。
在选择基于数据仓库中已处理数据的商业智能工具时，有多种选择。
| 用户数量 | 可视化人工周 | 需要连接器 | 连接器人工周 | 构建可视化和集成的成本 |
|---|---|---|---|---|
| 10 名团队成员 | 5 周 | Two | 6 周 | $21,758 |
| 50 名团队成员 | 5 周 | seven | 14 周 | $51,431 |
| 150 名团队成员 | 5 周 | Twenty-one | 42 周 | $134,513 |
像 Tableau 或 Looker 这样的 BI 可视化工具估计需要 5 个人周来实施您的数据基础架构并设置报告。Salesforce 或 Hubspot 等工具的每个额外连接器估计需要 3 个人周。我们通常看到每个 7 人的团队都需要一个新的连接器作为他们选择的工具。
如果分析系统需要实时警报和异常检测，这些也应该是考虑因素。如果产品所有者需要 24 小时才能意识到客户流有问题，那么收入可能会损失。
安全性和合规性
如果您的企业有安全性和法规遵从性要求，也应该考虑这些成本。这可能包括法律要求，如安全审计日志和数据违规检测，以及符合监管要求的机制，如通用数据保护法规(GDPR)和加州消费者隐私法案(CCPA)，以及擦除个人身份信息(如信用卡号)的方法。这意味着您可能需要让法律和安全团队来审查您的分析系统，以确保您不会给业务带来太多风险。
您的公司可能还对内部系统有其他要求，如企业单点登录和密码泄露检测，以帮助帐户管理。由于您的分析系统包含大量客户数据，因此良好的做法包括利用基于角色的访问控制和自定义权限来防止数据泄露，以及利用适当的系统来监控是否发生违规。许多可视化工具都有 RBAC，但是任何直接访问数据基础设施的人都可以很容易地绕过它。
以下是安全相关功能的典型成本:
| 特征 | 人-周 | 安全性和合规性的构建成本 |
|---|---|---|
| 安全审计日志 | 3 周 | $5,934 |
| 数据清理/GDPR 和 CCPA 支持 | 4 周 | $7,912 |
| 数据泄露检测 | 4 周 | $7,912 |
维护 API 分析解决方案的持续成本
一旦系统投入使用，系统处理万亿字节数据的持续成本仍然很高，通常来自三个方面:
- 计算和存储成本
- 可视化工具的许可费用
- 持续维护和修复
与流行的假设相反，由于工程师转移到需要加速时间的其他项目，维护成本会随着时间的推移而显著增加。许多公司实施 API 分析系统来推动 API 业务的采用和增长，但这种增长可能会直接导致额外的计算成本。如果技术债务增加，系统将很快需要后续投资，通过增加计算资源和在数据处理中利用更新的方法来处理额外的负载。
计算成本
根据我们自己的测量，1 亿次 API 调用*均需要 1tb 的存储空间。如果需要一年的数据历史，每月 1 亿次 API 调用将需要每年 12tb。
截至 2020 年 2 月，对于 2TB 硬盘、4 核虚拟机，AWS 红移按需定价为每小时 0.85 美元，对于 16TB 硬盘、36 核虚拟机，为每小时 6.80 美元。
以下成本假设数据保留一年，然后被删除。
| 月成交量 | 需要存储 | 计算和存储的年度成本 |
|---|---|---|
| 2500 万次 API 调用 | 4tb | $14,902 |
| 1 亿次 API 调用 | 12tb | $44,706 |
| 10 亿次 API 调用 | 120 太字节 | $418,308 |
可视化成本
可视化和报告的大部分成本是商业智能工具(如 Tableau 或 Looker)的许可费。
截至 2020 年 2 月，每个 Tableau Creator 席位每月费用为 70 美元，按年计费。
| 用户数量 | 可视化工具年费 |
|---|---|
| 10 名团队成员 | $8,400 |
| 50 名团队成员 | $42,000 |
| 150 名团队成员 | $126,000 |
维修费用
对于分析服务等复杂系统，持续的年度维护通常占初始构建时间的 25%，但也可能更高。这种维护包括错误修复(包括关键的安全修复)、来自各种业务单位的功能请求、升级过时的软件、随着 API 流量增加的性能优化以及修复数据质量问题。
支持不包括在内，但这一点应该考虑在内，尤其是如果业务用户将在公司范围内使用分析系统。
| 月成交量 | 需要团队 | 人日 | 年度维护成本 |
|---|---|---|---|
| 2500 万次 API 调用 | 6 个人 | 16 天 | $37,980 |
| 1 亿次 API 调用 | 13 个人 | 32 天 | $164,582 |
| 10 亿次 API 调用 | 19 人 | 41 天 | $308,196 |
总成本
第一年的总成本包括构建数据基础架构的成本、构建与现有工具连接的必要集成的成本、计算和存储成本，以及可视化工具的任何年度许可费用。
第一年成本
| 月成交量 | 用户数量 | 基础设施的建造成本 | 构建可视化和集成的成本 | 计算和存储成本 | 可视化工具费用 | 第一年总成本 |
|---|---|---|---|---|---|---|
| 2500 万次 API 调用 | 10 名团队成员 | $154,296 | $21,758 | $14,902 | $8,400 | $199,356 | ||
| 1 亿次 API 调用 | 50 名团队成员 | $668,616 | $51,431 | $44,706 | $42,000 | $806,753 | ||
| 10 亿次 API 调用 | 150 名团队成员 | $1,240,302 | $134,513 | $418,308 | $126,000 | $1,919,123 |
持续年度成本
持续的年度成本包括维护内部系统的维护成本，包括错误修复和安全修复，以及计算、存储和可视化工具的年费。
| 月成交量 | 用户数量 | 年度维护成本 | 计算和存储成本 | 可视化工具费用 | 持续年度总成本 |
|---|---|---|---|---|---|
| 2500 万次 API 调用 | 10 名团队成员 | $37,980 | $14,902 | $8,400 | $61,282 | ||
| 1 亿次 API 调用 | 50 名团队成员 | $164,582 | $44,706 | $42,000 | $251,288 | ||
| 10 亿次 API 调用 | 150 名团队成员 | $308,196 | $418,308 | $126,000 | $852,504 |
为什么购买 Moesif？
购买 Moesif 而不是自行构建的公司可以在初始设置和持续年度成本方面实现 5 到 10 倍的成本节约。作为一流的 API 分析服务，Moesif 不断增加高级功能，如转换漏斗和保留分析，并利用机器学习来帮助团队快速做出正确的决策，而不会陷入指标和报告中。
通过收购 Moesif，工程团队有了额外的带宽来专注于他们最擅长的事情:构建客户喜爱的伟大产品，而不是埋头支持传统的本土分析系统。
Moesif 的客户也获得了我们在开发 API *台方面的专业知识。企业客户可以联系我们的 API 专家，帮助您的内部团队定义他们的成功标准，同时在他们对如何最好地使用*台有疑问时为他们提供支持。
合成 API 监控和 API 真实用户监控的区别
所有 API 创建者共同关心的一个主要问题是监控。
什么是监控？
监控是了解我们的 API 的健康、性能和使用情况的一种方式。
解决一个请求需要多长时间？
API 在高峰使用时伸缩性好吗？
更新的推出会导致问题吗？
这些只是我们在 API 的生命周期中反复问自己的几个问题。我们可以用良好的监控设置来回答这些问题，但我们在这里可以采取什么方法呢？
在本文中，我们将了解两种主要的监听方式及其区别:合成&真实监听
总的来说，我们可以说这两种方法构成了有效监控解决方案的核心，但是让我们了解一下每种具体的方法。
综合监控
名称综合监控来源于这样一个事实，即这种方法综合使用和生成的请求。这些请求可以由 100%生成的数据或真实客户端在过去发出的记录请求组成。当一个真实的客户端发送请求时，实际的监控不会发生，而是当一个特定的监控客户端发送请求时。这个监控客户端也负责实际的监控。它发送请求并记录它们需要多长时间以及关于它们的其他信息。
合成监控也称为主动监控或主动监控，因为监控客户端 (pro-)主动向 API 发送 pings。
这种方法的一大优点是，它允许在 API 中的问题发生在真正的客户端之前定位问题。例如，开发人员可以创建一个请求，该请求只在将来新的客户端版本发布时发送给 API，然后看看会发生什么。
如果监控客户机每周 7 天、每天 24 小时定期运行，那么它还可以在没有真正的客户机在线时，甚至在 API 发布给真正的客户机之前收集数据。
这种方法的缺点是它不允许看到真实的客户端发生了什么。它只能测试开发人员已经预料到的或者过去记录的东西。因此，监控客户机可以发出完美的 API 健康的信号，但是当真正的客户机请求的行为与监控客户机稍有不同时，它们仍然可能一直失败。
此外，生成所有可能类型的请求可能会很快变得昂贵，因此即使开发人员知道如何做，他们通常也不能创建所有的请求类型，而只能创建一小部分测试。通常，一个测试套件可能只包含场景的整个状态空间的个位数覆盖。尤其是使用 GraphQL 这样的工具，客户可以比以往更加灵活。如果您没有为特定的客户场景创建测试，您可能根本不知道有问题。
真实用户监控
真实用户监控(简称 T1)之所以这么叫，是因为它在监控真实的客户请求，而不是依赖于合成的 pings。它的另一个名字是被动监控，因为没有涉及主动发送请求的主动客户端，而是一些被动记录客户端发送的请求的技术。这可以通过网络窃听等硬件解决方案来实现，也可以通过 Moesif 等工具在应用层实现。
这项技术有助于解决目前影响我们客户的实际客户问题。即使您的合成事件都显示绿灯，并且响应为 200 OK，您仍然可能有一些客户遇到麻烦。例如，如果我们在美国积极监控，但有些客户位于世界的不同地方，他们可能会遇到我们没有预料到的性能下降。真实用户监控对于 API 设计不断变化的现代动态微服务驱动的应用程序非常有帮助。这导致测试覆盖面太小，不能覆盖每个客户场景。
由于真正的用户监控查看的是生产流量，因此它也有助于回放过去的客户端行为，以便进行调试。
合成监听的好处也是真实监听的坏处。
只有当有流量时，才可能检测到真实客户的问题。如果流量微薄或者根本没有流量，我们就拿不到任何有真实监控的数据。
结论
合成监控技术和真实监控技术各有利弊，因此完整的监控解决方案应同时依赖这两种方法。
他们可以互相弥补对方的缺点，并带来更好的整体洞察力。
他们甚至可以互相借鉴。例如，真实监控方法的记录请求可以用作对合成监控客户端的请求。这可以通过 Moesif 的导出到 Postman 功能轻松完成。
摘录:使用 Moesif 准确跟踪所有 API 产品指标
构建有效的客户成功仪表板的秘诀
客户成功的秘诀是让你的客户开心并支持他们成功。一个简单的概念——直到你尝试去实现它。首先，你需要一个伟大的产品和一个伟大的客户服务团队。您还需要深入了解客户体验，包括他们的痛点以及如何帮助解决这些问题。
这是事情变得更棘手的地方，但答案可能已经藏在你的数据里了。您所需要的只是一个有效的客户成功仪表板，它可以自动识别问题，然后帮助您解决问题——如下面的仪表板示例所示。
客户成功 KPI 仪表板示例
“几年前，当我们遇到次优客户端 API 实践的错误时，我们可能会与团队成员共享一个永久链接，以便他们可以查看日志。这工作相当不错，但你仍然在筛选日志。现在有了 Moesif，可以将属于一起的事件分组，并在仪表板中轻松共享。然后可以主动解决问题，带来更好的客户体验。”康拉德·卡普兰，Pronto CX 公司的联合创始人。
Pronto CX 是一家以 API 为先的金融科技公司，专门为各种行业提供忠诚度和支付服务，从交通到现场活动。Pronto CX 公司在经历快速增长的过程中，一直在寻找能够保持出色的 100%客户保持率的工具。该公司开始使用 Moesif 来识别数据有效性问题，然后解决这些问题，使用客户成功 API 仪表板来获得最大结果。
什么是客户成功仪表板？
当谈到理解和实现客户成功时，实施一个有效的客户成功仪表板，支持 swift 关键绩效指标(KPI)分析，应该是您方法的核心。
客户成功仪表板是一个可视化工具，可帮助您跟踪从产品使用方式到保留率、流失率、月收入等一切信息。
为什么客户成功仪表板很重要？
Pronto CX 公司的客户成功 KPI 仪表板证明了这种仪表板对客户满意度的影响。它使 Pronto CX 公司能够实施被动和主动措施来提高其客户成功水*。
留住用户首先要了解他们在使用你的产品时遇到的困难以及原因。Pronto CX 公司之前对 API 问题采取了被动策略，让他们的客户有机会变得不耐烦，并面临取消合同的风险。通过 Moesif，他们能够自动监控和显示 API 的使用情况，获得客户洞察力，并确定 Pronto CX 可以主动干预并帮助其客户取得成功的情况。
你如何衡量客户成功 KPI？
客户成功仪表板可以支持从新客户到忠诚的老客户的旅程。为了监控这一过程，您需要衡量各种客户成功 KPI。其中最重要的包括:
- 客户流失率
- 客户终身价值
- 每月经常性收入
- 客户支持票据
- 净发起人分数
- 客户满意度
您还可以添加任何 KPI 来支持了解您自己的客户的成功并对其进行监控，例如上面的客户成功 API 仪表板示例中的 API 调用。
客户成功概览仪表板模板
您的客户成功概述仪表板模板将围绕您的特定产品进行设计。也就是说，可以概括出这样一个仪表板应该包括的一些广泛的例子。
客户成功仪表板上应该有什么？
首先要理解成功对你的客户意味着什么，你的目标是什么。毕竟，不同企业的客户成功案例大相径庭。
监控什么由你决定。假设您有一位销售代表，他已经实施了行为电子邮件来尝试和加速 API 集成。您可以在仪表板上监控影响。
您的仪表板将是客户健康指标和 KPI 的组合，监控积极和消极的客户成功指标。正面指标示例包括新客户数量和每月经常性收入。同时，流失率是一个负面指标的例子。
如何衡量仪表板的有效性？
您可以通过监控您的总体客户满意度和成功水*来衡量您的客户成功仪表板的有效性。有效性的另一个衡量标准是您的仪表板提供的投资回报。
对于数字移动支付*台 Reloadly 来说，衡量其仪表板有效性的一个标准是该公司在问题出现之前主动识别即将到来的问题的能力。
就投资回报而言，一种方法是通过 Moesif，我们可以获得有关问题的高级知识，从而能够积极主动地采取行动，从而提高客户满意度。“Reloadly 联合创始人兼首席技术官 Emmanuel Piard
仪表板的三大好处是什么？
就客户成功而言，仪表板具有多种优势。三个最有用的是:
- 减少客户流失
- 创造更稳定的收入
- 提高客户满意度
通过支持客户的成功，您也在支持自己的成功。
查看客户成功指标并获得洞察力
在上面讨论 KPI 时，我们提到了客户成功指标。监控比率，如客户流失率提供了客户成功的概况，可以推动对您的客户体验和您自己的业务的独特见解。
确定将提供最有用和最全面监督的客户成功指标的关键是了解您的客户需要什么。然后，您可以通过相关的指标来跟踪您在满足这些需求方面的成功。
你如何追踪客户的成功？
能够查看客户成功指标并获得洞察力是非常有价值的。但是你是怎么做到的呢？
在安利的例子中，跟踪成功意味着监控客户在使用安利 API 订购时出现的错误数量，然后与个别客户合作减少错误数量。
为了跟踪客户的成功，您需要实施一系列能够提供您的进展概况的指标。让我们来看看其中的一些。
什么是重要的 API 客户成功指标？
对您的企业来说，最重要的 API 客户成功指标将是那些深入到您所实现的细节的指标。此类指标的示例包括:
客户保持率
赢得新业务固然很好，但如果你的客户不坚持使用你的产品，你就有问题了。随着时间的推移，跟踪您保留的客户比例不仅是了解客户成功绩效的关键，也是支持企业长期生存的关键。
客户健康评分
您可以使用客户健康评分来确定您的客户中有多少比例是“健康的”，有多少比例是“有风险的”。在单个客户的基础上，这有助于你确定哪些客户可能会增长，哪些客户可能会流失。在组织层面，如果您发现越来越多的客户面临风险，它可以作为一个早期预警系统。
净推介值
作为市场研究以及监控客户成功和业务增长的一个长期确立的工具，你的净推介值与向朋友或同事推荐你的业务(或产品)的人的比例有关。跟踪你的净推广分数可以揭示很多关于如何积极(或相反！)你的客户看待你的生意。
客户终身价值
监控客户终身价值告诉你在客户与你的企业的整个关系期间，客户的价值是多少。计算你的客户终身价值，然后监控它，以确保它增加，是一个有效的方法来跟踪您的客户成功增长。
客户流失率
你的客户流失率越低越好。毕竟，走出去寻找新客户比留住现有客户花费更多。因此，努力降低你的流失率可以带来长期回报。
每月经常性收入
您的每月经常性收入是您每月从客户那里获得的收入。跟踪 it 对于了解您的客户成功绩效和监控您企业的财务可行性至关重要。
客户维系成本
我们上面提到，留住客户比出去找新客户更便宜，但留住客户远非无成本。通过衡量客户成功工作的成本并将其与您的客户数量进行比较，您可以监控留住每个客户的成本。
客户满意度得分
很简单，客户满意度分数衡量的是您的客户对您的业务有多满意。它是客户成功的优秀指标，尤其是与上述指标结合使用时。它们共同提供了对您的客户成功绩效的全面概述。
成功打造 API 产品的客户成功仪表板
API 产品的客户成功仪表板是一个非常重要的工具，用于了解这些产品能够提供的影响以及这种影响对您的业务整体成功的影响。
如果您准备实施客户成功 API 仪表板，为什么不联系 Moesif 团队，了解我们如何帮助您分析、询问和监控您的客户成功数据？
Stripe 开发人员体验和文档拆卸
在本文中，我们将探讨为什么 Stripe 开发者体验受到全球成千上万开发者的热情支持。Stripe 的任务之一是增加互联网的 GDP，在过去的十年中，他们每天通过 API 成功执行 2.5 亿个 API 请求，每年超过 910 亿个请求。Stripe 的成功来自于它对客户的关注，将开发者放在第一位，以及创新的设计实践。在本文中，我们将深入探讨 Stripe 针对开发人员的一些设计选择，并带您了解如何利用他们的经验为您的客户构建理想的开发人员体验。
三列开发人员文档
Stripe 的开发人员文档因其三栏布局而闻名，用于组织导航、内容发现和实时代码片段执行。顶部导航将文档分为 Stripe 的不同产品领域，如支付、业务运营、开发工具等。在左侧导航中，您可以在每个产品下执行的每个操作都有相应的快速入门指南，供开发人员使用。除了快速入门指南，Stripe 还提供了深入的文档和教程，内置在导航中，因此开发人员无需访问外部网站或搜索博客来获得问题的答案。
Stripe 开发者体验中我最喜欢的部分之一是他们的 UI/UX。条纹 UI/UX 允许您突出显示描述窗口中的元素，然后突出显示代码编辑器中与该描述相关的代码区域。对于开发人员来说，这是一个非常强大的特性，它提供了一个简洁的 UI 来帮助开发人员准确理解每个代码示例的功能。此外，当您将鼠标悬停在每个部分上时，会出现一个复制按钮，供您复制和粘贴特定的代码部分。还有一个下载按钮，可以下载 Stripe 提供的完整代码示例。总的来说，UI 是干净的、直观的，并且如你所期望的那样工作。开发人员可能没有意识到文档具有所有这些特性，因为从头到尾的整个体验是如此直观。
响应 Slate 的 API 文档
对于那些希望构建自己的 API 文档(外观和风格与 Stripe 或 PayPal 类似)的初创公司或开发者来说， GitHub 上有一个非常棒的开源框架，叫做 Slate 。Slate 开箱即用，设计简洁直观，对所有屏幕尺寸都反应灵敏。此外，由于它是完全开源的，你可以修改源代码，所有的文档都是用 Markdown 编写的。另外，从开发者体验的角度来看，包括教程和视频演练在内的开发者倡导使用你的 API 可以帮助开发者在第一次使用你的 API 时有一个无缝的体验。
Moesif 的开发者体验
在设计上，Moesif 的整体布局与石板和条纹略有不同。然而，就开发者体验而言，它仍然遵循相同的核心原则。左侧导航包含入门材料和教程。我非常喜欢 Moesif 文档体验的一个特点是，每个主导航项都有子导航项，这些子导航项以*铺的形式列在每个主页上。这有助于开发人员在菜单中有一个清晰的导航体验，并为每个选项的内容提供更多的上下文。此外，许多 Moesif 的 API 文档都嵌入了特定主题的 YouTube 视频，这有助于视觉和听觉学习者/开发者。将 YouTube 视频添加到开发者文档中是从谷歌搜索中获取流量的一个很好的方式，这也是 Stripe 可以做得更好的地方。点击 了解有关将 Moesif 集成到您的分析堆栈 的更多信息。
Moesif 在侧边导航上列出了安装 SDK 的每种方法，并且他们有每种方法的分步说明。此外，开发人员可以通过查看右侧的子导航来确定文档页面上的内容。
为了与 Moesif 的 API 接口，Moesif 正在使用开源框架 Slate 来格式化他们的文档。它是用 Moesif 的调色板定制的，看起来很漂亮，在移动设备上完全响应。
开发者体验综述
如果您是一名希望为 API 创建文档的开发人员，请记住包括以下内容，以便为开发人员提供卓越的开发体验:
- 适用于所有屏幕尺寸的响应式页面布局
- 代码突出显示和语法。当开发人员用鼠标突出显示某个元素时，在代码窗口上突出显示相应的元素。
- 在 API 文档中提供可视化、图表和图片
- 将 YouTube 视频添加到您的文档页面，其中包含一个开发人员倡导者，他可以指导开发人员使用您的 API
- 添加复制和粘贴按钮，使开发人员可以轻松地立即尝试代码
- 三栏导航结构是开发人员的理想格式
要了解关于 Moesif 的更多信息，以及为什么开发人员喜欢他们的分析解决方案，请访问 Moesif 主页了解更多信息。
开发人员需要交钥匙 API 分析的 3 个原因
当您的*台运行在 API 上时，所有这些 API 都需要完美地运行。快速解决 API 中的问题不仅有帮助，而且是强制性的。延迟和错误监控只是开始:健康的服务器与健康的产品不是一回事。通过全面了解您的 API，解决错误案例和 API 滥用是最容易的，这就是 API 分析的用武之地。
如今，使用现成的解决方案来实现身份验证、支付处理和其他关键功能是很常见的。尽管如此，API 分析解决方案通常是内部构建的，耗费了数月的开发人员资源。这是你的团队可以用来进一步开发你的产品本身的时间。
幸运的是，交钥匙解决方案确实存在。请继续阅读，了解像 Moesif 这样的 API 分析*台能够使 API 开发人员的工作更容易、更快、更高效的三个原因。
原因 1:消除 API 错误日志的神秘性
“作为一名科学家，我热衷于数据分析。当您有数千个错误和数百万个 API 调用时，查找、显示和共享像 400/500 错误这样的 API 指标是非常不同的”
搜索 API 事件日志非常耗时，单值指标通常无法解释复杂的错误情况。
API 分析提供了更快的查询和对有缺陷的 API 的更深入的了解，加速了您的调试过程。例如，Moesif 提供了对日志的实时洞察，可以根据任何数量的 API 调用进行扩展。将该层添加到您的 API 堆栈中可以让您…
- 实时跟踪和过滤 HTTP 请求
- 检查请求和响应 HTTP 负载
- 检查 API 日志，并在几秒钟内在 Postman 或 cURL 中重放请求
- 使用各种不同的参数，大规模细分和聚合 API 调用量
了解 API 的行为对于稳定性和良好的用户体验至关重要。增强的 API 调用可见性使得日志搜索变得更加简单。
原因#2:通过错误警报了解情况
“该工具一上线，我们就能够看到正在发生的交易类型，我们就能够发现基础架构中的安全漏洞。我们有来自受制裁国家的交易，这些交易是通过我们没有封锁的某些国家进行的。从第一天开始，这就是该工具的胜利。”
-Marat Asadurian，Trulioo 软件工程高级经理
基础设施监控系统并不是发现 API 使用异常的最佳工具。他们更关注跟踪服务器正常运行时间、延迟和更多一般性错误。静态和动态警报消除了错误检测中的一些猜测。警报可以发送到许多不同的渠道，确保技术团队有充足的时间来解决问题。
静态警报可以在达到静态阈值时通知您。例如，您可以创建一个提醒，让您知道用户何时在您的 web 应用程序上面临授权问题。
Alert if more than 20 HTTP ‘401 - Unauthorized’ status codes are returned in a REST API response within 15 minutes
Moesif 的动态警报提供了一个新错误的更广阔的视角。它们会自动将错误与您的历史数据进行比较，提供发现复杂错误所需的上下文。您可以根据您的产品面临的具体问题定制我们的动态警报过滤器。如果您正在跟踪关键用户，您可以设置这样的动态警报:
Alert if a user’s API usage is abnormally decreasing over the last week
动态警报还为恶意用户或无意的编码错误提供了额外的防线。例如，用户可能有意或无意地向某个端点发送流量。异常大量的流量可能会使服务器过载，导致 DDoS 中断。为了防止这种情况，您可以设置一个针对端点查询数量异常增加的警报。如果某个端点收到异常大量的请求，该过滤器会立即向工程和安全团队发出警报，以便他们了解情况并迅速采取行动。
Alert if an allowed user is creating an abnormally large amount of traffic against an endpoint, within the last 24 hours
当涉及到错误和威胁时，额外的防线只能增强产品的可靠性。警报为您的团队提供了对 API 中的异常做出适当反应所需的时间。
原因 3:简化与非开发人员的协作
“此外，您拥有的许多内置报告正是 API 公司想要的那种产品问题”
-James Messigner，ShipEngine 开发体验总监
虽然产品和开发团队站在同一边，但是不断变化的需求和时间表使它看起来不是这样。完美的 API 分析可以帮助您向非开发人员传达您的想法，并帮助您确定产品路线图或 bug backlog 中的优先级。
大多数现代分析*台都具有强大的数据可视化功能，API 分析也不例外。Moesif 提供安全的定制仪表板和报告，旨在向非技术和技术利益相关者传达关键的 API 见解。
例如，假设你在一个团队中开发一个应用内购买的移动*台。您的产品团队取消了一个存储支付信息以备将来使用的有缺陷的功能。使用像 Moesif 的漏斗报告这样的可视化工具，您可以证明为什么调试优先。漏斗分析是非开发者模拟他们理想客户从发现你的产品到购买的旅程的常用方法。
漏斗报告细分了过去七天内你的应用用户从销售漏斗中掉出的位置。你的产品团队知道你的理想客户在这段时间内至少进行了 100 次应用内购买。因此，我们将漏斗分为三个阶段，从左到右显示:
- 使用你的应用程序创建帐户的客户
- 对支付*台至少执行了一次 API 调用的客户
- 向支付*台提示至少 100 次 API 调用的客户
我们发现，*均而言，首次购买的顾客是在注册后 6 小时 5 分钟购买的。我们也看到只有大约一半的人在注册后进行了第一次购买。使用这种即时生成的可视化，你可以断言，修复有缺陷的功能可以减少注册和首次应用内购买之间的摩擦。
当多个团队联合起来提供一个伟大的产品时，所有团队成员理解彼此的需求是至关重要的。开发人员、设计人员、产品和客户团队之间的良好沟通有助于轻松协作，减少开发人员的干扰。
总之…
API 现在是我们互联世界的支柱，但分析最佳实践并没有跟上步伐。目前，开发人员补贴了不透明的 API 生命周期带来的大部分低效率。解决方案不像在内部编写分析基础架构那么简单。为了充分利用开发人员的时间，交钥匙解决方案是您的最佳选择。借助像 Moesif 这样的 API 分析解决方案，您可以…
- 快速轻松地调试错误，无需繁琐的日志搜索和脆弱的单指标测试
- 与简单的基础设施监控相比，您可以更深入地了解 API 的使用情况
- 自动检测和通知复杂的错误、恶意攻击和延迟问题
- 与非技术合作者就 API 使用和产品健康状况进行清晰、准确的交流
- 赢回宝贵的时间，专注于编码
想确切了解 Moesif 如何节省工程资源？点击此处了解更多信息。！
分层定价策略-定义、示例和优势
正确的分级定价策略可以确保您有效地将 API 和其他数字产品货币化，鼓励您的客户增加支出，同时确保他们对此感到满意。但如果做错了，你可能会激怒你的客户，把他们推向你的竞争对手。在本帖中，我们将解释如何让你的分级定价正确，并最大化你的 API 的收入。
如何实施分层定价策略
分层定价是一种将产品打包成固定成本包的方式，而不是使用基于使用的定价模式。每一层都提供固定范围的功能:用户数量、数据量、支持深度等。客户可以选择最符合其要求和预算的层。然后，一旦客户扩大了他们对您产品的使用，并且超过了他们所选择的层级，他们就会进入下一个层级。这是软件即服务(SaaS)产品(如 API)的常见定价策略。
了解如何实施分层定价策略包括清楚仔细地定义您的层级。这也意味着要考虑如何最好地激励您的客户从一个层级发展到下一个层级。
什么是分层定价策略？
分层定价策略的核心是每层包括什么，以及这些功能的收费是多少。为了制定你的定价策略，分析你的产品并确定哪些功能与你的产品密切相关，哪些是附加的，哪些可以被认为是定制的。将这些功能划分为不同的层，并使用我们的同伴博文中的分析来确定这些层的价格。
作为理智检查，你可以看看你的竞争对手，看看他们提供什么和什么价格。如果你因为定价过高而被挤出市场，你可能需要重新考虑你的策略。
有效的分层定价策略可确保您的客户在每一层都觉得物有所值。考虑从免费层开始鼓励产品的采用，目的是随着用户使用量的增加，将那些采用你产品的用户转移到付费层。
什么是分层定价结构？
分层定价结构与您如何为每一层定价以及其中包含的内容有关。这对于整个分层定价模式的成功至关重要。
您的产品的性质和您的客户使用它的方式将影响您在每一层上提供什么。你的商业模式是 B2C 还是 B2B 也会影响你的定制定价方法，因为这些模式需要不同的策略。
分层定价的一个例子是什么？
您可以通过诸如 Moesif 和 Stripe 之类的解决方案来建立您的分层定价结构，或者您可以实施一个定制的解决方案，尽管后者需要更长的时间并且涉及更大的复杂性)。
让我们以一个 API 为例，您正在向您的客户收取使用费用。您可以对客户发送到终端的每个查询/呼叫收费。然后，您可以根据使用量的增加提供更低的每次通话价格，从而激励客户升级到更贵的层级，以享受折扣率。
分级定价的好处是什么？
实施得好的话，分层定价结构可以让你的客户很容易理解你的产品会让他们付出什么代价。这还会让他们觉得，每次提升一个级别并增加支出，他们都会获得额外的价值。
当你的分级定价正确时，好处是多方面的，如下所示。
定价结构很容易理解
有了分层定价，您的客户就可以很容易地准确了解他们花了多少钱得到了什么。您可以用几个要点和一个比较表来并排显示各个层次，从而定义每个层次中的产品。
这种定价结构使您的客户可以预测成本。通过让他们每月轻松地为你的产品做预算，你就减少了采纳过程中的摩擦。每个人都赢了。
普遍接受的定价
分层定价模式在 SaaS 行业内广为人知。因此，你是在向你的客户展示一些已知和熟悉的东西。同样，这减少了他们决定采用你的产品时的摩擦。
使用普遍接受的定价结构也支持那些想要采用你的产品但需要他们的经理签字同意的人。经理们将清楚地看到产品的成本，并在熟悉的定价模式下舒适地工作。
易于实施
要实现分级定价，您只需要一个订阅计费软件。它非常简单，不会耗费你的时间和资源。你可以使用该软件建立一个价格较低的层级，加上一个或多个价格较高的层级——这是一个既定的策略，意味着你可以利用向下倾斜的需求曲线。
降低计费的复杂性
与动态定价相反，固定定价也意味着您可以降低计费流程的复杂性。您不需要通过分析来实施任何计量或使用情况跟踪。您只需决定每层的价格，并相应地开出账单。
到目前为止，一切顺利。但是分层定价也有不利的一面…
分层定价策略的缺点
揭示分层定价策略的利弊，并考虑其好处，这才是公*的。毕竟，使用层级只是一种定价模式。在您决定实施分层定价之前，请考虑以下因素。
价格上涨会引起摩擦
分级定价的可预测性意味着您的客户将很快习惯您的产品每月的花费。这也意味着，当他们升一级时，他们可能会对价格上涨感到恼火。
价值观念在这里发挥了作用。你的下一层可能包括一大堆令人兴奋的特性。但是，如果您的客户只是因为达到了某个限制(例如特定的用户数量或事件数量)而升级，那么他们可能不需要这些额外的功能。因此，成本的大幅上涨可能会引起不满，因为客户并不认为他们获得了足够的附加值来证明价格上涨是合理的。在决定你的定价策略时，这肯定是要考虑的因素。
太多变量
如果您的每一层都有太多的变量，这可能会促使客户在他们觉得准备好之前就向上移动一层。毕竟，客户不太可能一次超过所有的计划限额。因此，最简单的方法是坚持使用几个批量定价指标。这使客户更容易了解他们何时将达到该层的极限，并降低了突然出现该层跳跃的可能性。
层数太多
如果您有太多的层，这也可能是一个问题。使事情变得混乱，潜在客户很难看出哪一层最适合他们。分析瘫痪开始了，你放慢了速度，甚至失去了一笔潜在的销售。为了避免这种情况，最多提供三层或四层。
缺乏灵活性
分层定价策略不允许个性化定价，在这种情况下，您可以考虑您的客户群能够支付的不同金额。通过使用固定价格层级，您就失去了为适应每个客户而对产品进行不同定价的能力。
收入损失
如果你对你的层级定价错误，你可能会错过收入。您需要以一种不仅能吸引客户，而且能充分覆盖您的成本的方式来为您的层级定价。这意味着要仔细考虑每一层，包括顶层，在顶层，任何一种“无限制”的服务都可能会消耗你的时间和资源。
在花时间分析了分层定价策略的缺点并回顾了其优点后，我们有必要快速浏览一下替代定价模型。层级的主要替代方案是现收现付(PAYG)定价。
API 领先的分层定价的流行替代方案
没有一个全面的现收现付的解释和例子，就不应该决定采用分层定价策略。PAYG 是受 API 领导者欢迎的分级定价的主要替代方案，它意味着客户只为他们使用的东西付费。
现收现付解释和示例
从现收现付(PAYG)手机，到诸如煤气和电费之类的公用事业，基于使用量的计费——另一种说法是随用随付——是一个熟悉的概念。它基于计量，可应用于一系列数字产品以及公用事业等服务。
PAYG 解释说简单来说就是根据你测量的东西来计费。这可能是从交易量到独立用户的任何东西。显然，你需要做一些严肃的数字运算，找出什么最有利于你的产品货币化，就像决定在分层定价模型的每一层提供什么一样。
PAYG 计费的优势
PAYG 帐单提供了一系列的好处。一个是，由于 SaaS 产品中广泛的 PAYG 实现，它已经成为许多决定是否使用你的产品的人熟悉的支付结构。正如我们上面提到的，当涉及到你的支付结构时，提供一种安心和熟悉的感觉从来都不是一件坏事！
也许 PAYG 定价模式的最大好处是，它减少了客户增加支出时的摩擦。客户不会经历成本的突然增加，以及相关的问题，如感觉他们没有准备好或没有获得足够的附加值，他们的成本会随着他们的使用而增加或减少。无论他们在任何一个月的花费是多是少，他们都会明白，根据他们使用你的产品的程度，他们的花费是合理的。
PAYG 开单的消耗指标
如果你走 PAYG 定价路线，那么你需要决定你的消费指标。你在这方面的想法可能会受到你所提供的产品种类的影响。例如，如果它是一个 API，或者是一个基于事件的*台(比如 SMS 和 analytics)，那么您可以考虑一个指标，比如 API 调用的数量或者发送的消息的数量。与此同时，处理支付或费用报告等金融功能的*台，使用一定比例的收入或交易费可能会更好。
PAYG 计费的其他消耗指标包括数据量(发送的千兆字节数、用时数)、用户量(用户/座位数)和资源因素(计算机数量、活动小时数)。
这就是 Moesif 发挥作用的地方。通过与 Recurly、Stripe 或 Chargebee 合作，您可以使用我们的分析*台实施 PAYG 计费和发票，毫不费力地将您的 API 货币化，只需点击几下鼠标即可增加收入。
实施分层定价策略或 PAYG 定价模型的决定不应轻易做出。如果有疑问，为什么不与 Moesif 团队讨论这些选项。
太多日志选项
原文：https://www.moesif.com/blog/technical/logging/Too-Many-Logging-Options/
介绍
前几天，我收到一封电子邮件，询问在记录云应用程序时应该使用哪些选项。我决定，为其他同病相怜的人宣传一下他们的反应可能会有好处。有很多伐木公司，但每一家都专注于一个特定的领域。想想分析领域。有大量不同的营销分析和商业智能公司，但每个公司都专注于特定的领域。你可能不会将 AppsFlyer、MixPanel 和 Google Analytics 相提并论，相反，你应该问你的业务需求是什么，哪家公司符合这个标准。
这篇文章并不意味着深入探究或比较，而是对许多公司和日志/异常跟踪的重点领域的介绍。
移动/Web 应用程序异常跟踪
有几家公司专注于异常跟踪。也就是说，当错误发生时，会为应用程序中已捕获和未捕获的异常生成一个报告。其中许多还有额外的功能，比如将错误分配给开发人员。他们的 SDK 通常捕获比典型日志消息更多的细节，比如安装的 lib 版本、环境变量等。
由于大量的移动和客户端 JS 代码被混淆和/或缩小(即编程或丑化)，如果不访问源映射，堆栈跟踪可能很难理解。它们将模糊的变量和方法名称映射到源代码中的原始名称。寻找自动化这一过程的*台。
Crashlytics 是免费的，但只支持 iOS/Android 上的移动原生应用，不支持 web。他们有一个用于公共 ide 的插件，当一个发布版本使用模糊处理构建时，可以自动上传一个源地图。Crashlytics 报告已捕获和未捕获的异常，以及一些额外的指标，如 DAU 和 MAU，并有一个最好的“仪表板”，可以每天查看应用程序的运行情况。空气制动也可以用来代替像防撞系统这样的东西。 Airbrake 也支持 web 应用，尤其适合 Ruby 环境。
在 web 应用程序方面，你有一些其他的选项，如 Sentry、Airbrake 和 Rollbar 。Sentry 开源了所有东西，但也提供了托管版本。Sentry 适用于 JVM 应用程序，包括 Servlet 和其他 JVM 语言。Sentry 支持常见的日志框架，如 Logback 和 Winston。Sentry 的搜索并不是最好的，网络应用有时会有点慢。他们的定价是基于事件摄取的，不管是否抛出错误。如果您有很多日志消息，这可能会让 Sentry 比其他选项更昂贵。另一方面，空气制动和翻车保护杆只根据你的错误率收费。因此，如果你的应用程序更多地处于维护模式，错误更少，你可能会考虑这些。
最终，它们仍然不是满足您生产调试需求的终极解决方案。这些*台中的日志搜索仍处于初级阶段，因为它们以异常和堆栈跟踪为中心，而不是原始日志记录。你不能有花哨的正则表达式或自定义查询。因此，您可能会发现自己也集成了一个日志解决方案。
记录
日志记录与上面讨论的异常跟踪软件非常不同。大多数日志*台比异常跟踪集成更加通用。它们可以被视为传统的 syslog 服务器，可以从各种开源日志框架(如 Logback 或 Winston)中读取数据。与异常跟踪不同，这些日志记录*台还可以记录非业务应用程序代码，如反向代理服务器日志、数据库日志等。
因为许多人记录所有的事情，所以它们可以用于其他业务需求，比如审计跟踪。
许多人都以某种方式听说过 Splunk。Splunk 是日志记录领域的现任者之一。他们最初从内部解决方案开始，现在有了价格合理的托管 SaaS 产品，但这不是他们的主要关注点。虽然他们为拥有大量数据的大公司提供了一些很好的搜索和聚合功能，但除非你是那些大公司中的一员或者有花不完的钱，否则我们不推荐 Splunk。剩下的竞争者有:Loggly、Sumo Logic、Paper Trail、Logentries 和一些你可以在 Stack Share、Quora 等网站上找到的小公司。
这一领域还有许多其他竞争对手；然而，它们仍然实现了相同的功能:从许多机器中提取日志数据，并整合到一个可搜索的数据存储中，比如 ElasticSearch。Sumo Logic 是功能最丰富但价格更高的产品之一，可以被视为“云中的 Splunk”它们提供了很好的异常检测和来自日志数据的聚合。Loggly 是比较便宜的选项之一，功能比较少。他们在正则表达式解析方面做得很好，每个 JSON 字段都可以是一个过滤器或方面。
自定义 ELK 堆栈
有时人们会问:“我是否应该托管我自己的麋鹿栈。我不想担心供应商锁定？”除非你是有定制需求或者使用率非常高的比较大的公司，否则我绝对不建议你之前建立自己的 ELK 栈。尤其是如果你没有很大的 DevOps 背景。你的路线图上可能有足够多的产品特性、成长秘诀、客户等等。日志记录是您必须投入大量精力才能正确扩展的事情，您可能每秒会投入数千或数百万个事件。您不希望担心优化 JVM 参数和内存消耗以使 LogStash 运行良好，或者确保 ElasticSearch 正确备份和故障安全，以便在一些 elastic search 节点关闭时不会丢失所有数据。较大的公司有完整的团队为日志记录创建数据管道(或者在我们的例子中是一家初创公司；))当你准备好了，你可以随时设置你自己的 ELK 堆栈，但现在更容易支付 100 美元/月左右，然后支付工资，不仅是设置，还有支持。
供应商锁定:
在选择数据库技术时，需要付出很大努力来避免供应商锁定。您的应用程序代码变得依赖于特定的数据库客户机驱动程序、查询模式等。在不同技术之间导出数据本身可能需要一些工作。另一方面，除了审计跟踪要求之外，日志数据并不会真正保留很长时间。日志 SaaS *台通常插入标准框架，如 Logback。因此，更改提供者可能需要几分钟时间，并且只需要包含一个新的库和一些针对密钥/秘密的应用程序配置开关。因此，我认为供应商锁定的风险较小。
谢谢
我们感谢我们的精选测试版客户，他们一直在试用 Moesif，为我们提供了宝贵的反馈，使调试变得更加容易。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
五大 Python REST API 框架
原文：https://www.moesif.com/blog/api-product-management/api-analytics/Top-5-Python-REST-API-Frameworks/
Python 是一种非常流行的编程语言，用于构建 RESTful APIs。选择正确的框架来创建 API 是初始构建阶段的一个关键因素。在本帖中，我们将探索 5 个最流行的 REST API 框架，用于使用 Python 构建 web APIs。这些框架都利用了 Python，但是复杂性和定制程度各不相同。首先，让我们深入了解决定从哪个框架开始构建的一些关键因素。
如何选择一个 API 框架
选择 API 框架的第一个因素通常是决定您希望使用哪种语言。既然你正在阅读这篇文章，你可能已经决定构建一个 Python 项目。接下来，您将不得不整理可供您选择的框架。在这一点上，您将需要从您的 API 中获得什么类型的功能，并确保所选择的框架能够支持这些需求。一些框架会有插件和依赖项，允许与其他*台轻松集成，一些可能更精确地支持您的用例，而另一些可能在您需要的功能方面受到限制，自动取消它们的资格。确保框架支持你的用例及功能是至关重要的。
最后但同样重要的是，你还应该考虑学习曲线和可用的教育材料和文档。作为 python 开发人员，良好文档和示例的可用性是您和您的团队如何快速扩展 API 的重要因素。在决定一个框架之前，浏览文档，并进行快速搜索，以确保您可以找到可以指导您的示例，并告诉您在您选择的框架中构建 API 需要付出多少努力。现在我们有一些因素要考虑，让我们看看一些流行的 Python 框架选项。
金字塔
Pyramid 是一个全栈的 Python web 框架，它让你从构建 Pyramid 开始。随着您的成长，Pyramid 也会与您一起成长，根据需要进行扩展，并添加新的功能来处理 web 应用程序开发的各个方面。金字塔框架是一个通用的、不断发展的 python web 开发框架。它包含了大量来自最流行框架的标准特性，包括 MVC 模式、路由、模板、安全性、会话和数据库。甚至还有一个名为 preserve for production deployment 的 web 服务器。
优点:
- Ajax 请求的使用
- 灵活且易于配置
- 适用于基于 SQL 的项目
缺点:
- 设置添加模板的配置不容易
- 缺少文件
- 没有内置的数据库管理功能
Web2py
Web2py 是一个基于 Python 的框架，可以作为任何数据库驱动的 Web 应用程序的后端。Web2py 有很多有用的特性，包括 HTTP 处理和 URL 管理。此外，它有一个内置的调度程序，用于独立于 web 服务器线程运行的后台任务。最后，web2py 有一个数据库抽象层，Python 对象通过它映射到数据库对象，如表、查询和记录。数据库抽象层与一个或多个驱动程序交互，以支持各种数据库，包括 Sq Lite、Oracle 等。
Web2py 是一个基于 Python 的 Web 框架，用于数据库驱动的 web 应用程序。核心是处理 HTTP 和 URL，但它也有一个调度器来运行后台任务，还有一个数据库抽象层来将 Python 对象映射到数据库对象。它还提供了 MVC 支持、表单验证、安全性和访问控制。
优点:
- 大量文档
- 适应团队的需要
- 适用于大型项目
缺点:
- Python 3 不支持
- 不灵活的插件系统
- 无法加载数据模型
快速 API
FastAPI 是 Sebastián Ramírez 基于 Python 3.6 异步特性创建的新 Python API 框架。它在硅谷迅速流行，并发布了 Starlettle 和 Pydantic，以使其开发快速、简单、可扩展。FastAPI 的客户遍布世界各地，包括优步、网飞和微软。
优点:
- 快速编码
- 高性能
- 轻松创建插件
缺点:
- 社区支持
- 使用 Pydamtic 进行请求验证，这有时很难理解，需要您编写自己的自定义验证程序。
姜戈
Django 是最流行的 Python 框架，它被大量用于 web 开发。开发人员和设计人员喜欢包含电池的方法，在这种方法中，Django REST framework 提供了构建应用程序所需的一切。这意味着 Django 开发人员不必依赖单独的库来实现功能。Django rest 框架包含了许多不同类型应用程序的特性，因此它可以在任何类型的网站上工作。
优点:
- 机器学习能力
- 快速处理
- CDN 连接和内容管理
缺点:
- 整体的
- 不适合较小的项目
- 学习曲线
瓶
Flask 是 Python 项目的一个流行的 web 框架。这些年来，Flask 增加了许多新特性，加上它自己与其他全栈框架如 Django 和 Ruby on Rails 不相上下的特性。它还有一个构建 web 应用程序的极简方法。
优点:
- 证明文件
- 可量测性
- 轻量级选手
缺点:
- 维护和实施成本高
- 复杂的技术体系
- 安全风险
添加 API 分析和货币化
构建 API 只是开始。一旦构建了 API 端点，您将希望确保监视和分析传入的流量。通过这样做，您可以识别潜在的问题和安全缺陷，并确定您的 API 是如何被使用的。这些都是开发和支持 API 的关键方面。
随着 API *台的发展，您可能会专注于 API 产品。这是从简单地构建 API 到将 API 作为商业工具使用的转变。很像一个更正式的产品，API 产品需要被管理，并且可能会被货币化。从你的 API 中获得收入是扩大你的业务底线的好方法。
有了 Moesif，你可以实现以上所有。Moesif 可以通过 SDK 或插件轻松集成，并在几分钟内启动和运行。一旦 Moesif 与您的 API 集成，您将能够探索图表和报告，以查看:
- 实时 API 流量
- 检查使用情况的时间序列报告
- 转换漏斗
- 保留报告
- 还有更多…
Moesif 还通过允许您跟踪使用情况并将其同步到 Stripe、Recurly 或 Chargebee 等计费提供商来实现 API 货币化。几分钟内，集成您的 API 并开始向客户收取使用费。Moesif 允许您精确调整您想要的账单，并且高度可定制以满足您的确切需求。
包扎
在本文中，我们讨论了用 Python 编程开发 RESTful APIs 的 5 个最流行的框架。我们查看了每一项的高级概述，并列出了一些注意事项。我们还讨论了如何决定使用哪个 API 框架的一些关键因素。最后，我们研究了 Moesif 如何通过实现分析和货币化来帮助您将 API 开发提升到一个新的水*。
想从 Moesif 开始吗？只需登录 Moesif，尝试这些伟大的功能。还没有账户？注册免费试用,点击几下鼠标，开始探索您的用户分析。
面向开发者的 8 大区块链 API
开发人员一直在寻找新的方法来使他们的应用程序更加安全和高效。区块链 API 是实现这一点的一种方式。区块链 API 是一种应用程序编程接口，允许开发人员与区块链进行交互。通过使用区块链 API，开发人员可以访问区块链的数据和功能，而无需构建自己的区块链*台。这可以节省时间和资源，并为开发提供更安全的环境。在本帖中，我们将为开发者探索最好的区块链 API。我们将研究每个区块链 API 的特性和优点，以及如何使用它们来创建更安全、更高效的分散式应用程序。
什么是区块链？
区块链是所有加密货币交易的数字账本。随着“完成的”块随着一组新的记录被添加到其中，它不断地增长。每个块都包含前一个块的加密哈希、时间戳和事务数据。比特币节点使用区块链来区分合法的比特币交易和试图重新花费已经在其他地方花费的硬币。
API 允许区块链开发者以多种方式与区块链交互。例如，他们可以为用户创建钱包，发送和接收付款，以及检查余额。该 API 还使开发人员能够监控市场和趋势，并创建可用于跟踪价格或管理投资的应用程序。
最受欢迎的区块链是支持比特币的那个，但还有许多其他类型的区块链正被开发用于各种目的。其中一些包括以太坊，莱特币和 Monero。
使用区块链 API 有什么好处？
区块链 API 为开发者提供了许多好处。它们可以帮助简化开发应用程序的过程，并使其更容易与其他系统集成。此外，区块链 API 可以提供对存储在区块链上的数据的访问，使开发人员更容易创建利用这种加密数据的应用程序。
区块链 API 还可以帮助降低开发应用程序的相关成本。通过使访问存储在区块链上的数据变得更加容易，开发人员可以避免构建自己的基础设施来支持他们的分散式应用程序。这可以节省大量的时间和金钱。
此外，区块链 API 可以为开发者提供一种将应用货币化的方式。通过对访问 API 提供的数据或功能进行收费，开发人员可以从他们的应用程序中获得收入。这有助于抵消开发和维护分散式应用程序的成本。
最后，区块链 API 可以帮助为应用程序创建一个更加开放和可访问的生态系统。通过使开发人员更容易访问其他应用程序提供的数据和功能，区块链 API 可以帮助创建一个应用程序可以相互操作的环境。这可能导致新的和创新的应用程序开发被创建，如果不使用 API，这是不可能的。
区块链开发的最佳区块链 API
有许多不同的区块链 API 可供开发人员使用，每种 API 都有自己的优缺点。在本文中，我们将看看目前可用的一些最好的区块链 API，并对每个 API 进行简要概述。
BlockCypher API
BlockCypher API 是目前最流行的区块链 API 之一。它提供了一个简单的界面，可以很容易地开始区块链开发。允许开发者在各种*台上与比特币、以太币、莱特币和 Dogecoin 进行交互。多功能开发工具使您能够与智能合约交互，获得关于未确认交易的通知或创建多签名交易。其他功能包括:
- 数据地址。交易、冻结、智能合约。
- 互动。创建交易记录。解码交易。与合同互动。部署合同。
- 通知。交易 webhook。阻止 webhook。双花网钩。Websocket。
- 高级功能，Multisig。Segwit 支持。信心因素。
链式 API
链 API 是区块链开发者的另一个受欢迎的选择。它提供了比 BlockCypher 更全面的功能，对于更有经验的开发人员来说，这是一个很好的选择。Chain 还有很好的文档和对多种编程语言的支持。ChainAPI 有一个用户友好的界面，允许 API 提供者很容易地建立第一方的 oracles。API2 员工使用接口来代表 API 提供者进行集成，从而大大提高他们的效率和正确性。Chain API 将使 API 提供者和请求者更容易跨多个链与 Airnode 协议进行交互，包括一个节点仪表板。
CoinBase API
对于区块链开发来说， CoinBase API 可能是一个很好的替代选项。比特币基地专业版提供了一个 API，可以很容易地执行各种任务。这包括获取实时价格、安全存储数字货币、购买或出售加密货币以及处理数字钱包。他们还为您的区块链解决方案提供了一个高级选项和一个更高级的 API。CoinBase API 提供的一些特性:
- 生成比特币现金钱包和地址。
- 安全地存放硬币。
- 获取实时和/或历史价格数据。
- 当付款到达时得到通知。
- 发送/接收或出售/购买比特币现金、比特币、莱特币和以太坊。
加密 API
Crypto APIs 是一家区块链基础设施提供商，致力于使 Web 3 解决方案的开发和管理变得简单高效。他们提供钱包即服务(WaaS)、区块链数据、区块链事件、区块链自动化、区块链工具和市场数据，使开发变得更容易。开发人员使用他们的 SDK 访问来自单一提供商的 100 多个终端，以获得各种解决方案，包括数字银行、交易所、钱包、托管机构、借贷产品等。Chainlink、Ledger、Nexo 和 Paypal 已经尝试了 Crypto APIs 公司的 REST APIs。他们喜欢白手套支持和快速有效的功能。区块链开发者很欣赏它们的可靠性。一些功能包括…
- MPC 的钱包即服务是市场上最好的数字钱包——它结合了目前可用的顶级功能、保护和授权过程。
- 区块链数据-使用 REST APIs 从单点统一访问复杂和动态的数据。
- 借助节点即服务，您将能够通过共享或专用节点基础架构快速部署您的区块链技术。利用 JSON-RPC，它可以插入到现有的基础设施中，并提供一个简单的 Javascript 开发环境。
- 区块链自动化-自动将收到的任何硬币或代币转发到首选的主要存款地址。
区块链 API
区块链 API 是区块链开发值得考虑的额外选项。区块链 API 是为您的项目提供加密货币支付的完美解决方案。他们的服务和能力的高质量使其易于集成。区块链 API 已经成功与超过 25，000 名开发者集成。他们提供了许多不同的 API 来满足不同客户的需求。他们有用于钱包、支付处理、查询数据、探索区块链网络、分析加密数据等等的 API。
它有几个方面使其成为市场上有竞争力的供应商。这包括在区块链以块形式进行的数据存储。这样做的结果是 JSON 数据，它处理事务。区块链的离线优先方法也意味着他们不需要额外的加密货币存储服务。它有一个庞大的开发人员社区和低超时，以及一个可访问的 JSON 数据格式。您还可以通过电子钱包账户访问区块链网络。
Block.io API
Block.io API 提供了一个简单的接口，使得开始区块链开发变得容易。Block.io 还提供了对多种编程语言的支持，对于希望用自己选择的语言编写代码的开发人员来说，这是一个不错的选择。不要忘了彻底测试你的应用程序，并始终保持你的私钥保密。
BitPay API
作为一种国际数字资产，BitPay 的 API 允许你执行各种各样的任务。BitPay 提供了一个基于标准的 REST 接口，使应用程序开发人员能够以强大而安全的方式与他们的 BitPay 帐户进行交互。使用 BitPay API，客户可以管理发票、退款、查看商户记录等等。开发人员可以选择使用他们选择的语言通过 HTTPS 调用 API，或者利用我们的代码库。而且，如果他们的首选语言没有列出，他们仍然可以定制集成。
GetBlock API
GetBlock API 是区块链开发者探索的另一个热门选择。GetBlock 提供了一种简单、容易的方法来使用区块链的力量。发现他们的高速运行节点和对比特币 API 的安全访问，以及币安在区块链的智能链，如比特币，让你高效地运行去中心化的应用程序。GetBlock 提供 API、智能合约和 explorer 数据服务。它还提供了一个可以访问原始数据的区块链开发程序。当您使用我们的服务时，保证您可以快速访问块、交易和合同，这可以通过简单地使用基本 API 数据来实现。GetBlock API 拥有有用的技术指南和文档，并提供定制的 SLA，这些 SLA 是为满足您的业务需求而定制的解决方案。
确定区块链 API 时要考虑的因素
在选择最佳编程语言、架构模式、框架或库时，开发人员和开发团队都有偏好。区块链 API 是相似的。
技术:使用开源代码很重要，因为它可以被其他开发者测试，这有助于避免错误和提高整体安全性。
性能:区块链 API 的性能和容量各不相同，因此选择一个符合您应用需求的 API 非常重要。如果您只需要加密几个文档，每秒几个事务可能就足够了，但每秒几千个事务的应用程序将需要称为微服务的子系统。这将允许在处理用户请求时处理高负载和持续响应。
兼容性:你需要确保你选择的 API 能够支持你需要的硬币。
如何使用区块链 API
如果你是一名区块链开发者，想要开始使用区块链技术，你首先需要的是一个区块链 API。这将允许您与区块链进行交互，并在其上构建您的区块链应用程序。
有许多不同的区块链 API 可用，因此选择一个适合您需求的 API 非常重要。要考虑的一些因素包括您正在使用的编程语言、您需要的特性以及所提供的开发工具的级别。
一旦你选择了一个区块链 API，你需要注册一个账户并获得一个 API 密钥。然后，您可以开始构建您的应用程序开发。
在部署应用程序之前，一定要彻底测试它。此外，请始终监控区块链中可能影响您的应用的变化。像 Moesif 这样的工具可以帮助利用浏览器 SDK 从客户端访问 API 调用数据。从那里，我们可以生成调试和监控报告，以确保您的网站运行顺利。如果出了问题，我们会立即提醒您，这样就没有时间扩展成更大的问题。
与 Moesif 一起支持和监测
Moesif 具有独特的功能，允许您将应用程序中发生的每个事件与用户和/或公司相关联。这让我们对开发人员的体验以及每个人如何使用 API 有了更细致的了解。漏斗和滞留就是一个很好的例子。
漏斗是你的应用程序中流程的逐步分解。例如，您可能正在优化您的注册过程，并寻找加快注册速度的方法。该分析为您提供了洞察，以及用户完成这些步骤需要多长时间，以及完成这些步骤的客户比例。这一点很重要，因为它有助于建立一个基线，您可以在尝试提高转化率和 API 使用率时使用这个基线。
T2】一个保留分析可以帮助确定客户何时退出或对你的产品和 API 变得不活跃。这有助于提高保留率，并让您知道您的开发人员体验何时出现问题。这将使您能够建立基线，将您的开发人员体验的改善或恶化与用户的保留联系起来。
T2】跟踪 API 使用情况的另一种方法是使用警报，让您知道用户遇到了什么困难，或者让您知道流量的异常情况。例如，警报可能用于让客户成功团队了解用户遇到的问题，以便他们能够伸出援手。警报还允许产品团队从短期问题反馈中学习，并在未来做出改进。警报由两种类型组成:静态和动态。
静态警报可以设置为一个特定的阈值，比如在一个小时内有个以上的 401 -未授权错误。动态警报允许您设置一个阈值，例如当用户的 401 错误与他们的*均数量相比激增时，您会注意到。它允许您监视趋势或峰值，而无需为阈值输入具体的数字。
这两种形式的提醒都可以改善你的产品的用户体验，特别是如果它是高质量的并且得到团队成员的支持。有关如何在 Moesif 中创建提醒的更多信息，请查看我们的文档。
Moesif 允许您根据用户经历的事件设置自动电子邮件流。这是通过创建行为电子邮件来完成的。例如，如果一个用户有大量的 401 -未授权响应，那么你可能想给他们发送一封电子邮件，建议他们如何解决这个问题或一个指南。这减轻了支持团队的压力，也使得采取即时和主动的行动成为可能。
通过 Moesif 实现 API 货币化
作为一个 API 提供者，你可能想用你的 API 创造一些收入。当第一次开始货币化过程，你可能会发现挑战是陡峭和复杂的。为了解决这些问题并创造流畅的体验，需要进行大量的定制和测试。幸运的是，Moesif 是一个强大的 API 货币化*台，可以提供帮助。通过该*台提供的无限选项，作为 API 提供商，您可以轻松推动 API 的采用和收入。
有了 Moesif，您可以灵活地做出明智的决策，以增加收入和利润。您还将拥有其他工具来补充您的用户旅程并改进您的 API 产品。
使用 Moesif，使用数据可以同步到提供商。计算出的 API 使用量被发送给计费提供商，并用于为用户生成发票。或者，您可以支持预付费计费，即开发者在需要时购买积分。
T2】关于如何在 Moesif 中赚钱的更多信息，请查看我们的文档。
使用 Moesif 的客户成功
引领客户成功对于 API 优先或以开发人员为中心的企业来说，与传统的企业软件有很大不同，最好的 API 产品是以一种易于使用和放手的方式构建的，这意味着一旦*台实现，客户就不必登录*台。
当客户成功与 API 优先的企业合作时，他们应该准备好两种不同的客户体验。第一个体验是当客户注册并登录到您的门户时。第二，客户在与您的 API *台集成和交互时的体验。两者都被认为是入职体验的一部分，应该记录每一项的指标。更重要的是，API 具有提供长期价值的潜力。注册但从未完全整合或使用该*台的客户可能会很快流失(如果他们已经付费)。
在 Moesif 中，每个 API 调用都可以归属于一个用户和/或公司。Moesif 为这些公司和用户创建了一个档案，允许客户成功团队对客户属性有一个 CRM 风格的视图。
T2】客户成功团队还可以轻松跟踪客户与*台的互动，并关注关键的客户健康指标。这些指标将显示在用户或公司概况控制面板下。能够在显示客户使用情况的可视化仪表板中查看客户指标，包括可能发生的错误和集成问题。
T2】结论
该列表中的区块链 API 提供了广泛的功能，从允许开发人员创建自己的数字货币钱包，到帮助他们与以太坊区块链上的智能合约进行交互。虽然其中一些 API 仍在开发中，因此可能不如其他 API 可靠，但它们都显示了区块链技术未来的巨大前景。同时，我们鼓励您尝试所有这些 API，看看哪一个最适合您的项目。
在为自己创建 API 时，使用像 Moesif 这样的解决方案来监控和改善用户的 API 体验是至关重要的。使用本文中讨论的许多特性，可以很容易地跟踪和增强 API 的采用。我们涵盖的特性包括 API 分析、 API 监控和 API 计量计费。要为自己的 Web3 APIs 尝试这些特性，请登录 Moesif 或立即注册开始。
每个开发者工具都应该使用的 5 大行为邮件
使用行为邮件，让你的打开率翻倍。
吸引客户的最佳方式是分享能引起共鸣的内容。没有什么比根据开发人员自己的行动和行为向他们发送有针对性的电子邮件更能引起共鸣了。
在一篇配套的博客文章中，行为电子邮件加速 API 集成，我们解释了行为驱动的开发人员拓展如何加速 API 产品公司的 API 集成。但是，让开发者和产品经理集成你的 API 优先*台的最佳电子邮件到底是什么呢？
我们检查了数千封发给我们自己客户的电子邮件，发现当我们将电子邮件的重点从人口统计/公司地理问题(公司规模和垂直、角色、位置等)转移到行为问题(开发人员漏斗阶段、端点问题、产品利用率、费率限制等)时，我们实现了打开率翻倍，API 上线率显著增加。通过在正确的时间将正确的内容发送给正确的人，我们能够改善我们的整体开发人员体验。
每个 API *台公司都应该使用的五大行为邮件如下:
1.按目标划分的欢迎电子邮件
在注册您的服务时，询问您的潜在客户他们希望通过您的*台实现什么。例如，在我们的入职工作流程中，我们的第一步是询问他们的目标:
在他们的欢迎邮件中，清楚地表明你倾听了他们的关键问题——解释你的产品如何满足他们的需求。使用合并标签或个性化标记，并将相同密钥问题插入到电子邮件的主题行甚至标题中，如下所示。
2.基于 API 使用的开发人员集成电子邮件
因为 API 优先的公司最终对推动集成最感兴趣，所以衡量开发者在他们的集成漏斗中的位置，并相应地定制你的电子邮件，以更好地指导开发者的旅程。衡量他们所处阶段的最佳方法是查看 API 调用的数量。将电子邮件信息分为三组:整合漏斗的顶部、中部和底部，我们得到:
| API 调用的次数 | 整合阶段 | 电子邮件主题 |
|---|---|---|
| 前 7 天没有 API 调用 | 顶端 | 文档和行动手册的集成帮助 |
| 每天少于 1，000 次 API 调用 | 中间 | 沙盒->包含案例研究的产品 |
| 每天超过 1，000 次 API 调用 | 底部 | 追加销售高级功能 |
要了解更多细节，请参见我们的同伴博客文章中关于基于使用的电子邮件的部分。
3.订阅计划通知
自助式 API *台需要随着用户数量的增加而经济地扩展。在 SaaS，最大的管理难题之一往往是处理订阅问题。通过跟踪 API 调用量，可以自动处理配额和计划调整:
| API 度量 | 电子邮件主题 |
|---|---|
| 接*计划定额 | 计划警告 |
| 超计划定额 | 计划升级 |
| 用户*均水* | 速率极限 |
4.细微的错误警告
服务水*协议(SLA)、维护通知和错误警告通常由法律协议管理。不遵守这些约定可能会导致从不良客户关系到经济处罚的各种后果。通过深入研究 API *台本身，可以根据细微的 API 指标发送电子邮件警告:
| API 度量 | 电子邮件主题 |
|---|---|
| 在过去 Z 小时内，端点 Y 上出现超过 X 个错误 | 检查端点 Y 的错误警告 |
| 使用过时或易受攻击的 SDK | 升级警告 |
| 中断供应 | 全球断电警告 |
| *台漏洞 | 易受*台警告影响的客户子集 |
| 超过 400/500 错误流或 SLA | 检查集成的错误警告 |
5.新功能电子邮件
让客户了解最新和最棒的*台功能通常是保持互动的可靠方法。对于那些处于集成漏斗底部的人(生产中的人)来说尤其如此，因为他们会欣赏任何可能使他们的生活更轻松的新*台功能。事实上，当我们使用下面的通知宣传我们的新行为电子邮件功能时，我们看到电子邮件参与度随着客户使用我们*台的活跃程度而上升。
通过行为电子邮件提高参与度并推动采用
使用本指南作为模板，创建您自己的获胜电子邮件活动。我们发现，通过使用前 5 名行为电子邮件，我们能够将打开率提高一倍，并加速整合…
如何使用 Moesif 和细分市场跟踪销售和营销工具中的 API 使用数据
为什么是 API 使用数据？
您可能已经在使用各种分析和营销自动化工具来为您的客户提供个性化体验。
然而，如果你的公司通过 API 交付大部分价值或者运行一个开发者*台，那么你的客户可能不会每天登录你的在线门户网站。这意味着如果你的用户行为数据只来自你的网站，那么你只知道他们何时执行一些管理任务。不从 API 使用数据中衡量和采取行动意味着你错过了提供更好的产品和更个性化的体验的巨大增长机会。
API 使用数据可以告诉您客户是否是新集成的，用了多长时间，以及他们使用最多的 API 特性。
什么是细分市场？
Segment 是一个很好的*台，可以将网络和移动分析数据发送到您营销堆栈中的许多不同工具。您可能希望了解产品使用量，在 Salesforce 中存储销售资格的参与度指标，发送到 Hubspot 以触发营销自动化行动手册，发送到 Drift 以触发聊天机器人。
Moesif 的段源可以做什么？
Moesif 细分市场来源将从 Moesif 获取 API 使用数据，并通过细分市场将其发送到任意数量的目的地，包括您的 CRM、营销自动化工具和用户分析工具。
在 CRM 中存储帐户级别的使用情况
为了验证和衡量新试验和试点的成功，您应该在您的 CRM(如 Salesforce 或 Hubspot)中跟踪帐户级别 API 的使用情况。Segment 可以轻松地将您的 CRM 连接为目的地，这将使像 Moesif 这样的源自动向您的 CRM 发送使用数据。连接后，您可以创建群组或保存列表，例如:
成功试用转换的领先指标:
- 整合的试验
- 试用谁发送 API 流量的生产级别
良好追加销售机会的领先指标:
- 接*计划使用限额的客户。
- 测试新 API 特性的客户。
潜在客户流失的领先指标:
- 大幅减少 API 使用的客户
触发个性化电子邮件
最优秀的开发者营销人员会建立超个性化的电子邮件和应用内消息，根据与他们的 API 的特定交互来锁定开发者。您也可以通过点击几下来触发某些操作:
- 当开发人员使用不推荐使用的功能和端点时，发送警告电子邮件。
- 在他们成功进行第一次 API 调用后发送电子邮件。
- 当他们还没有融入时，发一封电子邮件询问他们是否需要帮助。
- 当他们没有利用你发布的新功能时，发送一封电子邮件。
添加 Marketo、Hubspot 和 Drift 等营销自动化*台作为细分市场的目的地，以便根据 API 使用情况发送电子邮件。
衡量和改进营销工作
如果你在付费搜索和展示广告上花钱来增加注册你的服务的开发者的数量，你绝对应该衡量这笔花费的有效性。哪些渠道导致完成入职培训并成功整合的用户比例最高。您最*的 Java meetup 是否提高了使用您的 API 的 Java 开发人员的比例？
除了衡量有效性，您还可以根据最*与您的 API 进行了新集成但从未完成购买的开发人员的电子邮件来运行重新定位或重新营销活动。作为合格购买者的开发人员可能会忘记他们正在试验的 API，所以当他们准备好通过重定目标获得解决方案时，你必须在他们的脑海中占据首要位置，这一点很重要。此外，您可能希望避免针对开发人员的付费活动，这些开发人员即使不是付费客户，也大幅扩展了他们的使用，因为他们可能已经是活跃用户了。
除非你在为扩展特性做广告，否则你可能不想继续向已经对你的服务满意的开发者做广告。
如何开始和结束想法
将 Moesif 和 Segment 结合使用可以加速您的开发者营销和宣传工作。使用分析工具可以帮助你和你的团队做出数据驱动的决策，而不仅仅是凭直觉。设置集成非常快，可以在 Segment UI 中完成。查看段的文档进行设置。
使用 Moesif API 分析跟踪 Salesforce API 使用配额
原文：https://www.moesif.com/blog/technical/salesforce/Tracking-SalesForce-API-Usage-Quota/
跟踪您的 Salesforce API 使用情况
了解第三方 API 等数字资源是确保您高效使用这些订阅的关键，并且一个团队不会剥夺其他团队的每日或每月配额。如果没有可见性，您将不知道哪些应用程序消耗了大部分资源，以及如何减少这种使用。像 Salesforce 这样的 SaaS 对访问他们的开放 API 的 API 调用的数量进行了限制。如果您经常达到配额限制，而不是仅仅提升 Salesforce 层，您可能希望找到使用限制不断达到的根本原因。
在本指南中，我们将向您展示如何在几分钟内设置 Moesif API analytics 来跟踪您的 Salesforce API 使用情况。
- 你如何确定一个特定的应用程序或部门在一段时间内调用 API 的次数？
- 出现了多少个
REQUEST_LIMIT_EXCEEDED: TotalRequests Limit exceeded错误？ - 如何确定 API 调用是从哪个地理位置发出的？
- 我如何深入了解某一天某个已连接应用程序的 API 调用？
在本教程中，我们将讨论如何使用 Moesif 跟踪 Salesforce API 的使用情况。
如何创建 Salesforce 帐户/实例
如果您还没有 Salesforce 帐户，您可以在 Salesforce 的注册页面上创建一个新帐户。
登录后，您的组织使用的实例会在浏览器地址栏的 URL 中显示。示例 URL: https://na132.lightning.force.com/lightning/setup/SetupOneHome/home
在本节中，我们将创建一系列 REST 请求。在每个请求中，基本 URI 将与 REST 资源结合使用。这些例子的基本 URI 是https://yourInstance.salesforce.com/services/data。
下面我们将提交一个请求来检索每个可用 Salesforce 版本的信息。
curl https://na132.lightning.force.com/services/data/
此请求的输出，包括响应头-
Content-Length: 88
Content-Type: application/json;
charset=UTF-8 Server:
[
{
"version":"20.0",
"url":"/services/data/v20.0",
"label":"Winter '11"
}
...
]
如何创建云代理
登录你的 Moesif 仪表盘 ，进入右上角菜单 - > 安装 - > Codeless Proxy Integration。您将看到一个框，用于输入您的 API 域或主机。Moesif 的无代码集成将从您的原始 API 基础 URL 创建一个新的可跟踪 URL。
您需要用新的 URL 替换原来的 URL，您的 API 请求将通过云代理网络进行代理，我们将看到所有请求都被 Moesif 捕获。
出于某种原因，如果我们不想让应用程序 Id 出现在 URL 路径中，我们可以为每个 API 请求添加以下 HTTP 头:
在 Moesif 中查看捕获事件
配置完成后，我们可以使用这个可跟踪的 URL 来发出请求。
curl -XGET 'https://https-na132-salesforce-com-3.moesif.net/<ApplicationId>/services/data'
注意:上述请求中的 applicationId 应替换为您的 Moesif ApplicationId。
我们可以通过登录 Moesif 并查看 API 分析 - > Live Event Stream来验证事件是否被捕获。
结论
使用上述方法，我们可以使用 Moesif 跟踪任何 Salesforce API 使用情况，并执行高级分析。
构建集成 Web3 监控的以太坊 DApp 教程
这篇文章介绍了使用 Web3.js 和 Truffle 创建一个简单以太坊 DApp 的步骤，并设置了对发送到区块链的 API 事务的监控。本文还解释了开发 DApps 所涉及的各种技术。
介绍
什么是区块链
分散式应用(或 dapp)是不依赖于运行在 AWS 或 Azure 中的集中式后端的应用，这些后端支持传统的 web 和移动应用(在托管前端代码本身之外)。相反，应用程序直接与区块链交互，这可以被认为是分布式节点群集，类似于应用程序直接与 Cassandra 节点的“无主”群集交互，该群集在不可信对等网络中的每个对等点上都具有完全复制。
这些区块链节点不需要一个会违背真正分散的目的的领导者。与各种共识协议(如 Raft 和 Paxos )中的领导者选举不同，区块链事务通过工作证明或利益证明被发送到“随机”节点并由其处理。这些节点是不受信任的节点，运行在世界各地各种计算设备上的任意大小的网络中。
这种技术可以实现真正的分散分类账和记录系统。
DApps 是通过 API 与这些区块链交互的前端应用。对于以太坊，这个 API 是一个 JSON-RPC 层，叫做以太坊 Web3 API，Moesif 原生支持。
以太坊是什么？
以太坊是区块链技术的实现，可以运行智能合约。以太坊虚拟机是图灵完全的，可以直接在区块链网络上运行任意计算。尽管比特币的命令集有限，但以太坊合约允许应用程序开发者准确指定合约上可以执行的交易。简单的智能合约可以被认为是一个有限状态机(FSM) 带有一组自定义转换。
什么是智能合约？
智能合约可以使区块链用户在一组用户之间交换金钱和财产或执行其他操作，如投票，而无需任何中央授权。
对于以太坊*台，智能合约是用一种叫做 Solidity 的语言定义的。
什么是 JSON-RPC
JSON-RPC 是一个无状态的轻量级远程过程调用(RPC)协议，使用 JSON 作为有效负载。与以资源为中心的 RESTful API 不同，像 JSON-RPC 这样的 RPC APIs 是过程化的，可以比 RESTful API 耦合得更紧密。
前端应用程序使用 JSON-RPC 与以太坊集群通信。Web3 是以太坊兼容的 API 和绑定，它是使用 JSON-RPC 规范构建的。
任何去中心化的应用都必须使用 Web3 SDK，例如 Web3.js 用于基于浏览器的 d app。
这些部分是如何组合在一起的
上面是生态系统的示意图，以及所有技术是如何结合在一起的。
构建 DApp 的教程
现在你已经有了一些以太坊 DApps 的背景知识，让我们浏览一下教程。
我们将使用 Truffle Framework ，它为搭建以太坊的 DApps 提供了一套工具和样板代码。在我们开始之前，让我们先来看看一些注意事项。
-
DApp 有用户界面吗？除非您的 DApp 是一个自动化流程。dapp 通常有一个 UI 组件，如 web 或移动应用程序，因为它通常是人类与智能合约或以太网进行交互的一种方式。如果你的 DApp 需要在浏览器中运行，那么你可以像任何传统的单页面应用一样用 Javascript 构建你的 UI。作为最流行的 SPA 框架之一，我们将选择 React。
Truffle 框架提供了一个样板文件(称为 box)，
truffle-react，它派生自create-react-app样板文件代码生成器。 -
你设计好你的智能合约了吗？智能合约为你的 DApp 定义了规则和过渡，是运行在以太坊虚拟机中的一部分。避免在你的智能合约中加入不必要的逻辑，因为运行其计算的气体可能非常昂贵。我们将从 truffle 的简单智能合约开始，称为简单存储。它存储一个无符号整数
storedData，并提供一个 setter 和 getter。
pragma solidity ^0.4.18;
contract SimpleStorage {
uint storedData;
function set(uint x) public {
storedData = x;
}
function get() public view returns (uint) {
return storedData;
}
}
- 测试环境呢？由于以太坊合约上的任何写交易都将花费汽油你将需要一个测试网络来避免这种情况。以太坊提供官方测试网络，而 Truffle Framework 提供本地测试环境。
逐步指南
1.安装 Truffle 框架
npm install -g truffle
我们在这里使用 -g 标志，这样我们就可以在其他项目中继续使用这个框架。
2.生成样板代码
truffle unbox react
松露框架称样板文件为盒子。react 样板文件基于脸书的create-react-app样板文件。
这将生成一组文件和文件夹。
需要关注的文件夹很少。
- 文件夹是存储 react 代码的地方。
- 文件夹是存储用 solidity 编写的智能合同的地方。注意我们之前提到的
SimpleStorage.sol文件。 - 是管理以太坊网络上的合同部署的脚本。
- 在
public/中，index.html文件是 react 应用程序被注入的入口点。
3.启动开发环境
truffle develop
这引发了两件事。首先，在http://127.0.0.1:9545的以太坊节点模拟器，创建 10 个测试账户，每个账户有 100 个以太。其次，它会启动 truffle 命令行提示符。
4.汇编合同
在 truffle development 命令提示符下:
compile
这将把你的 solidity 契约编译成 JSON 工件，包括称为以太坊虚拟机(=EVM)字节码的字节码。你会在build/contracts文件夹中找到编译好的合同。
5.部署合同
在 truffle development 命令提示符下:
migrate
这将把合同部署到仿真以太网。(注意，您可以稍后通过修改truffle-config.js文件部署到真正的以太坊网络。)
现在，您可以在 DApp 中添加一些交互功能，例如编辑App.js文件。
6.跑 DApp
此时，您可以在浏览器中运行 DApp:
npm run start
但是，它和以太坊还没有太多的互动。所以我们在这里补充一些。
首先，我们需要通过获取 Web3 对象的句柄并设置提供者来连接到以太网。
注意:如果你想知道 DApp 是如何连接到 Web3.js 的，请查看utils/getWeb3.js。Web3 首先检查浏览器窗口中是否已经注入了 Web3 对象，并使用该对象。但是如果没有注入 Web3 实例，Web3 会尝试连接到作为网络提供者的http://127.0.0.1/9545。如果你正在使用薄雾浏览器或使用元蒙版扩展，web3 对象将被注入。您可以配置元掩码扩展(或 Mist 浏览器)将您的 DApp 连接到哪个网络，等等。
7.修改 DApp 代码
在App.js中，我们在 React componentWillMount()生命周期方法中获得对 web3 对象的引用，并将其存储在本地状态中。我们还实例化了契约的本地版本。
getWeb3
.then(results => {
this.setState({
web3: results.web3
})
// Instantiate contract once web3 provided.
this.instantiateContract()
})
.catch(() => {
console.log('Error finding web3.')
})
现在，我们可以添加一个小表单:
<form className="pure-form pure-form-stacked">
<fieldset>
<label htmlFor="storage">Storage Amount</label>
<input id="storage" type="number" ref={c => { this.storageAmountInput = c }} />
<button
className="pure-button"
onClick={(e) => {
e.preventDefault();
this.addToSimpleStorage()
}}
>
Set Storage
</button>
</fieldset>
</form>
该表单将允许用户设置他们希望存储在 SimpleStorage 契约中的值。按钮的操作处理程序如下:
addToSimpleStorage() {
if (this.state.simpleStorageInstance && this.state.accounts) {
const value = this.storageAmountInput.value;
this.state.simpleStorageInstance.set(value, {from: this.state.accounts[0]})
.then((result) => {
return this.state.simpleStorageInstance.get.call(this.state.accounts[0])
}).then((result) => {
this.setState(prevState => ({
...prevState,
storageValue: result.c[0]
}));
}).catch((err) => {
console.log('error');
console.log(err);
});
} else {
this.setState(prevState => ({
...prevState,
error: new Error('simple storage instance not loaded')
}))
}
}
在处理程序中，我们从本地状态获得 SimpleStorage 和 accounts 的实例化契约。然后，我们使用从 html 表单中获得的值设置 storageValue。
就是这样，我们简单的小 DApp。需要注意的几件事:
simpleStorageInstance.set触发简单存储契约的 set 方法。- 关于如何工作的细节，请查看 Truffle 的契约库，它有点像 Web3js 的包装器。
8.运行我们简单的 DApp
npm run start
您应该能够设置智能合约的存储值，该值将存储在以太坊区块链上。
设置以太坊 Web3 API 监控。
由于 DApp 没有集中的服务器，当你在生产中部署你的 DApp 时，就没有服务器来安装监控工具，如 Datadog 或 New Relic 。为了监控与智能合约和以太坊网络的交互，我们希望安装一个支持 DApps 的监控解决方案。
Moesif 很乐意支持以太坊 Web3 作为监控和分析的兼容 API。
Moesif 可以使用浏览器 SDK 直接从客户端捕获 API 调用数据，进而用于调试和监控问题，并在出现异常时向您发出警报。
我们将使用 moesif-browser-js 来集成 GitHub 上可用的。
1.创建一个 Moesif 账户以获得一个应用 id。
2.将以下代码片段添加到public/index.html
<script src="//unpkg.com/moesif-browser-js@1.2.0/moesif.min.js"></script>
<script type="text/javascript">
var options = {
applicationId: 'Your Moesif application id'
// add other option here.
};
// for options see below.
moesif.init(options);
// this starts the capturing of the data.
moesif.start();
</script>
3.重新加载您的应用程序
Moesif 自动检测以太坊 Web3 调用并跟踪它们。您可以通过登录 Moesif 并查看事件流来验证事件是否被捕获。
源代码
本教程的源代码可以在 Github 上找到。
Moesif 以太坊 DApp 支持
请查阅这篇文档，了解 Moesif 如何支持基于以太坊 Web3 和 JSON-RPC 构建的去中心化应用。。还有更多信息设置自动解码十六进制值为人类可读值。
元掩码的常见问题和常见问题
我收到了很多人们经常遇到的问题，特别是关于从默认的松露开发网络切换到 Metamask 的问题。所以，我写了一篇博文:关于 Metamask 和 Web3 的常见陷阱和解决方案的 FAQ。
使用 Moesif 和 Chargebee 设置基于使用的 API 计费的教程
现代 API 企业正在向基于使用量的计费模式迁移，这种模式能够自动扩大收入，同时消除采用新 API 的障碍。使用 Moesif，您可以与 Recurly 和 Chargebee 等订阅管理解决方案集成，在几分钟内快速添加基于使用的高级计费。在本指南中，我们将介绍 Moesif 与 Chargbee 的集成，以及一些基于使用计费的建议。然后，我们将讨论如何利用嵌入模板和行为电子邮件让您的客户了解它们的使用情况。
本指南假设您已经熟悉 Moesif 的计量 API 计费和收费人的订阅管理。我们还建议阅读一份正确实施现收现付定价的行动手册，以熟悉不同的计费模式。
解决方案的工作原理
为了正确实施基于使用的计费，除了标准订阅管理之外，您还需要一些组件:
- 计量每个客户的*台使用情况，并根据使用情况开具发票
- 当客户接*或超过配额或阈值时，向他们发送自动提醒
- 为客户提供一个仪表板，以检查他们的订阅使用情况
此示例演示了如何设置后付费账单，其中客户根据其上个月的使用情况按月付费。虽然这是最常见的基于使用的计费形式，但也有其他模式，如预付费计费、基于信用的余额和基于阈值的发票。查看行动手册以正确实施现收现付定价进行深入比较。
GitHub 上有一个工作示例应用
在每个续订期(通常每月一次)，收费人将调用 webhook 从 Moesif 获取客户的使用情况。这是通过您的 Moesif 帐户中的预定义查询来完成的。Moesif 还会在客户接*预定义的配额时发送提醒电子邮件，该配额可能是客户指定的。
1.安装 Moesif 监控 SDK
为了处理基于使用量的计费，您需要准确地计量每个客户的 API 使用量。这可以通过 Moesif 服务器集成或 API 网关插件来完成。下面的 Node.js 就是一个例子。
// 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',
// Optional hook to link API calls to users
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);
2.将收费订阅信息同步到 Moesif
为了正确地向客户发送配额和计费通知，您需要将客户电子邮件存储在 Moesif 中。您还需要存储客户的计划。我们建议使用以下映射:
| 穆塞夫 | 受款人 | 描述 |
|---|---|---|
| 用户 | 客户/联系人 | 一个帐户中的单个用户及其姓名、电子邮件和用户 id |
| 公司 | 订阅 | 订阅信息及其相关的计划配额或价格 |
每个帐户处理多封电子邮件
在 Chargebee 中，每个订阅对象只能与一个客户对象相关联。如果一个订阅可以有许多席位(用户),这就使数据模型变得有些复杂。作为一种变通办法，Chargebee 的确可以让你存储两个特殊联系人:账户电子邮件和账单电子邮件。
因为 Moesif 是为基于账户的业务(即 B2B)设计的，所以 Moesif 对用户的处理是不同的。一个 Moesif 公司可以与许多用户相关联，每个用户都有自己的元数据。我们建议通过拆分客户对象，而不仅仅是主要客户，将该客户下的所有联系人同步到 Moesif，这样可以更灵活地确定由谁接收电子邮件通知。每个用户都有一个指定用户标签或角色的字段。
为了将 Chargebee 订阅同步到 Moesif，我们将使用一个重复的 cron 作业获取过去 24 小时内所有最*创建或更新的订阅。付费订阅 id 将映射到 Moesif 公司 Id，而客户 Id/联系人 Id 将映射到 Moesif 用户 Id。
费用的变化
- 在 Billing LogIQ 设置中，选择通知并等待关闭发票。
- 对于发票日期，我们推荐发票关闭日期
通过 cron 作业同步的代码
下面我们将保存所有用于分析的订阅字段，但您可以选择将哪些属性保存为 Moesif 公司或用户元数据。我们循环浏览订阅和公司。Chargebee API 将分页限制为 100 项，因此我们在静默期之后继续重复代码。
GitHub 上有一个工作示例应用
const chargebee = require('chargebee');
const cron = require('cron');
const basicAuth = require('express-basic-auth');
const bodyParser = require('body-parser');
const express = require('express');
const safeGet = require('lodash/get');
const superagent = require('superagent');
const moesifapi = require('moesifapi');
const moment = require('moment');
// Initialize SDKs
chargebee.configure({ site: process.env.CHARGEBEE_SITE, api_key: process.env.CHARGEBEE_API_KEY });
moesifapi.configuration.ApplicationId = process.env.MOESIF_APPLICATION_ID;
chargebee.configure({ site: process.env.CHARGEBEE_SITE, api_key: process.env.CHARGEBEE_API_KEY });
const CronJob = cron.CronJob;
new CronJob('*/10 * * * *', function() {
try {
console.log('Run syncSubscriptions');
syncSubscriptions();
} catch (err) {
console.log(err);
}
}, null, true, 'America/Los_Angeles', null, true);
function syncSubscriptions() {
chargebee.subscription
// We only need to sync subscriptions that have been updated in the last 24 hrs.
.list({
limit: 100,
'sort_by[asc]': 'updated_at',
'updated_at[after]': moment().utc().subtract(24, 'hour').unix(),
})
.request()
.then((subscriptions) => {
console.log(`Received subscriptions`)
// Save Chargebee subscriptions as Moesif companies
const companies = subscriptions.list.map((s) => {
return {
company_id: s.subscription.id,
metadata: s.subscription // Rest of metadata
}
})
// console.log(JSON.stringify(companies));
moesifapi.ApiController.updateCompaniesBatch(companies, (error, response, context) => {
if (error) {
console.log(error)
} else {
console.log(`Synced Chargebee Subscriptions to Moesif Companies Successfully statusCode=${context.response.statusCode}`)
}
// Save Chargebee customers and contacts as Moesif users
const users = subscriptions.list.map((s) => {
const contacts = s.customer.contacts ?
contacts.map(c => {
return {
user_id: c.id,
company_id: s.subscription.id,
email: c.email,
first_name: c.first_name,
last_name: c.last_name,
metadata: { label: c.label, ...s.customer } // Rest of metadata
};
}) : [];
return [
...contacts,
{
user_id: s.customer.id,
company_id: s.subscription.id,
email: s.customer.email,
first_name: s.customer.first_name,
last_name: s.customer.last_name,
metadata: s.customer // Rest of metadata
}
];
});
usersFlattened = users.reduce(function(a, b){
return a.concat(b);
}, []);
moesifapi.ApiController.updateUsersBatch(usersFlattened, (error, response, context) => {
if (error) {
console.log(error)
} else {
console.log(`Synced Chargebee Subscriptions to Moesif Users Successfully statusCode=${context.response.statusCode}`)
}
});
});
}
);
}
3.处理计量计费网络挂钩
Chargebee 的发票 API 有一个方便的 webhook ，可以在发票生成时触发。这为您提供了一种方式来告诉 Chargbee 根据客户在 Moesif 中的使用情况，在客户的计费周期内向客户收取多少费用。
您可以通过以下两种方式添加费用:
在本例中，我们将直接在发票中添加费用。然而，更复杂的设置可能需要利用附加组件。
计算账单周期
一旦发票处于待定状态，订阅就已经续订，因此我们开始了一个全新的计费周期。因此，我们希望根据上一个计费周期而不是当前计费周期来计算客户的使用量。
公司用途查询
为了确定客户的使用情况，我们首先需要确定哪些 API 调用是“可收费的”，这是由您的定价和业务模型决定的。例如，通信 API 可以基于发送的 SMS 来收费，而电子商务*台可以基于进行的购买来收费。我们可以利用 Moesif 的高级过滤机制和管理 API，只需点击几下鼠标就可以构建这个查询。在这个例子中，我们包括了所有路由匹配/purchases或/withdraws的 API 调用。
- 要在
getCompanyUsageQuery()函数中生成 JSON，登录 Moesif，进入事件 - > 分段。 - 从这里，添加应该包括的任何过滤器，例如特定的端点或字段。
- 确保在公司 id 上添加过滤器。实际值和图表的日期范围无关紧要，因为它们将在代码中被覆盖。
- 点击右上角的橙色“嵌入”按钮，然后“通过 API 获取”。这将为该报告提供完整的 JSON 查询。
- 查询参数
from和to以及有效负载值company_id.raw将在下面的代码中被覆盖。
处理基于用量的开票的代码
GitHub 上有一个工作示例应用
const chargebee = require('chargebee');
const cron = require('cron');
const basicAuth = require('express-basic-auth');
const bodyParser = require('body-parser');
const express = require('express');
const safeGet = require('lodash/get');
const superagent = require('superagent');
const moesifapi = require('moesifapi');
const moment = require('moment');
const app = express();
chargebee.configure({ site: process.env.CHARGEBEE_SITE, api_key: process.env.CHARGEBEE_API_KEY });
app.use(
basicAuth({
users: { [process.env.CHARGEBEE_WEBHOOK_USERNAME]: process.env.CHARGEBEE_WEBHOOK_PASSWORD },
})
);
const UNIT_COST_IN_CENTS = 1; // How much each transaction is worth in cents
// Simple sample query which can be found going to "Events" -> "Segmentation" in Moesif.
// Then select the orange Get Via API button under "Embed".
function getCompanyUsageQuery(companyId) {
return {
aggs: {
seg: {
filter: {
bool: {
must: [
{
terms: {
'request.route.raw': [
'/purchases',
'/withdraws',
'/'
]
}
},
{
term: {
'company_id.raw': companyId
}
}
]
}
},
aggs: {
weight: {
sum: {
field: 'weight',
missing: 1
}
}
}
}
},
size: 0
}
}
app.use(bodyParser.json());
app.post('/chargebee/webhooks', (req, res) => {
const event = req.body;
if (event && event.event_type === 'pending_invoice_created') {
const invoice = event.content.invoice;
// Retrieve subscription for this invoice to get billing period
return chargebee.subscription
.retrieve(invoice.subscription_id)
.request()
.then((subscriptionResult) => {
const subscription = subscriptionResult.subscription;
console.log('Retrieved subscription');
console.log(JSON.stringify(subscription));
// We should query metric the previous billing period.
const params = {
from: (moment.unix(subscription.current_term_start)
.subtract(parseInt(subscription.billing_period), `${subscription.billing_period_unit}s`)).toISOString(),
to: moment.unix(subscription.current_term_start).toISOString()
};
console.log('Params: ' + moment.unix(subscription.current_term_start).toISOString());
console.log(JSON.stringify(params));
// Get usage from Moesif
return superagent
.post(`https://api.moesif.com/v1/search/~/search/events`)
.set('Authorization', `Bearer ${process.env.MOESIF_MANAGEMENT_API_KEY}`)
.set('Content-Type', 'application/json')
.set('accept', 'json')
.query(params)
.send(getCompanyUsageQuery(subscription.id))
.then((countResult) => {
const count = safeGet(countResult, 'body.aggregations.seg.weight.value');
console.log(`Received count of ${count}`)
const amount = count * (UNIT_COST_IN_CENTS); // How much each transaction is worth in cents
console.log(`Adding cost for subscription=${subscription.id} of ${amount}`);
chargebee.invoice.add_charge(invoice.id,{
amount : amount,
description : `Usage of ${amount} widgets`
}).request(function(error, chargeResult) {
if(error){
//handle error
console.log(JSON.stringify(event));
console.log(error);
res.status(500).json({ status: 'internal server error' });
} else {
console.log(chargeResult);
res.status(201).json({ status: 'ok ' });
}
});
})
.catch((error) => {
console.log(error.text);
res.status(500).json({ status: 'internal server error' });
});
})
}
console.log(JSON.stringify(event));
res.status(500).json({ status: 'internal server error' });
});
app.listen(process.env.PORT || 5000, function() {
console.log('moesif-chargebee-example is listening on port ' + (process.env.PORT || 5000));
});
3.嵌入使用报告
现在，Moesif 和 Chargebee 已经完全设置好了基于使用情况的发票，您还需要想办法让您的客户了解他们的使用情况。有两种方法可以做到这一点。第一个是嵌入式仪表盘，这样您就可以显示使用情况的指标。
嵌入式使用情况报告使您能够向客户提供自助服务指标，以便他们了解他们所支付的费用。这些报告为您的客户创造了额外的透明度和信任，因为他们可以跟踪他们获得的相对于成本的价值。首先，查看嵌入模板文档和示例 GitHub 项目
4.设置配额提醒和电子邮件
您还可以利用 Moesif 行为电子邮件在客户接*或超过其账单周期配额时自动通知客户。这可以是一个静态阈值，特定于一个计划，甚至特定于一组客户。
首先，请按照我们的指南设置配额和计费问题的自动通知。
结束语
有了 Moesif 和 Chargebee，您现在有了一个准确的机制来根据客户的使用情况向他们收费。因为遥测数据已经存储在 Moesif 中，所以您可以利用其附加的小部件，如行为电子邮件和嵌入式仪表板，只需点击几下鼠标，就可以让您的客户了解他们的订阅情况。此外，您还可以在 Moesif 中设置提醒，以便您自己的客户成功团队能够主动联系，这在账单可能会在账单周期之间大幅波动时非常重要。首先，查看 GitHub 上的示例应用。
通过分析 API 负载释放业务洞察力
API 现在是企业打破公司孤岛的事实上的方法，它支持内部部门和外部客户和合作伙伴之间的数据共享。根据 Cloud Elements，现在超过 50%的 B2B 协作发生在 API 上，并且还在继续增长。您的企业可以部署 API，通过让合作伙伴和客户以编程方式连接您的服务来实现自动化和数据共享，从而为他们提供额外的价值。同时，您的企业可以通过拼凑其他公司的 API 集合来构建新产品和服务。
API 正在成为现代企业连接供应商和客户的事实上的数字供应链。因此，流经 API 的数据很好地代表了企业的健康状况。然而，缺乏利用这些数据的工具。
如今，商业分析工具要么侧重于:
- 数据库和仓库中的离线事务数据，如 Redshift 或 Snowflake
- Mixpanel 和 Amplitude 等工具中的在线使用指标，以了解消费者如何与 web 和移动界面进行交互。
这就为公司留下了一个缺口，这些公司不仅试图获得对其网络和移动资产的洞察，还试图获得对任何 API 驱动的数字资产的洞察，无论是合作伙伴集成、供应商 API 还是提供给客户的 API。随着 API 围绕 REST、JSON 和 GraphQL 等常见设计模式进行标准化，公司收集和分析这些数据变得更加容易，而无需构建复杂的定制解决方案。
API 分析解决方案的架构
面向技术用户的基线 API 分析
首先，API 分析系统应该捕获关于 API 的基本信息，比如 HTTP 动词、路径或路由以及 HTTP 头。还应该跟踪其他元数据，如状态代码、身份验证信息和延迟。此类属性支持技术指标，如按端点细分的 90%延迟，并发现任何异常值。
将 API 分析扩展到业务用户
对于业务用户来说，仅仅跟踪性能和功能 API 度量是不够的。为了使 API 分析系统有用，请求需要与业务概念联系起来，例如 API 事务的含义、资金或价值流动的方向以及 API 的用户是谁。因为 API 本质上是技术性的，所以添加诸如事务描述和哪个团队拥有 API 之类的上下文是至关重要的。例如，如果我们要查看最大的客户正在使用的顶级端点，可能会进行如下的 top k 聚合:
| 端点 | 每日事件计数 |
|---|---|
| 获取/项目 | Five hundred and forty-five thousand four hundred and fifty-one |
| GET/items/:id/类别/ | Four hundred and fifty-four thousand one hundred and fifty-one |
| 帖子/评论 | Three thousand four hundred and eighty-eight |
| 过帐/采购 | One hundred and one |
然而，商业用户的 API 分析可以用简单的描述来标记 API 事务。如今，这可以通过流行的 API 标记语言(如 Swagger/OpenAPI)自动完成，生成如下所示的报告:
| 端点 | 每日事件计数 |
|---|---|
| 获取项目列表 | Five hundred and forty-five thousand four hundred and fifty-one |
| 获取项目类别列表 | Four hundred and fifty-four thousand one hundred and fifty-one |
| 创建评论 | Three thousand four hundred and eighty-eight |
| 创建采购 | One hundred and one |
分析请求和响应主体
捕获整个有效负载不仅可以深入了解哪些端点被调用或延迟时间，还可以了解 API 查询或发布到 API 的实际客户。这使得能够跟踪销售和订单等业务实体。还应该跟踪其他元数据，如状态代码、身份验证信息和延迟。下图显示了响应 JSON 中按“标签”字段分组的 API 调用数量，它们按客户名称分组。
通过查看网络上的实际数据，我们能够看到 API 何时以缺货作为标签或类型做出响应。
添加客户人口统计信息
通过在 Salesforce 和内部用户表等系统中提取客户信息，业务用户可以按照客户名称、员工数量和营销属性对 API 数据进行分割。这使得业务用户能够了解哪些类型的用户在最大程度上采用和成功使用 API，同时投资于推动结果的正确的销售和营销计划。例如，下图显示了按营销渠道细分的独特 API 用户。
商业用户如何利用 API 分析？
通过添加客户人口统计信息，设计良好的 API 分析系统可以回答以下问题:
- 跟踪客户从最初接触到完全激活/整合客户的过程，同时发现哪些营销举措推动了更高的激活率。
- 通过观察产品保持率来发现特定的 API 程序是否健康。
- 通过了解使用或不使用哪些 API 特性来规划更好的产品策略。
- 当一个新的帐户激活或有困难时进行监控，并先发制人任何艰难的讨论。
在下图中，我们能够跟踪顾客的旅程，了解他们在哪里下车。为此，我们需要定义一些标准，比如第一个 Hello World 的时间(T0)和有价值行动的时间(T2)
使 API 分析具有可操作性
为了具有可操作性，最终用户需要能够在达到特定标准时创建操作和工作流。例如，每当特定新用户的 API 流量发生变化时，客户经理或客户成功经理就可以创建一个警报。产品经理可以创建一个仪表板，显示关于唯一活跃用户和功能使用的各种指标，而首席营销官可能需要一个仪表板，显示哪些营销渠道驱动了最多的激活以及转化率趋势如何。这意味着 API 分析系统应该能够为每个使用服务的团队创建仪表板，包括销售、客户成功、支持、产品和营销。
部署 API 分析的障碍
虽然部署 API 分析会对部署 API 的组织的增长轨迹产生巨大影响，但组织需要考虑一些问题。
维修费用
高容量的 API 会给设计不良的分析系统带来沉重的负担。团队总是超额订阅，这意味着在创建不向客户公开的内部系统时会走捷径，无论是在可伸缩性、安全性还是两者上。
合规风险
分析系统可能会跟踪 PII 或受监管的敏感信息，如 GDPR 和 CCPA。在存储此类数据时，拥有正确的流程和工作流来终止和删除数据至关重要。此外，还应该有可靠的访问控制来保护用户数据。
易用性
虽然技术用户可以在 Splunk 和 Datadog 等 APM 工具中直接解析日志和挖掘时序指标，但如果他们被迫采用此类工具，业务用户的生产力将会下降。在这种情况下，工程和数据科学团队产生了额外的负担。自助分析对于任何重视敏捷开发和创新速度的组织来说都至关重要。
Moesif 和 Recurly 基于使用的 API 定价
过去，购买或租赁服务器并一次性付款是很正常的，与利用率无关。随着无服务器计算的兴起，构建 API 的基础设施变得更加便宜，按需定价成为常态。既然你只为你使用的东西付费，为什么不把基于使用的定价作为一个特性包含在你自己的 SaaS 产品中呢？
通过基于使用的定价，您的客户不会被高昂的前期成本吓倒，相反，他们的成本会随着业务的增长而增长。Recurly 是一种订阅管理服务，允许您根据客户的 API 使用情况向他们收费。
本指南假设你已经熟悉 Moesif 的计量 API 计费和 Recurly 的订阅管理。我们还建议阅读一份正确实施现收现付定价的行动手册，以熟悉不同的计费模式。
本文解释了如何在 Node.js 快速安装中使用 Recurly 设置基于使用的定价，API 使用数据来自 Moesif。
解决方案的工作原理
为了正确实施基于使用的计费，除了标准订阅管理之外，您还需要一些组件:
- 计量每个客户的*台使用情况，并根据使用情况开具发票
- 当客户接*或超过配额或阈值时，向他们发送自动提醒
- 为客户提供一个仪表板，以检查他们的订阅使用情况
先决条件
你需要一个 Moesif 账户和一个递归账户。你还需要安装 Node.js 。
设置 Moesif
第一步是将 API 请求与您的客户 id 关联起来。这是 Moesif 设置中的一个基本步骤，稍后需要它来告诉 Recurly 客户需要支付什么。
// 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',
// Optional hook to link API calls to users
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);
您还必须用一个从请求上下文中提取用户的函数来替换identifyUser。在本例中，id 由 Node.js 身份验证中间件设置。如果您在公司级别进行认证，您可以选择实现identifyCompany函数。有了这个设置，你所有的 API 请求都会被记录到 Moesif API Analytics 中。下一步是递归设置。
递归设置
Recurly 有计划和客户帐户，客户可以订阅多个计划。在本例中，我们将为基于使用的定价创建一个简单的计划，客户只能订阅一个计划。
要在 Recurly 中创建基于使用情况的计划，请创建计划，然后选择基于使用情况的附加组件。您可以设定一个基本价格，然后根据客户的需求提高价格。为了简单起见，我们将创建一个免费计划，在本例中只收取每次使用的费用。
图 1 显示了在哪里可以找到递归计划的配置。
点击右上角的“新计划”，然后创建一个名为“基于使用”的新计划，计划代码为“001”。每个计费周期的价格将保持为零。
在“计划加载项”下，创建新的加载项。此加载项需要名称和代码。它应该在计费周期结束时计费，因为我们事先不知道客户将使用什么。接下来，创建一个名为“requests”的新“度量单位”,并将其设置为固定价格 0.01 美元。这样，每个请求都要花一分钱。附加组件不应该是可选的。
您的计划创建表单应该如下所示:
连接 Moesif 和 Recurly
现在我们在 Recurly 中有了一个基于使用的计划，客户可以订阅它。我们需要递归地将订阅 id 链接到 Moesif 中的客户 ID。
Recurly 在他们的文档中明确声明，不应该使用 webhooks 来创建帐户，而应该使用 API 客户端的返回值。这意味着递归订阅创建和 Moesif 公司和用户创建必须一次完成。
先说反曲部分。在注册的 Express API 端点中，您必须使用以下两个递归 API 调用。
let account;
try {
account = await recurlyClient.createAccount({
code: getNewCustomerId(),
firstName: request.body.firstName,
lastName: request.body.lastName,
address: request.body.address,
});
} catch (error) {
console.log(error);
return response.end();
}
let subscription;
try {
subscription = await recurlyClient.createSubscription({
account,
addOns: [{ code: "001" }],
currency: "USD",
planCode: "001",
});
} catch (error) {
console.log(error);
return response.end();
}
第一个将为您的用户创建一个 Recruly 帐户，第二个将开始订阅。您需要自己创建一个唯一的帐户代码。最简单的方法是首先在您自己的认证系统中注册一个客户，并使用您生成的 ID。
第二个递归 API 调用将为递归帐户订阅计划。计划的代码及其附加代码是我们之前创建计划时使用的代码。
如果一切顺利，您应该最终得到两个对象，account和subscription。我们将在下一步中使用这些来将他们与 Moesif 内部的公司和用户联系起来。
const moesifCompany = {
company_id: subscription.uuid,
metadata: subscription,
};
const moesifUser = {
user_id: account.account_code,
company_id: moesifCompany.company_id,
email: account.email,
first_name: account.first_name,
last_name: account.last_name,
metadata: { ...account },
};
moesifapi.ApiController.updateCompany(
moesifCompany, (error) => {
if (error) console.log(error);
};
moesifapi.ApiController.updateUser(moesifUser, (error) => {
if (error) console.log(error);
};
为了从一个递归subscription中创建一个 Moesif 公司，我们必须创建一个带有company_id的新对象；为此，我们将使用新创建的subscription的uuid,并将剩余的订阅数据放入moesifCompany对象的metadata。
接下来，我们使用moesifapi库，它将与moesif-nodejs一起安装。updateCompany功能将在 Moesif 服务中创建新的公司记录。因为我们使用了订阅的 uuid，所以这两者现在是链接在一起的。
最后一步是创建一个 Moesif 用户。虽然它不是公司级别的计费所必需的，但如果我们想知道谁为公司发出了哪个请求，它将会有所帮助。
将 API 用法发送到递归
推送指标与预更新 wehook
从 Moesif 到 Recurly 有两种不同的同步使用方法
- 当触发订阅预续订 webhook 时，循环发送计费周期的使用情况，该消息在订阅续订前 1 天发送。工作量减少，但准确性降低。
- 连续发送循环使用数据，如每小时或每天的工作。更多的工作，但也更准确
公司用途查询
为了确定客户的使用情况，我们首先需要决定哪些 API 调用是“可收费的”,以及每个调用值多少钱。例如，通信 API 可以基于发送的 SMS 来收费，而电子商务*台可以基于进行的购买来收费。我们可以利用 Moesif 的高级过滤机制和管理 API，只需点击几下鼠标就可以构建这个查询。在这个例子中，我们包括了所有路由匹配/purchases或/withdraws的 API 调用。
- 要在
getCompanyUsageQuery()函数中生成 JSON，登录 Moesif，进入事件 - > 分段。 - 从这里，添加应该包括的任何过滤器，例如特定的端点或字段。
- 确保在公司 id 上添加过滤器。实际值和图表的日期范围无关紧要，因为它们将在代码中被覆盖。
- 点击右上角的橙色“嵌入”按钮，然后“通过 API 获取”。这将为该报告提供完整的 JSON 查询。
- 查询参数
from和to以及有效负载值company_id.raw将在下面的代码中被覆盖。
为了将递归订阅同步到 Moesif，我们将使用一个递归 cron 作业获取过去 24 小时内所有最*创建或更新的订阅。递归订阅 id 将映射到 Moesif 公司 Id，而帐户 Id 将映射到 Moesif 用户 Id。
处理基于用量的开票的代码
const recurly = require('recurly-nodejs');
const cron = require('cron');
const basicAuth = require('express-basic-auth');
const bodyParser = require('body-parser');
const express = require('express');
const safeGet = require('lodash/get');
const superagent = require('superagent');
const moesifapi = require('moesifapi');
const moment = require('moment');
require('body-parser-xml')(bodyParser);
const app = express();
const UNIT_COST_IN_CENTS = 1; // How much each transaction is worth in cents
// Simple sample query which can be found going to "Events" -> "Segmentation" in Moesif.
// Then select the orange Get Via API button under "Embed".
function getCompanyUsageQuery(companyId) {
return {
aggs: {
seg: {
filter: {
bool: {
must: [
{
terms: {
'request.route.raw': [
'/purchases',
'/withdraws',
'/'
]
}
},
{
term: {
'company_id.raw': companyId
}
}
]
}
},
aggs: {
weight: {
sum: {
field: 'weight',
missing: 1
}
}
}
}
},
size: 0
}
}
app.use(bodyParser.xml());
app.post('/recurly/webhooks', (req, res) => {
const event = req.body;
if (event && event.prerenewal_notification) {
// We should query metric the previous billing period.
const params = {
from: moment(prerenewal_notification.subscription.current_period_started_at).toISOString(),
to: moment(prerenewal_notification.subscription.current_period_ends_at).toISOString()
};
console.log(JSON.stringify(params));
// Get usage from Moesif
return superagent
.post(`https://api.moesif.com/v1/search/~/search/events`)
.set('Authorization', `Bearer ${process.env.MOESIF_MANAGEMENT_API_KEY}`)
.set('Content-Type', 'application/json')
.set('accept', 'json')
.query(params)
.send(getCompanyUsageQuery(subscription.id))
.then((countResult) => {
const count = safeGet(countResult, 'body.aggregations.seg.weight.value');
console.log(`Received count of ${count}`)
const amount = count * (UNIT_COST_IN_CENTS); // How much each transaction is worth in cents
console.log(`Adding cost for subscription=${subscription.id} of ${amount}`);
// Save the API usage amount to Recurly
recurly.createUsage(
prerenewal_notification.subscription.uuid,
"001",
{ amount: amount }
);
}).catch((error) => {
console.log(error.text);
res.status(500).json({ status: 'internal server error' });
});
}
console.log(JSON.stringify(event));
res.status(500).json({ status: 'internal server error' });
});
app.listen(process.env.PORT || 5000, function() {
console.log('moesif-recurly-example is listening on port ' + (process.env.PORT || 5000));
});
嵌入使用报告
现在，您的基于使用情况的发票已经通过 Moesif 和 Recurly 完全设置好了，您还需要研究如何让您的客户了解他们的使用情况。我们建议您这样做的最佳方式是使用嵌入式仪表板，它优雅地显示了使用度量。
嵌入式使用情况报告使您能够向客户提供自助服务指标，以便他们能够了解他们所支付的费用。这些报告为您的客户创造了额外的透明度和信任，因为他们可以轻松地跟踪他们获得的相对于成本的价值。首先，查看嵌入式模板文档和示例 GitHub 项目。
设置配额提醒和电子邮件
您还可以利用 Moesif 行为电子邮件，在客户接*或超过其账单周期配额时自动通知客户。这可以是一个静态阈值，特定于一个计划，甚至特定于一组客户。
首先，请按照我们的指南设置配额和计费问题的自动通知。
摘要
Moesif 和 Recurly 是基于使用计费的绝佳组合。遥测数据存储在 Moesif 中，因此您可以利用其附加的小部件，如行为电子邮件和嵌入式仪表板，让您的客户随时了解他们的订阅情况。
您还可以使用 Moesif 设置警报，这样，如果使用/计费在计费周期内大幅波动，您自己的客户成功团队就可以主动寻求帮助。
以用户为中心的 API 指标与基础设施指标，以及如何选择正确的分析架构和数据存储
在短短几年内，数据驱动的团队从没有足够的数据到淹没在指标的海洋中。现在可以跟踪、处理和分析每一个动作、反应和结果。然而，我们收到的一个关键问题是，哪些指标是重要的，哪种分析架构和数据存储最适合特定的分析要求。
对于技术产品和工程团队来说，有两种重要的度量标准:
- 基础设施指标，如 EPM(每分钟错误数)
- 以用户为中心的指标，如 MAU(每月活跃用户数)和会话时长
什么是产品指标？
API analytics 或 web analytics 之类的产品指标围绕着用户(或者公司，如果你是 B2B 的话)如何体验你的应用。也被称为用户行为分析，每一个事件或行为都可以追溯到单个客户，并且可以通过一起查看多个事件来发现行为趋势。
通过关注以客户为中心的使用，我们可以发现产品问题，例如为什么用户停止使用您的 API，或者他们最常使用的功能或端点。
产品指标牺牲了对后端基础架构的亚秒级可见性，同时提供了对跨多个会话和跨多个用户的单个用户的客户体验和行为的更多可见性。产品分析的一个关键区别在于，所有事件数据都与单个用户或公司相关联，这使得能够快速生成*均会话长度等聚合数据或生成采用漏斗。此外，产品指标通常会进行汇总，以支持更长期的趋势，如月环比或季度环比。
对于产品指标，您对某项服务在最后一分钟发生了什么不太感兴趣，而更感兴趣的是发现客户或产品体验的问题和长期趋势。客户不在乎单个请求是命中实例 A 还是实例 B，但是如果某个特性令人困惑或者没有创造价值，他们可能会停止使用您的服务。
Moesif、Amplitude 和 Mixpanel 等工具侧重于产品指标，包括:
- 我的月活跃用户和 API 调用最多的用户是多少？
- 用户在我的采用漏斗中处于什么位置？
- 哪些用户最忠诚？通过群组保持分析
- 哪些用户有糟糕的客户体验或可能流失？
- *均会话长度是多少？
什么是基础设施指标？
基础设施指标不围绕用户。相反，它们围绕着内部服务的长期趋势。在查看基础设施指标时，您很少会跟踪用户实体。这类工具包括 Datadog、New Relic、Kibana 和其他 APM(应用程序性能监控)工具。
基础设施指标包括:
- 随着时间的推移，我的错误率和内存利用率趋势如何？
- 当服务失败时，过去 5 分钟内发生了什么？
- 通过服务地图，哪些服务存在通信问题
由于基础架构指标通常存储在基于时间的事件存储中，因此您可以进行超快速筛选和指标聚合，因为任何时间范围或服务/实例名称筛选都会显著减少数据集，例如只查看过去 24 小时或过去一小时内创建的数据。
比较基于时间的数据模型和以用户为中心的数据模型
如果您正在构建自己的度量系统，那么您选择的数据模型类型将对您可以对数据进行的分析类型产生重大影响。正如大多数工程师所知，事后更改数据模型是一项繁重的工作，可能需要迁移旧数据。
基于时间的数据存储
如果您想要搜索和分析日志以进行功能和性能监控，通常只添加基于时间的数据存储是最好的。由于基础架构指标最感兴趣的是现在发生的事情，或者过去 24 小时发生的事情，因此利用基于时间的模型可以将过去 24 小时的热数据存储在更强的节点上，而旧数据可以根据保留策略调出，甚至一起删除。基于时间的日志的一个巨大好处是，显示一段时间内趋势的聚合可以非常快地执行，因为聚合只涉及一小部分数据。任何指标聚合都可以通过简单的 map reduce 并行完成，这可以通过内部数据库流程或 Spark 等第三方框架来完成。
基于时间的指标的一个缺点是，通过一起查看多个事件来查看用户行为趋势几乎是不可能的。即使是最简单的查询，如查找*均会话长度，也会因为内存不足错误而削弱基于时间的存储，因为会话长度必须从每个用户的第一个和最后一个事件中获得。这是因为用户 id 是一个高基数的键，需要连接内存中每个用户的所有事件。除非您等待长时间运行的作业来加载和转换数据，否则无法完成漏斗和群组保留分析等更复杂的分析，这需要花费数小时或数天时间，从而消除了自助交互式分析的优势。
以用户为中心的数据存储
以用户为中心的数据存储不是基于时间的数据存储，而是由用户记录组织的。用户的所有关联事件数据都与该用户一起存储。
因此，与全局事件日志不同的是，您有了一个基于滚动期和用户 id 的两级树结构，并构建了用户配置文件，其中每个用户节点都与其各自的事件相关联。这使得为美国的所有用户执行诸如*均会话长度之类的计算变得相对琐碎，因为所有需要做的是对位于美国的用户进行过滤，然后执行简单的 map reduce 函数来计算每个用户的*均会话长度。完成后，我们可以将每个用户的会话长度整合成一个全局长度。不必担心用户 id 是高基数的。
当然，对于以用户为中心的数据存储，不利的一面是使数据过期或将特定时间段移动到更强大的节点会更加困难。虽然这是可行的，但滚动周期更长，例如每月或每年，以避免基于时间的索引的连接爆炸，而基于时间的索引可以滚动到每小时或每天。这意味着，即使你只对最*的数据感兴趣，比如上个小时发生的事情，你仍然会接触到比纯粹基于时间的方法更多的数据。当你关注周环比或月环比趋势时，以用户为中心的指数效果最佳。
第二个缺点是构建一个以用户为中心的管道来存储数据更加复杂。像 Logstash 和 Fluentd 这样的日志聚合管道将无法执行为正确的用户按顺序插入数据所需的洗牌和转换。因此，您必须利用 Spark 或 Hadoop 等分布式集群计算框架来转换数据，这需要更多的工程资源。执行 shuffle 的一种方法是首先将传入事件存储在基于时间的数据存储中，然后运行 Spark 作业。请记住，如果您的某个用户触发了大量事件，您可能会遇到降低性能的热点。
用户渠道对客户体验至关重要
快乐的客户+客户忠诚度=品牌倡导者
如果你在寻找提高客户满意度、体验和忠诚度的方法，你需要关注客户如何使用和采纳你的产品。为此，你需要关注你的用户漏斗，有时被称为转换漏斗。在这篇文章中，我们将向你展示用户漏斗可以改善你的业务的一些关键领域的七种方式，以促进上述所有！
用户渠道是你的客户在与你的产品或服务互动时所选择的路径。这可以跟踪从他们第一次发现你的产品，注册，并开始使用特定功能的步骤。通过了解和优化用户漏斗，您可以有针对性地进行改进，以提高客户满意度和忠诚度。以下是用户渠道可以帮助你做到这一点的七种方式:
1.改进入职流程
入职流程对新用户至关重要。对于许多客户来说，入职体验是“成败”的一步，在这里你会看到大部分人被淘汰。如果用户体验良好，他们更有可能留下来继续使用产品。如果没有，他们更有可能流失，或者更糟，对你的产品进行负面评价，即使他们没有机会真正体验它。
用户渠道可以帮助您了解用户在哪里下车，以及是什么导致他们这样做，从而帮助您优化入职流程。入职流程通常包含多个可分割的步骤。通过在过程中的每一步检查转换，而不是将其视为一个单一的实体，您可以快速改善体验，并就应该在哪些方面做出更明智的决定。一个伟大的营销战略和销售团队能做的只有让人们注册，入职是你真正脱颖而出并为你的产品创造福音的地方
2.提高参与度
参与是让客户满意的关键，让他们能够提供产品反馈和见解。提供反馈可以帮助产品团队改进功能，跟上竞争对手并建立持久的关系。参与可以有许多不同的形式，包括在客户生命周期的不同阶段使用客户反馈调查。你可能会发现，向新客户发送试用后电子邮件调查可以保持客户参与，并有望为你的产品或服务注册付费账户。
提高参与度的尝试也可能来自产品电子邮件。这些电子邮件可能会显示最新的功能或定制的电子邮件流，指出根据其他行为为特定用户带来最大价值的功能。当使用一个序列来尝试和推动采用时，关注你的用户漏斗，看看你推动参与的行动是否会导致转化和采用，这很重要。
3.减少流失
当客户参与进来时，他们不太可能关注其他竞争对手或寻求我们的替代解决方案。相关文档和支持对客户的成功至关重要。分析客户流失的原因对于公司的发展至关重要，对于理解哪里可以创造新功能，哪里可以改进现有功能也很重要。通过收集数据来了解客户流失的原因，您可以跟踪用户体验的变化，以了解客户流失是在减少还是在增加。用户漏斗可以让你准确地看到客户旅程中的哪个阶段最有可能引起客户流失。
4.提高客户满意度
让客户满意是让客户开心的关键因素。如果他们对你的产品或服务不满意，他们会继续抱怨。识别用户漏斗中的负面体验有助于创建指南，帮助客户更好地利用您的产品和服务。根据易用性、文档或功能可用性等因素，客户满意度可能会提高或降低。用户漏斗有助于找出痛点，进行补救，并跟踪改进对客户的影响。
5.提高忠诚度
客户忠诚度是留住客户的关键。建立一个喜欢你的产品并继续回到*台的客户群是建立经常性收入的最好方法之一。正如大多数人所知，发展业务最昂贵的部分之一是吸引和吸纳新客户。通过保持客户忠诚度，你可以继续从那些已经采用你的产品的人那里增加收入。
要建立客户忠诚度，了解客户哪里需要支持的能力至关重要。这种支持可以来自持续的营销和产品文档，也可以直接来自客户成功团队。最重要的是，忠诚度可以表明你的公司有能力提供客户感兴趣的产品或服务，并从中获得重复价值。
6.增加收入
收入增加是客户满意度和客户忠诚度提高的自然结果。通过提高用户漏斗和转化率，您可以提高客户满意度和忠诚度，从而增加收入。
7.改善整体客户体验
整体客户体验是吸引客户的关键。这项工作从销售代表到客户成功团队开始。
典型用户旅程的七个关键阶段
认知阶段
这是一个潜在客户意识到你的品牌或产品的时候。例如，他们可能会看到一则广告，读到一篇关于你的产品的文章，或者被朋友推荐。
兴趣和考虑阶段
一旦他们意识到你的产品，他们需要对它产生一定程度的兴趣。这是你需要提供更多信息的地方，关于你的产品能为他们做什么，为什么他们应该关心。这可能来自不同的来源，如指南、影响者营销、社交媒体、电子邮件营销、数字营销、Reddit、Twitter 和/或 LinkedIn。任何社交媒体*台都可以在客户旅程中发挥重要作用。
欲望
在这个阶段，潜在客户非常想要你的产品，正在考虑购买。他们可能会比较不同的产品，阅读评论，或联系销售团队，因此营销策略对任何新客户都非常重要。
行动
最后，潜在客户采取行动，购买你的产品。但是他们的旅程并没有随着销售团队而结束。
保留
即使有人已经购买了你的产品，你也需要让他们参与进来，这样他们才不会成为一次性顾客。你可以通过提供优质的客户服务、提供额外的产品或服务，或者发放奖励来培养客户忠诚度。
再活化
如果某个客户已经有一段时间不活跃了，您可以尝试通过特别优惠重新激活他们，或者将他们添加到公司电子邮件列表中。
介绍
最好的客户是那些告诉他们的朋友你的产品并帮助你带来新的商业线索的人。你可以通过推荐项目或其他激励措施来鼓励这种行为。
用户渠道是创造快乐的潜在客户和不断回头客的重要部分。通过了解您的客户经历的旅程并优化每个阶段，您可以确保他们从认知阶段到推荐阶段有一个*稳愉快的体验，并提高客户忠诚度。你希望你的客户成为品牌倡导者。
为什么是用户漏斗？
用户漏斗是让你的新客户更开心的好方法，原因有很多。首先，用户渠道可以帮助你引导你的客户通过你的网站或应用程序，这种方式对他们来说非常简单和直观。这有助于减少沮丧和困惑，并使他们更有可能找到他们正在寻找的东西。
其次，用户漏斗可以帮助你收集关于你的客户的重要数据，你可以用这些数据来改善他们的体验。例如，您可以使用来自用户渠道的数据来了解哪些页面或功能最受客户欢迎，并做出相应的更改。
第三，用户渠道可以帮助你细分你的客户，这样你就可以针对目标受众定制你的营销和沟通。这可以确保你的客户只收到他们感兴趣的相关信息，这使得他们更有可能参与你的品牌。
总的来说，用户漏斗提供了很多好处，可以让你的新客户更开心。通过使他们更容易在你的网站或应用程序上找到他们需要的东西，并通过提供你可以用来改善他们体验的有价值的数据，用户漏斗可以帮助你从头到尾为你的客户创造更好的体验。
如何实现用户漏斗
用户漏斗是让你的新客户更开心的好方法。通过实施用户漏斗，你可以以更有效的方式引导客户浏览你的网站或应用，从而为他们提供更好的体验。
用户漏斗可以帮助你追踪用户的行为，并看到他们在哪里下车。通过这种方式，您可以对您的网站或应用程序进行更改，以改善用户体验。此外，用户渠道还可以帮助您向客户进行追加销售和交叉销售。
有几种不同的方法来实现用户漏斗。对于 B2C 领域的前端分析，一种方法是使用 Google Analytics。你可以在谷歌分析中设置用户渠道，方法是进入管理部分，选择“目标”菜单。在那里，您可以创建一个新目标，并选择“漏斗”作为类型。
实现用户漏斗的另一种方式是通过 A/B 测试。A/B 测试允许你用一小组用户测试你的网站或应用的不同版本。这样，您可以看到哪个版本最适合您的客户。
Moesif 是一个很好的工具，可以跟踪用户的整个旅程。您可以看到用户在哪里注册，何时使用产品，何时购买或订阅产品。点击此处获取使用 Moesif 用户漏斗的帮助指南。
总的来说，用户漏斗是通过跟踪用户行为来改善你的网站或应用程序的客户体验的好方法。
用户渠道的类型
有几种不同类型的用户渠道，企业可以用来让他们的新客户更开心。
一种用户漏斗是免费试用漏斗。这种漏斗为新用户提供产品或服务的免费试用期。免费试用期结束后，用户需要为产品或服务付费。这种类型的漏斗是让新客户在承诺付费之前试用你的产品或服务的好方法。
另一种用户漏斗是订阅漏斗。这种类型的漏斗需要新用户注册订阅才能访问你的产品或服务。一旦订阅结束，用户将不再能够访问您的产品或服务。这种漏斗是让新客户承诺定期使用你的产品或服务的好方法。
最后一种用户漏斗是一次性购买漏斗。这种类型的漏斗允许新用户直接购买你的产品或服务。不需要用户做出任何承诺，只要他们愿意，他们就可以使用你的产品或服务。这种漏斗是吸引新客户进行一次性购买的好方法。
提高顾客满意度的 7 个技巧
- 保持你的用户漏斗简单和用户友好
- 让新顾客轻松找到他们想要的东西。
- 提供良好的第一印象，创造品牌知名度
- 提供卓越的客户服务
- 客户支持了解他们的需求创造忠诚的客户
- 积极主动地创建持续的教育内容，在他们的客户之旅中为他们提供支持。
- 对客户保持表示赞赏
最后的想法
用户渠道是增加销售额的好方法。通过了解用户如何与你的产品互动，你可以设计一个引导他们购买的漏斗。用户渠道也可以用来接纳新用户。通过向新用户展示你的产品的最重要的特性，你可以帮助他们开始并增加他们继续使用你的产品的机会。用户漏斗可以用许多不同的方式来设计。重要的是考虑用户的旅程，以及每一步你想让他们做什么。通过设计一个用户漏斗，你可以让用户更有可能采取你希望他们采取的行动，这可能会带来推荐和品牌知名度。
总的来说，用户漏斗是提高客户满意度的好方法。通过为用户提供一条清晰的路径，你可以帮助他们更容易地实现他们的目标。这可以为您的客户带来更好的体验，最终让客户更加满意。
通过 Kong API Gateway 使用人工智能支持的 API 分析
原文：https://www.moesif.com/blog/technical/kong/Using-AI-Powered-API-Analytics-with-Kong-API-Gateway/
Kong 是一个流行的开源 API 网关，可以帮助你管理你的 API。有了 Kong，即使您有多个微服务，您也可以从一个集中的位置处理身份验证、速率限制、数据转换等事务。Kong 的核心是 NGINX，这是最流行的 HTTP 服务器之一。
由于是开源的，Kong 很容易在内部部署，除了 Postgres 或 Cassandra 商店之外，不需要安装许多组件。事实上，你可以在几分钟内完成跑步。
Moesif 在 Kong hub 中有一个插件，可以让你了解 API 的使用情况并监控你的 API 流量。像谷歌分析一样，Moesif 是一项托管服务，因此您不必担心维护大型数据管道和数据存储，同时获得类似于 Mixpanel 或谷歌分析的洞察力。借助 Moesif，您可以了解 API 的使用方式和用户，确定哪些用户遇到了集成问题，并监控需要优化的终端。
概观
Moesif Kong plugin 是一个代理，它收集指标并发送给 Moesif 收集网络。这使您能够全面了解 API 的使用情况，即使是跨不同的 Kong 实例和数据中心区域。Moesif 建议对在 Kong 配置的所有服务和路由使用相同的 Moesif 应用程序 Id。但是，建议对每个隔离环境使用单独的 Moesif 应用程序 id，例如生产和开发环境。
装置
要安装插件，安装 Lua Rock，然后启用插件:
luarocks install --server=http://luarocks.org/manifests/moesif kong-plugin-moesif
您可能需要更新您的 kong.conf，方法是将 moesif 附加到 plugins 字段(如果是旧版本的 kong，则为 custom_plugins)。确保该字段未被注释掉。
plugins = bundled,moesif # Comma-separated list of plugins this node
# should load. By default, only plugins
# bundled in official distributions are
# loaded via the `bundled` keyword.
现在插件已经安装好了，启用插件。
curl -i -X POST --url http://localhost:8001/plugins/ --data "name=moesif" --data "config.application_id=Your Moesif Application Id";
一旦你启用了 Moesif 插件，数据应该开始出现在你的 Moesif 仪表板上。下面，我将按照请求User-Agent来分组 API 的使用情况。我们可以看到 Node SDK 是这个 API 最流行的 SDK。
插件如何工作
该插件在本地捕获指标，并在您的本地 Kong 实例上对它们进行排队。这使得插件能够在不影响应用程序的情况下将指标数据带外发送到 Moesif 收集网络。关于设计 SDK 的最佳实践，请看这篇文章。
该插件是开源的，可以在 GitHub 上获得。
支持的功能
使用 Moesif SDK 时可用的大多数功能在使用 Kong 插件时也是可用的。具体来说:
服务/路线检测
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。类似地，如果您将 Kong 用于 GraphQL API，这也是受支持的。
地理分段
Kong 插件将从 NGINX 捕获 IP 数据，以及计时指标，以启用地理热图和过滤，如下图所示，显示用户体验到的延迟超过 1 秒。
用户会话
如果您为 Kong 配置了身份验证，Moesif Kong 插件将自动捕获经过身份验证的凭证，对此不需要进行任何配置。捕获会话信息使得 Moesif 能够生成 API 会话跟踪和用户配置文件以及关于用户第一次看到时间、用户最后一次看到时间等信息。
您可能会发现添加用户人口统计信息(如客户电子邮件和名字)非常有用。只要您拥有用户的 API 密钥/会话令牌，您就可以使用任何 Moesif API 库在任何时候添加/更新用户配置文件元数据。
这使您能够为您的 API 消费者之一调出完整的客户旅程。您将看到客户的人口统计信息以及他们进行的任何 API 活动。
因此，Moesif 能够执行更高级的用户群组分析，这允许您跟踪 30 天的活动保留时间。保持率衡量的是一群人中再次使用你的产品并保持活跃的用户的百分比。对于您的产品，什么被认为是有效的取决于产品的类型。对于流媒体移动应用程序来说，在某一天活跃可能意味着播放一首歌曲。对于一个支付 API，它可以在一天中处理一次信用卡支付。
传入和传出 API
Moesif Kong 插件可以用于你自己的 API，也可以用于你所依赖的合作伙伴的 API。这对于了解合作伙伴的基础架构发生了什么以及了解任何问题非常有用。只要流量流经您的 Kong 实例，Moesif 就可以对其进行分析。
结论
通过这种方式，该插件将捕获 API 请求和响应，并记录到 Moesif，以便通过 Kong 和处理应用程序周围所有其他服务的 Kong 轻松检查和实时调试您的 API 流量。
在 Moesif 中使用事件标签
原文：https://www.moesif.com/blog/technical/api-analytics/Using-Event-Tags-In-Moesif/
有时，您可能希望将相关的事件分组在一起，或者希望给事件起一个友好的名称。如果您想要将一组 API 调用合并到一个 API 产品中，这一点尤其正确。幸运的是，有了 Moesif，你就可以做到这一点，这样一组事件就可以作为一个单元来看待，就像 SKU 一样。在 Moesif 中，这可以通过使用事件标签特性来完成。
创建事件标签
创建事件标记的第一步是导航到实时事件日志屏幕。这可以通过转到 +新按钮并选择实时事件日志来完成。
一旦在实时事件日志屏幕上，我们可以确定我们的标签的过滤器。在本例中，我们将筛选两个相关的端点。将两条路由添加到过滤器后，我们现在可以创建标记了。点击创建标签按钮。
然后会出现一个显示标签过滤器的模式。我们将为标签键入一个名称， Categories API ，然后点击创建“Categories API”。
最后，您将点击创建标签按钮。
现在，标签已经创建好了，可以在 Moesif 中使用，这样就可以使用一个标准来查看事件。
更新标签也会更新旧事件。但是，这可能需要几分钟时间。您可以从标签管理器中查看标签的处理状态。
使用事件标签
使用事件标签可以像任何其他属性一样使用。一个很好的例子就是在实时事件日志查询中使用标签。不必指定端点，只需指定包含与标记匹配的事件。下面是该过滤器的外观和输出的快速演示。
您还会注意到，条目还会显示它们所属的标签。每个条目都显示了类别 API 标签。
类似地，您可以像任何其他属性一样按标记名分组。下面我们可以看到每个 API 的流量。这有助于在创建计费表时将您的端点组织到 API 产品中。
访问和编辑现有标签
要编辑现有标签，您可以通过标签管理器访问它们。这可以通过 Moesif 中屏幕底部的设置菜单来访问。
点击后，您将能够看到以前创建的标签，编辑它们，并删除它们。
要编辑标签，只需点击条目末尾的省略号按钮，然后点击编辑。
然后会弹出一个模式，允许您编辑标签的过滤器。完成后，点击保存按钮。
要删除不想再使用的标签，只需点击条目的省略号按钮，然后点击删除。
然后会出现一个模式来确认删除。点击是删除标签。
从 OpenAPI 规范生成标签
在标签管理器屏幕中的另一个可用特性是基于您的 OpenAPI 规范自动创建标签的能力。为此，只需上传或拖放您的 OpenAPI 规范，标签就会自动生成。
包扎
这就是创建标签的全部内容，这样您就可以在一个标签下将事件指标组合在一起。无论是试图更容易地查找相关事件，还是将 API 产品的概念添加到您的指标中， Event Tags 都是实现这一点的好方法。
还没用 Moesif？轻松创建账户并在几分钟内将 Moesif 与您喜爱的编程语言或 API 管理工具集成。立即试用 Moesif 和事件标签，释放 API 和产品分析的力量。
使用 Moesif 和 Stripe 进行现收现付的 API 计费
为客户提供多种支付产品的方式，可以提高灵活性和便利性。一般来说，客户为使用付费有两种方式:后付费和预付费。预付费有时也被称为 PAYG，或现收现付。
如果客户没有密切跟踪他们的使用情况，后付费使用有时会导致计费意外。这可能给这些用户带来麻烦，也可能给服务提供商带来问题。结果可能是由于客户无法支付账单而导致客户流失和收入损失。使用后付费也有很多积极有用的情况。你现在使用的许多服务可能是后付费服务。
预付费或 PAYG 服务可以让用户更加放心。本质上，用户将购买信用，当这些信用被使用时，他们对服务的访问被切断。这对于预算和确保账单不会随着使用而飙升非常有用。这种方法允许团队预先支付他们的账单，这对服务提供商来说非常好，因为他们知道使用收入是有保证的。
Moesif 的最新计费功能可以支持这两种使用情况。如果你不熟悉 Moesif 中的计费表，你可以在这里查看更多关于它们的细节。我们将使用*台中的一些功能来实现 PAYG 流。
-
1 -我们将建立一个用户群组,其中包含没有信用的用户
-
2 -我们将建立一个治理规则,阻止没有信用的用户
-
3 -我们将建立一个行为电子邮件，让用户知道他们没有信用了
让我们来看看如何在 Moesif 中实现 PAYG 货币化方案。
先决条件
为了实现上面的 PAYG 流，我们需要做一些事情。这包括:
- 主动Moesif-条带集成
- 您需要配置并激活 Moesif 和条带集成。
- 有源计费仪表
- 一旦条带集成处于活动状态，您还需要确保设置了一个活动的计费表。
创建定制仪表板，监控整个 API 客户群的消耗和成功指标。T3】
建立队列
要在 Moesif 中设置群组，您将使用左侧的导航导航至用户屏幕。
然后，我们将为该群组创建过滤器，以便如果他们在条带中的余额大于或等于 0 。
在 Stripe 中，负余额表示用户有可用的信用。余额以美分表示。因此，拥有 100 美元信用额度的用户将在条带数据中显示为-10000。
我们的过滤器将如下所示:
这就是我们建立群组过滤器所需要的。我们的下一步是创建群组。为此，我们将点击屏幕右上角的创建群组按钮。
然后，您将看到一个模型，允许您命名群组(如果您愿意，还可以设置群组通知)。输入群组的名称，并点击模式右下角的创建群组按钮。
之后，系统会提示您使用新创建的群组。在模式的下一个屏幕上，选择创建治理规则。
这将把您带到治理规则屏幕，您可以在这里创建规则。
利用 Moesif 将新用户集成到您的*台并快速解决问题。T3】
设置治理规则
对于治理规则，我们将看到我们新创建的群组已经添加到了 Apply To Users 字段下。我们还需要确保阻止复选框被选中，覆盖响应状态应该被设置为 402 需要支付，并且覆盖响应主体下拉列表应该被设置为合并标签，并且应该在文本输入中填充一条 JSON 错误消息。
然后点击右上角的创建。
创建之后，您需要确保通过在上将规则切换到来启用规则。
启用规则后，您需要点击屏幕右上角的保存。
您的治理规则现在将被激活。
该规则可能需要几分钟才能生效。如果规则没有立即生效，给 Moesif 15 分钟来传播规则并使其生效。
设置行为电子邮件
为了主动让用户知道他们已经用完了信用，我们还将通过群组向他们发送一封行为电子邮件，这与治理规则的触发方式相同。
为此，我们将单击左侧导航中的行为电子邮件菜单项。然后我们将点击创建模板。
对于这个例子，我使用 Sendgrid 作为 SMTP 服务器。关于如何设置的更多说明，请查看我们的博客。您需要设置您的电子邮件服务器，然后才能发送电子邮件。
点击创建模板后，系统会提示您想要设置的电子邮件类型。Moesif 提供了许多不同的“预装”选项供您选择，但就我们今天的目的而言，我们将选择空白。点击此按钮，我们将进入电子邮件设计界面。
在电子邮件设计屏幕上，我们将:
- 命名我们的电子邮件
- 选择我们的团队来触发电子邮件(我们之前创建的那个)
- 添加我们的主题行
- 从地址添加我们的，并且可选地，从名称添加我们的
*** 选中循环工作流的复选框* 将字段后符合重新注册条件的**设置为“1 小时”****
**下面是配置完成后的外观示例。
接下来我们将关注模板本身。我们将单击添加行按钮，开始向模板添加一些元素。
然后，我们将点击添加内容。
接下来，我们将从右侧菜单中拖放一个文本元素到模板上。
单击新添加的文本元素。我们将开始在其中输入我们的电子邮件内容。这样我们可以添加一个更加定制化的感觉，我们将在编辑器中点击合并标签，并选择的名字。
我们完成的电子邮件看起来将如下所示。然后，我们将单击 Test 向我们的帐户发送一封测试电子邮件，以验证电子邮件配置是否一切正常。最后，我们将点击创建来实际创建电子邮件。
一旦你回到行为电子邮件菜单，你也要确保在是活跃的栏中的电子邮件是打开的。您可以使用滑块在状态之间切换。
群组、治理规则和电子邮件现在都已经设置好了，可以进行测试了。
使用 Moesif 降低分析成本——零维护，不影响性能。T3】
测试设置
测试设置很容易做到。首先，我们将登录 Stripe，选择一个客户，并给他们一些积分。
然后，我们可以为这个用户发送一个请求，并看到在 Postman 中返回一个 200 OK 响应。
然后，我们将从该用户的 Stripe 中扣除点数，使他们的余额为 0 美元。
然后，用户将被添加到 Moesif 群组中。
值得注意的是，由于 Moesif 的工作方式，成员加入群组或从群组中移除可能需要几分钟时间。如果表格右侧有一个黄色警告标志，则用户尚未同步到群组中。如果是绿色支票，则用户已成功同步到群组。
然后，我们将再次发送一个用户没有信用余额的请求。然后，Moesif 将阻止该呼叫，并向用户返回一个 402 付款要求。
这将有效地阻止用户使用 API，直到他们将更多的信用添加到他们的 Stripe 帐户。
最后，用户还应该收到我们之前创建的“资金不足”电子邮件。会被接收到，看起来像这样:
这样，我们就可以确认我们的 PAYG 货币化计划完全有效。现在，用户将被要求为他们的账户充值，以便使用 API，并且还会收到电子邮件通知他们。
当然，为了根据您组织的需求定制它，还需要考虑许多其他因素。您可以为您的治理规则设置一个最低信用阈值，其中用户必须拥有大于 10 美元的条带信用才能使用 API，或者类似的东西。您还可以在客户达到 0 余额之前通知他们，以确保他们不会暂停使用并导致其应用程序的服务中断。
试试吧！
想为您的 API 和应用尝试 PAYG 计费或后付费计费吗？立即注册moes if，开始使用计费表、行为电子邮件、治理规则和强大的分析，开箱即用。Moesif 是满足您所有货币化需求的“一站式商店”，我们支持越来越多的支付*台，包括 Stripe 、 Recurly 和 Chargebee 。**
使用 Moesif 的实时事件日志来过滤和检查 API 调用和事件
如您所知，事件日志是操作系统和其他软件中的常见功能，用于跟踪系统和应用程序错误。当你有 API 流量要跟踪，或者有前端动作要观察的时候，使用 Moesif 的 实时事件日志 是一个简单的过滤和查找你需要的数据的方法。在本文中，我们将回顾一下实时事件日志的基础知识，包括如何过滤您想要的数据，您可以对日志执行的不同操作，以及如何使用它们进行故障排除和调试。
什么是实时事件日志？
Moesif 中的实时事件日志是所有应用程序或服务中发生的 API 事件和动作的实时运行记录。实时事件日志允许您过滤收到的 API 调用和动作中的特定属性。实时事件日志为您提供了一种简单易用的方式，让您以用户为中心，深入了解您*台上的 API 使用情况和用户行为。
为什么要使用实时事件日志？
实时事件日志是一个非常有用的工具，可以实时跟踪网站或应用程序上发生的事情。使用实时事件日志可以帮助您排除错误，跟踪用户活动，并深入了解您的网站或应用程序的使用情况。
在查看传统日志时，搜索和过滤可能非常困难。Moesif 轻松支持极其简单或复杂的查询。Moesif 允许您基于日志中的数据构建查询，这样就不会有猜测。例如，如果您在一个端点上进行过滤，Moesif 将使用当前数据中包含的端点预先填充过滤器下拉列表。
Moesif 还支持主体和标题分析，这意味着您可以基于特定的主体字段及其内容使用 Moesif 过滤器。这种粒度级别是 Moesif 区别于其他 API 和产品分析*台的部分原因。
使用实时事件日志
既然你已经知道了 Live Event Log 是什么以及它的作用，那么让我们来看看如何在 Moesif 中使用它。虽然这不是一个你可以创建和使用实时事件日志的详尽列表，我们将向你展示一些创建和使用它们的常用方法。
要进入实时事件日志屏幕，点击新建按钮并选择实时事件日志。
如何创建过滤器
创建过滤器是查看实时事件日志屏幕中事件的最佳方式。一旦你进入实时事件日志屏幕，过滤器输入就会出现在顶部。
您可以通过各种 API 属性进行过滤，如 URI 路由、查询参数、HTTP 头和主体字段。您还可以根据事件是 API 调用还是操作进行过滤。动作在您的用户界面中显示客户的活动，如“登录”或“浏览指南”。
实时活动日志还允许您仅显示新用户和公司的活动。这可以通过使用“仅新用户”和“仅新公司”过滤器按钮来完成。
根据您要查找的数据，过滤器可能非常简单，也可能非常复杂。有关如何构建过滤器的更多信息，请查看我们的文档。
显示事件数据
您还可以自定义查看实时事件日志的方式。您可以查看来自现场事件日志的数据，作为流或表。流视图将每个 API 调用或动作显示为可点击的元素。
表视图以类似于电子表格的方式显示事件。
导出数据
Moesif 提供的其他功能包括通过浏览器下载事件或导出事件以在 Postman 中运行的能力。
要导出事件，选择一些事件并点击批量导出按钮。
然后，您将选择是否希望输出为 JSON、CSV 或 Parquet 格式以及要发送的电子邮件。一旦表格完成，点击开始导出按钮。
导出完成后，您将收到一封电子邮件，其中包含上一个模式中指定的电子邮件的下载链接。
对于 Postman，只需选择想要导出的 API 调用，然后单击屏幕顶部的 Run in Postman 按钮。
然后会提示你下载邮差合集。收藏将被保存，然后可以上传到邮递员。更多细节，请查看我们的文档，它显示了一步一步的程序。
使用 Diff 2 事件比较事件
有时比较两个不同调用的请求和响应是有意义的。当试图调试 API 调用中的问题时，这是一个常见的场景。您可能想要检查成功的调用和导致错误的调用之间的区别。要在 Moesif 中做到这一点，可以使用 Diff 2 Events 函数来比较两个 API 调用。
一旦选择了两个调用并点击了 Diff 2 Events 按钮，您将能够看到红色突出显示的文本显示已移除的更改，而绿色显示已实施的更改。
使用这一功能可以省去寻找差异的手工工作，并以易读的方式轻松地向用户展示。
将您的搜索保存到仪表板
一旦你可以创建一个你喜欢的实时事件日志过滤器，你可能想把它添加到 Moesif 的仪表板上。Moesif 让您可以选择保存并与您的团队成员或私下分享您创建的日志。要将现场事件日志保存到 Moesif 中的仪表板，点击保存按钮。
在出现的模式中，命名您的新工作区(您刚刚创建的实时事件日志)，选择您希望该工作区是私有的还是为您的团队所有，并选择您希望将其添加到的仪表板。
最后，单击模式底部的 save 按钮，将工作区保存到仪表板中。
将实时事件日志导出为公共链接或嵌入模板
如果您想将您的实时活动日志分享给无权访问 Moesif 的用户，包括您的客户，您可以使用公共链接或嵌入模板。
一个公共链接可以用于安全地与外部共享指标，或者在 iFrame 中静态嵌入图表。公共链接有一个不能更改的静态过滤器。要创建一个，点击实时活动日志屏幕顶部的分享按钮。
在出现的模式中，确保选择了公共链接。
从模式中获取链接或静态嵌入代码。
如果你想让用户调整一些过滤器，你可以使用一个嵌入模板。此功能允许您在面向客户的应用程序中嵌入动态图表。可以创建动态字段(如经过身份验证的用户)来限制数据访问。要创建模板，点击实时事件日志屏幕顶部的嵌入按钮，并选择创建模板。
在这里你可以添加你的沙盒策略，然后点击获得嵌入代码。
现在，您可以将生成的代码嵌入到您的应用程序中。
尝试一下
Moesif 的实时事件日志对企业和开发者来说都是非常有用的工具。我们希望这份指南能让你更好地理解 Moesif 的实时事件日志是如何工作的，以及它的一些最有用的特性。无论您只是想要一种简单的方法来分析*台上发生的每个事件，还是试图对您的应用程序和 API 进行故障排除，实时事件日志都是不可或缺的工具。要亲自体验现场活动日志，请登录至 Moesif 或立即注册开始体验。
使用货币化堆栈来分析和规划游戏收入
DARPU 和货币化栈的一个例子
人们衡量一款游戏(或其他产品)的关键指标之一被称为 DARPU(通常只是 ARPU)，即每用户日*均收入。取决于游戏的类型，以及游戏的优化程度，ARPU 可能会有很大的不同。将货币化堆栈视为对 ARPU 有贡献的功能/类别的分解。
我们来看一个因果街机游戏的例子。它有 6 美分的 ARPU。在下面的图表中，我们可以看到每个功能对总收入的贡献。广告是不言自明的。游戏有能量，哪种像生命，哪种在这个游戏里玩出水*都是需要的。在你不得不购买能量/生命来继续尝试之前，它限制了你可以失败的次数。这款游戏也有游戏前的能量补充，这意味着当你选择一个级别玩时，你有机会购买能量补充(想想《糖果粉碎传奇》中的“彩色炸弹”、“水母”和“条纹包裹”)。此外，该游戏提供了游戏内的电源，这意味着当你在游戏过程中，你可以购买额外的电源(想想《糖果粉碎传奇》中的“棒棒糖锤”)来帮助你。该游戏还提供了继续当你没有通过水*，并得到一个机会，继续玩，以击败水*。在这个游戏中，这些功能都贡献了不同的数额。
研究和计划:
在你的游戏发布后，你可以获得真实的盈利数据，但即使在你开始设计游戏之前，你也需要考虑你的筹码最有可能是什么样子。当你推销一款游戏时，你经常会被问到这个问题:你如何赚钱？货币化堆栈可以帮助你回答这个问题。
根据你正在开发的游戏的类型，赚钱的筹码会有所不同。卡牌游戏(例如 Ayakashi，巴哈姆特之怒)或 4X 游戏(例如霍比特人或卡米洛特王国)的货币化堆栈将与投资和快速游戏(例如 Farmville)或街机游戏(例如糖果粉碎)非常不同。同一个游戏在不同的*台(web vs. iOS vs. Android)或不同的市场(中国 vs .美国)可能有不同的 ARPU，但通常情况下，货币化的比例看起来还是一样的。
虽然在每一个类型中，不同的游戏会赚取不同的金额，但是如果你在这个类型中观察足够多的游戏，模式就会出现。
每个流派中的最佳游戏将在同一市场的同一*台上实现相同范围的盈利。有经验的游戏制作人或产品经理通常会知道对于某一类型的游戏来说什么是好的 ARPU。例如，最佳街机/休闲游戏在 iOS 上的 DARPU 值可能在 6-8 美分之间。
更深层次的分析和研究将揭示每个主要功能/类别对货币化堆栈的贡献。这里，往往也有格局。这仍然是一个估计，但是你会感觉到一个相似的特性会给 ARPU 带来多大的贡献。例如，广告通常会将 1 美分归因于 ARPU。在许多街机游戏中，如《糖果粉碎传奇》，“继续”将比游戏中的能量增加更赚钱，这反过来将比游戏前的能量增加贡献更多的收入。Continue 机制特别强大且经过验证，通常会贡献 50%到 60%的 ARPU。(虽然我不知道 CCS 的确切数字，也不能透露我管理的游戏的确切货币化堆栈，但我做过足够多的街机游戏，知道这是一个很好的估计。)
根据你的研究数据，你可以创建你计划的货币化堆栈，更自信地回答你将如何赚钱的问题，并证明这些数字是正确的。
堆栈如何影响设计考虑:
在您的规划阶段，货币化堆栈(即使只是一个估计或目标)将帮助您优先考虑功能。甚至可能放弃一些功能。举例来说，如果我们知道游戏中的能量提升通常比游戏前的能量提升更赚钱，也许更多的想法应该放在“游戏中的能量提升”上。
如果你知道在大多数街机游戏中，继续机制是收入的主要来源，那么思考继续在你的游戏中意味着什么是很重要的。对于糖果粉碎传奇，这是额外的举动；对于 Ruby Blast，这是额外的时间。对于其他游戏来说，可能不是很直接。这将需要获胜条件的设计(击败一级意味着什么)来适应这种机制。在游戏设计(尤其是获胜条件)出炉后，再想尝试添加这个就难多了。我看到很多因果/街机游戏没有这个功能，那么他们是把钱留在桌子上。
游戏启动后，货币化堆栈可用作诊断工具。例如，如果你的 ARPU 不如同类游戏高，那么你可以通过数据查看你的实际盈利情况。通常你会发现一个类别的贡献没有预期的多，或者没有竞争对手的多，也许这个功能设计得很糟糕。这将有助于您集中资源修复这些功能。它还可能会显示你的货币化堆栈与其他游戏的货币化堆栈之间的差距。您可以尝试通过添加正确的功能来缩小差距。
警告:
-
蚕食效应:我们不能期望不断增加货币化功能，并期望收入不断增加。举个例子:如果特征 A 贡献了 1 美分，但是特征 B 贡献了 0.5 美分。实现功能 A 和功能 B 不一定会总共贡献 1.5 美分。
-
ARPU(和盈利栈)只是一个衡量你游戏好坏的标准。不要忽略其他指标，如保留率。有时候这是一种交换。当你收紧夹点，你增加了 ARPU，但有时你减少了保持力。
结论:
1.在计划阶段/推介阶段，使用货币化堆栈作为工具来回答你如何在 F2P 游戏中赚钱并设定目标的问题。做研究，找出其他游戏的盈利情况。
-
在游戏设计/制作阶段，使用货币化堆栈来帮助指导您的功能优先级并确定最佳解决方案。
-
游戏推出后，使用货币化堆栈作为衡量标准，看看你如何与竞争对手和你的目标相抗衡。
笔记
此外，我写的这篇和其他几篇关于货币化的文章发表在 gamasutra 上。
使用 Sendgrid 和 Moesif API Analytics 发送行为电子邮件
在本指南中，您将学习如何使用 Sendgrid 发送 Moesif 行为电子邮件。
Moesif 行为电子邮件是一项根据客户的 API 使用情况自动向客户发送电子邮件的功能。这可用于通知客户有关技术问题，如达到速率限制、使用废弃的 API 或集成中断。您甚至可以使用它来触发与业务相关的事件，比如某个商品何时发货。如果某个东西可以映射到一个 API 调用，那么你可以从它发送一封电子邮件。
在的配套文章中，我们介绍了如何在 Moesif 仪表板中配置行为电子邮件。
Sendgrid 是一项托管电子邮件服务。他们提供了一个 API 来向你的用户发送电子邮件，并为你托管 SMTP 服务器。
先决条件
该操作指南需要一个 Moesif 账户和一个 Sendgrid 账户。
设置电子邮件服务器
设置电子邮件服务器的第一步是从 Sendgrid 获取 SMTP 凭证。
为此，您必须登录到 Sendgrid 仪表板。
下面的屏幕截图说明了如何导航到凭据。
这将启动一个向导，引导您完成 Sendgrid API 密钥的创建，为您提供 SMTP 凭证，并测试一切是否按预期工作。
API 键需要一个名称来创建。生成的 API 密钥将是您的 SMTP 密码。
这些凭证必须输入到 Moesif 电子邮件服务器配置表中。
要导航到该表单，请遵循下一个屏幕截图中的步骤。
您可以将凭证从 Sendgrid 站点复制并粘贴到 Moesif 站点。
如果 SSL 端口有问题，可以使用端口 587。
Moesif 表单如下所示:
测试设置
然后，您可以使用 Moesif 通过新配置的 SMTP 服务器发送一封示例电子邮件。
配置完邮件服务器后，您必须创建一个新的电子邮件模板:
对于新模板，您必须填写必填字段:模板名称、主题行和发件人电子邮件地址。
在 Sendgrid 控制台中按 verify integration，Sendgrid 将等待您发送测试电子邮件。
之后，点击 Moesif 网站上的“测试”按钮，输入目标电子邮件。
然后，Sendgrid 控制台将确认 SMTP 连接工作正常。
摘要
用 Sendgrid 设置 Moesif 行为邮件只需要几分钟。
使用像 Sendgrid 这样的服务可以缓解发送电子邮件时可能出现的许多常见问题，例如验证问题和电子邮件被错误地识别为垃圾邮件。
通过将 Moesif 的行为电子邮件服务与 Sendgrid 相结合，您能够让您的 API 消费者及时了解重要的问题。
使用时序图探索 API 的使用
深入研究 API 和产品分析的一个主要原因是为了能够轻松识别数据中的趋势。当然，在查看像原始 API 调用日志这样的东西时，趋势可能很难看到，但是在查看旨在方便您可视化趋势的图表时，趋势可能会容易得多。进入时间序列图。
时间序列图着眼于特定时间间隔内的趋势。你可能在日常生活中熟悉这些类型的图表。举例来说，显示标准普尔 500 指数每月*均回报率的图表通常显示在时间序列图中。想象一下，如果您可以用这种类型的图表来显示 API 指标，如调用量、*均延迟，甚至是更以业务为中心的指标，如每天或每周新加入的用户数量。有了 Moesif 时间序列功能，你就可以做到这一点。
什么是时间序列？
在 API 和产品分析环境中，时间序列分析允许您查看特定时间段内 API 流量的总体趋势。一般来说，时序图是一种显示数据集的方式，该数据集测量一段时间内的一些量。时间序列图表用于统计学、信号处理、计量经济学、数学建模以及许多其他用途。
使用时间序列的好处
使用时间序列报告来显示 API 使用情况有很多好处。时间序列数据的好处是随着时间的推移易于收集和跟踪。使用时间序列图表是直观识别趋势和轻松比较历史数据的好方法。另一个好处是，时间序列图表还可以帮助公司识别未来可能的趋势，因为它可以直观地预测趋势的走向。
在 API 和产品分析的背景下，时间序列图表也是向那些不太懂技术的人显示数据的一种简单方式。不像其他类型的报告可能需要一些技术知识来解读，时间序列报告的视觉特性使其易于理解。
可以为不同的时间段创建时间序列，例如每小时、每天、每周、每月或每年。这允许您比较不同时间段的使用情况。这可以帮助开发人员规划未来的流量，并优化他们的 API 性能。这些信息可用于改进 API 设计、优化性能和解决问题。此外，时间序列可用于跟踪客户满意度或监控 SLA(服务水*协议)。
如何创建时间序列图表
用 Moesif 创建一个时间序列图表极其简单。第一步是导航到时间序列屏幕，这可以通过点击新按钮并选择指标选项下的时间序列来完成。
一旦你进入时间序列屏幕，你就可以根据你想要在时间序列图表中追踪的数据建立过滤器。Moesif 允许用户通过解析您的数据轻松构建过滤器，从而提高效率。
例如，您可能希望显示时间序列数据，以显示用户遇到的 404 -未找到错误的趋势。为此，您可以为response.Status Code = 404 Not Found添加一个过滤器。下面是输入到 Moesif 后的样子。
如果您想在事件标准中更加具体，您还可以选择通过选择 + Where 按钮来过滤多个事件，并添加额外的标准。
结果将显示如下，使用条形图样式。Moesif 能够适应几乎无限复杂的过滤，因为您可以添加的额外的 where 子句的数量没有限制。
如果您在实时 API 日志中过滤事件，相同的过滤器将用于过滤时间序列图表。更多细节，请查看我们的文档。
时间间隔如何与时间序列图一起工作
Moesif 将通过匹配时间间隔的底部和顶部来对齐时间间隔。你可以通过转到应用和团队设置来更改你的全球时区。默认情况下，浏览器自己的时间被用作时区，但您可以根据需要对此进行任何更改。Moesif 始终与日历时间间隔保持一致，因此最后一个时间间隔可能不会被完整报告。例如，如果当前时间是下午 5:55，并且您选择了“每日”时间间隔，则最后一个时间间隔将只包括从上午 12:00 到下午 5:55 的数据。这种不完整的时间间隔通常会在时间序列上显示为虚线，表示该时间间隔没有完整报告。
添加分组以获得更深入的见解
Moesif 时间序列图表也支持 Group By 功能。使用 Group By 允许您根据特定标准对数据进行分组。这可能是按照Response.StatusCode、Company Domain、UserId对数据进行分组的方式，甚至是类似于Initial UTM Source的方式。下面的图表显示了一个时间序列，它由Response.StatusCode为每个对 /login 端点的 API 调用进行分组。这可以帮助用户看到特定响应的趋势，并帮助团队了解如果趋势是负面的，例如错误状态代码的高发生率，如何潜在地解决问题。
如果图表上的线条太多且变得拥挤，您可以在图表下方的图例中选择一个时间序列分组指标的名称，以显示或隐藏整个线条。当在时间序列图表中绘制了大量的数据和线条时，这将非常有用。
如何在时序图中使用 API 指标
除了event count之外，您还可以绘制其他指标。您可以从预定义的指标中进行选择，也可以根据自己的数据需求创建自定义指标。有多种选项可供选择:
- 事件累积
- 唯一用户
- 独特的公司
- 唯一会话/API 密钥
- *均延迟
- 最大延迟
- P90 潜伏期
- 请求人数
- 死亡人数
- 总计请求内容-长度
- 自定义指标
数值型或有日期的字段将显示数据字段的最小值、最大值和*均值以及不同的值。字符串类型的字段将只显示不同的值。
例如，添加自定义指标允许您在图表上使用多个指标。这可以使用指标下拉菜单中的自定义指标选项来完成。此外，您可以通过再次单击按钮 + Add Metric 在图表上添加多个指标。
如何更改图表样式
时间序列图表可以使用三种不同的样式呈现，条形、线形或表格。
点击时间序列的左上方，获得条形图、折线图或表格视图。
您还可以使用以下选项查看您的数据:日志标度(Log Scale)、、【百分比分解】、、和添加标记(Add Marker)。
百分比分解绘制每组的计算值与每个区间所有组的总和。增长率从第二个间隔开始，绘制与之前间隔相比的计算值。添加标记允许您通过添加线条与图形进行交互。
保存您的图表
保存到 CSV
如果您只是想提取绘制的数据，Moesif 提供了通过 CSV 文件下载当前事件的选项。
\
如果您正在下载所有术语，我们建议使用批量导出功能来获取这些数据。
将作品保存为公共链接或嵌入模板
Moesif 允许你以多种方式保存你的工作。
- 私人的
- 组
- 公共链接
- 嵌入模板
要创建一个，点击时间序列仪表板顶部的共享按钮。
要创建私有工作空间，在将出现的模式中确保选择了私有。然后，您可以命名您的新工作区，并选择您想要将它添加到的仪表板。最后，点击模式左下方的保存按钮，将工作区保存到所选仪表板。
要创建一个与您的团队共享的工作区，步骤与创建一个私有仪表板非常相似。确保选择了团队，命名您的工作区，并将其添加到所需的仪表板中。确保点击保存将您的工作区保存到仪表板。
公共链接
公共链接可用于安全共享指标。一个公共链接允许你在 iFrame 中嵌入图表。要创建一个，点击时间序列日志屏幕顶部的分享按钮。
点击获取共享链接生成链接，嵌入到你需要的地方。
嵌入模板
使用嵌入式模板，您可以将动态图表嵌入到可定制的布局中。如果是更复杂的数据可视化，动态字段将允许您将数据限制在您授权的范围内。
要创建模板并将其嵌入到应用程序中，点击时间序列屏幕顶部的嵌入按钮，然后选择创建模板。
默认情况下，标题和正文是私有的，但是如果您需要基于这些字段进行过滤，您可以更改设置。值得注意的是，所有使用该模板的客户都会看到应用于数据的相同过滤器。
通过 API 访问
借助嵌入式模板，您可以为客户定制应用程序。例如，您可以创建一个按钮，通过在动态字段中输入数据来生成图表。
通过使用 read:events 范围生成管理 API 键，您可以获得以下数据，并订阅管理 API。在下面的命令中替换 YOUR_MANAGEMENT_API_KEY 并执行。
通过 API 访问数据可以允许更复杂的定制。如果复杂的定制不是你所追求的，最简单的方法将是利用嵌入式模板来代替。
创建警报
对于希望监控并主动采取措施让客户满意的用户来说，警报规则是一项重要功能。例如，您可能希望在大量客户的流量减少或延迟增加时收到警报。您可以使用警报规则来监控您创建的 API。此处为预警的单据
导航至时间序列屏幕右上角的警报。
您应用的过滤器将在屏幕右侧的警报选项卡中弹出。
Moesif 为您提供了创建动态警报或静态警报的选项。动态警报寻找与 API 使用相关的峰值和趋势，而不是寻找预先确定的阈值。
静态警报允许您在端点达到每小时 1，000 次呼叫时接收通知。当这种情况发生时，通知将被发送到预定的通道。
设置您的新渠道模式
如果 Moesif 检测到一个潜在的问题，它会通过电子邮件或您配置的任何应用程序通知您。如果您想为警报配置一个新的目标，您可以通过添加另一个通道来完成。要添加新频道，请点击警报面板上的新频道。
然后填写字段并选择您希望将警报发送到哪个频道。最后，点击保存保存详细信息并创建频道。
新创建的频道可以添加为新的和现有警报的频道。
试试吧！
为了亲自试用时间序列功能，今天就登录或注册，开始使用 Moesif！
API 的虚荣心指标与跟踪 API 交易的商业价值
作为一名 API 产品经理，您希望您的 API 拥有出色的开发人员体验。这意味着开发人员可以快速启动并运行，他们可以从您的 API 获得一致的行为，他们可以很容易地解决他们遇到的任何错误，您的 API 可以让他们轻松地解决他们的业务需求。
跟踪您的 API 是了解它们性能的一个重要部分，这导致大多数组织建立他们自己的内部 API 跟踪系统。虽然这种方法对一些组织有效，但对组织来说，错误地跟踪度量标准更为常见。跟踪错误的指标会导致对 API 的错误理解。
在这篇博文中，我们将探讨一些公司在开始定义和收集开发人员如何使用 API 的数据时面临的常见陷阱，以及您和您的团队如何关注真实的、可操作的指标，而不仅仅是虚荣的指标。
为什么内部 API 分析工具没有击中目标
一些组织更喜欢构建自己的 API 分析工具，并在内部跟踪指标。当组织为 API 指标构建自主开发的分析工具时，他们会遇到某些导致不准确指标的陷阱:
- 为 API 重建网站分析
- 构建产品和构建分析工具之间的权衡
- 报告看起来最成功的指标的压力
- 未能恰当地衡量 API 事务
对于产品团队来说，将他们用于网站分析的工具重新用于 API 分析是很常见的。这种方法通常将 API 调用视为等同于站点视图，将流行端点视为流行页面的类似指标，并且没有分析开发人员体验的方法。
例如，传统的 web 分析将导致在端点或呼叫量级别的报告，而这很少是重要的。有时，响应中更详细的信息会讲述一个更好的故事。或者，聚合额外的请求和响应元数据可能比使用单个 API 端点更重要。
当你试图让你的 API 适应现有的分析工具时，你可能会误解结果。例如，一个组织可能会错误地认为他们收到了许多 API 调用，因为他们的 API 很受欢迎。真实的情况可能是，访问它的开发人员经常遇到错误，或者当开发人员可能与您的端点进行更少但更长的对话时，某些端点不受欢迎。如果你的内部开发团队没有构建 API 度量工具的经验，他们可能不是构建 API 分析软件的合适团队。
除非你有无限的工程资源，否则当构建 API 分析工具的问题在内部出现时，它总是意味着将开发人员从开发你的业务所关注的产品转移到 API 分析工具上。我们已经讨论过，如果您的开发团队没有构建 API 分析工具的经验，这是多么不理想，还有一个额外的缺点是，由于开发人员专注于其他项目，所以花在构建您的产品上的时间更少。您的开发人员也很可能更喜欢关注您的产品，而不是构建分析工具。构建内部分析工具给开发团队带来了不同类型的压力。
不要相信虚荣的衡量标准
当内部团队不得不构建 API 分析工具时，他们也经常承受着为 API 报告良好指标的压力。没有人想成为坏消息的传递者，许多组织会要求他们的内部指标团队提供好的指标报告，以激励他们的同事，向投资者验证他们的成功，并出于营销目的共享数据。这是导致高技能开发团队报告虚荣度量的原因。他们面临着非故意的，但迅速增加的压力，要报告看起来不错的指标，这导致他们关注看起来令人印象深刻但没有反映他们的 API 实际上有多成功的指标。
尽管分享一个无意义的曲棍球棒图可能很诱人，但随着时间的推移，有比 API 请求更有用的指标，除非您可以将调用直接与收入联系起来。相反，考虑 API 的整体健康和成功，例如延迟的改善如何影响开发人员的体验。
许多组织定义了错误的成功度量标准，这使得他们对他们的 API 如何成功地实现他们的目标产生了错误的想法。虚荣心指标很容易创建，在为开发人员构建的产品中尤其常见。为开发人员构建的产品和服务通常关注开发所花费的时间，或者首次用户的数量和提供的 API 密钥。像这样的指标不能告诉你任何关于你的 API 的开发者体验，你的 API 为开发者创造了多少价值，或者你的 API 与你公司的更广泛的目标有多一致。
将 API 事务与业务价值联系起来
既然我们已经讨论了内部 API 分析工具的挑战以及它们如何导致虚荣心指标，那么让我们来看看应该关注哪些指标，以便您可以了解您的 API 的性能以及它在多大程度上实现了您的业务目标。让我们先来看看 API 用户的开发体验。
你的 API 的开发者体验从他们注册使用它开始。你应该跟踪每个开发者的旅程，从他们最初的注册开始，到他们生成的第一个 API 密匙，接着是他们的第一个 API 调用和他们最早的 API 事务的长度和内容。这些数据为您提供了许多关于 API 开发人员体验的信息，包括:
- 开发人员开始使用您的 API 是多么容易
- 他们将它集成到项目中的速度有多快
- 乍一看，什么端点最有用
- 开发人员最容易遇到错误的地方
- 哪些开发人员需要支持
当开发人员在使用您的 API 时遇到错误时，通过提供快速支持，这些信息使您可以轻松地进一步开发您的 API 并改善您的开发人员体验。您还可以看到特定渠道的用户是否更有可能达到相关的 API 使用水*。
从中期来看，这可以让你跟踪你的 API 如何留住开发者，这是理解你的 API 提供了多少价值的重要部分。您还将了解哪些端点的事务数量最多，典型的事务持续多长时间，这表明您的资源应该集中在哪里。
您跟踪的 API 指标应该包括唯一的标识符，以便更容易地跟踪单个客户的使用数据。这使得理解您的 API 性能变得容易，并使您的客户支持变得快如闪电。客户使用是跟踪业务价值的一个重要指标，持续跟踪 API 事务非常重要，这样您的组织才能清楚地了解您的 API 满足客户需求的程度。
您的客户还对他们随时间推移的使用情况感兴趣。您应该向每个客户提供他们的使用信息，以便他们了解何时接*使用配额，这样他们就不会意外达到配额限制。他们可能还想知道在访问您的 API 时他们通常使用多少网络资源，这使得他们能够轻松地分配足够的资源来访问您的 API。他们最常使用或用于传输最多数据的终端对于您的客户来说也是重要的指标，因为这些信息会告诉他们哪些终端为他们提供了最大的业务价值。这有助于获得良好的客户体验，使他们更有可能使用您的 API。
你需要长期考虑的 API 分析的一个重要方面是如何扩展你的分析。随着客户的增长，API 调用的数量会增长，API 调用的长度和内容也会增长。虽然准确执行 API 分析已经非常具有挑战性，但久而久之变得更加困难，API 事务的数量也在增长。您的 API 分析实现需要准确地跟踪业务价值，并应对 API 的增长。
靠自己很难构建精确的 API 分析工具。即使是经验丰富的团队也需要大量资源来衡量他们的第一次分析，并且您需要不断地开发您的指标来为您的组织获得更详细的信息。但是，这不是放弃的理由。出色的 API 指标将为您的业务带来巨大的价值，它们使您的产品和支持团队更容易改善您的客户体验，并且您的指标会告诉您应该关注 API 的哪些方面。
跟踪 API 事务有效吗？
到目前为止，我们已经讨论了组织在分析 API 时最容易陷入的陷阱，它们发生的原因，以及您应该关注的度量标准。现在，我们将针对不同的用例，直接比较常见的虚荣心指标和 API 事务指标。
API 采用是一个对许多组织都很有价值的指标，因此正确地衡量它是很重要的。流行的方法是查看为一个 API 提供的 API 键的数量。这表明 API 很受欢迎，很多开发人员发现它很有用，但是依赖这个标准是危险的。它只是告诉你，很多开发者考虑过使用你的 API。这不会告诉你他们是否成功地实现了他们的第一个 API 调用，他们到达了入职旅程的哪个阶段，或者他们遇到了多少错误。另一方面，如果您使用唯一标识符来查看您保留用户的情况，并跟踪从创建一个 API 键到“Hello World！”需要多长时间您将知道是否需要改进您的入职、文档和支持。
许多组织已经成功地从内部构建自己的 API 分析工具过渡到 Moesif 的 API 分析工具。Symbl.ai 是一家数据驱动型公司面临着在专注于产品开发和构建内部 API 分析之间进行权衡的绝佳例子。Moesif 提供深度 API 分析，允许 symbl . ai完全理解客户如何与他们的 API 交互。
理解您的 API 可能具有挑战性，但使用正确的分析工具，您可以为客户实现最大价值，并跟踪您成功实现组织目标的情况。使用 Moesif API Analytics 您的组织可以构建出色的 API。
将 GraphQL API 添加到 Postgres 数据库的六种简单方法，比较 Hasura、Prisma 和其他方法
PostgreSQL 是世界上最流行的开源 SQL 数据库之一， GraphQL 是一个日益流行的新兴 API 规范。
将久经考验且广为人知的 PostgreSQL 与 GraphQL 带来的新的 API 创建方式相集成不是很好吗？
在本文中，我们将讨论六个不同的项目，它们试图将 SQL 与 GraphQL 世界融合在一起。其中一些甚至允许基于数据库结构自动创建模式。
以数据库为中心的方法
以数据库为中心的解决方案试图消除大多数配置和模式设置。他们将检查我们的数据库的外观，并为我们提供类型和端点。
由于他们知道数据库是如何构造的，他们可以为我们生成高性能的解析器，所以我们不会遇到 N+1 查询问题。
1.哈苏拉
Postgres 上的即时实时图表
哈苏拉可能是目前球场上最令人兴奋的球员。是类固醇 PHPMyAdmin。
它运行在 Docker 容器中，作为数据库前面的服务器，并为我们提供了一个 DB 和 API 的管理 UI，有点像 PHPMyAdmin 所做的。
它自带认证和授权特性，甚至可以与其他认证提供者集成。
如果没有托管服务，它会变得越来越糟糕，所以如果你不喜欢像 AWS AppSync 这样的东西，但你喜欢 T2 的一些东西，那么就选择 Hasura 吧。
它是在 Apache 2.0 许可下开源的，大部分是用 Haskell 编写的。
此外，创作者提供有偿支持计划。
2.海报
通过将 PostgreSQL 指向您现有的 PostgreSQL 数据库，立即启动 GraphQL API 服务器
PostgreSQL 类似于 Hasura，它允许从 PostgreSQL 模式生成 GraphQL API，并作为服务器在我们的数据库前面运行。它只是进入了一个不同的方向来实现这个目标。
它不使用 Docker 容器，并试图尽可能多地重用 Postgres 功能。例如用户管理、通过 RLS 的授权和可自动更新的视图。
所以它非常适合在设置和配置这种数据库方面有多年经验的 Postgres 专业人员。他们可以使用他们所有的技能，让 Postgraphile 为他们做 API 工作。
Postgraphiles 也主要关注 CLI 来完成所有的交互，这可能是数据库管理员更喜欢的。
这是一个在麻省理工学院许可下发布的开源产品，主要用 TypeSCript 编写。
创作者还提供了一个付费的专业版，提供额外的功能和付费支持。
3.Prisma&graph QL Nexus
【2021-05-02 更新】
Prisma 取代传统 ORM
[Nexus 是]声明性的、代码优先的 GraphQL 模式，用于 JavaScript/TypeScript
Prisma 是一套开源的数据库工具，用于数据访问(类似于传统的 ORM)、迁移和数据管理。
开发人员可以使用 SDL 的一个子集来定义一个数据模型，Prisma 将该模型映射到他们的数据库，从而简化了数据库迁移的过程。
Prisma 然后生成一个类型安全的数据库客户端，可以在您的 API 服务器内部使用。当与 GraphQL Nexus(一个代码优先的 GraphQL 模式构造库)和nexus-prisma集成一起使用时，开发人员可以利用自动生成的 CRUD 操作来处理数据库模型。这使得只需几行代码就可以构建完整的 GraphQL CRUD API！
然后可以根据应用程序的用例定制和扩展生成的 API。
它是在 Apache 2.0 下授权的开源软件，用 Scala 编写。
Prisma 还提供付费企业版。
什么是 Moesif？ Moesif 是最先进的 REST 和 GraphQL 分析*台，被数以千计的*台用来衡量您的查询执行情况，并了解您最忠实的客户正在使用您的 API 做什么。
以模式为中心的方法
接下来的三个解决方案在方法上更经典一些，它们需要手动创建模式，没有太多额外的东西，但是它们试图帮助解决常见的问题。
它们还需要使用 Node.js，因为它们是常规的 Node.js 库。
4. Node.js API 初学者工具包
使用 Node.js 和 GraphQL 创作数据 API 后端的样板文件和工具
Node.js API 初学者工具包可能是启动和运行 GraphQL API 的最基本的方法。
这是一个样板项目，附带了连接到 Postgres DB 所需的所有 Node.js 库，运行 HTTP 服务器并创建 GraphQL 模式和解析器。
对于需要完全控制 API 服务器每个部分的绿地项目来说，这是一个良好的开端。
没有付费支持，只有免费的社区支持。
它是开源的，有麻省理工学院的许可，用 JavaScript 编写。
5. graphql-sequelize
通过 Sequelize 为 MySQL 和 Postgres 提供 GraphQL 和 Relay
这是一个从序列模型中生成 GraphQL 解析函数的库。我们仍然需要创建我们的模式，但是不必再担心解析器了。
对于那些已经掌握了大量 Sequelize 知识并且不想放弃它的人来说，这是一个正确的解决方案。
这是一个用 JavaScript 编写的开源库，在麻省理工学院许可下发布。
6.加入怪物
它是一个函数，接受 GraphQL 查询，并动态地将 GraphQL 转换为 SQL，以便在解析之前进行高效、批量的数据检索。
Join Monster 通过提供一种使用 Postgres 的全部 SQL 功能的方法来帮助 GraphQL 模式建模。它允许告诉每个 GraphQL 类型它属于哪个表，因此它可以从每个 GraphQL 查询生成最佳 SQL 查询。
对于那些想自己构建大部分 API 服务器但不想直接使用 SQL 的人来说，这是一个极好的解决方案。
Join Monster 是在麻省理工学院许可下开源发布的。是用 JavaScript 写的。
结论
有许多不同的解决方案可以通过 GraphQL API 访问 Postgres 数据库。各有利弊。
如果我们不能全押在云解决方案上，这里列出的系统允许我们选择我们希望在 API 中“手握”多少东西，以及我们希望自己做多少事情。
有了 Hasura 和 Postgraphile，我们终于有了与语言无关的方式来完成事情，这将让许多非 Node.js 开发人员感到高兴。
一个优秀的 API 产品经理应该具备什么样的品质
随着越来越多的公司意识到 API 第一思维模式的好处，并将他们的 API 视为产品，对良好的 API 产品管理实践的需求越来越大，以使公司的 API 战略成为现实。然而，API 产品管理是一个相对较新的领域，对于什么是 API 产品管理以及一个项目经理应该做什么来确保他们的 API *台是成功的，几乎没有既定的知识。
API 产品管理的许多当前实践是从其他产品和*台(如 web 和 mobile)继承而来的，但是 API 产品由于其营销和客户使用的方式而有其独特的挑战。虽然消费者移动应用很少拥有详细的开发者文档和开发者关系团队，但你会发现这些项目在专注于 API 产品的公司中很常见。第二个独特的挑战是 API 是非常以开发人员为中心的，很多时候 API PMs 本身就是工程师。然而，如果没有好的流程，这可能会导致 API 或开发人员程序对他们的客户真正想要的东西失去同理心。不要因为你是工程师，就认为你的客户会想要和你一样的功能和用例。
本指南列出了什么是 API 产品管理，以及成为一名优秀的产品经理应该做的一些事情。
了解业务合理性
在你开始你的 API 产品管理职责之前，你应该首先理解你公司的 API 计划的高级目标是什么。这种 API 是像 Stripe 和 Twilio 这样的公司的顶线收入的核心驱动力，还是像 Dropbox 或 box 一样，建立第三方开发者的生态系统以建立竞争护城河并扩大你的市场？
为开发而开发 API 可能是一个独立的研究项目，但对于大多数需要创收的公司来说，将会以灾难告终。作为一个 API 产品经理，你应该仔细倾听你的客户到底想要什么，不管他们是内部团队还是公共 API 程序的外部开发者。这对于 API *台来说尤其困难，因为涉及到许多利益相关者。您可以让单个开发人员决定采用和使用您的 API，但是您也可以让决策者最终决定是否继续使用企业协议。你也可能与最终应用的最终用户交谈。
精通 API 指标
如果没有指标和 KPI，您作为项目经理的努力就没有任何价值。就像 2020 年的任何产品管理角色一样，仅仅基于直觉或少量客户样本发布功能不再适用。您的衡量标准应该与产品目标保持一致，例如参与度或保留率。这避免了依赖虚荣指标的陷阱，如页面浏览量或每分钟请求数，这些指标与营销和工程团队一致，但与产品团队无关。更多信息请查看 API 监控对 API 产品经理和成长团队意味着什么
通常，API 产品指标与三个领域之一相一致:
- API 采用
- API 参与/使用
- API 保留
一旦您理解了高级业务目标，您就可以为您和工程师创建您的内部目标和关注领域。然后，我会花相当多的时间来理解现有或即将出现的 API 的不同用例。这可以是对当前 API 使用数据的调查，也可以是直接采访客户。您需要了解客户使用的不同终端和功能，以及他们的最终目标。这些 API 是用在一个手机 app 里的吗？它们主要由合作伙伴或内部团队在内部使用吗？这样你就可以开始规划不同的客户角色。这是一个销售/创收的 API 吗？如果是这样，向销售团队索要一些电话或数据，了解潜在客户的需求。如果是内部的，与其他团队进行几次(WFH)午餐会议，看看他们在构建什么。
一旦完成，您就可以开始规划您的*台战略了。在客户发现访谈中，你注意到了什么趋势吗？如果可能的话，我总是乐意提供更多的帮助。
善于管理积压
项目管理占据了 API 产品经理日常职责的很大一部分。大多数 API 团队本质上都是技术型的，并且会在任何给定的时间处理无数的 bug、客户的特性请求和新产品计划。原料药产品的大部分客户是其他企业而不是个人消费者。这意味着他们将有特定的请求，如定制集成工作、处理安全性和隐私要求，以及帮助客户设置*台。面对这种源源不断的需求，产品经理需要在内部利益相关者的需求、产品开发和客户需求之间进行*衡。如果工程师在不可恢复工程(NRE) 上花费太多时间，那么长期的产品愿景永远无法实现，最终输给推动产品前进的竞争对手。另一方面，如果花太多时间在有远见的功能而不是可以帮助现有客户的小事上，客户会不高兴，因为他们没有得到他们期望的支持，导致流失和收入损失。使用像吉拉或 Pivotal Tracker 这样的工具可以帮助管理来自不同利益相关者的这些请求，并确保产品进度不会延误。
了解基于使用的打包和定价
虽然不一样，但 API 和 SaaS 是很多次一起听到的项目。成为一名优秀的原料药产品经理的一部分是对 SaaS 产品中使用的不同包装和定价方案有敏锐的理解。大多数 API 都有某种基于使用的元素，无论是每月的交易数量、每月跟踪的用户数，还是 API 定价的其他价值指标。虽然一些 API 产品可以采用纯交易定价模式，如每条消息 5 美分，但大多数 API *台都将其产品打包在层中，其中包含一组针对目标受众的功能和使用配额。优秀的 API 产品经理知道纯交易定价和分层定价之间的权衡，以及什么是好的定价价值标准。有关如何管理自助定价的更多信息，请查看如何推出新的自助开发*台
对开发者感同身受
对于大多数 API 产品来说，终端客户或者涉众都是软件工程师，因为大多数 API 产品需要一些集成工作来利用它。构建和扩展 API *台可能是一项艰巨的任务，但始终专注于最佳的开发人员体验对于一个成功的产品来说至关重要。拥有良好的开发者体验意味着在你的产品中添加一些特性，这些特性可以推动开发者前进，使他们能够成功地使用你的 API，包括低摩擦的入职流程以及最新的、易于理解的开发者文档。开发人员体验包括其他项目，如公共变更日志和状态页面，以记录*台的变更和中断。像在入职期间在代码样本中嵌入开发人员的 API 键和提供调试 API 日志这样的小事，可以让您的 API 成为开发人员优先的 API。
了解企业安全性和合规性要求
大多数 API 都需要安全，并且符合各种隐私和行业特定的法规，如 GDPR 和 CCPA。这可能需要特定的 API 功能来确保您自己的公司合规，但也需要新的端点来帮助确保您的客户能够减轻自己的合规负担。有关合规性特征的更多信息，请查看 CCPA 要求和 API 程序合规性清单
在许多公共和内部 API 的背后，往往是包含大量客户或专有数据的数据库。*衡受监管行业的大客户的合规性需求与可以帮助初创企业的个人开发人员的功能，对于避免一个客户对您的产品路线图产生太大影响至关重要。如果您不熟悉企业 API 产品所需的安全性和合规性特性，可以看看 enterpriseready.io
结束语
API 产品管理是软件行业中一个新的但正在成长的领域。本质上是技术性的，并且与 SaaS 和企业软件一致，API 产品经理需要某些特质，而这些特质通常是以消费者为中心的公司所不需要的。与开发人员社区一起工作可能会非常令人兴奋和满足，但需要极大的关注和同情心。
API 监控对 API 产品经理和成长团队意味着什么
如今，无数工程团队已经利用 API 监控来跟踪基础设施的健康状况，并在服务停止或不健康时进行报告。可以跟踪各种与工程目标一致的 API 指标，如正常运行时间、*均延迟、每分钟请求数和每分钟错误数。然而，这些指标与产品所有者和增长团队的业务目标不一致。这篇文章介绍了如何利用 API 监控工具来促进您的业务增长和产品路线图。
甲板版本
//www.slideshare.net/slideshow/embed_code/key/45xC73Vj8oiMLT
What Does API Monitoring Mean for Product Managers? from Derric Gilling
业务目标概述
作为产品经理，您的目标通常符合以下三个方面之一:
- 采用
- 约会
- 保留
根据产品的状态，公司关注不同的领域。在一个 API 发布时，采用可能是你的第一要务，因为当没有人首先知道你的 API 时，很难优化参与和保留。一旦你尝试了采用，并且有一小群用户测试了你的 API，你就可以开始寻找提高参与度和保持度的方法，这可以通过优化 onboarding 来实现，确保正确的产品特性存在，并且对用户有价值。一旦你看到参与度和保持度指标处于良好水*(即一小群忠实用户)，你就可以转而专注于采用，因为你现在可以双倍下注一个正在工作的产品。
1.采用
采用侧重于 API 的漏斗增长。推动采用的方法取决于您正在创建的 API 的类型。对于内部 API，您可以向公司中能够利用它的其他部门和团队宣传该 API。对于公共 API，您可以利用付费广告和内容的组合以及直接推广。
2.约会
一旦你有一群用户注册并测试你的 API，你就要确保你能推动产品参与度(即使用度)毕竟，那些产生大量兴趣和注册，但不能维持高产品使用度的 API 有失去投资的风险。任何项目计划都是为了给用户创造价值而发起的，无论这些用户是内部团队，还是外部客户和合作伙伴。
3.保留
保留类似于参与，除了它跟踪一群用户的参与随时间的衰减函数。在三个产品指标中，保留率是产品/市场契合度的最佳替代指标之一，因为它排除了外部因素，如由超大规模销售和营销预算推动的高采用率。如果你有一个忠诚而有粘性的产品，那么留存率会比一个漏船的产品高。
1.监控 API 采用情况
跟踪开发人员对 API 产品的采用类似于对其他产品的采用，最好用漏斗来完成。开发者漏斗跟踪用户从最初注册到使用你的 API 发布一个可用应用的旅程。与衡量移动应用获取的其他漏斗不同，API 用户可能会在一个漏斗阶段停留数天或更长时间。这意味着你不仅要跟踪每一步的转化率，还要跟踪到达下一步所需的时间。
在您的漏斗中跟踪的推荐步骤:
- 预集成阶段:用户注册或生成 API 密钥。
- 沙盒阶段:用户进行了第一次 API 调用。从阶段 1 到这个阶段的时间可以称为到第一个 Hello World 的时间(TTFHW)
- 生产阶段:用户部署了他们的全功能应用程序，创造了一些有价值的东西。从前一阶段到这一阶段的时间可以称为第一个工作应用程序的时间(TTFWA)
通过分阶段规划您的采用流程，您可以发现产品中需要改进的地方。F
对于许多 API *台来说，缺少文档和简单的入门会降低 TTFHW 的速度。这可以包括
- 包含许多整合步骤的漫长入职流程
- 没有针对需要额外开发的编程语言或框架的 SDK
- 劣质或过期的文档。大多数开发人员喜欢在集成之前对 API 进行研究。
另一方面，开发商控制之外的其他内部利益相关者会降低 TTFWA 的速度，例如:
- 法律和合规风险
- 项目优先级
- 性能测试和安全审查的阻止程序
2.监控 API 使用
一旦用户采用了你的 API，你就想要提高参与度和使用率。
虚荣度量
明智地选择您的指标，不要落入虚假(即虚荣)产品指标的陷阱。虽然许多营销团队负责页面浏览量和注册量，但这些指标只衡量漏斗顶端，而不是产品本身的成功。你甚至可以有一个没有任何产品的登陆页面，仅仅通过一大笔广告预算就能获得大量注册。类似地，有许多基础设施指标与工程目标而不是产品目标相一致。例如，每分钟增长的请求指标可能意味着一个成功的产品，但是由于大量的健康调查或机器人流量，增长可能是人为的高。甚至*均延迟也不是衡量产品性能的最佳指标，因为持续缓慢的 API 可能是好的，不像加载缓慢网站的体验。
推荐的参与度指标
每周活动 API 令牌
每周活跃 API 令牌，即在给定的一周内访问 API 的不同令牌的数量，是跟踪 API 产品的最佳北极星指标之一。因为单个开发人员帐户可以创建多个 API 令牌，例如用于沙盒和生产环境，所以更准确的衡量标准是每周活跃用户或每周活跃公司。但是，这需要能够将 API 令牌链接到相应用户或公司帐户的分析基础架构。
当一个开发者注册使用你的 API 时，你也应该跟踪引用的域和 UTM 参数。这使您能够按 UTM 来源或 UTM 活动对每周活动令牌进行分组，以更好地了解有助于使用和参与增长的营销渠道。
API 流量排名靠前的客户
了解你的 API 的顶级消费者有助于你了解你最有价值的用户想要什么。通过按端点或特性对其进行细分，您可以查看二级指标，例如哪些端点最受参与用户的欢迎，但没有被那些没有真正使用您的 API 的用户所利用。可能有一小部分非常有价值的特性需要更多的曝光。
第 90 百分位延迟
*均延迟可能是一个错误的指标，因为它没有显示延迟的变化。大多数使用您的 API 的用户可以处理持续高延迟的 API，因为它是可预测的。然而，延迟差异很大的 API 更难使用。延迟变化会导致发送错误警报，触发代码中的竞争条件，并使容量规划变得更加困难。衡量这一点的一种方法是通过第 9x 百分位延迟。您还可以根据客户、端点或其他数据进行分组，以找到延迟差异最大的热点。
3.监控 API 保留量
一旦你对采用和参与有了很好的理解，研究 API 产品留存以发现产品中需要改进的地方是很重要的。产品留存是一个从收入留存中诞生的概念，需要将你的用户群分成不同的群组，比如通过注册日期。然后，您跟踪每个群体返回到您的*台的百分比。
虽然所有的留存曲线都是向下倾斜的，因为没有产品能保证在注册后 100%的留存，但提供长期客户价值的好产品的留存曲线随着时间的推移会接*非零*衡，如上图所示。然而，不符合产品/市场的不良产品将表现出向下倾斜到零的保留曲线。这意味着你有一艘漏水的船，在进一步投资采用之前，应该优先解决你的产品保留问题。否则，你只是在浪费时间和金钱来获取那些不会留下来的用户。
在上述指标中，我们探索了按用户 SDK 分组的 API 保留。我们可以看到 PHP 比其他 SDK 的留存率低得多。这可能意味着 PHP 有问题或者有一些需要修复的性能问题。
结束语
让开发者采用你的 API 很难。它需要对开发者想要什么有一个好的直觉，同时不要让个人偏见成为障碍。构建开发人员真正喜欢的产品的两种最佳方式是通过 1。查看真实的使用数据和 2。客户发现和调查。拥有定性和定量数据对于规划和投资正确的产品计划非常重要。
每个 web 开发人员都应该知道的 CPU Arch，第 1 部分:线程与进程
介绍
有很多讨论软件开发范例和最佳实践的博客文章，也有一些是关于硬件的。与此同时，从计算机体系结构的角度来看，讨论每个开发人员应该知道什么的文章的数量我一只手就能数出来。本文的目标不是深入探究 CPU 架构、操作系统等。我将概述一些原则，这些原则是我们作为开发人员在繁忙的日子里可以放松的。
线程与进程
安全性和可靠性
在 Docker 容器和 VM 出现之前，CPU 硬件有一个最古老的沙盒技巧:进程和虚拟内存。作为开发人员，您应该明白，一个进程将在它自己的隔离内存空间中运行，并且只能通过特定的机制(如进程间通信(IPC))与其他进程对话。因此，如果您有进程 A 和进程 B，并且它们都有一个逻辑地址 0x0，那么它们实际上指向物理内存中两个独立的区域。现代 CPU 硬件通过分页提供安全保护，确保进程只能从自己的内存空间读写。常见的分段错误实际上最初是由 CPU 硬件通过一个 #PF(页面错误)由于非法访问而触发的。(注意:我将省略 x86 分段，因为分段寄存器在 64 位模式下不再真正“使用”)。
另一方面，同一进程中的线程共享相同的地址空间。访问同一个地址空间可能是好事也可能是坏事。如果线程崩溃，应用程序的状态可能是未知的。硬件中没有安全保护来防止流氓线程以非预期的方式访问其他线程的数据。事实上，Chrome 开始在自己的进程中运行每个浏览器标签，而不是仅仅使用多线程。如果你曾经在 Chrome 标签中看到“哦，Snap…”的话，那是一个无意中执行了某些东西的过程。失败的选项卡崩溃并且不再运行，但是剩余的选项卡可以照常继续工作。
这不是意味着进程必须在内存中复制代码和数据吗？
是也不是。现代操作系统和硬件可以用一种叫做写时复制(COW) 的东西做一些聪明的事情。当您在 Linux 中调用 fork()时，最初并不是所有内容都被复制到内存空间的一个新部分。确保进程不会写入进程外内存空间的同一个分页硬件也可以在写入标记为只读的页面时抛出#PF。此标志允许操作系统处理故障，这意味着如果需要，将旧页面复制到内存中的新页面。
使用进程不需要缓慢的上下文切换吗？
是的，进程需要上下文切换，但是线程也需要。一个线程还具有附加到它的执行上下文，它由它的各种 CPU 寄存器值(例如 x86 中的 EAX、EBX…)组成，在下一个线程可以开始执行之前需要存储其他内容。事实上，现代 SIMD 编码，如许多视频编码和压缩算法，以观看您最喜爱的高清网飞节目，使用一些相当大的寄存器，需要写入内存。事实上，AVX 的最新版本由 32 个 64 字节宽的寄存器组成！当提到进程比线程慢时，通常指的不仅仅是上下文切换本身，而是刷新翻译后备缓冲器(TLB)中的条目。TLBs 保存了我们前面提到的分页机制的缓存翻译。因为一个新进程将在它自己的内存空间中执行，所以它不能使用旧进程的翻译，并将重新开始。这意味着 TLB 对新的工艺将会冷淡。如果翻译不在 TLB 中，则在存储器访问完成之前，页面未命中处理器(PMH)需要逐级遍历页面表。页表遍历是繁重的指针追踪算法，可以降低加载延迟。有一些捷径可以最大限度地减少行走所需的关卡数量，但最终的问题是寒冷的 TLB 会导致加载延迟远远大于温暖的 TLB。即使被访问的变量已经在某个地方的 CPU 缓存中，也会发生这种情况(我们将在后面讨论)
所以最终的结论是，流程的上下文切换可能不会太长，但是可能会有延迟的影响，甚至会降低后上下文的速度。
线程太多。
在这个寒冷的 TLB，过程并不是唯一可以忍受的东西。如果线程没有被调度在同一个逻辑 CPU 上(CPU 亲缘关系)，也可以经历这种情况。这引出了下一个问题:应用程序可以运行的逻辑 CPU 数量是固定的。虽然现代操作系统有许多进程和线程可以在各种阻塞和等待状态下同时运行，但实际上 CPU 一次只能运行固定数量的线程。无论线程是否在同一个进程中，都是如此。当你启动更多的线程，然后你可以积极地运行，操作系统必须抢先上下文切换。如果您只是为每个任务生成一个又一个线程，认为它将全部并行运行，您可能会惊讶地发现，与在一个线程池中运行少量线程相比，您对性能的损害可能更大。
一般来说，大量线程会导致系统颠簸。系统颠簸是一个通用术语，当 CPU 开始交换或移动资源而不是执行实际执行时使用。CPU 的资源大小是有限的，TLB、高速缓存、甚至内存中分配的页表都是有限的。当您开始在更多线程之间切换时，您可能会给这些子系统带来压力，导致仍然热的数据被驱逐，这对性能是有害的。默认情况下，许多异步 web 框架被配置为将它们的工作线程池与逻辑核心的实际数量相匹配，或者它们可以添加一些额外的阻塞，但仍然在一个数量级内。想想优步的司机。有时候，让长途旅行的乘客上车，开一会儿车，然后不断地让新乘客上车，让老乘客下车，会更容易、更快捷。乘客数量是您的固定资源，如逻辑处理器、缓存大小和 TLB。如果你接了新乘客，你必须先赶走老乘客，为新乘客腾出空间。如果您开始发现自己在等待卸载和装载，而不仅仅是驾驶(工作或执行)，这种进出行为就是颠簸。
第二部分
这是较长系列的第 1 部分，请继续关注下一部分
谢谢
我们感谢我们的精选测试版客户，他们一直在试用 Moesif，为我们提供了宝贵的反馈，使调试变得更加容易。
什么是原料药产品？
原文：https://www.moesif.com/blog/api-product-management/developer-platforms/What-Is-An-API-Product/
我们都听说过 API 产品或 API-as-a-product 这样的术语。这些术语本身似乎使用得相当自由，让我们中的一些人对其含义有一个假设，但没有真正牢固的掌握。随着加入 API 经济并为其做出贡献变得越来越受欢迎，API 产品成为任何寻求利用它的企业的重要组成部分。所以问“什么是 API 产品？”是一个有很多不同角度的相关问题。
API 产品与任何其他产品没有什么不同:它以某种方式、形状或形式传递价值。在 API 的上下文中，我们基本上是说，我们已经创建并打包了一个可以为内部和外部组织带来价值的 API。您可能决定从一开始就构建一个 API 产品，或者您可能选择将 API 产品化，作为数字化转型推动的新商业模式的一部分。
您可能熟悉的 API 产品的几个例子是:
谷歌地图
google maps API 可能是使用最广泛的 API 之一。大多数需要任何类型的位置查找、地理跟踪或任何其他基于位置的功能的网站和移动应用程序都可能使用谷歌地图 API。简单的入门、使用和优秀的文档是这款产品的一些标志。
Tomorrow.io
Moesif customer Tomorrow.io 也是一个很好的 API 产品的例子。该 API 被大大小小的组织所使用，实现了真正的 API 产品方法，提供了丰富的开发人员文档、多个定价层以及 API 消费者注册和自助服务/板载的能力。
如您所见，API 产品通常专注于一组特定的功能，比如位置查找或当前天气。这些公司已经找到了一种方法来创建 API，为其他开发者和他们的组织提供价值。这就是构建 API 产品的真正含义。
什么是成功的 API 产品？
因为任何为开发者提供价值的 API 都可以转化为 API 产品，所以对于开发者和构建它的公司来说，看看什么是好的 API 产品是很重要的。
自助集成
开发人员以自助方式从注册到实际使用 API 的能力至关重要。大多数开发人员不喜欢复杂的入职或由销售团队领导的入职。开发人员应该能够注册和订阅您的 API，并以一种非常“低接触”的方式集成它，只有当他们遇到独特的情况或无法克服的错误时，才会寻求支持。这也可以通过使用 API 网关或 API 管理*台来改进，以确保 API 集成和 API 访问在所有 API 资源中是统一的。
开发者文档
由于 api 是高度技术性的，好的 API 文档对于支持好的产品是至关重要的。帮助 API 消费者的开发人员文档应该相对多样化，包括集成技巧、如何使用特性，甚至如何解决开发人员可能面临的常见问题。你也可以考虑通过添加全面的书面和视频教程来进一步增强你的文档，这些教程向 API 消费者展示如何实现共同的结果。
API 货币化
要开发一个产品并维持下去，你需要增加收入。对于 API，这意味着弄清楚向 RESTful API 开发人员收取什么费用，以及如何实现这个过程。作为一个 API 提供商，通常，你需要决定你是否有一个免费的试用或免费层，如果你要做预付费或后付费计费，以及你将使用哪个计费提供商。这些考虑是你的 API 货币化策略的关键方面。当然，API 货币化可能非常复杂，但让结账、管理费用和收款变得容易是良好客户体验的关键。
收集用户反馈的能力
在您构建产品时，您会希望不断改进和增加客户使用的关键领域的价值。这意味着您需要收集关键的操作数据、用户数据和 API 调用的使用度量。将这些因素结合在一起将有助于您开发一个更稳定的 API 产品，它是高性能的，并且在客户最常用的所有领域都有交付。这也是深入了解您的入职体验并揭示客户在采用您的 API 的早期阶段可能会遇到的挑战的一个很好的方式。
Moesif 能帮上什么忙？
Moesif 可以通过利用该*台的一些核心特性来帮助公司构建优秀的 API 产品。这些特性有助于实现我们上面提到的一些要点，这些要点是成功的 API 产品的一部分。Moesif 可以帮助简化 onboarding、API 货币化、帮助开发人员导航产品等等。让我们看看下面的一些细节。
用户渠道
使用 Moesif 的用户漏斗分析，您将能够在用户旅程的每个步骤中看到某些趋势和转化率。如果你把焦点放在入职上，这很能说明问题。例如，您可能有这样一个用户漏斗:
- 注册
- 第一次 API 调用
- 第二次 API 调用
- 第 1000 次 API 调用
通过跟踪这一点，您将能够看到一些关键的见解:
- 有多少人注册了却从来不做 API 调用？
- 有多少人进行了第一次 API 调用而没有后续调用？
- 开发人员进行第 1000 次 API 调用的比例是多少？
你还可以看到在顾客旅程的不同阶段之间转换所花费的时间，并想出可能的改进方法。例如，你可能认为从注册到第一次 API 调用，用户应该只需要 5 分钟。但是，当查看数据时，您会发现实际上*均花费了一个多小时。这可能暗示您需要改进您的集成步骤，或者只是简单地添加一些更好的文档。
当您进行这些改进时，您可以不断地检查转换的改进以及步骤之间花费的时间。这将有助于你确定你是走向优化还是远离优化。
计费仪表
Moesif 计费表允许你轻松地将你的 API 货币化。这是可能的，因为 Moesif 允许你拨入你的计费标准，然后 Moesif 会将 API 使用统计数据发送给你选择的提供商，例如 Stripe 、 Recurly 或 Chargebee 。让你的 API 成为产品的一大障碍是实际实现端到端的解决方案来实现你的 API 货币化模型。有了 Moesif，这不再是一个问题。例如，看看这个使用 Moesif、Stripe 和 Kong 的现成 API 货币化示例。计费表也可以与 moesif 中创建的 API 治理规则很好地匹配。这些规则可以用于阻止基于未付发票的端点的 API 请求。
行为邮件
无论是“欢迎”邮件、“后续步骤”邮件，还是帮助陷入困境的开发人员的邮件，与客户建立积极的沟通渠道都是至关重要的。这些类型的电子邮件可以让客户参与进来，还可以帮助他们解决问题，而不必寻求支持。
使用 Moesif，您可以为何时发送电子邮件创建特定的标准。这可能是当用户注册您的 API 时，当他们使用新添加的 API 功能或许多其他场景时，他们在 30 分钟内从一个端点收到超过五个 401 响应。设置这些电子邮件极其简单，并且可以不费吹灰之力为您的客户体验增加价值。
警报
Moesif 允许您设置一些条件，在这些条件下，您的团队将收到诸如新客户注册、入职问题、持续错误等事件的警报，而不是以手动方式主动监控开发人员。这些警报可以发送到许多不同的渠道，包括电子邮件，短信，寻呼机，Slack，或一个自定义的网络挂钩。
通过设置警报，您的支持团队(和其他人)可以在客户找到他们之前主动采取措施帮助他们，或者更糟的是，决定放弃使用 API。
嵌入式模板
您可以为用户构建一个自定义仪表板，以查看诸如实时日志或用户使用时间序列之类的内容。Moesif 可以通过嵌入的模板特性帮助加速这一过程。有了嵌入式模板，您可以使用您最喜欢的图表，甚至那些无法访问 Moesif 的人也可以使用它们。例如，您可以在您的 API 仪表板中嵌入一个时间序列图表，其中添加了一个配额行，以显示开发人员离达到其配额还有多远，以及他们的 API 请求量如何随时间变化。
包扎
API 产品与任何其他产品没有什么不同，它们都要求用户在使用产品时有一个轻松愉快的体验。像大多数产品一样，分析可以帮助确保您在采用和客户满意度方面朝着正确的方向前进。Moesif 可以帮助挖掘这些分析，获得洞察力，并允许您通过行为电子邮件或警报等功能采取行动。要升级您的 API 产品游戏，现在就注册 Moesif 的,获得深入的见解和功能，帮助您发展和改进*台。
什么是 API 可观察性
原文：https://www.moesif.com/blog/api-engineering/api-observability/What-is-API-Observability/
API 可观察性是正确执行 APIOps 循环并确保您为 API 用户构建有价值的东西的关键要素。如果你对 APIOps 周期不熟悉，看一看本指南中的，它提供了一个敏捷框架来快速构建面向业务和服务客户需求的 API。API 可观测性本身是传统监控的一种进化，脱胎于控制系统理论。
传统的监控侧重于跟踪已知的未知情况。这意味着您已经知道要度量什么，比如每秒请求数或每秒错误数。虽然度量值可能事先不知道，但是您已经知道要测量或探测什么，比如一个计数器来跟踪桶中的请求。这使得可以报告系统的健康状况(如红色、黄色、绿色)，但对于解决工程或业务问题来说，这是一个糟糕的工具，因为这通常需要询问任意的问题。
您如何确定自己已经达到了传统监控的极限？嗯，当你正在调查一个问题，你告诉你的同事“我们可以解决这个问题，但我们没有合适的背景”。上下文是一个负载词，但它意味着你的解决方案无法回答未知的未知。相反，您需要修改您正在跟踪的指标，重新部署，然后最终查看结果以获得该上下文。
API 可观测性源于控制系统理论，通过推断状态和行为，从系统的输出尽可能多地观察系统的内部工作。有了一个复杂的分析工具来分析所有这些数据，您就能够回答任何关于您的 API 行为的任意问题，而不仅仅是一些可直接测量的预定义指标。这意味着你可以回答任何关于你的“黑匣子”如何进入这种状态的问题，甚至可以重现这种状态。
商业方面呢？
API 可观察性不仅仅用于诊断 API 所表现出的工程问题，它还可以帮助诊断业务问题。这些可能在本质上更抽象，但与观察你的身体服务有着相同的原则，只是扩大了范围。为了实现这一点，您不仅需要对物理基础设施进行全面观察，还需要对其他投入进行全面观察，如收入、增长和销售效率指标。这使您能够将您的“黑匣子”从仅仅一项服务扩展到整个产品或业务单位。
通过将您的 API 中发生的事情与更广泛的业务信息(如客户人口统计)联系起来，我们现在能够回答业务问题。例如，我们可以看到哪些客户请求了缺货的商品。我们不需要直接有一个计数器来测量每个顾客的缺货商品的数量。相反，像 Moesif 这样的高基数、高维度分析系统能够跟踪从 API 流出的所有信息，使我们能够动态地创建这个报告。在这种情况下，所有信息都已经可以用来创建任意报告。
什么是开发人员关系，什么是常见角色？
开发者关系不仅仅是 API 优先公司的一个角色或部门。开发者关系是一种心态，让开发者采用一个*台，让他们的计划成功，而不是试图卖给那些开发者。这使得开发者关系不同于传统的销售和营销角色。然而，如果你问“什么是开发商关系？”，您可能会得到许多模棱两可的回答，因为开发人员关系是各种不同角色和职位的总称。有些头衔包括“开发者倡导者”和“开发者传道者”，但也可以包括其他新的头衔，如“开发者体验经理”。“这些角色因公司而异，甚至在公司的不同团队中也是如此。
这篇文章概述了 devrel 中的一些不同角色，例如:
- 开发者福音传播者
- 开发商代言人
- 开发者体验
- 开发者营销
概观
开发者关系的艺术是在你的社区内建立真实的关系，而不是向他们推销或营销。这可以通过面对面、在线或其他方式完成。与开发人员的任何交流通常都属于 devrel 的范畴，需要高超的技术交流技巧，与角色无关。一些开发人员关系角色专注于社区参与和宣传。其他 devrel 角色专注于产品管理和开发者体验。
开发者福音传播者
当工程师听到开发人员关系时，就会想到开发人员传道者的角色(也称为技术大使)，因为这是最受关注的角色之一。一个开发者传道者专注于“把话传出去”。这可能意味着在会议上发言、参加聚会和举办黑客马拉松。他们的日程表很快就被承诺排满了，出差的时间可能比在办公室的时间还多。然而，他们也花费大量时间在线创建代码样本、网络研讨会和主持虚拟办公时间。布道者必须有技术头脑，但不一定自己就是工程师。他们大部分时间都在充当公司的品牌大使。
开发商代言人
与开发人员布道者不同，开发人员倡导者的目标不是制造轰动，并向全世界介绍你的*台。相反，开发人员倡导者的角色更多的是客户成功和产品之间的融合。他们的目标是让开发人员能够成功地利用您的*台和 API，同时向内部产品团队宣传他们的需求。他们是更大的社区和各种内部产品团队之间的有效纽带。他们可能会收集反馈，创建演示和代码示例，或者找到产品问题和产品缺陷的解决方案。在一些公司，他们可能表现得像“销售工程师”或“解决方案顾问”，通常比布道者更专业。
开发者体验
就像移动应用需要好的用户体验一样，好的 API 需要好的开发者体验(DX)。对于开发人员使用的任何东西，一个专门的开发人员体验团队的行为就像事实上的产品所有者一样。他们可能拥有入职流程、SDK/API 设计和文档。在一些公司中，开发人员关系存在于产品组织中，并拥有整个开发人员体验。在其他公司，devrel 可能与市场营销保持一致，导致开发人员体验归另一个团队所有，如产品团队或专门的开发人员体验团队。
开发者营销
营销本身通常不包含在 devrel 的保护伞下，但是 devrel 确实与开发者营销紧密合作，保证了它的包含。开发者营销有传统的营销目标，如营销合格的线索(MQLs)和推动收购。然而，对开发者的营销与传统的 B2B 或 B2C 营销有很大不同。如果它围绕着“集客营销”的原则，创造一个吸引人们的品牌，而不是把一个品牌推给开发商。开发者营销几乎总是涉及大量内容联合战略，但也包括付费渠道，如广告词，以及活动赞助。开发商营销可能会赞助一个会议，他们公司的一个拥护者会在会上发言。
结束语
Devrel 是一个现有的新领域。如果你是一家 API first 或*台公司，拥有一个 devrel 团队可以帮助你与开发者建立关系，而不会在营销或销售方面显得过于强势。
什么是动态采样，它是如何工作的
原文：https://www.moesif.com/blog/technical/api-analytics/What-Is-Dynamic-Sampling-And-How-It-Works/
有时，您可能希望限制进入 Moesif 的分析数据量。这可能是因为您想要排除特定的流量，例如内部或运行状况检查流量，或者您可能想要减少不必要的数据以控制成本。我们的企业计划为客户提供的动态采样正是为此而构建的。动态采样允许您根据客户或 API 行为控制将哪些 API 调用记录到 Moesif。Moesif 智能推断指标，即使在多采样率下也能准确报告。这意味着，无论您设置了什么样的规则或采样速率，您都可以确保您看到的仍然是数据的准确表示。
动态采样通过在 Moesif 仪表板中设置采样规则来控制。您可以根据请求路径、响应状态代码、用户或公司行为等标准创建规则。您还可以控制每个规则应用的采样速率。采样率是事件进入 Moesif 的百分比。例如，如果您设置一个规则，对 50%的事件进行采样，那么 Moesif 将智能地记录一半的匹配事件(而不是每隔一个事件记录一次，以满足 50%的采样率)。
为什么使用动态采样
我们的动态采样功能适用于客户的两种使用情形:
- 让用户能够减少 Moesif 中过多或不感兴趣的呼叫，同时保留您从*台中获得的洞察力。
- 允许用户降低其企业订阅成本并节省资金。Moesif 会考虑您创建的采样规则，并智能地推断使用指标。
抽样的 API 调用不计入您的配额；例如，如果您的 API 通常每月看到 100 万个 API 调用，但全局采样率被设置为 25%，则只有每月进入 Moesif 的 25 万个事件将计入该配额。
何时不使用动态采样
如果您避免对进入 Moesif 的特定事件进行动态采样，那将是最好的。这些用例包括当您利用其他 Moesif 功能时，如计量计费或治理规则，您希望在 Moesif 中评估每个呼叫。
对进入 Moesif 的 API 调用数量进行动态采样会影响货币化的 API，因为它无法跟踪确切的使用情况，可能会遗漏一些事件，这取决于所应用的采样率。这将影响您的计费仪表和发送给客户的发票。但是，一种解决方法是对未货币化的端点应用动态采样，并让事件以 100%计入您的计费表样本。
不使用动态采样的另一个原因是，当记录的 API 调用少于订阅计划支持的调用数量时。例如，假设您正在进行的 API 调用比您的订阅计划包括的要少。在这种情况下，动态采样是不必要的，除非您只是试图在 Moesif 中排除不想要的数据，以保持数据的整洁。这方面的示例可能不包括来自运行状况检查探测器或内部测试的流量。
四种类型的采样率
动态采样规则分为四种样本集，并按以下方式排列优先级:
- 单个用户或公司的采样速率
- 基于正则表达式规则的采样率
- 基于用户行为和人口统计数据的采样率(保存的群组)
- 全球适用的采样速率
这意味着，如果为特定客户设置了采样率，这将优先于与客户所属的行为群组相关联的采样率。全局采样速率的优先级最低，默认情况下，所有客户的采样速率都设置为 100%。如果一个 API 调用与多个规则匹配，它将由优先级层次结构中的第一种采样率进行处理。
如何在 Moesif 中创建动态采样规则
现在您已经了解了什么是动态采样以及它能做什么。我们简单看一下如何设置一些动态采样规则。首先，导航到 Moesif 中的动态采样屏幕。
在这里，我们可以访问已经创建的所有采样率。
选择 + Rule 按钮将允许我们创建新的用户或公司、正则表达式或群组采样规则。
特定用户或公司
选择新用户规则或新公司规则后，分别选择用户查找或公司查找按钮。
在本例中，我们将展示用户查找，但公司的流程是一样的。
继续从用户列表中选择一个 ID 进入他们的 剖面图 。您可以使用 Users Where 过滤器快速找到您要寻找的用户。
在“采样速率”下的“配置文件”视图中，选择铅笔图标以更改特定用户的采样速率。
禁用继承切换以允许调整用户的采样速率。通过手动输入速率或使用滑块设置所需的采样速率，然后选择保存。
正则表达式规则
返回到动态采样规则页面，在 +新下拉菜单中选择新正则表达式规则，输入您想要的标准和采样率并保存。在这个例子中；我们将采样率设置为零，以排除对任何健康端点的所有 GET 请求。这些呼叫不会出现在用户界面中，也不会计入我们的活动配额。
通过保存的群组获得行为或人口统计数据
通过利用保存的群组完成行为和人口统计采样；如果你对保存的队列不熟悉，请查看我们的博客文章、书面指南或视频指南以了解更多信息。
设定群组的取样率相当容易。在动态抽样规则页面选择 +新按钮，然后选择新用户规则或新公司规则。将出现一个模式，让您选择一个普遍保存的群组。继续设置所需的采样速率和优先级。优先级在用户或公司群组内排序。用户样本规则始终优先于公司样本规则。
全球的
您可以通过点击动态采样规则页面上的设置按钮来应用全局规则。出现的结果模式允许您设置全局采样速率，抑制已知的 bot 流量，以及明确或通过 regex 规则阻止来自给定 IP 地址的流量。模态的底部展示了在其各自的用户配置文件中设置了采样速率的所有用户或公司。
尝试一下
出于许多原因，动态采样可能是 Moesif 配置的重要组成部分。我们还回顾了一些限制和场景，在这些场景中，动态采样不是最佳选择，比如在对端点应用计费计量或治理规则时。最后，我们讨论了如何在 Moesif 内部建立不同类型的规则。
如果您已经加入了 Moesif 企业计划，那么您可以使用动态抽样。请随意查看我们的深度书面教程或视频指南。如果您没有企业计划，您可以联系我们的销售团队来解锁这一强大的功能。如果您是 Moesif 的新手，今天就注册，开始为您的组织释放 API 分析的力量。
什么是 HTTP 中间件？构建、设计和使用中间件的最佳实践。
原文：https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/
为了从任意环境中捕获 API 调用，我们必须为许多常见的 web API 框架创建中间件。这里介绍的一些知识也可以帮助那些创建中间件的人。
特别是，我们为以下框架创建了中间件:
- Python Django
- Ruby on Rails
- PHP Laravel
- 节点快递
- Java servlet
- 春天
- 球衣
- 支柱
HTTP 中间件简介
什么是中间件？
我使用术语中间件，但是每种语言/框架对这个概念的称呼不同。NodeJS 和 Rails 称之为中间件。在 Java 企业世界(即 Java Servlet)中，它被称为过滤器。C#称之为委托处理程序。本质上，中间件在用户定义的控制器之前或之后的 HTTP 管道中的特定阶段对 HTTP 请求或响应执行一些特定的功能。中间件是一种设计模式，可以在没有很多代码接触点的情况下，雄辩地添加横切关注点，如日志记录、处理认证或 gzip 压缩。
由于这些横切关注点是在中间件中处理的，控制器/用户定义的处理程序可以专注于核心业务逻辑。
中间件能做什么
中间件通常非常灵活。一些中间件是被动的，比如日志中间件。gzip 压缩等其他中间件可以对请求或响应主体执行转换。中间件可以添加 HTTP 头，添加供业务逻辑使用的内部标志，等等。这是管道设计模式的实现。
事实上，甚至像主体解析这样的基本框架特性也可以被认为是中间件。如果框架中包含的那些不适合您的用例，您可以为各种二进制协议添加定制的主体解析。
您甚至可以调用其他服务，例如在 Redis 中查找会话令牌，或者从 MaxMind 数据集执行 GeoIP 查找。
需要考虑的关键事项
如果你想做某件事，首先要考虑的是中间件。所以中间件最适合横切关注点。如果它是一个特定的业务逻辑，只适用于很少的情况，那么，也许中间件不是正确的选择。
如果您应用程序有许多常见的任务(比如日志记录、身份验证、解析 JSON 或者向每个请求或响应添加一些公共共享数据)，那么将逻辑重构到中间件中是有意义的。
表演
由于中间件的跨领域特性，确保它的性能尤其重要，因为任何增加的延迟都可能影响整个应用程序。延迟可能来自 I/O，如磁盘或网络访问。
例如，如果您为需要在 SQL Db 中查找用户信息的 API 创建了身份验证中间件，那么 I/O 读取将会停止 HTTP 请求管道，直到收到来自 SQL Db 的响应。即使使用 NodeJS 这样的非阻塞框架，客户端仍然会看到增加的延迟。
关于延迟与带宽的初级读本
延迟与带宽是两个正交但相关的指标。带宽指的是诸如每秒请求数或一次活动客户端或连接的最大数量等指标。另一方面，延迟是指对第一个字节的响应时间，或者执行特定查询的*均时间。然而，它们是相关的，因为延迟的增加也会减少系统的带宽。例如，增加等待时间也可能增加队列的驻留时间。
通常，NodeJS 等非阻塞框架主要关注通过不占用资源(即线程)来增加应用程序的带宽。类似于添加额外的虚拟机或负载*衡器来处理额外的流量。然而，无论系统的带宽如何，也无论使用非阻塞还是阻塞架构，每个用户或客户端仍可能经历高延迟。 *对于我们的例子，更好的解决方案可能是使用内存中的散列表，比如 Redis，通过会话令牌进行查找。更低延迟的解决方案是使用 JSON Web 令牌(JWT ),其中安全认证和授权只需要 CPU 周期。
一些框架，比如 Node，被设计成自下而上的非阻塞 IO。然而，在其他框架中(比如 PHP 或 Ruby on Rails)，在后台线程上执行 IO 或处理繁重的任务是很重要的。
被动中间件
尽管存在上述 NIO 的局限性，但这并不是说它对减少延迟没有好处。特别是对于只写 I/O 的被动中间件，将中间件设计成非阻塞或异步的是理想的。例如，Moesif 的中间件不修改响应，所以 HTTP 管道没有理由等待任何对 Moesif 的写入。因此，我们将 Moesif 中间件设计成异步的。
对于 PHP Laravel 这样的阻塞框架，您可能需要实现自己的异步方法。对于 Moesif Laravel 中间件，我们利用一个 unix fork 在一个单独的进程中处理向 Moesif 发送任何数据。
令人惊讶的是，在 linux 中派生一个进程是一个轻量级的任务。关于原因的更多信息，请阅读每个 web 开发者应该知道的关于 CPU Arch 的事情
排序
每个中间件都被实例化为管道中的一个步骤，因此排序对于功能正确性可能很重要。然而，即使两个中间件可以重新排序，您也应该考虑性能或安全问题。具有短路返回路径的轻量级中间件应该在较重的中间件之前。
例如，通过 301 永久重定向将非 HTTPS 重定向到 HTTP 域的中间件应该放在解压缩和解析请求体的中间件之前。否则，你就是在浪费 CPU 周期来解压一个将被丢弃的身体。
还要考虑安全性和 DDoS 保护。如果只有一个特定的 IP 地址白名单被允许访问您的 API，而所有其他的都被拒绝，那么您可能希望在执行昂贵的操作(如查询数据库中的帐户信息)之前检查 IP 地址。
基本框架
通常，您正在使用的框架实际上是建立在另一个框架之上的。例如，Ruby on Rails 构建在 Rack 之上。所以当你在构建一个 rails 中间件时，你实际上是在为 Rack 构建一个。
这可以为你所用。在 Moesif，我们不需要为每个 Java 框架创建一个单独的中间件。相反，我们发布了一个单独的 Java Servlet SDK。许多现代 Java 框架都是建立在 Java Servlet 之上的，比如 Spring、Struts 和 Jersey。有时，您可以选择在 Java Servlet 之类的基础框架上构建，或者在 Spring 之类的高级 web 框架上构建。
结束语
构建中间件会迫使您深入研究每个框架更多底层技术。框架的许多公共服务(比如认证和主体解析)都是作为中间件实现的。
您是否花费大量时间调试客户问题？
Moesif 使 RESTful APIs 和集成应用的调试更加容易
什么是产品导向型增长，为什么它对 API 优先的公司至关重要？
有一种普遍的误解，认为产品导向的增长意味着企业不关注销售。事实并非如此。只是在客户旅程的后期，产品导向的增长会在销售中层层叠加。这可能是一种非常有效的方法，特别是当它与深入的数据洞察相结合来推动增长时。
对于 API 优先的公司来说，这种以产品为导向的方法是成功的基石。我们将在下面深入探讨为什么它如此重要的细节，但首先让我们从基础开始…
什么是产品导向型增长？
产品导向型增长正如其名称所暗示的那样——获取、激活、扩张和保留主要是由产品导向的。客户要么使用产品的免费版本，要么支付象征性的费用来使用它，只有在客户有机会直接看到产品的价值后，销售才会进入等式。
在产品主导的模式下，推动销售的是产品本身。通过使用该产品，在公司客户支持团队的支持下，同时在销售团队的支持下，客户几乎无缝地通过产品采用的四个阶段:激活、扩展、保留和采用。
不同的销售方式
使用产品导向的增长模式并不意味着假设产品自我销售，没有销售人员。这只是意味着销售团队关注人们实际上在用产品做什么，而不是坐在那里分析目标行业和创建理想的客户角色。他们的目标是增加现有客户的账户，而不是向冷淡的潜在客户销售。
通过在客户旅程的后期阶段进行分层销售，任务的性质发生了根本的变化。推销产品需要更少的努力，因为客户已经熟悉它和它所能提供的价值，所以推销新东西的努力就被消除了。相反，销售工作更多的是为组织创造更多的价值。这可能是让更多的团队使用产品，增加产品的使用率，或者找到更多的用例，以便客户升级到更高价值的计划。
谈到产品导向的增长，销售人员和客户成功团队之间有着紧密的联系。客户成功员工致力于确保客户从产品中获得最大收益——他们了解产品的价值，如何充分利用产品，以及产品如何为他们的业务带来最大利益。虽然重点是确保客户获得价值，而不是销售，但展示产品的潜力可以导致更深层次的整合和不断增长的使用。产品对客户的成功变得越来越重要。
为什么产品导向的增长对 API 优先的公司如此重要？
产品导向型增长并不适合所有企业。例如，如果你在销售太阳能电池板，前期成本和安装过程就排除了使用产品导向的增长方式。然而，对于 API 优先的公司来说，让客户试用产品的成本和努力是最小的，产品导向的增长模式可能特别有效。
其中一个原因是，他们在一个购买变得更加分散的领域销售产品。个人开发人员将寻找适合他们特定用例的解决方案，并且他们可以以最低的成本试用。这些开发人员通常对销售和营销团队持怀疑态度，因此在做出任何重大承诺之前使用产品的实践性质在多个层面上起作用。
将技术团队作为一个整体进行销售可能会很困难。他们有源源不断的更高优先级的任务要处理，当你试图引入新事物时，你正在与“这里没有发明综合症”作斗争。事实上，当您尝试向他们销售新产品时，许多开发人员自然倾向于怀疑他们是否能够自己构建它！
产品导向的增长避开了这场艰苦的战斗，取而代之的是工程师们以他们自己的方式和速度发现产品。如果集成很容易，通过采用产品导向的方法，API 优先的公司正在授权个人开发者围绕为他们工作的 API 解决方案作出决定。一旦开发人员加入进来，与首席执行官的对话就变得容易多了。
向开发商销售
为开发人员提供一种快速且经济的方法来测试 API，意味着他们可以用它来试验并证明这个概念。试用计划中负担得起的产品意味着在经理的信用卡上弹出一些东西，而不是通过繁琐的采购和法律审查过程。API 优先的公司，如果定价和 swift 集成正确，可以极大地减少产品上市过程中的摩擦。
这并不是完全绕过采购。远非如此。它是为开发者提供一个了解产品的简单机会——直接体验它，看看它对业务有多适合。给他们点击率高的服务条款、快速集成和他们可以用经理的信用卡支付的价格，你就为一个小规模的概念验证试验奠定了基础，这个试验有可能带来未来销量的突然飙升。随着所有相关的采购活动的进行，法律的束缚在后来的阶段自然地跳过了。
正确计费
这种以产品为导向的增长方式需要围绕你的计费模式进行一些思考。这就是基于使用的计费发挥作用的地方。开发人员可以支付象征性的费用来开始使用该产品，并在他们完成概念验证的同时在他们的测试帐户中试用该产品。之后，当开发人员将产品投入生产时，基于使用量的计费模型需要随着客户使用量的增长而扩展。
API 非常适合这种现收现付的计费方式，因为有多种方法可以跟踪它们的使用。请确保您使用了正确的指标！从广义上讲，价值指标可以集中在以下几个方面:
- 交易量 API 调用次数、发送的消息数
- 收入/成本份额–收入百分比、交易费
- 数据量–发送的千兆字节，生成的分钟数
- 用户–每月活跃的独立用户
- 资源–计算单位、活动时间
这些例子暗示了可以嵌入基于使用的计费的巨大多样性。他们还强调了正确计费的复杂性。
以电子邮件自动化 API 为例，它允许客户创建电子邮件模板并向潜在客户发送电子邮件。以模板数量为中心的基于使用情况的定价可以让客户存储 1，000 个模板，并且发送零封电子邮件。客户将从产品中获得零价值，同时收到巨额账单，这使他们成为高风险客户。然而，基于发送的电子邮件数量或联系的不同联系人的账单，将与客户从产品中获得的真正价值密切相关，因此更有可能继续使用该产品。这就是实施正确的价值指标如此重要的原因。
数据驱动的销售
使用数据推动销售是这里的关键。您的客户成功团队的支持需要在客户使用量不断增长的适当时机，无缝地融入与销售人员的对话中。为此，API 至上的公司需要数据。
通过跟踪客户健康状况和使用增长，销售团队可以在恰当的时候与客户展开讨论，以确保客户从其产品中获得更多价值。他们可以创建一个考虑当前使用情况和未来增长计划的计划。
这就是 Moesif 发挥作用的地方，它提供了一个可扩展的解决方案，该解决方案具有自动资源，可以标记使用量的增加，并建议(例如)进行讨论，以确保客户仍然采用最有价值的计划来满足他们的需求。
但是追踪使用数据不仅仅是为了找到合适的销售时机。这也是为了确保客户不会在使用量增加后收到巨额意外账单，然后由于成本意外上涨而取消。相反，销售人员适时打电话讨论更合适的计划可以确保客户觉得他们仍然物有所值，即使他们的账单增加了。
如何用你的产品吸引开发者
希望自己的产品引领发展的 API 优先公司不必坐等开发者发现它们。他们需要主动推销产品，以确保开发人员听说过它，并看到它有足够的潜力来试用它。
这意味着对开发人员体验的大量投资需要投入到鼓励与产品的初始接触中，并使开发人员更容易进行第一次概念验证。这可以通过教程、演示、技术文档、博客帖子、网络研讨会等方式实现。这种性质的内容成为销售漏斗不可或缺的一部分，因为它支持开发者首先试用产品。
在这种以产品为导向的模式下，易用性成为重中之重。从注册指南到集成演练，入职需要超级简单，因为每个绊脚石都会降低产品成功的可能性。与此同时，入职和试用流程需要尽可能实现自助服务，否则将无法轻松或快速地扩展。
同样，定价和包装模式在这里也很重要。许多公司都可以使用自助服务试用版，因此计费选项需要围绕各种各样的需求来构建。然而，每种模式的核心都需要低价来最初激活客户，并支持他们参与产品。在那之后，一旦他们意识到产品对他们的业务有多么有价值，是时候让 API 优先的公司让他们的销售团队施展他们的魔法了。
什么是产品留存率，如何提高产品留存率？
产品保持率是检查企业健康状况的一个极其重要的指标。计算你的企业的保留率将返回给定时间段内继续使用你的产品或服务的用户的百分比。保留率实际上可以被视为衡量客户忠诚度的一个标准，也是您与新客户或现有客户关系质量的一个很好的反映。如何提高客户保持率是许多企业非常关心的问题，制定一个伟大的客户保持战略是解决这个问题的最佳途径。如果你能设法保持低客户流失率并继续留住客户，那么在获取客户方面做得很好才有意义。
客户保持率低可能是你的产品有问题的主要标志，包括产品价值的价格过高。高客户保持率意味着你当前的客户重视你的产品，产品的持续使用带来了可持续的收入来源。保持力分析很容易执行，但是使用像 Moesif 这样的*台来创建保持力分析是随着时间的推移跟踪客户保持力的最佳方式。让我们来看看保留报告每个部分的细节，以及如何在 Moesif 中创建和解释它们。
API 优先业务的产品保留
如果你的业务是 API，那么衡量产品留存率就有点不同了。衡量开发人员门户的登录情况可能不准确，因为开发人员通常不会每天或每周登录管理门户。衡量原料药产品保留率的最佳方法是通过一致的原料药活动。然而，并不是所有的 API 流量都是相等的。使用 API 流量作为保留报告的基础，需要考虑为客户创造价值的流量，而不仅仅包括任何 API 调用。如果您采用基于使用量的计费模式，为客户带来价值的流量可能与您收取的费用相同。API 业务的客户可能使用不同的 API 来满足不同的需求，这意味着您可能需要一种方法来过滤客户可能发送的特定字段或数量。例如，不应在保留报告中考虑 4xx 或 5xx HTTP 错误响应代码，因为这些通常是错误情况，会扭曲保留分析。
确定第一个事件并返回事件
当我们考虑客户保留时，有两个重要事件用于确定用户是否被保留。初始事件被称为“第一个事件”，这将是您的保留报告开始的地方。第一事件可以通过确定用户何时第一次从产品接收价值来确定。对于电子商务*台，这可能是用户第一次实际创建采购订单。如果你是一个通信*台，第一个事件可能是用户通过该*台发送一条短信。您也可以将其推广为任何 API 调用。
保留分析的第二部分是当用户执行一个返回事件时，表明他们是一个回头客。返回事件是指客户返回*台，并执行一项活动，从产品中获得价值。通常，这是在第一个事件中执行的相同类型的事件，但也可能是完全不同的事情。每次用户执行返回事件时，他们都被视为保留用户。当用户不再执行返回事件时，用户不再被保留并且可能不再使用该产品。
在 Moesif 中创建保留报告
在 Moesif 中创建保留报告很容易。第一步是导航到用户屏幕。一旦进入屏幕，接下来你要做的就是从屏幕左上方的下拉菜单中选择保留。
现在在保留屏幕上，您可以指定第一事件和返回事件。在本例中，我们将着眼于创建一个简单的保留分析，其中当用户在*台上进行购买和重复购买时，第一个事件和返回事件。我们还将通过指定响应状态代码等于 200 或 201 来确保仅包括成功的结账，表示成功的调用。下面是它在 Moesif 中的样子。
在 Moesif 中，如果未指定事件，Moesif 将根据为该用户接收的任何事件来计算保留时间。这有时很有用，但通常更准确地选择特定的第一个和返回事件。正如你所看到的，Moesif 自动创建了一个图表，描绘出客户保持曲线。
添加分段和分组
为了进一步细分保留报告，我们还可以考虑向数据添加分段和分组。
对于细分，我们可能希望只包括执行了某项活动的客户或属于我们客户群中某个细分市场的客户。例如，在我们之前构建的示例的基础上，我们可以添加一个细分子句，以查看企业和非企业客户在保留率方面的差异。为此，我们将添加细分市场，以区分这两种类型的客户。下面是一些例子。
另一个观察分析的角度是使用按分组的功能。这使我们能够看到不同用户群的保留情况。例如，我们可以将前面的示例改为只查看非企业客户，并添加一个 Group By ，以便按照 UTM Source 对该细分市场内的客户进行分组。这将向我们展示，根据用户来自哪个 UTM 来源，他们的客户保持率是什么样的。这可以帮助我们了解在创造忠诚客户时，哪些策略有效，哪些策略无效。这就是它的样子。
有了这两个额外的特性，我们可以真正深入挖掘客户维系的各个方面，并得出比没有细分和分组更深入、更具体的见解。
解释留存报告
当实际查看保留报告时，了解您正在查看的内容非常重要。有几个场景显示了健康的保留，其他场景显示了不健康的保留或需要改进的保留。
保持力高/最佳
最佳保留率因行业而异，因此很难说您希望您的保留率达到什么水*。也就是说，有很多研究显示了行业的*均保留率，包括 ProfitWell 在 2020 年完成的这项研究。在此报告中，我们可以看到以下按行业划分的*均保留率:
- 零售:63%
- 银行业:75%
- 电信:78%
- IT: 81%
- 保险:83%
- 专业服务:84%
- 媒体:84%
根据你所在的行业，你显然希望确保你的留存曲线开始快速变*，并大致保持在这些目标附*。同样重要的是，看看你在做什么来保持这么高的客户保留率，并继续这样做来留住忠诚的客户。如果随着你对入职、业务流程、市场营销和其他因素的改变，保留率开始下降，你可能要考虑恢复到保留率较高时的策略。很可能你的服务或应用程序的体验没有达到客户的期望。你的客户保持策略应该始终以尽可能保持高的客户保持率为目标。
张力迅速下降
如果留存率迅速下降到较低水*，这通常意味着客户对产品不满意，或者没有从产品中获得价值来证明退货的合理性。如果您按月查看留存率，到第二个月留存率显著下降，您可能希望查看更短时间段的留存率，例如每周甚至每天。在记忆力差的情况下，好的一面是小的变化可能会导致巨大的差异。当保留率很低时，你需要继续密切关注潜在的改进，因为低保留率会给许多企业带来灾难。
保留报告没有显示多少历史记录
如果您的业务仅开展了 4 周，或者您仅跟踪了 4 周的留存率，那么很难查看 12 个月的留存率，因为数据不存在。如果您发现您的保留报告比您预期的更快停止，您需要确保您有足够的数据来支持您正在尝试查看的时间跨度。如果您的数据有限，请考虑使用更短的时间单位，例如每天或每周查看保留时间，直到您的数据增长到足以每月或每年进行评估。
当然，每家公司对他们应该保留的员工都有不同的期望。你很可能属于上述三种类型中的一种，甚至可能是多种。一旦你评估了你的记忆力，下一步就是保持它，或者更有可能的是，提高它。接下来，让我们看看提高记忆力的一些方法。
提高保持力的技巧
保持能力可能有点难，但是跟踪保持能力的指标是提高保持能力的第一步。有很多方法可以提高记忆力，根据你所处的行业，有些方法可能比其他方法更适用。这里有一些留住客户的策略，你可以尝试一下，从更多的忠诚客户中建立你的客户群。
完善您的入职流程
没有什么比糟糕的客户入职流程更能迅速吓跑新客户了。如果客户从未充分参与进来并发现你的产品的价值，就很难留住他们。这就是为什么提高你的入职培训是提高用户保持率的最佳方式。出色的入职体验通常会带来出色的客户体验，从而快速交付满足客户需求的解决方案。要了解您的入职流程在当前状态下的情况，您可能需要查看以下指标:
- 有多少用户正在开始入职流程，但尚未完成？
- 大多数人都放弃了入职流程。
- 在入职流程的哪个阶段，用户更有可能坚持到底？
一个极其复杂和漫长的入职流程会很快扼杀员工的忠诚度。用户发现价值的时间越短，你的入职就越有影响力。要使用 Moesif 深入了解入职，您可能希望使用我们的用户渠道功能来查看入职流程中的每一步，有多少人转换到下一步，以及完成每一步需要多长时间。更好的入职体验可能是通过改善整体客户体验来真正提高保留率的秘诀。
通过客户反馈调查吸引客户
喜欢你的产品的优秀客户可以回答一些关于他们为什么继续使用你的产品的问题。放下你的产品的顾客也可以提供同样多的见解。通过对这两类客户的客户调查获得客户反馈，可以深入了解用户留下和离开的原因，这是保持方程的核心。使用客户调查来建立定性的客户数据可以帮助你了解客户建立品牌忠诚度的快乐程度。
对于留下来的用户来说，询问他们最喜欢产品的哪些方面、他们属于哪个人群以及产品的哪些部分可能会让他们离开是很重要的(这可能是关于功能、可靠性甚至价格的问题)。一旦你发现是什么留住了用户，并发现了一些趋势，你就可以加倍努力，试图将这些好的氛围传播给新的和其他现有的客户。至于负面反馈，这可以优先考虑，以确保问题得到解决，从而提高保留率。
更重要的是，尤其是如果你的留存率已经很低的话，弄清楚为什么以前的用户会离开这个*台。在一个简短的调查中，你可以问这些客户他们为什么离开，怎样才能让他们回来。这将让你对问题和潜在的解决方案有更深入的了解，让你走上改进产品的正确道路，并有望提高客户保留率。一旦产品得到改进，你甚至可能会想联系这些以前的用户，让他们知道他们的反馈已经被听取，你很想让他们尝试你的新的和改进的体验。
客户反馈调查是一种非常有效的方式，可以获得对一些最大的客户体验和保留问题的简洁反馈，并可能帮助您发现影响客户满意度的问题，这些问题您甚至从来不知道。
一旦获得客户，不要停止营销
一旦有人注册、加入并使用了产品，许多公司就会停止营销。从逻辑上讲，这可能有道理，但实际上，这与事实相去甚远。你应该始终致力于吸引用户，让他们把你的产品和服务放在第一位。这可能包括时事通讯、产品发行说明和其他重要内容，以保持用户参与并发现产品的新价值。与客户保持联系并继续推广您的产品是让客户再次使用该产品并发现释放其价值的新途径的好方法。这应该是企业实施的几乎所有客户保留策略的基石。
对这种方法的一个很大的警告是，确保您使用智能自动化来持续向现有客户营销。使用包含与用户相关内容的个性化电子邮件，对于保持收到价值和被惹恼之间的界限至关重要。使用应用程序中的事件来驱动特定的电子邮件可能是一种很好的方式，例如当用户第一次使用某个功能时，您可以通过电子邮件向他们发送概述或文档链接，这样他们就可以根据需要深入了解。在 Moesif 中，可以通过使用行为电子邮件来进行这种类型的电子邮件营销，您可以根据应用程序的使用情况或应用程序中的特定事件或客户行为来触发特定的电子邮件。这可以作为一种方式来保持对现有客户的营销，同时也确保您提供良好的自动化客户支持。您还应该确保发送的电子邮件数量不会让用户不堪重负，从而有可能将您列入黑名单或退订名单。
使用 Moesif 提高保留率
现在，您已经知道了什么是客户保持率，为什么它很重要，以及一些关于如何提高客户保持率的技巧，您可以开始使用 Moesif 跟踪客户保持率指标。还没有使用 Moesif 吗？立即注册开始行动，在几分钟内开始跟踪和提高客户保持率和客户忠诚度。无论您是使用我们的保留分析来跟踪您的客户保留率，还是使用行为电子邮件或其他功能来帮助提高客户保留率，Moesif 都可以帮助您提高客户成功和保留率。让 Moesif 帮助您建立一个有效的客户保留策略，因为保留一个忠诚的客户是增加收入和增加客户终身价值的最有效的方法。
关于熔毁的技术深度探讨，它有用吗？
原文：https://www.moesif.com/blog/technical/cpu-arch/What-Is-The-Actual-Vulnerability-Behind-Meltdown/
Meltdown 无疑席卷了互联网。攻击看起来非常简单和优雅，然而白皮书遗漏了特定漏洞的关键细节。它主要依赖于缓存计时旁路和访问全局映射内核页面的推测性执行的组合。
这种深入探讨假设您对 CPU 架构和操作系统内核行为有所了解。首先阅读背景章节了解分页和内存保护的基础知识。
攻击的简化版本:
- 推测性内存读取内核映射(管理程序)页面，然后对值执行计算。
- 基于计算结果，有条件地从存储器向某个其他非缓存位置发出加载。
- 虽然当出错异常退出时，第二次加载将从流水线中被核爆，但是它已经向 L2 发出了加载请求，并且除了确保未完成的存储器请求仍然像预取一样将线带入高速缓存层次结构之外。
- 最后，一个单独的进程可以向这些相同的内存位置发出加载，并测量这些加载的时间。高速缓存命中将比高速缓存未命中快得多，高速缓存未命中可用于表示二进制 1(即命中)和二进制 0(即未命中)。
第 1 和第 2 部分。与指令的推测性执行有关，而第 3 部分和第 4 部分使微体系结构状态(即在高速缓存中或不在高速缓存中)能够提交给体系结构状态。
攻击可信吗？
Meltdown 白皮书中没有规定的是，什么样的特定 x86 指令序列或 CPU 状态可以支持推测性地执行内存访问，并允许向量或整数单元消耗该值。或 L2 元。在现代英特尔 CPU 中，当发生错误(如页面错误)时，管道不会被挤压/核化，直到违规指令退役。然而，在加载甚至在 L1D$中查找或转到内存之前，在所谓的地址生成(AGU)阶段和 TLB 查找阶段完成了对页面保护、分段限制和规范检查的内存权限检查。以下是更多相关信息。
执行内存权限检查
英特尔 CPU 执行物理标记的 L1D\(和 L1I\)需要将线性(虚拟)地址转换为物理地址，然后 L1D$才能通过标记匹配来确定它在缓存中是命中还是未命中。这意味着 CPU 将尝试在(翻译后备缓冲区)TLB 缓存中查找翻译。TLB 将这些转换与页表或页目录许可一起缓存(访问页所需的特权也与物理地址转换一起存储在页表中)。
TLB 条目可能包含以下内容:
- 有效的
- 物理地址减去页面偏移量。
- 读/写
- 用户/主管
- 进入
- 肮脏的
- Memtype
因此，即使推测加载已经知道访问该页所需的权限，也要与当前特权级别(CPL)和所需的 op 特权进行比较，因此可以阻止任何算术单元消耗推测加载。
此类权限检查包括:
- 分段限制检查
- 写入故障
- 用户/主管故障
- 页面不存在故障
这就是许多 x86 CPUs 实际上被设计用来做的事情。当 op 失效时，负载将被拒绝，直到故障被软件/uCode 处理。负载将在去往整数/向量单元的途中被清零。换句话说，用户/管理员保护故障类似于页面不存在故障或其他页面翻译问题，这意味着从 L1D$中读出的行应该立即丢弃，并且微操作简单地进入等待状态。
防止整数/浮点单元消耗故障负载不仅有利于防止这种泄漏，而且实际上可以提高性能。即，如果 L2\(未命中 L1D\)，则故障加载不会用坏数据训练预取器、分配缓冲区来跟踪内存排序或分配填充缓冲区来从其获取数据。这些是现代 CPU 中有限的资源，不应该被那些不太好的负载消耗掉。
事实上，如果加载错过了 TLB，必须执行页面遍历，如果在遍历期间发生故障，一些英特尔 CPU 甚至会终止 PMH 中的页面遍历(页面错过处理程序)。页面遍历执行了大量的指针追踪，并且必须消耗宝贵的加载周期，所以如果它在以后被丢弃的话，取消它是有意义的。此外，PMH 有限状态机通常只能同时处理几个页面遍历。
换句话说，从性能角度来看，中止 L1D Load uOp 实际上是一件好事。媒体文章称英特尔下滑是因为他们试图以较低的安全性为代价获取尽可能多的性能，这是不真实的，除非他们想声称推测和缓存的基本概念被认为是折衷。
狐狸
虽然这并不意味着熔毁漏洞不存在。这个故事不仅仅是白皮书和大多数新闻帖子所讨论的。大多数帖子声称，只有投机性内存访问和高速缓存计时攻击的行为才能造成攻击，现在英特尔必须彻底重新设计其 CPU 或消除投机性执行。
Meltdown 更像是一个逃过英特尔 CPU 验证的逻辑错误，而不是像媒体目前所说的“现代 CPU 架构的根本崩溃”。它可能可以通过硬件中的一些门变化来修复。
事实上，错误修复可能是一些门的改变，在 L1D\(管道中添加正确的拒绝逻辑，以掩盖加载命中。英特尔 CPU 肯定已经获得了这些信息，因为在确定 L1D\)缓存命中之前，必须完成地址生成和 TLB 查找阶段。
导致漏洞的所有场景都是未知的。是某些 CPU 设计错过了对这种架构行为的验证吗？是绕过这些检查的特殊 x86 指令序列，还是设置 CPU 状态以确保实际执行加载的一些附加步骤？Project Zero 认为，只有在 L1D$中出现故障负载时，攻击才会发生。也许英特尔在未命中路径上有逻辑，但在命中路径上有逻辑错误？如果某些英特尔 OoO 设计对崩溃免疫，我不会感到惊讶，因为这是一个特定的 CPU 设计和验证问题，而不是一般的 CPU 架构问题。
不幸的是，x86 在内存执行单元中有许多不同的流程。例如，某些指令(如 MOVNTDQA)在 L1D$中的内存顺序和流程与标准的可缓存加载不同。Haswell 事务同步扩展和锁增加了验证正确性的复杂性。指令提取通过与 D 端加载不同的路径进行。验证状态空间非常大。算上所有的旁路网络，你就能看到有多少不同的地方需要验证故障检查。
有一点是肯定的，缓存和投机不会很快消失。如果是逻辑上的 bug，对于未来的英特尔 CPU 来说可能是一个简单的修复。
为什么今天这种攻击更容易了？
假设有一条指令即使在有错误的情况下也能使加载命中并消耗，或者我在上面的 catch 中是错的，为什么它现在才发生而不是几十年前才被发现。
-
今天的 CPU 有更深的管道咳普雷斯科特咳这在推测性内存访问和那些出错访问的实际核/挤压之间提供了更宽的窗口。出错指令不被处理，直到该指令退出/提交给处理器架构状态。只有在退役时，管道才会被拆除。长流水线允许在出错指令的执行和它的退出之间有一个大的窗口，允许其他推测性指令跑在前面。
-
与高速缓存命中/整数运算等仅针对 CPU 的快速运算相比，高速缓存层次结构更大，内存结构速度更慢，这在高速缓存命中和高速缓存未命中/内存之间提供了更大的周期时间差，从而支持更强大的高速缓存计时攻击。今天的大型多核服务器 CPU 使用精心制作的网状结构来连接数十或数百个内核，这一点被夸大了。
-
x86 CLFLUSH 和 PREFETx 等细粒度缓存控制的性能增强特性为缓存计时攻击提供了更多控制。
-
更广泛的处理器，可同时支持并行整数、浮点和内存操作。人们可以将长浮点操作(如 divide 或 sqrt)放在出错指令之前，以保持内核忙碌，但仍然保持整数和内存管道不受攻击。由于出错的指令在退役之前不会核化流水线，所以它必须等到指令序列中任何更早的指令被提交，包括长时间运行的浮点运算。
-
虚拟化和 PaaS。许多网络规模的公司现在都在运行工作负载云提供商，如 AWS 和 Azure。在云计算出现之前，财富 500 强公司会在自己的硬件上运行自己的可信应用。因此，不同公司的应用程序在物理上是分离的，这与今天不同。虽然 Meltdown 是否允许来宾操作系统侵入虚拟机管理程序或主机操作系统尚不清楚，但已知的是许多虚拟化技术比成熟的 VT-x 更轻量级。例如，Heroku、AWS Beanstalk 或 Azure Web 应用程序中的多个应用程序以及 Docker 容器都在同一个虚拟机中运行。公司不再为每个应用程序配置单独的虚拟机。这可能允许恶意应用程序读取特定虚拟机的内核内存。在 90 年代，随着 Pentium Pro/Pentium III 的出现，OoO 执行成为主流，共享资源不再是一个问题。
-
在 x86 分页条目中使用全局位和用户/管理员位，这使得内核内存空间能够映射到每个用户进程(但受到保护，不会执行 Ring3 代码),从而降低 TLB 的压力，并减缓上下文切换到独立内核进程的速度。这种性能优化从 20 世纪 90 年代就开始了
这是 x86 特有的吗？
首先，缓存计时攻击和推测性执行并不是英特尔或 x86 CPUs 所特有的。大多数现代 CPU 在你的手表或微波炉的几个嵌入式微处理器之外实现多级缓存和大量的推测。
这不是英特尔或 x86 的特定问题，而是一般 CPU 架构的基本问题。现在有人声称，特定的 OoO ARM CPUs，如 iPhones 和智能手机中的 CPU，也存在这一缺陷。乱序执行自从被 Tomasulo 算法引入以来已经完成。与此同时，缓存计时攻击几十年来一直为人所知，因为众所周知，数据可能会在不应该的时候被加载到缓存中。然而，缓存计时攻击传统上被用来寻找内核内存的位置，而不是实际读取它的能力。这更像是一种竞争条件和窗口，具体取决于微体系结构。一些 CPU 的管道比其他 CPU 浅，导致核爆发生得更快。像 x86 这样的现代桌面/服务器 CPU 具有从 CLFLUSH 到 PREFETCHTx 的更精细的功能，这些功能可以作为附加工具来使连接更加健壮。
内存分页的背景
自从在 386 和 Windows 3.0 中引入分页以来，操作系统就一直使用这一功能来将一个进程的内存空间与另一个进程的内存空间隔离开来。一个进程将被映射到它自己独立的虚拟地址空间，该空间独立于另一个正在运行的进程的地址空间。这些虚拟地址空间由物理内存支持(页面可以换出到磁盘，但这超出了本文的范围)。
例如，假设进程 1 需要 4KB 内存，因此操作系统分配了 4KB 的虚拟内存空间，其字节可寻址范围从 0x0 到 0xFFF。该范围由从位置 0x1000 开始的物理内存支持。这意味着进程 1 的[0x0-0xFFF]被“安装”在物理位置[0x1000-0x1FFF]。如果有另一个进程正在运行，它也需要 4KB，因此操作系统将为这个进程 2 映射第二个虚拟地址空间，范围为 0x0 到 0xFFF。这个虚拟内存空间也需要物理内存的支持。由于进程 1 已经在使用 0x1000-0x1FFF，操作系统将决定为进程 2 分配下一块物理内存[0x2000-0x2FFF]。
在这种设置下，如果进程 1 从内存向线性地址 0x0 发出加载请求，操作系统会将其转换为物理位置 0x1000。而如果进程 2 从内存向线性地址 0x0 发出加载，操作系统会将其转换为物理位置 0x2000。注意这里需要一个翻译。这是页表的工作。
网络世界中的一个类比是，在一台主机上运行的两个不同的 Docker 容器如何将容器内的同一个/data dir 挂载到主机上的两个不同的物理位置/data/node0和/data/node1。
一系列映射内存被称为一个页面。CPU 架构有一个定义的页面大小，如 4KB。分页允许内存在物理内存空间中分段。在上面的例子中，我们假设页面大小为 4KB，因此每个进程只映射一个页面。现在，让我们假设进程 1 执行一个 malloc()并强制内核映射第二个 4KB 的区域。由于物理内存的下一页[0x2000-0x2FFF]已经被进程 2 使用，操作系统需要分配一个空闲的物理内存块[0x3000-0x3FFF]给进程 1 (注意:现代操作系统使用延迟/惰性内存分配，这意味着虚拟内存可以在被任何物理内存支持之前被创建，直到页面被实际访问，但这超出了本文的范围。请参阅 x86 页面访问/脏位了解详情)。
地址空间看起来与进程相邻，但实际上是跨物理内存空间的碎片:
流程 1
| 虚拟内存 | 物理内存 |
|---|---|
| [0x0-0xFFF] | [0x1000-0x1FFF] |
| [0x1000-0x1FFF] | [0x3000-0x3FFF] |
流程 2
| 虚拟内存 | 物理内存 |
|---|---|
| [0x0-0xFFF] | [0x2000-0x2FFF] |
在此之前还有一个额外的转换步骤，使用 x86 分段将逻辑地址转换为线性地址。然而，今天大多数操作系统不使用传统意义上的分段，所以我们现在忽略它。
内存保护
除了创建虚拟地址空间，分页也是一种保护形式。上述翻译存储在一个名为页表的结构中。每个 4KB 页面可以有特定的属性和访问权限，与翻译数据本身一起存储。例如，可以将页面定义为只读。如果对内存的只读页面执行内存存储，则 CPU 会触发一个故障。
直接来自 x86 参考手册，下面的非穷举属性位列表(其行为类似于布尔真/假)与每个页表条目一起存储:
| 少量 | 名字 | 描述 |
|---|---|---|
| P | 礼物 | 必须为 1 才能映射 4 兆字节的页面 |
| 读写 | 读/写 | 如果为 0，则可能不允许对该条目引用的页面进行写操作 |
| 美国 | 用户/主管 | 如果为 0，则不允许用户模式访问此条目引用的页面 |
| A | 进入 | 指示软件是否访问了此项引用的页面 |
| D | 肮脏的 | 指示软件是否已写入此条目引用的页面 |
| G | 全球的 | 如果 CR4。PGE = 1，确定转换是否是全局的，否则忽略 |
| 无红利(ex-dividend) | 禁止执行 | 如果 IA32 EFER。NXE = 1，execute-disable(如果为 1，则不允许从此项控制的 4k 字节页面获取指令；参见第 4.6 节)；否则，保留(必须为 0) |
最小化上下文切换成本
我们展示了每个进程如何拥有自己的虚拟地址映射。内核进程和其他进程一样，也有一个虚拟内存映射。
当 CPU 将上下文从一个进程切换到另一个进程时，切换成本很高，因为许多体系结构状态需要保存到内存中，以便挂起的旧进程在再次开始执行时可以使用保存的状态继续执行。
然而，许多系统调用需要由内核来执行，如 I/O、中断等。这意味着 CPU 会不断地在用户进程和内核进程之间切换，以处理这些系统调用。
为了最小化这个成本，内核工程师和计算机架构师将内核页面映射到用户虚拟内存空间中，以避免上下文切换。这是通过用户/管理员访问权限位完成的。操作系统映射内核空间，但只将其指定为管理员(也称为 Ring0)访问，因此任何用户代码都不能访问这些页面。因此，这些页面对于任何在用户权限级别运行的代码来说都是不可见的
在用户模式下运行时，如果 CPU 发现指令访问需要管理员权限的页面，则触发页面错误。在 x86 中，页面访问权限是能够触发 #PF(页面错误)的分页相关原因之一。
全球位
我们展示了每个进程如何拥有自己的虚拟地址映射。内核进程和其他进程一样，也有一个虚拟内存映射。大多数翻译都是进程私有的。这确保了进程 1 不能访问进程 2 的数据，因为不会有从进程 1 到【0x2000-0x2FFF】物理内存的任何映射。然而，许多系统调用由许多进程共享，以处理发出 I/O 调用、中断等的进程。
通常，这意味着每个进程将复制内核映射，这给缓存这些翻译带来了压力，并增加了进程间上下文切换的成本。全局位使这些特定的转换(即内核内存空间)在所有进程中可见。
结束语
探究安全问题总是很有趣的。与 20 世纪 90 年代不同，现在的系统被认为是安全的，并且随着加密、生物识别验证、移动支付和数字医疗的发展，系统变得更加重要。对于今天的消费者和企业来说，大臀位比 90 年代更可怕。同时，我们也需要继续讨论新的报告。
引发熔毁漏洞的步骤已被各方证明。然而，导致崩溃的可能不仅仅是投机和缓存计时攻击的行为，也不是 CPU 架构的根本故障，而是一个逃过验证的逻辑错误。这意味着，猜测和缓存不会很快消失，英特尔也不会需要一个全新的架构来修复崩溃。相反，未来 x86 CPUs 中唯一需要的变化是对组合逻辑进行一些小的门更改，这些更改会影响确定 L1D$(或任何临时缓冲区)中的命中是否是好的。
API 可观察性和 API 监控之间有什么区别
API 监控的传统定义在 SmartBear、APIMetrics 和 Runscope 等公司已经存在多年，对于检查 API 的正确性和性能非常有用。API 监控工具针对您选择的端点启动 API 调用，然后记录收到的响应。可以添加额外的检查，例如在 500 错误或超时时创建松弛警报。测试可以在触发时启动(例如当您的 CI/CD 管道部署了新版本时)，也可以按循环时间表启动(例如每 1 分钟)。API 监控测试可以是简单的，比如简单的健康和正常运行时间检查，也可以是非常复杂的，通过一长串 API 调用运行，并检查特定的状态代码、主体字段等等。
虽然 API 监控使您能够检查正常运行时间，并在 API 超时或响应 500 个错误时采取措施，但它也有局限性，因为它是一种黑盒形式的监控，具有提前创建的断言检查。测试或探测已经提前知道，这意味着 API 监控无法回答关于你的 API 如何运行的任意问题。相反，API 监控只能检查它生成的流量，而不是实际的客户 API 流量。随着越来越多的 API 暴露在互联网上，有了新的需求来探索和发现未知的未知，以防止 API 威胁，解决客户问题，并了解 API 的使用。这些需求导致了 API 可观察性的出现。
与黑盒测试和监控不同，API 可观察性是一种形式的白盒监控，需要代理或 SDK 被动地将 API 流量记录到可观察性服务中。这种数据收集可以在应用程序中完成，也可以添加一个不同的点，例如使用像 Kong 或 NGINX 这样的 API 网关。
API 可观察性的用例
监控客户体验
API 可观察性可以跟踪用户或客户与您的 API 的每一次交互，这使您能够描绘不同的端到端流，并了解热点可能存在于何处。大多数提供 API 的团队不能完全控制他们的消费者如何使用 API。这些消费者可能来自一个大型组织的另一个部门或产品，也可能来自不同的公司。作为开发人员，我们喜欢假设客户会以特定的方式使用我们的产品，但是 API 集成工作可能会很混乱或者充满错误。例如，您的 API 消费者可能会忽略您关于分页和过滤的建议，从而导致过多的数据被轮询。API 可观察性的目标是主动发现这些未知的未知，并补救它们，无论是您自己的代码还是 API 消费者的代码有问题。
API 问题疑难解答
因为 API 可观察性工具记录了 API 上发生的所有事情，所以您能够探索未知的未知情况，例如客户可能遇到的您以前从未见过的问题。您不需要提前创建一个测试来观察发生了什么。会出现各种各样的 API 问题，有些问题比较容易调查，比如缺少 API 键或 HTTP 头，但其他问题可能要复杂得多，需要跟踪 API 调用的历史和它们的计时。
检测并防范 API 威胁
一个设计良好的 API 可观察性*台不仅可以跟踪 API 上发生的事情，还可以跟踪谁在发出 API 请求，从而实现复杂的用户行为分析(UBA)以及用户和实体行为分析(UEBA)。通过跟踪复杂的用户流，您可以识别可能抓取您的 API 或访问未授权数据的可疑用户。
不像 web 应用程序可以结合像 Capctha 和浏览器指纹这样的技术，API 公开了对数据的原始访问。一些 API 甚至可能让客户以编程方式访问，这使得区分真正的 API 调用和恶意的 API 调用变得极其困难。这使得传统的基于规则的 Web 应用防火墙(WAF)如 ModSecurity 对 API 无用。相反，采用以用户为中心的方法的现代 API 可观测性解决方案可以使用高级异常检测来检测未知的未知。
了解客户 API 的使用
组织构建 API 是为了给 API 的客户或用户创造有价值的东西，而不仅仅是为了构建东西。与 API 安全性一样，这需要一种机制来将 API 调用归因于个人客户及其收入，并且是 API 的用户行为分析(UBA)的另一个用例。寻找 API 分析的常见团队包括产品组织，但也包括跟踪试点使用、试验和扩展机会的销售和增长团队。直到 2015 年，Twilio 的估值才达到 5 亿美元。据 Akamai 称，现在它是一家价值 300 亿美元的公司，所有 HTTP 流量的 83%来自 API 调用。API 不再仅仅是一种“后端技术”，而是一种关键的业务驱动力。
然而，API 调用只讲述了故事的一半(参与)，一个好的 API 可观察性工具还提供了存储客户人口统计和收入(用于货币化和细分)的能力，以及跟踪 API 外部发生的事情，如注册和计划购买。
API 可观察性的支柱
API 指标
API 指标使您能够监控工程和业务 KPI，例如性能和客户使用情况。一些指标跟踪工具只能监控单值指标，如每分钟请求数。然而，可观察性的一个关键主题是能够回答任何关于您的 API 和服务的问题，而无需提前计划哪些指标需要进行监控。在这种情况下，高基数、高维度的指标和数据存储可以方便地探索和回答未知的未知问题，并能够立即切片和切片。
API 日志
像 API 度量一样，API 可观察性*台也能够实时检查 API 调用，以便进行调试和审计。API 日志向您显示即时的准确调用。因为根据定义，API 的结构不同于传统的日志记录，所以 API 日志还可以用于生成聚合和指标，同时维护上下文。然而，API 调用可以有大量的 HTTP 头、主体键和属性。这意味着您的 API 可观察性工具应该能够通过它们进行过滤和聚合，而不需要依赖于对数据存储的全面扫描(这可能需要很长时间)。
GDPR 和 CCPA 要求对 API 日志之类的东西采用新的程序，这些程序在整个公司从安全团队到业务团队都在使用。您不能再简单地将 API 日志转储到日志管理解决方案中。相反，API 企业需要一种方法来导出和删除(或匿名化)特定于单个客户的所有相关日志和事件。这意味着 API 日志必须绑定到某个永久的用户标识符上(而不仅仅是轮换的 API 键)。
API 分析
API 可观察性的第三个支柱是 API 分析。与侧重于回答工程特定问题的 API 度量和日志不同，API 分析侧重于回答产品和业务相关的问题。简单地说，API 分析是 API 指标与关于客户是谁以及他们如何使用您的 API 的数据的融合。很多时候，API 分析工具可以从 CRM 或营销自动化工具等其他系统中提取数据，以便您能够绘制出客户旅程。API 分析可以包括漏斗指标，如有多少人激活和使用您的 API，以了解哪些端点产生的收入或增长最多。
API 跟踪
由于本质上是事务性的，API 包含关于何时发起请求、服务需要多长时间响应等时间的计时信息。不同的计时会产生难以重现的竞争条件和错误。API 跟踪可以很容易地理解不同的服务需要多长时间来响应，以及哪里会出现计时错误。跟踪使您能够进一步探索特定会话或相关 API 调用集要查看的日志。
结束语
任何希望快速自信地发布 API 的人都应该寻找一个 API 可观察性系统。API 为您公司基础设施的其余部分提供了窗口，并实现了全新的数字体验，但传统的监控只能回答已知的问题，如“我的 API 是否停机了”，而不能回答数据驱动的工程和业务团队所需的任意问题，也不能报告安全性和产品分析所需的实际客户 API 使用情况。
数据合规和数据隐私有什么区别？
在部署任何保存客户或用户数据的应用程序时，数据合规性和数据隐私都是需要考虑的重要方面。然而，数据管理的这两个领域有时会被误解。这篇博文将阐明数据合规性和数据隐私之间的区别。
什么是数据合规性？
数据合规性是指在数据的收集、处理和存储方面满足特定法律义务的要求。
例如，在欧洲拥有客户的公司必须遵守通用数据保护条例(GDPR) 。这是一个法律框架，让消费者有权查看公司掌握的关于他们的数据，反对公司对这些数据的处理，并要求公司删除这些数据。同样，在加州拥有客户的公司必须遵守加州消费者隐私法案(CCPA) 。
除了 GDPR/CCPA，其他合规框架的例子还包括健康保险流通与责任法案(HIPAA)、SOC 2 审计框架(T0)和 ISO/IEC 27001 标准(T3)。这可能包括公司为确保数据合规性而建立的一套政策、程序和审计。
什么是数据隐私？
数据隐私涉及保持敏感数据的私密性和机密性。在数据合规性是数据管理的法律方面的情况下，保持数据私密性是一个实际/技术问题。隐私计划的目标是倡导数据隐私，并确保只有授权用户才能在需要知道的基础上查看数据。它包含了典型合规计划之外的元素。
数据隐私通常适用于任何个人身份信息(PII)，即任何可用于识别某人的数据。社会安全号码、电子邮件地址、IP 地址等等都可以被认为是 PII。努力保护数据隐私的公司需要采取措施来保护这些数据的机密性，即使这不是合规性所要求的，因此倡导保护与数据相关的个人的隐私。数据隐私确保机制到位，以确保只有获得授权的人才能访问数据。
存储敏感数据
关于数据合规性和数据隐私的一个误解是，公司不能用任何第三方工具存储其数据，因此必须求助于“内部”解决方案。事实并非如此。第三方工具可能具有强大的访问控制和安全性，并在 SOC 2 和 ISO/IEC 27001 等第三方框架下经过严格审核。然而,“内部”数据存储可能允许许多员工通过一个通用的根密码进行访问，而没有任何健壮的审计日志记录，这可能远远不符合标准。
相反，工程师必须评估工具(无论是内部的还是外部的)，以确保有正确的机制来满足安全性和数据合规性标准。如果公司不像对待外部工具那样对内部工具应用严格的安全措施，数据泄露的可能性就会增加。
合规不仅仅是一个工程问题
GDPR、SOC 2 和其他框架是法律和操作框架。虽然这些框架对工程设计有很大影响，但它们会影响公司从法律、销售到支持的整个运营。如果一家公司需要与另一家公司合作，法律文书工作将为他们这样做铺*道路。在 AWS 中设置一个“安全”的环境并不意味着你符合 SOC 2。将您的数据存储在“内部”数据库中并不意味着您符合 GDPR，因为支持和销售等团队需要一些操作程序。
为了遵守 GDPR 法案，两家公司可能会签署一份通常称为“数据处理附录”的法律文件，该文件定义了不同方之间如何处理和保护数据。它将定义谁是数据控制者，谁是数据处理者，如何处理数据，服务级别协议和违规期间的程序，等等。该协议应涵盖可归类为 PII 的所有数据，并确保其符合相关合规立法的要求。
以 GDPR 为例，这意味着需要有一个适当的流程来满足个人访问、反对和要求删除其数据(无论数据存储在何处)的要求。
保持数据隐私
仅仅因为您遵守 GDPR 或 SOC 2，并不一定意味着数据是私有的，无论数据是存储在第三方工具中还是您的内部解决方案中。数据隐私是一种“超越”合规框架的艺术，尽一切努力确保客户数据的隐私。
有几种不同的方法来确保数据隐私。例如，Moesif *台有一个名为隐私规则的特性，它使您能够使用基于角色的访问控制(RBAC)在需要知道的基础上限制对某些字段的访问。例如，您可以创建一个隐私规则，确保技术支持人员不能查看或检查敏感的 HTTP 头或 PHI(受保护的健康信息)。然而，出于报告目的，分析师可能需要额外的访问字段。这超出了合规性通常要求的范围，以真正确保数据尽可能保密。
保持数据隐私的第二种方法是通过客户端加密，这是降低数据泄露风险和改善数据隐私状况的最新趋势。客户端加密使您能够使用一组轮换加密密钥来加密数据，只有极少数员工能够访问这些密钥。维护底层数据基础设施和处理管道，但没有查看实际数据的业务需求的工程师，只要他们没有访问加密密钥的权限，就无法查看实际数据。
这也是 Moesif *台的一个功能，它确保只有贵公司一小部分授权团队成员可以检查敏感数据。Moesif 员工将无法检查数据，因为他们无法访问客户管理的加密密钥
高枕无忧
数据合规性和数据隐私是重要而严肃的话题，会影响组织中接触敏感数据或客户数据的任何人。法律、运营和工程部门应通力合作，确保法规遵从性。此外，除了合规性框架的要求之外，公司还应努力实现更高的数据隐私。这可以是为了数据道德，也可以是为了减少数据泄露事件的风险。理解两者之间的区别是减轻整个主题压力的第一步——希望这篇文章能帮助你做到这一点！
如果您想了解更多信息，为什么不阅读 Moesif 如何简化 GDPR 合规性并确保数据保密？您还可以与我们乐于助人的团队聊天，他们将很乐意回答您所有的数据合规性和数据隐私问题。
什么是 TTFHW？
原文：https://www.moesif.com/blog/technical/api-product-management/What-is-TTFHW/
TTFHW 不是你在技术和产品领域听到的最常见的缩写。尽管它并不常见，但可以说它是公司试图挖掘并向新用户提供价值的最重要的缩写之一。
TTFHW，或第一次你好世界的时间，可能是你已经想到的事情。许多产品导向的爱好者称之为顾客的“啊哈！”瞬间。这是客户第一次从你的*台获得价值的时候。许多编程语言和程序员工具称之为“Hello World”时刻。这是一个成败的里程碑，也是一个你显然希望每个客户都经历的里程碑。TTFHW 简单来说就是到达“啊哈！”瞬间。
什么是 Hello World？
“第一次你好世界的时间”这个术语来源于很多软件开发人员都知道的事情:第一次运行一个用新语言构建的程序(以及到达那里所需要的时间)。许多语言都有 Hello World 指南，许多开发人员通过将“Hello World”打印到控制台或屏幕上，用一种新的语言创建了他们的第一个程序。
没有这些时刻，编程语言和框架就不会给我们带来价值。一个 Hello World 程序往往是一个小而简单的程序，开发者用特定的编码语言编写。这个程序通常为他们将要编码的后续程序构成构件。
当把这个应用到产品上时，“你好，世界”或“啊哈！”时刻可能看起来有点不同。可能很简单，比如一个用户第一次调用一个 API，收到一个响应。一旦他们达到 Hello World 里程碑，他们就会继续玩和使用这个产品。最理想的结果是，他们有望成为付费客户。
在更复杂的流程中，Hello World 事件可能有多个步骤。例如，如果我们正在运行一个电子商务*台，我们的 Hello World moment 可能只有在用户注册、登录并成功完成第一次购买后才会发生。当然，其他应用和产品可能有无限复杂的 Hello World 时刻。
为你的产品定义 Hello World
你的产品的 Hello World moment 只能由你来定义。这是因为每个产品都是不同的。只有你能决定用户从你的*台或产品获得价值的第一瞬间。有几种方法可以描绘出你的 Hello World 时刻，我再举几个例子:
- 如果你已经创建了一种新的编程语言，这可能是用户编译他们的代码并运行他们的第一个程序的时候。
- 如果您已经创建了一个投资应用程序，这可能是用户第一次将资金存入帐户并进行第一笔交易的时刻。
- 如果你已经创建了一个 API *台(特别是货币化的)，这可能是用户第一次调用 API 的时候，这时就要收费了。
你的应用程序很可能不属于这些类别，或者它确实属于。无论如何，您可能需要真正深入了解您认为的 Hello World 事件(或多个事件)。
如果你有一个多步骤的 Hello World，跟踪每一步是很重要的，因为你可以识别流程中的瓶颈。例如，如果您有一个 3 步流程，而第 1 步花费了用户 90%的时间来完成，这很可能也是您失去许多用户的地方。通过定义所有 3 个步骤，而不仅仅是最后一个，它给了我们一个真实的画面，我们的问题在哪里，哪里需要优化。
第一个你好世界的时间到了，为什么它很重要
为你的产品定义 Hello world moment 只是 TTFHW 等式的一小部分。最大的因素是到达那个点实际需要的时间。就需要多长时间而言，没有“一刀切”，但根据新产品的趋势和现代人对入职的态度，应该会很快。
顾客或用户到达 Hello World 时刻的时间越长，他们离开并完全放弃产品的可能性就越大。这意味着创造一个精益流程来实现第一个 Hello World 时刻至关重要。特别是对于多步骤流程，每个输入和点击都应该仔细管理。在“你好，世界时刻”到来之后能做的任何事情都应该推迟到那时。
通过跟踪第一个 Hello world 的时间，您可以开始收集关于哪些部分花费时间最长以及大多数用户在哪里下车的真实指标。您将能够看到趋势和阈值，例如当用户“花费超过 X 分钟来完成 Hello World 标准时，他们通常会放弃该产品”。这意味着您可以改进流程和跟踪，看看这些改进是否产生了影响。
除了简单地改进产品之外，还有第二种补救方法。这种方法可能包括当客户超过 TTFHW 的估计阈值时通知您的客户成功团队。更好的是，你可以在应用程序中通知他们进一步的资源，或者给他们发一封自动邮件，告诉他们如何更接* Hello World 时刻。
降低你的 TTFHW 很重要，因为这能让顾客进门，让他们兴奋地使用产品。尽可能缩短用户获得价值的时间，这对用户和你的产品都是双赢的。当测量 TTFHW 时，优化用户体验是最容易衡量的。
Moesif 中的 TTFHW 和用户漏斗
由于 Moesif 能够以高粒度跟踪用户指标，这使得它成为一个定义、跟踪和改进你的产品的伟大*台。
默认情况下，Moesif 在用户的配置文件中为 TTFHW 创建一个变量。这个高层次的 TTFHW 被计算为用户第一次被添加到 Moesif 时和他们第一次执行 API 调用时之间的差异。对于某些场景，这可能是准确确定产品 TTFHW 所需的所有复杂性。
对于更复杂的流程，我们的用户转向用户漏斗来创建多步漏斗，它跟踪 Hello World 旅程的每一步，并记录每一步之间花费的时间。正如您在上文中回忆的那样，这意味着我们可以确定哪些步骤在整个流程中花费的时间最长，而不是只关注单个事件。有了 Moesif，可以向用户漏斗添加无限数量的步骤。以下是 Moesif 中用户漏斗的一个示例:
这个用户漏斗反映了一个场景，其中有 3 个步骤来完成漏斗。第一步是用户注册时，第二步是用户第一次购买/支付时，最后一步是用户完成第 100 次购买/支付时。您还会注意到，您可以看到每个步骤的转换率以及每个步骤的转换时间。
一个额外的好处是，如果你的应用程序支持不同的配置文件和用户类型，一些产品可能会根据用户类型有不同的 Hello World 时刻。为此，可以为每个场景建立一个用户漏斗，以便准确地跟踪每个流量。
定义、跟踪和改进您的 TTFHW
使用 Moesif 来确定您的产品 TTFHW 并改进它很简单。Moesif 很容易与许多*台集成，包括最常见的 API 框架和 API 网关。一旦整合，您的指标可以很容易地用于确定上述所有因素。
从高层次开始，你可以很容易地定义你的用户漏斗中的一些关键步骤。从商业角度来看，进入第一个 Hello World 的结果是以后为用户带来实现的价值。下面是一个漏斗的例子，它跟踪用户对页面的初次访问，直到他们(和企业)获得实现的价值。您可以看到漏斗中每个步骤之间的*均时间以及每个步骤的转化率。
在 Moesif 中跟踪这些事件时，重要的是要记住 Moesid 可以在前端和后端跟踪事件。我们所说的“Web 动作”被认为是前端事件。“API/*台动作”是发生在应用后端的那些事件。您可能希望使用一种或两种类型的操作来定义您的用户漏斗。下面是一个示例，说明如何根据前面的示例拆分这些事件。
不管到达第一个“你好世界”或“啊哈！”有多复杂时刻，跟踪每一步都是吸引客户，留住客户的重要一环。TTFHW 是计算交付该价值需要多长时间。普遍的共识是 TTFHW 越快，你获得新客户的机会就越大。这是因为价值是提前交付的，确保更多的客户到达那个时刻，而不是放弃你的产品。
想走上快车道吗？只需注册 Moesif 并查看我们的指南，了解如何在几分钟内建立用户渠道来跟踪你的 TTFHW。
API 定价时需要了解的内容
原文：https://www.moesif.com/blog/api-monetization/api-strategy/What-You-Need-to-Know-When-Pricing-APIs/
为 API 正确定价是 API 货币化策略的关键部分。这意味着了解您应该如何对使用收费，是按月还是按季度定价更好，是数据层还是按使用量付费的 API 定价模式效果最好，以及一系列其他因素。在本帖中，我们将涵盖 API 定价时你需要知道的所有内容。
为你的 API 建立定价策略
谁为 API 买单？
在最基本的层面上，询问谁真正为 API 付费是很重要的。当你将你的 API 货币化时，你是通过向最终用户——利用你的 API 提供商业价值的公司——收费来实现的。因此，通过了解您的 API 提供的价值，您将能够更好地建立一个有利的定价策略。
当把你的 API 当作一个产品时，一个基本原则是理解你的客户。通过了解他们如何使用你的产品，你不仅可以更好地为你的服务定价，还可以让你对什么可行、什么不可行以及你的路线图上应该有什么有不可或缺的见解。关于将 API 视为产品的更多信息请查看我们丰富的库。
你如何计算 API 价格？
有几种方法可以确定 API 的价值。根据 API 调用的数量收费是一种常见的定价标准，但当涉及到您的定价模型时，这肯定不是唯一的选择。在制定 API 策略时，要考虑不同的基于使用的计费方法，包括:
- 交易量——基于 API 调用的数量。它非常适合 API 和基于事件的*台，例如在 communications Twilio 或 analytics[moes if]https://www . moes if . com/price？UTM _ campaign = Int-site&UTM _ source = blog&UTM _ medium = body-CTA&UTM _ content = pricing-your-APIs){:target = " _ blank " }。
- 收入/成本份额–您向最终用户收取一定比例的收入或交易费用。这非常适合金融*台，比如那些专注于支付条纹或费用报告的*台。
- 数据量–基于发送的千兆字节或处理的分钟数。对于专注于数据的*台来说，这是一个很好的方法，比如日志或存储 AWS 。
- 以用户为中心–基于每月活跃独立用户数量定价。这是现代版的按用户或座位收费。资源–基于计算单位或活动时间。非常适合数据库或虚拟机等计算基础架构。
你提供的产品将在你的定价策略中发挥关键作用。从 SaaS 价格点方法中可以学到很多东西，因为许多 API 定价策略都植根于更广泛的 SaaS 定价解决方案。SaaS 定价的主导思想强调需要根据三个主要因素来定价:交付产品的成本、竞争对手的定价和你的价值指标。也就是说，你的客户将如何支付。从你的第一批付费客户那里获得反馈也很关键，因为他们会有很多关于哪些定价模式适合他们，哪些不适合他们的想法。
内部与外部 API
面向外部的 API 通常是收费的，这些 API 可供组织外的其他公司使用。内部 API，您可以用来在您的组织内互连不同的服务，通常不收费，因此不需要定价策略。
现收现付 API
现收现付计费模式意味着客户只为他们消费的东西付费。这可以通过一系列指标来衡量，比如发送的消息数量。这种基于消费的定价模型非常适合 API，API 自然是基于事务的。
使用随用随付 API 计费，您可以根据客户的使用情况选择收费标准。你也可以实现批量折扣，这取决于你如何将你的 API 货币化。
随用随付模式易于实现，这使得它成为许多公司设计其第一个 API 货币化策略的流行选择。一个示例云架构说明了这种实现的简单性。
从客户的角度来看，实施现收现付计费成本较低。然而，从长远来看，如果不限制使用量，对他们来说成本会更高。你还需要实现一个系统，提醒你的用户配额限制，以避免他们收到意外账单。这样一个系统将会对你的信用有所帮助，因为它将会避免意外账单促使你的顾客货比三家寻找更便宜的替代品。
API 调用是如何计算的？
有许多不同的方法来计算你如何为你的 API 收费。这是 Moesif 真正的亮点，因为我们的*台可以基于 API 中的任何参数进行计费。这意味着您可以围绕客户的精确需求来制定您的 API 货币化策略。如果您决定基于使用计费，可能的消耗指标包括 API 调用次数、发送的千兆字节数、用时数、每月活跃用户数、活跃小时数等等。
一个 API 能赚多少？
不考虑定价策略，另一个关键问题是你的 API 能产生多少。API 是 SaaS 的一个子集，一次又一次地被证明能够以超高速扩展。
绘制两个 API 成功典范 Twilio 和 Stripe 的快速崛起的图表很有启发性。两家公司都基于 API 优先的模型——通过 API 提供服务。在 2011 年推出产品后，Stripe 的收入从 2016 年的 4000 万美元增长到 18 个月后的 4.5 亿美元，并在 2020 年增长到 70 亿美元。同样，Twilio 的收入从 2013 年的 5000 万美元增长到了 2021 年的* 4000 万美元。
API 或企业软件含义？
如果您可以选择提供 API 产品或企业软件解决方案，那么这个决定将对您创收的速度产生重大影响。一个策略是专注于向最终用户提供你的 API。这意味着您可以更快地进入市场，并将所有的工程人才集中在 API 提供的业务逻辑上。相反，如果你想构建一个企业软件解决方案，你也需要投资创建一个前端。通过将您的所有资源集中在您的差异化业务功能上，您可以为您的解决方案收取更多费用。
确定价格点，并相应地包装您的层
在开发分层定价模型时，由您来决定价格点并相应地包装您的层。采用“免费增值”的定价策略变得越来越普遍，即初始层是免费的，后面的层是付费的。在 Moesif 的案例中，我们有四个层次:免费、增长、专业和企业。
正如我们在最*的一篇文章中讨论分层定价时提到的，在交易和分层产品定价模型之间存在权衡。如果您使用分层方法，您需要定义每层包含哪些功能和使用配额。您还需要解决客户对此模型的主要担忧:
如果我达到了 API 计划的限额，会发生什么？
以 Moesif 为例，每一层都定义了用途、用户数量和功能。如果客户需要更多，他们可以选择升级到下一层，作为其计划增长的一部分。这是一个简单的模型，使客户可以轻松地进行预算和管理，因此当然可以考虑将其作为 API 定价策略的一部分。
什么是高级 API 商业模式？
从 Moesif 模型中可以看出，分层定价的另一个好处是可以引入溢价元素。什么是高级 API 商业模式？在这种情况下，顶层客户可以从任何其他层都无法获得的某些功能中受益。在 Moesif 的情况下，高级扩展包括将 API 使用数据同步到内部仓库、Salesforce 集成、MarTech 工具等的能力。您可以提供的高级 API 元素将基于您独特的业务模型。
API 解决了一个独特的需求吗？
API 定价的最后一个要素与你的产品提供的价值有关。问问你自己:这个 API 解决了一个独特的需求吗？如果是这样的话，那么你在定价方面就有了更大的自由，如果你的 API 满足了许多竞争对手的 API 也能满足的需求。
易用性也很重要，所以您还需要考虑 API 的易用性。是 REST API 还是另一种格式？它是基于云的 web API 还是在本地运行的？用户需要一个 API 密匙吗？如果需要，获取它的过程是否顺利？
API 的例子是什么？
本质上，你让客户访问你的 API 越容易，就越好。例如，佛蒙特州立法机构 API 使用 HTTP basic auth 进行认证，用户必须向佛蒙特州立法机构发送电子邮件才能获得 API 密钥。这就带来了摩擦和延迟，因为潜在用户在使用电子邮件之前必须等待回复。记住:客户更愿意为易于使用的 API 付费，而不是让他们头疼的 API。
命名 API 和 API 安全性
最后要考虑的几点是如何正确命名 API，这应该在设计决策中加以考虑，以及如何解决 API 安全性问题。API 安全性需要什么？这本身就是一个巨大的话题。一旦您制定了自己的 API 定价策略，请查看我们的 API 安全特性,以确保您尽全力降低自己和客户的安全风险。
立即设置您的价格
将上述所有因素纳入你的 API 定价策略，意味着你将能够有效地将你的产品货币化。越早考虑货币化越好。
今天就放手一搏吧。尝试我们的货币化解决方案，并把你在这里学到的一切付诸实践。
开发者*台的下一步是什么:嵌入式集成和 API
这是 Jeremy Glassenberg 在 2020 年 3 月旧金山 API 和 IPA Meetup 上演讲的姊妹篇。他演讲的完整视频在 Moesif 的 YouTube 频道上。
https://www.youtube.com/embed/XhCRkmabQl0
介绍
随着流行的 web 服务扩展其开发者*台，让合作伙伴直接集成到它们的界面中，设计趋势正在从嵌入式集成领域的经验中形成。随着 Google Drive 连接 Balsamiq 和 ShiftEdit 等工具，Gmail 在其 web 和移动用户界面中支持 Docusign，以及 Trello 等服务在其自己的界面中提供插件，由第三方提供的定制体验正在证明自己是改进产品和发展业务的一种很好的方式。
让我们看看什么是成功的和不成功的，什么趋势在起作用，以及启动成功的嵌入式集成计划需要哪些 UX 和技术考虑。
2008 年开局不利
对嵌入式集成框架的第一次尝试，让第三方的东西出现在你的界面中，变得有点混乱。早期的解决方案包括 iGoogle、OpenSocial，甚至是一家 YC 公司 youOS，它让网页像操作系统一样运行。
回到 2008 - 2010 年，令人困惑的问题仅仅是用例没有被考虑清楚。消费者不一定想让网络像操作系统一样，或者将第三方的内容整合到他们的社交网络个人资料中。没有市场需求。
雪上加霜的是，iGoogle 和其他*台不仅面向开发者，而且当这些产品失败时，它们在消费者面前也失败了。这对企业来说很不利，所以它们被悄悄地关闭了。*台提供商变得畏首畏尾。
市场的兴起
随着 web 服务的增长和用户群的扩大，大公司看到了开发人员拼凑解决方案来构建他们想要的特性和服务。确实有一群人试图在 Gmail 之外增强 Gmail。Trello，Shopify，Wix，twitch 和许多其他公司也是如此。
通过与客户群积极互动，这些公司可以确定他们需要什么，并构建真正的用例。他们看着:
- 他们在实验什么
- 他们是如何开始的
- 他们学到了什么
他们只有在拥有足够多的用户基础时才推出*台，他们可以看到他们的产品中缺少一些东西，用户正在要求，并且他们不想自己构建和维护。
成功的嵌入式框架确实遵循市场模型。因为已经有了一个庞大的用户群，所以最重要的是留住客户，而不是采用客户或客户增长。
产品和用户体验
实际上，将开发人员*台实现为嵌入式框架有很多选择。突出前三名:
iFrames
让另一个网站嵌入您的网站。被许多人使用，包括 Intercom 和 Google Docs。
| 赞成的意见 | 骗局 |
|---|---|
| 免费开放 | 性能和安全问题 |
| 设置简单 | iFrames 和移动应用程序不能很好地协同工作 |
卡片
像物体一样形成。由 Slack 和 Gmail 使用。
| 赞成的意见 | 骗局 |
|---|---|
| 移动友好 | 没有标准 |
| 更好的安全性(不允许客户端 javascript) | |
| 良好的性能 |
扳机
打开一个新窗口并调用 API。iFrames 使用供应商特定的 API“编程语言”调用客户端 javascript。
设计和用户界面
最佳实践要求为开发人员提供一些 UI 组件，以便界面看起来一致。一个很好的例子是 Shopify，他们正在激励和简化开发者的体验；他们只是给出了更多的代码，也就是说，组件的样式就在他们的库中，而不是推出一个特定的 UI；这样就可以更快地编写应用程序，并拥有一致的用户界面。
DevEx
更进一步，帮助您的开发人员在清单、表格(脸书)或开发门户(Trello)中轻松管理他们的应用。
结论
嵌入式框架使第三方能够在您自己的界面中，在您自己的用户体验中深入工作。我们已经介绍了如何超越 API，以及如何理解服务如何与您的产品相联系，并为您的用户创造有意义的体验。
建立框架，让这些第三方应用成为体验的一部分，是留住客户的基础。
确定 API 价格的最佳方式是什么？
作为一个 API 提供者，一旦你决定从你的 API 中获得收入，下一步就是弄清楚你将如何为使用定价。和任何商业决策一样，有很多方法可以为 API 定价。有许多短期策略可以建立初始定价，然后反复寻找最适合您客户的定价模式和价位。从长期来看，还可以采取一些措施来确保您的定价保持相关性，并*衡保留和收入。
在本文中，我们将深入探讨 API 定价的所有相关问题。我的目标是给你一些想法和一些最佳实践。希望在本文结束时，您将对 API 定价以及如何将下面的技术应用于您组织的货币化 API 有更好的理解。最后，我们将看看 Moesif 如何帮助你弄清楚哪些 API 可以赚钱，如何定价，以及如何实际向用户收取使用费。让我们跳进来吧！
API 定价是如何工作的？
与大多数产品定价一样，API 定价包含两个主要问题:将收取什么指标的费用，以及将实施什么定价模型？例如，您可以选择对每个 API 调用计费，并对每个调用收取固定的费用。当使用量超过一定数量时，您还可以享受每次通话的折扣率。也许您会决定只对每个用户或用于访问 API 的 API 密钥收费。
每家公司可能有不同的衡量标准，他们希望根据这些标准计费，并且可能希望实施不同的定价模型。这些选择都非常依赖于你正在货币化的 API 和你的业务需求。
什么是收费的通用指标？
有无限多的度量标准可供选择。不过，一般来说，我会想到一些常见的场景。以下是一些用于衡量 API 使用情况的最常用指标:
每个事件
这个指标适用于进入 API 的每个调用。每次通话都被记录下来，并计入计费周期的总数。例如，如果您希望对每个 API 调用收取 0.10 美元的费用。如果用户调用 API 5 次，他们将在账单上收到 0.50 美元的费用。这是最受欢迎的指标之一，因为它最容易实现。
每个请求/响应的主体计数
在某些情况下，您可能希望计算 API 请求或响应主体中的元素数量。如果您想根据进出 API 的有效负载向用户收费，这是非常好的。例如，如果我们希望对请求体中的每个元素收费 0.10 美元(因为每个元素都将由我们的服务处理)。在这种情况下，如果开发人员发送一个请求，请求体中有 3 个要处理的元素，他们的 API 调用将被收取 0.30 美元。
每个唯一用户
当您希望根据访问 API 的唯一用户来收取使用费时，这种方法非常有用。与使用 API 密匙不同，在 API 密匙中，一个用户可能有几个密匙，相反，您在用户级别收费。举个例子，如果你想对每个用户每月收费 10 美元。在这种情况下，不管用户使用多少 API 键，可能每个环境或应用一个，他们访问*台的 API 只需支付 10 美元。
每个 API 密钥
与每个唯一用户类似，费用将基于用于访问 API 的唯一 API 键的数量。在计费期结束时，总 API 密钥使用量将被累加并计费。例如，如果每个 API 键每月的成本为 5 美元。在这种情况下，如果一个开发人员有 3 个 API 键，他们使用这些键来访问 API，那么这个月他们将被收取 15 美元的使用费。
除了这里讨论的指标，还有很多其他指标。其中一些可能提供了一个很好的起点，随着您的扩展，您可能会发现需要测量更复杂的指标来适应您未来的用例。
可以实施哪些定价模式？
定价模式千差万别，尽管许多公司都使用一些主要的定价模式。下面让我们快速了解一些更标准的定价模型，这些模型可以在对 API 使用收费时使用。
标准定价
当您希望对每个 API 调用或每个唯一用户收取相同的价格时，可以使用这种定价模型。本质上，每一个被记录的使用单位都将在相同的价格点上被收费。这是现存的最简单的定价模型，如果你不想一开始就变得太复杂，这可能是一个很好的起点。
包裹
当您希望按包或一组单元对 API 使用收费时，可以使用这种定价模型。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。
分等级的
如果您想使用定价等级来收取使用费，分级定价是可行的。例如，在分级定价方案中，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。
卷
使用基于数量的定价可用于根据售出的单位总数对每个单位收取相同的价格。例如，您可以对 50 个单位收取$10.00，或对 100 个单位收取$7.00。在计费期结束时，使用量总计，总使用量将决定应用于每个使用单位的价格。
当然，这并不是一个详尽的列表。根据客户或产品的不同，您也可以对每种产品使用不同的定价模式。选择对您的特定 API 最有意义的定价模型应该在推动客户使用和确保收入最大化之间取得*衡。
确定 API 价格的最佳方式是什么？
一旦你决定了衡量标准和定价模式，你就必须决定你将向客户收取多少费用。当然，这可能非常复杂，取决于您使用的指标和定价模型等因素。下面的建议旨在指导您在考虑 API 价格时的一些重要考虑事项。
为您的业务计算 API 的成本
你需要考虑的一件事是你的 API 给你的业务带来的成本。这种成本可能是持续的支持成本、新特性的开发成本，甚至是 API 利用的第三方 API 或服务增加的成本。
最容易确定的成本是您的 API 使用的其他服务以及与它们相关的成本。目标应该是至少涵盖这些将直接导致您的业务支出的成本。您可能会考虑第三方 API 成本，可能是您的 API 用来提供其功能的其他服务，或者甚至是您的基础设施成本，如果 API 调用量会使成本增加或减少的话。
创造一个产品也需要花费时间和金钱来支持和持续的工程努力。这也应该被计算到你的 API 的拥有成本中。如果用于支持和维护的资源将大部分时间花在货币化的 API 上，这一点尤其正确。计算出 API 的基础成本或总拥有成本，可以帮助您了解价格应该从哪里开始。
你通过你的 API 增加了多少价值？
你的 API 给潜在用户带来了很多价值吗？例如，价值可能有许多不同的形式，但最常想到的一种形式是公司从使用您的 API 中节省了多少成本。这种节省通常表现为他们在内部开发类似服务的成本。如果这项服务需要他们 2 天的时间来创建和部署，也许你需要给你的产品增加一点深度，以获得更高的使用价值。另一方面，如果他们需要几个月的时间和大量的预算来建立你已经创造的东西，那么你可能处于一个非常好的位置。
可能很难量化确切的价值，但你应该很清楚在内部构建一个同等的服务需要什么，以及为了使用你的服务和构建他们自己的服务，公司可能愿意支付多少。另一种衡量价值的方法可能是，如果你通过你的 API 提供一项服务，而这超出了你的潜在市场的专业范围。这意味着他们可能需要雇佣一整套员工来创造你已经有的东西。使用您添加的值来给出您的定价范围，并最终确定您的 API 的价格。
你应该使用什么样的定价模式？
一般来说，在这方面你有两个重大的决定:你会收取订阅费还是根据实际使用情况收费？两者都有优点和缺点，也有结合两种范例的方法。例如，您可以收取每月 1000 次 API 调用的订阅费，然后以超额费的形式收取超额使用费。如果你决定对超额收费，除了定价模型之外，你还需要考虑你的超额模型。
一旦您确定了上述更高层次的定价问题，您就可以决定是否实施任何基于数量的定价、分层定价和其他可用的潜在定价方案。一些公司努力提供简单的定价策略，而其他公司则有大量的灵活性和选择。根据您的客户，以及他们可能使用的其他产品，您可能会感觉到哪种定价模式最有意义。
您是否应该将 SLA 和支持纳入使用成本？
除了按使用量收费之外，一些公司还对不同级别的支持收取额外费用。这可能是为你的 API 增加收入的另一种方式，可以计入你向客户收取的总价格中。你仍然可以根据一个严格的定价方案对你的 API 收费，但是对需要这样一个协议的公司的升级收费，比如一个改进的支持包。
继续测试你的价位
你的价格点不必永远一成不变。与大多数产品和服务一样，随着时间的推移，成本往往会增加。客户通常期望在某个时候有所增长，只要价值仍然以同等或超过的方式交付，他们就不会因为成本而流失。
您应该何时评估您当前的定价模式？
这个问题的答案很大程度上取决于你的商业模式。如果你做的是按月或按使用付费的模式，价格点在技术上可以随时改变。显然，你要确保客户意识到保护自己免受任何负面影响，并给客户一个适应新费率的机会。然而，如果你有一个按年付费的企业计划或更严格的基于时间的合同，你可能只能在续约时增加价格。
与竞争对手比较评估你的价格总是好的。如果您的服务更贵，您可能希望深入挖掘差异化优势，并从这方面推动，以确保您向消费者展示了成本的价值。
总的来说，应该经常评估和重新评估定价。这应包括查看您的收费、客户可以使用的定价模式，以及新功能是否保证整个定价方案的价格上涨，或者是否应在购买选项中添加新的产品包或附加产品。
推出价格变化的最佳方式是什么？
推出价格变化的最佳方式是确保你有准确的反馈回路。当价格发生变化时，您需要进行监控，以便客户成功和销售团队能够尝试带回流失的客户。这更像是一种被动的方法，并不是每个客户都会回来，有些人可能担心未来价格会进一步上涨。
你也要确保任何价格变化都得到很好的沟通。如果客户要续约，尽早开始谈判。如果顾客每月用信用卡付款，试着在下一个账单周期开始前让他们提前知道，这样他们就不会感到惊讶。需要注意的一点是，不要过度传达价格变化的“原因”。您可以简单介绍新功能、改进的 SLA 或其他高层次的增值，以证明增加的合理性。然而，通过列出你改进的所有特性，这可能会给客户一个机会说“我不使用它，为什么我要为它付费？”以及其他可能反对涨价的理由。
最后，你也可以在客户调查中添加一个关于价格的问题，以检查他们对当前价格是否满意，或者他们是否认为价格过高或过低。询问顾客“你愿意为我们的服务支付的上限是多少？”实际上是一种很好的方式，可以看到客户的感知价值，并在不试验实际价格的情况下测试上限可能是多少。
免费试用，免费层，还是什么都没有？
评估你的试用期价格也是你可以玩的东西。如果你有一个免费的试用版，试试它的长度也可能会吸引更多的付费用户。你可能会发现你的免费层“太好了”,许多客户会继续使用它。这可以防止客户跳到付费计划，因为免费计划已经涵盖了他们需要的一切。或许取消任何审判对你的生意有利？
试用可能是采用的主要驱动力，评估你的试用期优惠对你和你的客户如何起作用是定价策略的一部分。如果你在产品中尝试试用产品，确保有大量的分析输入，这样你就可以跟踪变化的真实价值。
使用 Moesif 进行转换分析和计费
有了 Moesif，使用 API 分析来帮助确定哪些 API 可以赚钱以及收取什么价格成为了一门更精确的科学。当然，你可以猜测所有这些因素，通过反复试验，找到有效的方法。这带来了巨大的风险，也浪费了从一开始就增加收入的机会。
使用 Moesif *台可以帮助您为 API 找到合适的价格，引导价格变化，并优化入职。该*台可以通过使用 SDK 的现有 API 代码或利用我们的插件通过 API 网关轻松集成。
研究 API 端点的 API 使用情况以盈利
您熟悉哪些 API 的流量最大吗？你知道流量来自哪些公司吗？通过询问和回答 API 使用中的关键问题，您可以快速确定利用哪些终端赚钱。你甚至可以准确地预测 API 何时开始货币化。Moesif 可以帮助生成报告，以您可能从未见过的方式显示 API 使用情况。
Moesif 的一个条形图，展示了每个客户的用户在哪里生成了最多数量的 API 事件
通过使用 Moesif 深入挖掘您的 API 使用情况，您可以发现许多问题的答案，这有助于确定 API 的价值以及潜在的收费标准。实施货币化后，这些报告可以帮助您查看用户和公司层面的收入，以推动长期组织目标，并为您的 API 产品路线图提供信息。
用户漏斗和留存
Moesif 的用户漏斗报告，显示完成三个集成阶段的用户百分比
在你实施或改变你的定价后，你需要确保客户仍然在转化为付费客户。这可以通过 Moesif 中的用户漏斗来跟踪。用户漏斗将允许您概述您的转化漏斗中的每个步骤，并查看在每个步骤中用户转化的百分比以及需要多长时间。
API 保留图表显示了哪些用户在不同的集成阶段使用了哪种语言。语言包括 node.js，python，go，ruby，php
留住顾客也很重要，尤其是在价格变化之后。通过留存报告，您可以查看产品的历史留存率，并确保最*的定价策略变化有利于您的业务，而不是降低留存率。
计费仪表
流程图显示数据从您的应用或 API 转移到 Moesif，然后再转移到支付处理器 Recurly、Stripe 或 Chargebee
Moesif 还可以帮助在您的 API 上实现货币化。通过使用计费表，您可以建立您想要货币化的终端和定价模式，并将使用总量发送给计费提供商，如 Stripe、Recurly 或 Chargebee。Moesif 的计费仪表以最少的工程工作量提供了端到端的货币化能力。如果您需要一个解决方案来轻松、安全、快速地将您的 API 货币化，那么 Moesif 的计费计量功能正是您所需要的。
包扎
最适合您业务的定价方案总是需要量身定制。对 API 调用进行定价可能非常困难，但是遵循上面的指导方针可以帮助您找到使它变得更容易和更精确的方法。确保您决定货币化的任何终端都能为开发人员及其组织带来价值，这对您的企业和他们的企业来说都是双赢的局面。
使用 Moesif 可以在 API 货币化的许多方面提供帮助，包括帮助您做出明智的定价决策，确定货币化的终端，以及在整个过程中跟踪客户保持率。首先，立即注册,亲自体验 Moesif 的 API 分析和货币化功能。
什么时候应该考虑计量计费
原文：https://www.moesif.com/blog/api-strategy/monetization/When-Should-you-Consider-Metered-Billing/
你曾经支付过电费、网络费或水费吗？该账单是基于您使用的资源量吗？如果是这样，您的提供商使用的定价模式是“计量计费”
如果你熟悉软件工具，你可能听说过这种模式的不同名称:“按需付费”、“基于使用的计费”、“基于消费的计费”、“PAYG”简而言之，这种支付模式允许客户只为提供的服务付费。不仅仅是公用事业。这种基于价值的定价模式与客户驱动的增长战略非常匹配，例如产品驱动的增长。此外，这种收入模式可以实时扩展。
SaaS 公司注意到了这一点。计量计费降低了新客户的准入门槛，在软件行业也越来越普遍。对于医疗创新*台提供商 NexHealth 来说，Moesif 基于使用量的计费使能够立即开始向客户计费，并帮助他们的 API 产品迅速成为收入来源。
那么，您应该考虑采用计量计费模式吗？
如果你正在建立一个 SaaS *台，而你的客户是…
…开发人员，或者是高度技术性的人员
…您服务的早期采用者
…付费使用您的 API 产品
然后，计量计费可能会加速你的增长。
对于你的潜在客户来说，购买任何软件服务或功能，尤其是一种新的软件，都不是一个简单的决定。这是一个大多数人只有在他们组织的技术领导的认可下才会做出的决定。顺畅、透明的计费体验有助于赢得客户和忠诚度。这对于你想转化为客户的开发者主导的 B2B SaaS 公司来说尤其如此。
计量计费迎合了软件专业人员的自主文化。让技术决策者完全控制他们的发现过程，使他们能够更快地集成。即便如此，任何 SaaS 定价模式的成功都取决于你如何衡量你的核心业务。
如果您可以跟踪价值指标，例如…
API 调用的次数
…唯一用户
…独特的会话
…API 密钥
那么计量计费绝对可以扩大你的客户群。
跟踪服务的关键价值指标将确保您和您的客户从您的产品中获得最大收益。例如，专门从事 SMS 的 API 产品在每次发送文本消息时都提供价值。假设 API 在一次 API 调用中*均发送 100 条消息，作为一个批处理。在这种情况下，服务的值映射到发送的 API 调用数的倍数。通过将这一价值指标附加到客户的账单上，他们为服务的真实价值付费。
该*台现在可以自动向发送更多短信的用户收费，而不会惩罚那些使用率较低的用户。这种定价的透明度可以提高收入，并建立现有客户的忠诚度。
值得注意的是，计量计费有被滥用的风险。一些客户会产生他们不打算支付的费用。您可以通过使用 Moesif 实现速率限制来缓解这个问题。或者，您可以自己构建这样的功能，尽管这样做通常很耗时且成本很高。
尽管存在这一缺陷，计量计费模式可能意味着增长和停滞之间的差异。
你能忽视开发商的支持吗？
如果您正在考虑为您的企业建立基于使用量的计费模式，请点击此处查看我们的完整实施指南。在那里，您可以彻底确定这种计费模式是否适合您的企业。
如果您有更具体的问题，我们也可以提供帮助。
或者，参考我们的计量计费页。无论您选择哪种定价模式，我们都希望这是您的制胜策略。
何时构建与购买 API 分析解决方案
原文：https://www.moesif.com/blog/financial/procurement/When-to-Build-vs-Buy-an-API-Analytics-Solution/
如果您以前从未购买过软件，购买新的企业分析解决方案会是一种很好的体验，但也可能是一项艰巨的任务。对于特定的用例，可能会有许多具有重叠功能的分析供应商，但每个供应商都有自己的优势和劣势。除了购买现成的 SaaS，你还可以在 Spark、Druid 和 Elasticsearch 等开源软件上构建自己的内部 API 分析基础设施。本文深入探讨了何时构建与购买现成的分析解决方案是有意义的，并提供了一个基于点的框架，用于在执行尽职调查时评估 API 分析解决方案。
公司应该做出的第一个决定是，他们是想要构建基础架构还是购买现成的解决方案。两者都有好处和风险。总的来说，采购缩短了精心设计的分析解决方案的交付时间，与自主开发相比，时间和资金成本更低，但自主开发可以让您更好地控制被跟踪和呈现的内容。
从 0 分开始回答以下问题。
什么时候买？
如果您对以下任何一项回答是，则加 1 分:
您的资源有限吗？
购买现成的分析解决方案几乎总是比自己构建和维护一个自主开发的解决方案更便宜。供应商可以分摊 R&D 成本来构建高性能基础设施，该基础设施可以扩展到许多客户的数十亿次 API 调用。此外，现成的 SaaS 解决方案几乎没有维护开销，而本土解决方案由于工程师更替、产品忽视和不断变化的业务需求，随着时间的推移会产生技术债务。根据 SAP 的数据，78%的本土企业应用在首次使用后就被抛弃了。由于工程资源的重新分配，功能和缺陷修复(甚至是关键的安全修复)在最初交付后仍然没有解决。如果您没有专门维护您的自主解决方案的数据基础架构团队，购买几乎总是有意义的。
你时间有限吗？
由于功能蔓延和意外的洋葱皮，构建一个可用的分析解决方案可能会拖上几个月或几年，即使对于快速移动的团队来说也是如此。完全托管的 SaaS 解决方案不到一天就可以启动并投入运行。您的团队在构建分析基础架构的每一天，都没有花费时间来构建客户要求的功能，从而推动您的底线增长。购买可以让你将精力投入到核心竞争力上，而不是报告基础设施。如果您的分析解决方案的第一次迭代需要六个月的时间，那么在数据收集和访问适当的数据方面会有六个月的延迟，从而导致次优的规划和执行。
实时性能重要吗？
您是否关心第二天是否会出现新数据，或者您是否在寻求实时监控和异常检测功能？供应商可以投入大量资源来使他们的解决方案具有高性能和实时性，如果您希望获得关于 API 和帐户级别运行状况的实时警报，这是必要的。为了缩短时间表，自制系统通常构建在 SQL 和 Hadoop 等现有技术上，供应商可以将更多资源投入到定制的数据存储和基础设施中。
许多团队需要访问数据吗？
公司范围内的工具需要强大的访问控制、审计日志、数据管理以及易于使用的界面，以便非技术用户可以访问现成解决方案已经内置的数据。自行开发的 API 分析解决方案通常是由工程师为工程师设计的，迫使非技术用户依赖于向已经超负荷的数据团队提出请求。这大大降低了洞察时间。
此外，由于急于快速构建，自制解决方案通常没有任何安全功能。大多数安全事故是由内部人员而不是第三方造成的，有时是由于员工共享密码、员工不了解适当的 IT 安全政策以及没有自动检测本土系统的威胁而无意造成的。仅仅因为它在公司防火墙后面并不意味着它是免疫的。
您的团队是否不熟悉隐私和合规法律？
随着 GDPR、CCPA 等法规以及即将出台的电子隐私法规的出台，企业现在不得不应对比以往更多的法规。本土的分析系统很少有适当的框架和功能来处理像 GDPR 的删除权这样的事情，以及停止收集特定用户或公司数据的方法。来自第三方供应商的现成 API 分析解决方案通常已经有了额外的特性和框架，可以让他们的客户更加轻松地完成这项工作。毕竟，他们的主要业务是销售合规的 API 分析软件。
您需要特定的集成吗？
您的 API 分析解决方案是仅由工程部门使用，还是您希望其他团队(如产品、营销和客户成功)也利用您组织的 API 数据？如果是这样，每个团队可能都有自己的工作流和工具选择。例如，工程可能使用 PagerDuty 和吉拉，产品使用振幅和细分，客户成功使用 Zendesk 和 Salesforce，最后财务使用 Tableau 和 Slack 机器人。您会与这些产品中的每一个产品建立集成吗？否则，您可能会有数据孤岛，这降低了 API 分析的有用性，并降低了您组织的生产力。现成的解决方案通常有一个插件和集成的生态系统。
需要数据科学和创建正确的 API 指标方面的专业知识吗？
由于他们有帮助许多公司利用 API 分析的经验，供应商通常拥有深厚的专业知识，可以与他们的客户分享在您的组织中利用 API 分析的最佳实践和方法。他们能够提供一个框架来构建一个更好的*台，并可以向您提供教程和其他知识来帮助您的组织。自行开发的系统通常是在没有任何专家参与的情况下构建的，包括不断发展的 API *台和要测量的内容。在 API 分析方面拥有深厚专业知识的合作伙伴可以帮助您开始跟踪 TTFHW (Time to First Hello World)等核心指标，并指导您了解 API 群组保持率分析的最佳实践，同时了解哪些自定义指标对您的业务非常重要。
什么时候建？
如果您对以下任何一个问题的回答为是，则减 1 分:
你在一个高度管制的行业吗？
某些高度管控的行业(如医疗保健和银行业)对数据的保存位置和可以收集的数据类型有非常具体的要求，例如 HIPAA 合规性。在这些情况下，构建自己的系统来完全控制数据而不依赖第三方供应商是有意义的。虽然大多数第三方供应商已经遵循了 SOC 2 和 ISO 合规性的一般最佳实践，并强化了基础架构，但可能没有 HIPAA 这样的行业特定合规性。如果他们这样做了，可能需要一个特殊的计划，不管怎样，你自己开发的系统也必须是兼容的。不要陷入假设内部系统对法规遵从性免疫的陷阱。
您想完全控制信息的外观吗？
构建分析解决方案可让您完全控制如何将信息呈现给最终用户。虽然许多现成的解决方案确实提供了为面向客户的门户定制仪表板和白标的方法，但如果您有非常具体的需求，则需要在内部构建。
你有具体的分析功能和指标路线图来跟踪吗？
您的组织是否有明确定义的路线图，说明哪些分析功能现在和将来都很重要。你认为供应商不能继续增加更多的高级功能吗？你的团队是否有某些其他公司没有跟踪的商业秘密指标？如果你不确定衡量的最佳方式是什么，read-made 解决方案将提供一个定义良好的框架，因此你不必考虑哪些分析功能是重要的，但这可能会限制你衡量非常具体的事情。
您有专门的数据工程资源吗？
您是否有专门的数据工程团队和数据科学团队来构建和维护这一*台？他们以前在您的组织中是否已经构建并支持过分析基础架构？一个专门的团队不会不断地在功能开发和构建分析基础设施之间进行上下文切换。这让他们有更多的时间花在维护和改进上。
拥有内部分析能力会给你带来竞争优势吗？
如果你正在构建和销售一个支付 API，而你的主要竞争优势是支付可以用全球每种货币进行，甚至可以在没有互联网服务的情况下离线进行，那么在内部构建你的支付基础设施是有意义的。另一方面，除非你从事销售分析解决方案的业务，否则与在分析领域拥有深厚专业知识的供应商合作是有意义的，这样可以补充你自己的工程专业知识，而不是另起炉灶。供应商不仅可以带来他们的基础设施，还知道如何跟踪最佳指标以及如何更好地跟踪它们。
你想开源你的分析基础设施吗？
构建自己的分析基础设施的一个被忽视的好处是，你也可以开源它。如果你的公司对开源内部工具有友好的政策，这可能是一个促进招聘工作的好方法，特别是如果你想招聘更多的数据工程师。既然你完全控制了分析*台，你可以随心所欲。如果你计划开源，确保你尽早做出决定。开源项目对代码的整洁性有更高的要求，并且还需要能够作为一个单独的容器运行，而不需要建立许多依赖的服务。如果您的分析基础设施依赖于许多组件，如 SQL 数据库、Hadoop、Spark 和 Kafka，那么开源可能会更加困难。
你有一个非常狭窄的用例吗？
如果您有非常具体的用例，并且不打算从那里扩展，构建有时是有意义的，因为您可以在计算和磁盘空间上过度优化。这是最难决定的问题之一，因为很难为未知做计划。如果您想跟踪一个指标，并且知道这就是您所需要的，那么购买解决方案可能没有意义。然而，要小心今天的用例似乎特定的谬论，因为随着更多的团队开始使用你自己开发的解决方案，你会发现在你的组织中利用 API 数据的新方法。
总结想法
构建与购买一个 API 分析解决方案可能是一个压倒性的过程，但是最好的公司在像上面那样应用一个方法时获得最大的 ROI。有时建议你两者都试试。毕竟，构建一个解决方案可能需要 6 或 12 个月，而购买的解决方案可能只需要几个小时就可以设置好。在这种情况下，首先购买是有意义的，即使是较短的合同，以便在您的公司研究需要什么来构建时启动并运行某些东西。今天基于 SaaS 的解决方案的了不起之处在于，你不需要承诺使用一个产品多年。购买一个解决方案，了解产品是如何工作的，然后在看到你的团队最常用的功能和他们不用的功能后去构建它。
每个 CRUD 应用程序使用哪个 HTTP 状态代码
原文：https://www.moesif.com/blog/technical/api-design/Which-HTTP-Status-Code-To-Use-For-Every-CRUD-App/
HTTP 规范定义了许多我们在响应客户时可以使用的状态代码。有些 API 只使用最基本的代码，并在其上定义自己的错误信号机制；其他人希望充分利用 HTTPs 代码集合来告诉他们的客户端发生了什么。如果你属于后者，这篇文章适合你。本指南介绍了各种 CRUD 操作，以及在干净的 API 设计中应该使用哪些状态代码。
HTTP 状态代码
状态代码是一个大于 100 小于 600 的数字，是 HTTP 响应的一部分。第一个数字定义了状态的类别。状态代码带有一个原因短语。代码是为了程序识别，短语是为了让人们理解发生了什么。
每个状态代码都必须遵循这两条规则，甚至是自定义规则(是的，状态代码是可扩展的)。
状态类别
如果我们了解 a 类状态代码，我们可以更快地定位问题。
100 - 199
这些是信息状态代码；它们通常告诉客户端，请求的报头部分已经收到，服务器将尝试遵从客户端的传输要求。比如使用不同的协议，或者在开始发送消息体之前告诉客户端它的请求会失败。
200 - 299
这些是成功的密码。他们告诉客户它的请求被接受了。在异步处理请求(202)的情况下，这并不意味着请求被成功处理，只是说它满足发送时的所有验证要求。
300 - 399
这些是重定向代码。他们告诉客户端，他们请求的资源在预期的位置不再可用。这可能有多种原因，可能是暂时的，也可能是永久的，但客户端必须向新位置发出请求。
400 - 499
这些是客户端错误代码。它们都是关于客户端发送给服务器的无效请求。这有几个原因，超时，错误的 URI，错过认证等。客户端正在发送不正确的输入，应在重试请求之前确认输入参数是否正确。
500 - 599
这些是服务器错误代码。它们通常表示服务器过载或代理后面的服务器不可达的问题，但有时它们可能与触发服务器上错误异常的客户端请求直接相关。这些错误可能是暂时的，也可能是永久的。通常，客户端最好重试相同的请求。
自定义类别
自定义类，即 599 以上的类是不允许的，但仍被一些服务使用。对于 API 设计者来说，它们是相关的坏例子。然而，API 客户机创建者必须处理它们。
因此，虽然通常不允许，但要做好在野外遇见它们的准备。
CRUD(创建、读取、更新、删除)
CRUD 模型为持久存储定义了最基本的 API 动作。创建、读取、更新和删除。它们构成了 API 端点的最大部分。让我们看看哪些状态代码符合他们的要求。
创造
创建动作通常通过 HTTPs POST方法实现。在 RESTful APIs 中，这些端点用于创建新资源或访问令牌。
状态代码
- 这是告诉客户一切顺利的基本状态代码。因为我们在创建访问令牌时没有创建端点可访问资源，所以我们可以使用 200 作为该操作的状态。
- 201 创建了——最适合创建操作。这段代码应该发出后端资源创建的信号，并附带一个
Location头，为新创建的资源定义最具体的 URL。在响应体中包含资源的适当表示或者至少一个或多个资源的 URL 也是一个好主意。 - 202 已接受 -常用于异步处理。这段代码告诉客户端请求是有效的，但是它的处理将在未来的某个时候完成。响应体应该包含一个指向已完成资源的 URL，其中包含一些关于资源何时可用的信息，或者包含一个指向某个监控端点的 URL，该端点会告知客户端资源何时可用。
- 303 参见其他——类似于 202 代码，但是使用
Location头字段来响应通知客户端关于所创建的资源的位置或端点，该端点允许客户端检查创建过程的状态。一些客户端会自动跟踪重定向类的状态代码。这个代码通常只用于POST请求。
阅读
read 动作通过 HTTPs GET方法实现，并用于获取资源表示。异步响应在这里并不重要，因为异步处理的原因通常是资源还不存在，需要创建，所以无论如何这是一个创建操作。
状态代码
- 200 OK -大部分读取动作将会以 200 OK 状态回答。
- 206 部分内容——这个代码对于太大而无法在一次响应中交付的内容列表非常有用。它必须与请求中的
Range头字段一起使用。通常，这个头字段定义了后端应该发送给客户端的字节范围，但是只要双方都理解，这个单位可以自由分配。 - 300 多项选择——如果一个资源有多个表示，并且客户端(或其用户)必须选择其中一个，那么就使用这个重定向。
- 308 永久重定向——这告诉客户端使用另一个 URL 来访问资源，并且不再使用当前的 URL。当一个资源有多个端点，但不想实现从所有端点读取时，这很有帮助。
- 304 未修改——像 200 一样使用，但没有主体，所以客户端将从先前的读取被重定向到其本地缓存的表示。
- 307 临时重定向——当资源的 URL 在未来可能改变时，客户端应该在访问真实的 URL 之前询问当前的 URL。
更新
可以用 HTTP PUT或PATCH方法实现更新。区别在于客户端必须发送到后端的数据量。
要求客户端发送一个完整的资源表示来更新它。(用新的替换旧的)
PATCH要求客户端只发送资源的部分表示来更新它。(在旧版本中添加、更新或删除这些部分)
状态代码
- 200 OK -这是最适合大多数用例的代码。
- 204 无内容(No Content)204 无内容(No Content)204 无内容更新(No Content)204 无内容更新(No Content)204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 客户端，例如当保存当前编辑的文档时。
- 202 接受 -如果更新是异步完成的，可以使用这个代码。它应该包括一个访问更新资源的 URL 或一个检查更新是否成功的 URL。它还可以包括对更新所需时间的估计。
删除
删除操作可以用 HTTP DELETE方法实现。
状态代码
- 有些人认为任何类型的删除函数都应该返回被删除的元素，所以被删除元素的表示可以包含在响应体中。
- 204 无内容 -最适合这种情况的状态代码。最好是减少流量，简单地告诉客户端删除完成，不返回响应体(因为资源已经被删除)。
- 202 Accepted——如果删除是异步的，并且需要一些时间，这是分布式系统的情况，适当的做法是返回这个带有一些信息或 URL 的代码，告诉客户端它什么时候会被删除。
API 变更
如果我们的 API 存在足够长的时间，它迟早会改变它的结构。最好的做法是避免中断更改，状态代码的重定向类可以对此有所帮助，因为一些客户端会自动跟随它们的Location头。
状态代码
- 307 临时重定向(Temporary Redirect)——如果将来资源可以在不同的 URL 上使用，这是正确的代码，但是我们希望当前的端点控制客户端重定向到哪里。这个状态代码将让客户端为每个请求返回到当前的 URL。
- 308 永久重定向 -如果资源现在可以在新的 URL 上使用，并且客户端将来应该通过新的 URL 直接访问它，那么这就是正确的代码。当前端点无法控制请求后的客户端行为，如果资源 URL 再次更改，则必须从新的 URL 发出后续重定向。
一个资源有多个端点
如果我们选择在我们的 API 中使用嵌套或子资源，那么只从根(非嵌套)资源交付表示将有助于保持实现的干燥。重定向状态代码对此有所帮助。
状态代码
- 308 永久重定向——如果我们有嵌套资源
/user/kay/comments/456和/posts/123/comments/456；和根资源/comments/456它可以使事情变得更容易，只需在嵌套资源中发出 308 重定向，其中Location头字段指向根资源，因此不是每个端点都需要交付实现。这应该只针对GET的请求。
错误
API 的下一个重要部分是它的错误。许多 API 框架在出错时默认使用 500 和 404 状态代码，但是根据具体情况，通常会有更多的描述性代码。
500 表示内部服务器错误，这可能是后端访问时没有检查其存在而丢失的头字段，也可能是后端想要调用的无法到达的第三方服务。
因此，可能是客户端做错了什么，我们会期待一个 400-499 的状态代码，但后端从来没有尝试验证请求，并试图处理它，即使它是无效的，我们最终与服务器错误。
404 表示未找到。这可能是因为客户端使用了一个错误的 URL 指向一些没有在后端正确设置的端点。
正如我们看到的，404 是一个客户端错误状态代码，但它很可能是我们在后端做错了什么。
错误的 URL
当客户端发送一个 URL 时，我们不知道。这可能有多种不同的原因，因此我们必须检查哪一种原因适用于此处。
状态代码
- 404 未找到 -这是最自然的反应，应该在客户端 URL 错误的情况下使用。
- 不允许使用 405 方法——在许多框架中，我们在 HTTP 方法旁边定义了 URL，因此删除其中一个定义会使一个 URL 的所有方法保持不变，只留下一个。响应必须包括一个列出允许做什么的
Allow头字段。 - 501 没有实现——像 405 一样，但是后端的所有资源都缺少该方法。
- 406 不可接受-URL 存在，但后端无法发送客户端将接受的表示。因此，对于特定的客户端，URL 的行为类似于 404，但是他们现在知道他们需要更新客户端。
- 410 消失了，这就像 404，但是我们知道资源在过去存在，但是它被删除了或者不知何故被移动了，我们不知道它在哪里。
- 414 请求-URI 太长 -当端点是正确的，并且资源存在，但是查询使 URL 太长而无法解释时，有时会出现这种情况。
- 308 永久重定向(Permanent Redirect)——如果我们知道一个资源已经移动到了一个不同的 URL，并且我们可以告诉客户端，那么这将是正确的代码。
- 307 临时重定向——和 308 一样，但是我们不知道将来资源是会回到原来的 URL 还是另一个不同的 URL。
没有权限
通常客户端不能访问后端的所有资源，所以我们需要一种方式来告诉他们。
状态代码
- 401 未授权 -客户端还没有授权自己访问后端，服务器可能会在授权之后授予它访问权限。
- 403 禁止 -客户端已经授权或者不需要授权自己，但是仍然没有访问资源的权限。
- 404 未找到 -如果 401 或 403 是这种情况，但后端出于安全原因不想告诉客户端该资源存在。
结论
HTTP 的创建者在设计它的时候考虑了许多状态代码，甚至在过去的几年里添加了许多新的状态代码。如果正确使用它们，它们可以通过利用客户端的自动重定向跟踪和更清楚地解释发生了什么来帮助极大地改善开发人员的体验。
有时我们可以为一个特定的情况使用多个代码，重要的是我们在整个 API 表面上保持使用的一致性。
为什么内容是开启开发者至上营销战略的关键
创立一家以开发者为先的创业公司和创办一家普通公司不太一样。当你的主要焦点是创造产品卖给开发者时，你需要围绕这些开发者的需求建立一个销售策略。偶尔发一封带有“点击此处观看演示”按钮的邮件是不行的。相反，是时候制定你的内容策略了。
为什么要相信我们的话？因为内容是 Moesif 在与开发者联系时的头号策略。如果你正在读这篇博客，这个策略正在起作用。
满足开发者的好奇心
向开发者受众销售是关于建立你的可信度。他们需要知道他们可以相信你的产品能够可靠高效地交付。这意味着你必须证明你知道你在说什么。
但事实远不止如此。总的来说，开发人员是一群好奇的人——他们喜欢进行自己的研究，深入主题，从不同的角度发现产品。这意味着你需要为他们提供多种途径来获得你的产品，并满足他们的输入需求。
一旦你建立了自己的信誉，确立了自己在特定领域的思想领袖地位，那么是时候考虑销售分层了。如果你有正确的内容策略，销售部分将很容易到位。
那么，我们在这里只是谈论几篇博文吗？
当然不是。一个强健的内容策略有多个方面。你可以举办面对面的活动，记录下来，然后转化成网络研讨会。然后，您可以将这些网络研讨会转录成文章——用于您自己的博客和您的开发人员受众经常访问的其他网站。当你把所有这些形式的内容结合在一起时，你就能从你的策略中获得最大的价值。
在每一点上，你的内容必须是有教育意义和有帮助的。它需要向读者传递价值，而不仅仅是营销信息。通过这些有价值的内容，你将有机会在开发者眼中成为你特定产品领域的思想领袖。成为某个特定主题的第一名文章可能非常有价值。
多层内容
一个好的内容策略有几个层次。在漏斗的顶部是关于一般问题和解决方案的内容——十大综述、博客文章、信息图表等等。目的是为你的品牌建立一个初步的认知，把你自己放在开发者的雷达上。
接下来是向开发者展示如何使用你的产品/*台/工具来完成某件事情的内容。从本质上讲，它是如何让他们的生活变得更容易的。这是关于在不同的场景中展示你的产品的真实价值，当然是以一种温和的、非促销的方式。
一旦你的开发者准备好发现更多？此时，您可以分享您的漏斗底部内容——您的深入案例研究、比较指南、白皮书等。
分享是关怀
这项工作不仅仅是创造你的内容。事实上，许多内容创作者犯的最大错误是不愿意分享他们的内容并获得反向链接。这些可爱的，有价值的反向链接，将说明你的专业知识，并展示你的内容作为开发人员需要的资源。
与许多人的想法相反，内容不是一个数量游戏。这是关于专业知识和可分享性。在 DZone 上创建一篇文章，你就能立刻吸引开发者的眼球。在 Stack Overflow 或 InfoQ 上，当开发人员寻找解决方案时，你就站在了最前面。这同样适用于任何吸引你的目标开发人员的网站。
清晰和信息图是你的朋友。你的内容越易读、越有用，人们就越有可能分享它。圣杯是让开发者在他们之间分享你的内容，在 Reddit 线程和社区论坛中使用它来回答彼此的问题。这时你就知道你已经搞定了。
在创建可共享内容方面，也有一些立竿见影的方法。举例来说，十大综合报道是在社交媒体上分享 10 个简单分享的好方法，你可以给你提到的 10 家公司都打上标签。请记住，你制作的每一个内容都要向读者传递价值。
当使用你的内容与开发者联系时，数据也很重要。你越了解哪些主题和哪些角度让开发者注册你的工具，或者积极参与你的*台，就越好。然后，你就可以很好地创建补充内容，为开发人员发现非常有价值的相同主题提供内容。
那么，关于销售…
一旦你创建了这个杰出的、互联的内容网络，下一步是什么？那么，是时候让您的销售团队参与进来了，而且是以一种有意义的方式参与进来。真正关心开发人员的痛点并理解他们消费内容的意图的销售人员将会把潜在客户变成付费客户。
一个开发者至上的公司如果做得好，将最有可能吸引人们注册其*台/产品，并最终提高其底线。
为什么数据驱动的客户成功在当今的新冠肺炎世界至关重要
在今天史无前例的经济衰退中，寻找和接*新客户比以往任何时候都更加困难。现在的责任是保持现有的客户成为你产品的有效用户。通过密切监控 API 度量标准，客户成功管理(CSM)团队可以获得关于那些存在混乱风险的早期警告，并在为时已晚之前纠正事情。
客户获取与客户保持:至少 5X 成本差异
根据不同的 调查，获得一个新客户的*均成本在 5X 和留住一个现有客户的 25 倍之间。那是在前 COVID 时代。在当今世界，可能更多。
CSM 的使命是帮助客户通过你的产品实现价值。客户价值实现是让客户不断回头客的飞轮。CSM 是加速飞轮的动力。
通过像 Moesif 这样以用户为中心的分析，可以密切关注您的客户在做什么，并在他们努力集成或使用您的产品和 API 时伸出援手。让我们看看您需要跟踪的重要指标是什么，这样您就可以达到您的保留目标
要跟踪以达到保留目标的指标
通过监控客户的活动，您将能够:
- 了解他们的使用行为
- 需要时提供更好的帮助
- 尽早发现客户流失
- 了解他们是否会续约
API 调用和保留的次数
通过跟踪客户何时开始和何时停止发送流量，了解他们何时参与(如下图所示)。将您的参数绑定到波段，这样如果值移动到预定义的波段，您会得到通知。使用实时警报主动识别并联系面临风险的客户。在 Moseif 中， alerts 可以通过 Slack、SMS、Email 和 PagerDuty 发送。有一级岗位懈怠，然后二级开火到 PagerDuty。如果需要，升级到工程或该系统的任何待命人员。
为类似的活动创建群组可以实现对大量客户的高效监控，无论他们是个人用户还是公司。按最活跃的公司分组，有 5 个以上 API 错误的新用户和许多其他类型的字段(上图)。
错误事件和流失
快速发现错误的有效负载，并与客户一起进行分类以确定问题。发现失败的系统并避免流失。如果您的客户集成了您的 API，但一直收到 400 或 500 错误，请在错误发生时立即得到通知，联系客户并控制它。按出现错误的每个用户的顶级 API、出现 4xx/5xx 错误的新用户、最大延迟(下图)等进行分组。
群组保持
随着时间的推移，准确测量产品保留率和粘性。产品保持率衡量的是一群用户中以某种方式与你的 API 交互，然后又回来与你的 API 交互的用户的百分比。按新用户、使用的 SDK 等分组(如下图)。
达到保留指标
CSM 团队现在面临着更大的压力来达到保留指标。随着商业因冠状病毒和就地庇护而陷入低谷，数据驱动现在比以往任何时候都更重要。监控重要指标，以避免这些艰难的讨论，保持您的客户成功，并确保他们真正续约。
为什么我创办了另一家应用程序日志公司
原文：https://www.moesif.com/blog/technical/logging/Why-I-Started-Another-Application-Logging-Company/
有许多日志记录和异常跟踪公司。从 Sumo Logic 到 Sentry，开发人员在应用程序日志记录和异常跟踪方面有了比以往更多的选择。为什么要在一个似乎有大玩家的领域创建一个新的伐木公司？
背景
在创办 Moesif 之前，我是 Trove 公司的首席技术官，在此之前，我是英特尔公司的 CPU 架构师。在每个职位上，调试总是我日常活动的一大部分。在我们的项目生命周期中，我的大部分日常工作都涉及到调试。我会调试客户报告的问题，调试回归测试中出现的错误，在提交之前调试我自己的代码，等等。无法回避的事实是，大多数开发人员花在调试上的时间比花在编码和产品开发上的时间要多。
对于 Trove 栈，我们使用 Loggly 来存储来自后端 API 驱动服务的应用程序日志。这些是 Scala、C#和 NodeJS 服务的组合。对于我们的 web 应用程序，我们还使用 Sentry 来记录和跟踪异常。对于我们的移动应用，我们使用了 Crashlytics。
我们还使用 New Relic 进行了一些性能监控，尽管 New Relic 主要对操作和性能人员有用，但对应用程序调试没有用。
然而，即使有了所有这些服务，调试仍然是一个手动和缓慢的过程。在自动驾驶汽车的时代，为什么我们不能让调试更加自动化？
分解调试过程
收集上下文
在 Trove，我收到了一些客户支持请求，客户在登录时会遇到错误。
要开始调试，我必须收集客户上下文，比如错误发生在什么设备上以及错误发生的时间。我通过从支持票据中搜索客户的电子邮件，在我们的用户数据库中查找了 user_id 。
在得到一个用户标识后，我进行了日志搜索，希望这个用户标识被记录为异常。
唉，我发现错误了！但问题是 Loggly 和 Sentry 中记录的异常非常普通:
缩小失败服务的范围
我们有相当多的微服务支持我们的后端利用工具，如 Docker。有些是 Node，有些是 Scala，等等。然后我们有了移动和网络应用。Loggly 中的错误只会告诉我错误发生在哪里。然而，我们都知道，通常错误是一些因果关系的结果，但原因可能是错误发生的上游。
为了缩小根本原因的范围，我继续进行我的手动日志搜索，寻找相关消息，试图追溯到源头。对于这个特殊的登录错误，我能够追溯到第三方 API，Google 认证 API。
消除过程
即使我们看到记录的错误，现在知道这是由于谷歌 API，它仍然是非常短暂的。即使在尝试完成谷歌登录步骤时，我自己也无法重现错误。
我开始收集更多的信息。
- 错误是否只发生在特定的数据中心？
- 它是通过 Google 登录 API 的特定参数发生的吗？
- 第一个出现这个错误的版本是什么？
对于任何开发人员来说，做这个排除过程的时间会非常长，是一种时间浪费。
结果呢
我们最终找到了导致错误的根源，在这种情况下，由于短暂的 HTTP 超时，移动客户端会调用 Google Auth API 以获得一次性使用授权代码(OTU)。这个 OTU 令牌被传递给我们自己的 API，然后它调用另一个 Google API 来验证授权代码，并交换一个访问和刷新令牌。由于授权码已被使用或过期，该最终端点将出错。
我们必须追溯到被调用两次的初始 auth 端点。谷歌将返回相同的 OTU 代码(可能是由于缓存)。
API 调用流程:
-> accounts.google.com/o/oauth2/v2/auth
-> api.usetrove.com/login
-> www.googleapis.com/oauth2/v4/token
这种做法有什么问题？
1.顾客必须告诉我
即使有始终连接的警报(Slack、PagerDuty、DataDog 等)，我仍然有客户告诉我有问题。为什么我们的测试没有发现这个？为什么 Sentry 或 Loggly 没有在客户之前提醒我这些问题？
一个提示:状态空间爆炸和 bug 的动态本质。
错误表现为特定的:
- 系统的状态
- 系统的输入(包括计时)
如果我可以精确地重新创建状态和输入，那么我就可以重新创建任何 bug。问题是现代网络应用的状态比几年前复杂了几个数量级。
国家分散在:
- 许多不同的 Pb 大小的数据存储
- 许多不同类型的设备和客户端也存储状态
- 构建工件和代码版本的状态
- 配置和环境状态
- 操作系统/虚拟机/容器状态
输入现在分散在数百个容器中，并且必须考虑网络延迟输入、用户对设备的输入等。
警报仍然是静态的(即，如果错误率在下一分钟翻倍，我必须设置警报来提醒我)。测试也是静态的。测试是人为设计的场景，很多时候是由开发人员编写的，他们也对特性进行编码。如果该特性由于跨服务交互的架构假设而存在缺陷，该怎么办？这些假设也可能被纳入测试，造成错误的通过。
2.日志搜索仍然非常手动
一旦我在日志记录或异常跟踪软件中发现错误，我仍然需要自己进行日志搜索。
从调试登录问题可以看出，从支持电子邮件中查找 user_id 需要时间。然后我必须找到该用户发生的异常。
调试就像尝试一堆小实验。您根据当前对错误场景的了解提出一个假设，然后研究日志，看它是否验证了您的假设。
你需要一遍又一遍地重复这一点，直到你有足够的证据断定根本原因是。
这个过程听起来不像是计算机能做得更快的事情吗？
3.日志必须手动编码
大多数开发人员会记录每个异常，或者至少记录他们认为的错误。如果您需要追溯到导致错误的服务，而消息没有被记录，该怎么办？就像人工测试一样，开发人员只能记录他们认为调试服务需要的东西。如果一个新的 bug 以不同于预期的方式强调服务，并且没有记录足够的上下文，该怎么办？
您必须添加更多的日志消息，然后看看是否可以重新创建该场景。发布一个包含更多信息的新版本来捕捉问题需要时间。
4.日志不能显示交互
大多数日志和异常跟踪工具将消息本身显示为问题单，或者类似于跟踪日志流。如果错误是跨多个服务的呢？如何用简洁的方式表现这一点？当您开始研究与跨多个系统的并发性相关的更复杂的错误时，仍然很难仅使用日志来查找根本原因。
结论
调试可能是有趣和令人兴奋的，尤其是有时当我发现一个疯狂的竞争条件时，这很有趣。然而，大多数公司不会因为“好玩”而付钱给开发者。花在调试上的时间不是花在产品开发或增长上的时间，这可能会影响收入和底线。
moes if 如何让调试变得更简单？
为什么 Twilio 客户不会去任何地方
众所周知:我们是像 Twilio 这样的 API first 公司的粉丝。超过 1000 万客户使用他们的*台，看来我们并不孤单。
长期以来，Twilio 一直是开发人员的宠儿，它*易*人的*台使得在几乎任何环境下发送语音、视频和 SMS 消息都很容易。
今天，我们将深入了解 Twilio 如何在客户参与方面提供最佳服务。
低代码/无代码功能
“建造还是购买”，这是个问题。就像经典的莎士比亚难题，“生存还是毁灭”，必须做出选择。对于 SaaS 公司来说，增加新功能的成本曾经意味着在内部构建这些功能，或者向外部供应商支付额外的功能。这两种选择都带来了严峻的挑战。
现在有了第三种选择。低代码/无代码(LC/NC)工具提供了额外的功能，无需编写复杂的代码。使用 LC/NC 工具，通常需要几个月才能构建的软件可以在几周内发布。自然，选项已经越来越受欢迎。
Twilio 没有错过这一趋势，他于 2017 年底推出了 Twilio Studio。Twilio Studio 让客户无需编写代码即可享受强大的通信基础设施。这对于非技术用户，以及希望快速构建的精益工程团队来说非常好。
简化的用户界面
Twilio 的界面既方便又易于控制。开发者和产品经理都不需要担心决策疲劳。像宾利一样，Twilio 驾驶起来很*稳，同时在引擎盖下提供了大量动力。
仅在 onboarding 中，就很容易看出是什么让 Twilio 的界面如此出色。
设定期望
从一开始，Twilio 就让用户知道会发生什么。预计到有人可能会问，“Twilio 是多少钱”，Twilio 立即让用户知道没有预付到期。
这是对他们在*台的每个方面提供的透明度的一个温和的介绍。Twilio 也很快让用户知道他们可以用他们的产品做什么。请参见他们早期入职流程中的以下元素作为解释。
在入职的最初几分钟，你就已经知道 Twilio 不打算给你惊喜。在*台的更深处，他们继续以同样的方式呈现新的信息。
少即是多
“完美的实现，不是当没有更多可以添加的时候，而是当没有什么可以拿走的时候。”-安托万·德圣埃克苏佩里
如果用一个词来形容 Twilio 的界面，那就是“精确”整洁的菜单、恰当的工具提示和强烈的视觉设计创造了一个干净的用户界面。
呈现给用户的每一个选择都被有意简化，而不失去意义。一旦用户完成了上述步骤，他们就会提供有针对性的问题来定制用户的新帐户。措辞直接、明确、*易*人。同时，呈现给用户的选择数量提供了没有压倒性的定制。
在这几个步骤之后，初始入职就完成了。从这里，用户第一次被引导到他们的仪表板。
用户可以立即体验 Twilio 的全部功能。免费用户有机会设置一个 Twilio 电话号码，添加队友，并尝试使用 Twilio Studio 进行 LC/NC 体验。
多样化的帮助资源
同时，可访问的支持资源确保任何需要详细信息的人都能找到它们。这些资源可以通过多个周到的链接获得，确保所有用户都能获得他们需要的信息。
用户可以选择通过帮助文章、文档、导游，甚至游戏 Twilio Quest 来了解 Twilio。
总的来说，Twilio 的界面提供了它所需要的一切，而没有损害用户体验。
他们是第一批“开发者优先”的人
在 Twilio 成为上市后独角兽公司之前，他们并不以像典型的 SaaS 企业那样销售而闻名。他们经常根本不“卖”。然而，它们仍然在增长。
创始人杰夫·劳森的一个著名故事完美地说明了这一点。
在劳森和两个朋友于 2008 年创立 Twilio 大约一年后，劳森受邀在一个名为“旧金山新技术聚会”的流行社交聚会上介绍它。劳森决定让 Twilio 软件自己说话，而不是谈论一种本质上难以解释的技术。在 1000 人面前，劳森开始讲述他的故事，同时编写了一个 Twilio 应用程序——一个简单的会议线路。
仅仅几分钟后，他就开了一个账户，获得了一个电话号码，在写了几行房间里每个人都能理解的代码后，他的会议线路就开通了。劳森然后要求每个人都打电话进来，就这样一群开发人员开了一个大型电话会议。劳森随后添加了一些代码，他的应用程序给每个人打了电话，感谢他们的参与。随着整个房间的电话开始嗡嗡作响，人群狂热起来。”–米格尔·赫尔夫特，福布斯
买之前先试试
Twilio 为开发人员提供了尝试他们产品的机会，而不期望购买。虽然与当时占主导地位的企业销售模式相反，但跳过前期成本赢得了开发人员社区的信任。很快，Twilio 就赢得了任何项目都可以使用的工具的声誉。
Twilio 不仅仅将开发者视为潜在客户，他们将开发者视为一个社区。有些人甚至认为 Twilio 推广了开发者福音。虽然他们的支付模式只是他们的开发者主导战略的一部分，但它仍然使他们的产品变得伟大。
任何创建 Twilio 账户的免费用户都会发现一套强大的功能。免费试用用户有权获得一个 Twilio 电话号码，允许他们尝试语音通话、视频会议和短信功能。因此，即使 Twilio 的免费功能也提供了他们付费计划的现实预览。
灵活的定价选项
如果用户决定超过他们的 15.50 美元的试算表，提供免费注册，他们的账单无缝扩展到 PAYG 定价。要了解更多关于 PAYG 模式的信息，请看我们的另一篇文章。
当新用户想成为客户时，他们会找到适合任何情况的计划选项。这对于几乎任何类型的用户来说都是非常好的，无论他们是想实验性地构建项目，为了好玩，还是为了重要的基础设施。几乎可以适应任何用例。
我们为什么喜欢 Twilio
如果说在软件世界中有什么是不变的，那就是变化。作为一个把未来寄托在我们的信念上的公司，每个公司都将成为 API 公司，我们期待看到其他 API 第一的公司成长。
Twilio 继续适应 SaaS 不断变化的现实——它以适应迎接每一个新的挑战。我们渴望在 Moesif 获得类似的弹性，这就是我们提供透明定价功能和简化入职流程的原因。
Moesif 提供四个计划层级，每个层级都有灵活的 PAYG 计费
我们的定价模式结合了按需付费的灵活性和订阅的可靠性。用户可以使用我们的四个价格等级中的一个来衡量他们每月的使用情况。但是，如果他们使用我们服务远少于或多于预期，那么他们每月的账单将反映实际的使用情况。
与 Twilio 类似，我们也致力于简化入职流程。对于大多数安装，Moesif 只需要几行代码来添加我们的 SDK。每个入职工作流都可以根据用户现有的技术体系轻松定制。像 Twilio 一样，我们的*台旨在通过提供有针对性的信息来减少决策疲劳。
像 Twilio 一样，我们也提供“先试后买”的模式。这样，Moesif 用户可以在做出决定之前体验我们产品的全部功能。任何人都可以通过在这里注册免费试用成为用户。
总的来说，我们有充分的理由认为 Twilio 是客户参与方面的“领导者”。它干净的用户体验、对开发者社区的承诺以及创新的速度无疑使它成为通信基础设施的绝佳选择。换句话说，这一千万顾客不会很快离开！
解决 Chrome 扩展中的内容安全策略问题
之前，我们讨论了一个用例，一个 Chrome 扩展通过脚本标签将一个脚本注入到网页中。该脚本将在该网页的上下文中运行，以便扩展可以访问资源并与网页共享 javascript 对象。然而，一些网页有一个内容安全策略，阻止 AJAX 调用不属于白名单的域。这篇文章解释了我们解决这个问题的方法。
执行上下文
本质上有三个执行上下文，其中每一个都是几乎完全隔离的环境。
-
网页的执行环境，这些包括网站最初加载的任何脚本，或者添加到文档的 DOM 中的脚本标签所包含的任何内容。在此上下文中运行的任何脚本都受网页的原始内容安全策略的约束。此外，你不能直接访问任何 Chrome 扩展资源。(查看如何将脚本加载到这个环境中)
-
内容脚本的执行环境。它们是由
chrome.tabs.executeScript()启动的脚本。内容脚本可以操作主机网页的 DOM。在这个执行上下文中，您不能访问网页上的任何 javascript 对象或函数。但它仍然可以访问 chrome 扩展资源，如chrome.runtime或chrome.tabs。 -
Chrome 扩展本身的执行环境。
APIRequest.io Chrome 扩展的背景
创建了 APIRequest.io Ajax Capture Chrome 扩展，以捕获单页面应用程序的请求和响应(以使这些应用程序的协作和调试更加容易)。在这个扩展存在之前，据我们所知，由于 Chrome WebRequest API 的限制，没有可以捕捉响应的扩展。我们找到的解决方案包括使用一个脚本标签将一个脚本注入到网页的上下文中，如本文中所讨论的
但是，由于时间限制，最初的版本没有添加与内容安全策略的兼容性。因此，在网页的执行上下文中，如果原始网页的内容安全策略不允许我们与不属于原始白名单的域进行通信，我们就不能进行 AJAX 调用(需要将捕获的数据存储在持久化和可共享的链接中)。
解决办法
为了与任意内容安全策略兼容，解决方案是将数据传递到另一个不受内容安全策略约束的执行上下文，执行 AJAX 调用，并处理结果。
网页上下文和内容脚本之间的消息传递。
这涉及到使用window.postMessage()
发送消息
const domain = window.location.protocol + '//' + window.location.hostname + ':' + window.location.port;
// console.log(domain);
window.postMessage({ type: 'API_AJAX_CALL', payload: payload}, domain);
domain变量是消息将被发送到的网页。因为网页和内容脚本实际上是在同一页面上执行的，所以通过使用主机网页的同一域，消息将被传递给内容脚本，反之亦然。
虽然可以做window.postMessage(data, '*')，但是“*”暗示任何页面都可以读取消息，这可能是危险的。如果消息是敏感的，您不希望恶意网页(在其他选项卡中)看到这些消息。
1.接收消息并进行 AJAX 调用
在内容脚本上下文中，我们不受内容安全策略的约束，我们可以接收消息并进行 API 调用。
window.addEventListener("message", function(event) {
// We only accept messages from ourselves
if (event.source != window)
return;
// console.log("Content script received event: " + JSON.stringify(event.data));
if (event.data.type && (event.data.type == "API_AJAX_CALL")) {
//make my ajax call here with the payload.
const request = superagent.post(myAPIEndPointUrl)
request.send(event.data.payload)
.end(function (err, res) {
returnAjaxResult(err, res.body)
});
}
}, false);
由于发送消息的window是同一个窗口，我们应该在接受消息之前检查以确保它是相同的。这确保了我们知道消息来自哪里。
2.将 Ajax 的结果返回到原始上下文
windows.postMessage没有回调方法。因此，要将 AJAX 结果传递回原始网页，我们必须再次使用windows.postMessage。
function returnAjaxResult(err, resbody) {
const domain = window.location.protocol + '//' + window.location.hostname + ':' + window.location.port;
// console.log(domain);
window.postMessage({ type: 'API_AJAX_RESULT', payload: {error: err, responsebody: resbody}}, domain);
}
通过这种方式，内容脚本就像是对不在内容安全策略中的域的 AJAX 调用的代理。
ContentScript 和扩展之间的消息传递
因为两者都可以访问 Chrome 扩展相关的对象，所以你可以使用这些资源
从内容脚本到扩展:
chrome.runtime.sendMessage({payload: playload}, function(response) {
// callback
});
将消息从扩展传递到内容脚本更有趣，因为这取决于您执行内容脚本的选项卡。(chrome.tabs.executeScript 也需要一个tabId，所以你只要记住就可以了。)
chrome.tabs.sendMessage(tabId, {playload: playload}, function(response) {
// callback
});
消息传递也有回叫，这使得处理起来容易了许多。
结束语
我们的重点不是构建 chrome 扩展，但作为我们自己使用的一个附带项目工具，这绝对是一个有趣的项目。对于这个内容安全策略问题，我曾搁置了一段时间，以代替时间限制，但是后来一个用户发消息给我说，他能够使用消息传递来解决这个问题。我们很高兴其他人也发现我们的附带项目很有用，因为我们经常为我们自己的单页应用程序使用 APIRequest.io Capture Chrome 扩展和我们非常受欢迎的 Moesif CORS 扩展。
你对 API 活跃用户的衡量是错误的
API 提供者需要了解他们的消费者如何使用他们的 API。使用指标是必不可少的，因为它们告诉你 API 的采用情况，你的 API 如何随时间增长，以及哪些端点看到更多(或更少)的使用。当您查看 API 使用指标时，您应该从与您的服务最密切相关的角度来衡量 API 上的活跃用户。这将告知您的组织在哪里分配计算资源，您决定开发哪些 API 端点，以及您记录哪些 API 端点。
什么是活跃用户？乍一看，这似乎只是简单地跟踪使用一个端点的用户数量。但是 API 用户不能像网站用户一样被追踪。相反，你需要看看你的用户在你的产品环境中是如何访问你的 API 的。
API 上的活跃用户是什么样子的？一个活跃的 API 用户是任何一个经常调用你的 API 来获得真实结果的用户。这并不意味着他们必须不断地进行 API 调用才能被认为是活跃的。API 消费者调用 API 的频率取决于 API 的上下文。如果一个活跃的用户需要从您的 API 中获得价值，他可能每天都会进行多次 API 调用，或者如果他需要从您的 API 中获得的只是每周的数据处理，他可能只需要每周进行一次 API 调用。一种常见的做法是将 API 使用指标分为每日活跃用户和每月活跃用户，以便更清楚地了解用户在不同时间段的活跃程度。
虽然采取一刀切的方法来衡量活跃的 API 用户可能很有诱惑力，但是在决定衡量什么时，您需要考虑 API 的上下文。您的度量应该反映您的 API 如何在现实世界中为用户创造价值。例如，允许您发送 SMS 消息的 API 应该跟踪用户发送的 SMS 消息的数量。压缩视频的 API 会跟踪为每个用户压缩和发送的数据文件的大小。这些指标应该与所提供服务的价值直接相关。
坏度量，好度量
虽然 API 提供商通常通过跟踪独立用户的数量来衡量活跃用户，但这是一种虚荣的衡量标准，它让事情看起来很好，但并没有真正传达多少信息。由于独立用户的数量通常会随着时间的推移而增加，这很容易让人想到这样的指标，因为它可以向内部利益相关者讲述一个积极的故事。不幸的是，对活跃的独立用户进行简单的计数是一个糟糕的指标，因为它没有给出用户使用 API 做什么的详细信息。如果你是一家百货商店，这与计算橱窗购物者的数量没有太大区别。有趣的是，它没有告诉你有多少人来买东西，他们买了什么，或者他们花了多少钱。相应地，您想知道用户是否继续以有意义的方式使用您的 API，为您的 API 消费者创造了多少价值，以及哪些 API 端点和功能对您的用户最有价值。没有关于 API 消费者的有意义的信息，您的组织就不能决定在哪里应用新的开发或者如何分配资源。
随着用户群的增长，扩展 API 指标非常重要，但这一点经常被忽视。当您有少量的 API 消费者和少量的使用模式时，衡量活跃用户可能很简单。但是，随着 API 变得越来越复杂，准确测量有意义的用户活动变得越来越困难。您需要一个前瞻性的度量策略，随着您的 API 的发展而发展。这有一个额外的好处，那就是确保您的组织不会随着 API 的增长而抛弃老用户。像您的组织已经创建的 API 键的唯一数量，或者对您的 API 端点的调用总数这样的指标，并不总是指示它们最初测量的内容。例如，一个开发者可以创建多个 API 键。
让我们看看什么是好的度量标准。好的度量应该给你关于 API 消费者如何与 API 交互的有意义的信息。您的指标应该能够回答以下问题:
- 在您的 API 响应中传递了多少数据？都有用吗？
- 每个用户与您的 API 保持连接的时间有多长？
- 哪些端点最活跃？
- 用户在进行 API 调用时有多成功？
好的指标不仅仅告诉你有多少开发人员使用了你的 API。上面的问题是考察你的 API 消费者对你的 API 的参与程度的不同方式。如果你的 API 专注于在不同设备之间传输数据，那么传输的数据量是你的用户参与度的一个很好的指标。另一方面，如果您的 API 提供实时服务，比如视频内容的实时字幕，那么连接的长度将是一个更好的参与度指标。 了解更多 关于 Moesif 如何帮助您跟踪参与度指标的信息。
API 活跃用户，真的
好的度量标准的一个好的起点是将您的 API 调用聚合成有意义的事件，而不是查看 API 调用的原始数量，这可能是一个嘈杂的信号。事件可以是对 API 调用的更详细的观察，结合了 API 调用及其结果。
测量事件而不是 API 调用还允许您查看不同类型的事件之间的比较，包括它们的共同点。观察失败的事件可以揭示失败的共同根源。例如，如果您的用户因为太多的流量流向您的 API 端点而遇到失败的事件，您的组织可以通过向您的 API 分配更多的资源来处理这个问题。或者，与您的开发人员入职相关的失败事件的模式可能指向您的用户在开始使用您的 API 时遇到的麻烦。这可能意味着需要更全面的文档，或者您的用户可能需要额外的支持来集成您的 API。
让我们看一些 API 事件度量的真实例子。执行双因素验证的 API 至少有四个基本的 API 事件。成功发送验证短信将是第一个 API 事件，并伴随着一个发送短信失败事件。另外两个事件是当验证代码被成功验证时，以及当验证代码未被验证时。这些事件一起显示了 API 消费者成功使用 API 实现其目标(在本例中，验证电话号码)的频率。通过将 API 交互分成事件来区分成功和失败的 API 交互，可以很容易地理解 API 的实际活动。
最佳实践
虽然我们已经讨论了如何通过事件来衡量活跃的 API 用户，从而更好地告知您的 API 消费者如何使用您的 API，但是还有其他好处。例如，您可以使用您的活动 API 使用指标，直接根据您的服务为用户创造的价值来为用户计费。您的组织可以对成功的活动进行计费，从而将计费与实际结果直接联系起来。例如，打电话的 API 可以根据通话时间计费，发送短信的 API 可以根据发送的短信数量计费。
依赖活跃用户指标时，实时报告至关重要。当你的用户使用你的 API 时，通过测量他们可以获得很多有价值的见解。例如，您可以在用户遇到失败事件时立即发现它们，使您的团队能够实时解决失败问题。如果用户的问题得到及时的支持，他们就不太可能离开你的服务。实时分析还允许您的组织查看在给定时刻(例如在重负载期间)成功事件的数量与失败事件的数量的对比情况。借助实时事件指标，您的团队可以快速响应用户需求，监控失败事件，并了解哪些终端为用户提供了最大价值。 打造更好的 API 产品moes if 提供的深刻见解。
实时成功
衡量 API 用户的总数可能会产生误导，因为它没有提供关于 API 消费者如何从 API 中获得价值的上下文信息。将您的 API 调用批处理到事件中，将为您的组织提供大量 API 信息。您将能够评估失败的事件，以便您的组织能够了解哪个 API 端点需要更多的关注和资源。您还将能够比较成功事件的模式，以便您的组织能够了解哪些端点为您的 API 消费者创造了最大的价值。
要真正了解你的用户，把你的衡量标准集中在他们用你的 API 做什么，以及他们是否真正达到了他们想要的结果。您的度量标准应该关注为您的用户创造最大价值的 API 事件，以便您了解应该将资源集中在哪里。通过实时测量用户的活动来了解他们，给自己最好的机会来满足他们的需求。如果你一直以来对 API 活跃用户的衡量都是错误的，现在是时候重新考虑你的策略了。你的内部利益相关者和你的客户都会为此感谢你。
Moesif 全新应用内体验升级指南
我们已经对 Moesif 的应用内体验进行了重新设计，这是一次重大的重新设计！作为我们为用户提供最佳体验之旅的一部分，我们简化了应用内导航。这一更新使得在 Moesif 中找到关键功能变得更加容易，并且有望让现有用户看到一些他们以前没有使用过但可能有用的功能。
正如所有大大小小的变化一样，可能会有一个学习曲线。这就是为什么我们制作了一个简短的指南来概述如何在 Moesif 中导航到所有您喜欢的功能。
TL；博士:我们增加了一个创建新按钮，允许用户轻松创建他们喜欢的图表、分析和工作流程。所有导航都是通过左侧导航菜单完成的。动态采样功能现在可以通过设置访问。Moesif 中的应用程序可以通过位于 Moesif 仪表板左上角的下拉菜单进行切换。
“新建”按钮
您可能会注意到的第一件事是，只需单击 Create New 按钮，即可创建新的仪表板、图表、警报和工作流。该按钮位于左侧导航的顶部。
单击该按钮时，您将看到许多不同的选项，可以轻松创建新的图表、分析和工作流。将鼠标悬停在每个选项上还会给出每个选项用途的简要描述。
选择这些选项中的任何一个都会将您带到所选选项的相应屏幕。当然，您仍然可以单独导航到屏幕并从那里创建，但这提供了一种快速开始新内容的简化方法。此功能支持一键访问 Moesif 最常用的所有功能。
反馈
如果您对我们的新设计有任何反馈，请告诉我们！
动态采样移动了！
动态采样是一个节省成本的特性，它使您能够根据客户或 API 行为控制将哪些 API 调用记录到 Moesif。因为 Moesif 从不接收跳过的 API 调用，所以它们不计入您的订阅的事件配额。此外，Moesif 自动推断和标准化指标，因此即使不同的客户和行为有不同的采样率，您的报告也是准确的。
在 Moesif 中配置动态采样的入口已经移到设置菜单下。从这里，您可以访问动态采样以前为您提供的所有相同功能。
您还可以在设置菜单中找到我们新发布的隐私规则和自定义角色功能。隐私规则使得基于团队成员的角色编辑字段变得容易，并有助于保持敏感数据的私密性
左侧栏
Moesif 中的导航现在通过左侧边栏菜单完成。我们设计它是为了让 Moesif 的功能更容易访问和导航。您保存的所有内容现在也可以从左侧边栏访问。在这里，您可以找到已保存的仪表板、群组、警报规则以及您或您的团队在 Moesif 中创建的其他工作流。
下面包括一些关于某些功能现在的位置以及对它们的任何改进的描述:
仪表盘
仪表板能够在单个屏幕上为您提供多个视图或图表。这是一种可定制的方式，您可以在一个地方查看所有想要的数据。
因此，您可以更快地开始，您的 Moesif 帐户将有预建的仪表板，每个部门一个:
- 产品
- 客户成功
- 工程
- 安全性
- 销售
- 营销
这些包含了基于我们所看到的效果最好的指标。这可以为你提供一个很好的修改起点，或者你可以从一张白纸开始。
要访问 Moesif 中的仪表板，在左侧导航中，您可以在保存的仪表板菜单项下选择您想要查看的仪表板。默认情况下，Moesif 有一些预填充的仪表板，涵盖一些关键的业务领域，包括产品、客户成功、工程和其他一些领域。这些以及您创建的任何其他仪表板将列在保存的仪表板菜单项下。
要创建新的仪表板，只需点击保存的仪表板菜单项旁边的 + 按钮。
您还可以在菜单中移动已保存仪表板的顺序，并创建一个子仪表板。当您将鼠标悬停在保存的仪表板下的各个项目上时，这些选项就会出现。
我们还对单个工作区内的功能进行了一些改进。为了更好的可访问性和可读性，工作区的注释现在显示在右边。现在你可以很容易地创建和发布评论(包括给你团队中的其他 Moesif 用户添加标签的能力)。
然后保存评论供以后查看。
另一个改进是重新定位了恢复搜索按钮，这样你可以很容易地恢复你过去保存的搜索。
事件
事件屏幕允许用户在应用许多不同的过滤器配置时可视化他们的数据。事件屏幕中的视图和图表包括实时事件日志、时间序列、分段、地理热图和智能差异。
创建图表和查看事件日志可以在事件屏幕中完成。要导航到该屏幕，您需要在左侧菜单中选择事件。
要在不同的图表和视图之间进行选择，如时间序列或实时事件日志，您需要从下拉列表中选择所需的图表，并在那里使用它。
用户
Moesif 中的用户功能允许您深入分析用户。这使得 Moesif 用户能够对基于用户的指标进行排序和过滤。有了这些数据，你就可以深入挖掘用户漏斗、留存率和用户构成分析，从而描绘出你的企业和用户群的完整图景。
用户指标和工作流也可以通过左侧导航访问。在导航中，您会看到用户菜单项以及到您创建的每个用户群的链接。
在用户屏幕上，您可以通过屏幕左上角的下拉菜单导航至不同的功能和工作流程。在这里，您将导航到诸如漏斗、保持和构成等功能。
创建用户群组后，它将显示在左侧导航中用户标题下的用户群组折叠菜单下。
公司
与 Moesif 中的用户功能类似，公司功能允许您执行相同的功能，但基于公司数据进行过滤和排序。
公司指标和工作流程也可通过左侧导航访问。在导航中，您会看到公司菜单项以及到您创建的每个公司群组的链接。
在公司屏幕上，您可以通过屏幕左上角的下拉菜单导航到不同的功能和工作流程。在这里，您将导航到诸如漏斗、保持和构成等功能。
创建公司群组后，它将显示在左侧导航中公司标题下的公司群组折叠菜单下。
警报规则
警报规则使您能够监控 API 中影响客户的问题，并更加主动地确保良好的客户体验。您还可以利用警报来跟踪每个客户级别的指标。例如，您可能希望在新客户的流量大幅下降或*均延迟大幅上升时收到警报。警报可以发送到您选择的渠道，包括电子邮件、短信、寻呼机、Slack 或使用自定义的 WebHook。
警报屏幕也进行了优化，更易于导航。要进入警报屏幕，您可以在左侧导航的警报菜单项下找到它。在标题下方，您还会看到一个到警报历史屏幕的链接。
警报频道视图也被移至屏幕右侧，为左侧的新导航菜单让路。
行为邮件
Moesif 中的行为电子邮件功能允许用户在其应用程序中根据用户行为设置自动电子邮件。根据客户与您的应用程序的交互，发送速率限制警告、入职指导、集成错误等事件的警报，或您希望发送的任何类型的自定义电子邮件。
行为电子邮件现在也可以在左侧导航中找到。以前它们嵌套在警报&治理屏幕中。现在，它们更容易看到，也更容易接*。
嵌入式模板
嵌入式模板使用户能够将他们喜欢的事件日志和图表嵌入到他们的应用程序中。这允许客户查看这些指标，而不需要任何定制代码。
嵌入式模板也出现在主导航中，而不是像以前的 UI 那样嵌套在仪表板屏幕中。您仍然需要像过去一样，通过指标屏幕创建嵌入式模板。
一旦创建了嵌入式模板，就可以通过嵌入式模板屏幕查看它们。
治理规则
API 治理使您能够限制对 API 的访问，或者基于 API 的历史使用模式添加自定义头。适当的 API 治理为良好的 API 安全程序奠定了基础。例如，Moesif 的治理规则可以阻止恶意抓取您的 API 或访问异常大量项目的用户的访问。
除了 API 安全性，您还可以利用治理来满足业务需求和连续性。例如，您可以创建一个规则来阻止具有过期发票的客户访问，或者在客户访问旧版本的 API 时添加折旧警告标题。
最后，治理规则现在也可以通过主导航轻松访问。以前，治理规则可以通过旧的警报和治理屏幕访问。现在，在新的左侧导航中，治理规则菜单项位于底部。
试试吧！
我们的最新更新现已上线，随时可以使用！只需登录 Moesif，体验我们对应用程序外观和感觉的最新改进。我们非常期待您亲自体验我们最新的 Moesif 版本！
