原文链接：https://medium.com/api3/the-api3-technology-stack-7ac9a64d285e

作者：Ryan Boder

译者：iguana

字数：1318

翻译机构：WhaleDAO

本文简要介绍了构成API3第一方预言机技术栈的层次结构。

正如Burak在dAPIs: APIs for dApps中所说，"API3的目标是大规模地建立、管理和使其赚钱的dAPIs"...... "这意味着创造一个与Web3整体相媲美的dAPI经济"。为了实现这一雄心勃勃的目的。

处于堆栈的顶端是dAPIs，这些是API3工具包中最高级别的工具。dAPIs是受管理的API服务，旨在从智能合约的角度，起到类似于Web API的作用。dAPI 具有以下特征：

• dApp 为 API3 DAO 以透明的方式，为其交易提供的服务付费。dApp没有任何承诺，也没有与API供应商纠缠在一起。

• 他们有一个标准化的、用户友好的界面，旨在将技术抽取出来，单独实现。

• 它们智能合约完全存在于链上，并使用链外的第一方预言机基元，就像防护罩下的信标。

• 它们由 API3 DAO 专业管理，因此 dApp 不必担心 API供应商的可用性或寿命， dAPI能够动态适应 API 可用性的变化。

• dApp 由 API3 DAO 提供保险，以防止因故障而造成的损失， API3 DAO 的这种风险保护使 dAPI 具有可量化的安全性。

  dAPI 是 API3 技术堆栈中最容易使用和最自动化的工具， 由于对 API 供应商的不确定性更具弹性，dAPI 具有更多的覆盖范围，因此具有更多的量化安全性。

dApp 应该默认使用 dAPI，并且只有在有充分理由时才深入研究较低层级。

在堆栈的中间是信标。 信标是由 API 提供商本身托管和运营的第一方数据馈送，由 Airnode 提供支持。 信标主要用作构建 dAPI 的模块，但在必要时可以直接由 dApp 使用。 信标直接使用时具有以下特点：

• dApp 与 API 提供者的数据源关联在一起。 如果API供应商停止提供数据，或者dApp想切换到一个新的API供应商，那么dApp必须做出改变。

• dApp仍然受到API3 DAO的风险保护，以避免因故障造成的损失，但信标的覆盖面比dAPI小。信标对API供应商的不确定性的弹性较小，因为dApp直接依赖于API供应商。

• 信标可以单独访问，也可以组合成 "信标集"，从多个来源汇总数据。信标集是静态的--它的数据源是永久固定的。信标不能像dAPI那样被添加到信标集或从信标集中删除。

信标通常被用作dAPI的构建模块，dApp可能在某些情况下，倾向于直接使用信标而不是dAPI，例如：

• dApp需要从特定链上的特定API提供商那里获得数据，但在该链上没有来自该提供商的dAPI。

• dApp和/或API供应商相对于API3 DAO无疑是庞然大物，API3所能提供的风险保护是远远不够的，所以dApp和API供应商直接和对方对接更为合理。

• 由于合同或监管原因，dApp需要直接与API提供商合作，这会与API3管理的dAPI会产生冲突。

信标是较低层级的第一方预言机基元，可以根据需要使用，使API3技术栈更具有可扩展性，无论是向上还是向下。

dApps可以直接使用信标，但默认情况下应该更倾向于使用dAPI，只有在必要时才使用信标。

在堆栈的底部是Airnode协议。这些是底层规则和通信标准，使信标和dAPIs成为可能。直接使用 Airnode 协议为 dApp 提供了对其与 API 交互的最大控制权，但它也需要更多的努力和专业知识。

Airnode协议包括如下示例：

RRP 模拟传统的 Web API 范例，其中客户端向服务器发出请求，然后等待响应返回。 使用 RRP，“客户”就是您的智能合约。 Airnode 为智能合约提供了向 Web API 发送请求并接收响应的管道。

何时直接使用 RRP ，如下所示，当您的智能合约需要通过不固定的请求传递参数时——它们会随着每个请求而变化。

例如，假设你的智能合约需要知道用户所在城市的天气，而每个用户都在不同的城市。 运行一个不断更新的数据源来为世界上每个城市提供天气是没有效率的。 相反，dApps 可以直接使用 RRP，并在智能合约发送请求时将城市作为参数传递， 我们将这种使用模式称为 Web3 API。

PSP，也称为“pub-sub 协议”，是另一种可用于构建信标的 Airnode 协议。 不同之处在于 PSP 是由 API 提供者发起通信。 API 提供者无需等待来自智能合约的请求，而是“知道”何时发送响应并在正确的时间发送它们。

当智能合约使用 RRP 时，就像使用 Google 搜索一样简单。 合约发送一个带有参数（搜索词）的请求，并将立即得到匹配网页的响应。

当智能合约使用 PSP 时，它就像订阅 Google Alerts。 当发现符合某些参数（搜索条件）设置的标准的网页时，合约订阅将在未来的任何时间收到通知。

PSP 相对于 RRP 的优势在于 PSP 可以更高效。 在上面的“RRP 天气”示例中，如果智能合约想要在佛罗里达州奥兰多的温度达到 100°F 时向客户汇款，客户将不得不手动检查温度并要求付款， 如果这能自动发生就更好了。 但是为了使用 RRP 使该过程自动化，智能合约必须每天请求温度，这会因gas消耗而变得昂贵。

或者，智能合约可以使用 PSP 并订阅在奥兰多的温度达到 100°F 时收到通知，这是自动的且效率更高。 PSP 让智能合约将重复检查温度的工作传递给链下 API 提供者，这样更快并且避免支付大量gas。

dApp 可以直接使用 Airnode 协议，但对于具有固定 API 参数的典型数据馈送，应该更喜欢 dAPI 或 信标。

dApp开发者可以使用最高层的dAPIs，以获得最简单、最有弹性、风险最小的链下API访问。或者，如果他们的dAPIs不能满足特殊需求，可以选择与较低层的信标和Airnode协议合作。

智能合约开发者应该谨记：

• 优先使用dAPIs。因为它们是最简单的，安全性也最能量化。

• 如果想要数据反馈，但API3提供的dAPIs不能满足需求，可以直接使用信标。

• 如果想要低级别的访问API参数和响应，就直接使用Airnode协议。

API3技术栈被设计为带有一定的层次结构，可以轻松地服务于最常见的情况，同时可以灵活地向上和向下扩展，以服务于各种不太常见的应用案例。

原文链接：https://medium.com/api3/the-api3-technology-stack-7ac9a64d285e

作者：Ryan Boder

译者：iguana

字数：1318

翻译机构：WhaleDAO

本文简要介绍了构成API3第一方预言机技术栈的层次结构。

正如Burak在dAPIs: APIs for dApps中所说，"API3的目标是大规模地建立、管理和使其赚钱的dAPIs"...... "这意味着创造一个与Web3整体相媲美的dAPI经济"。为了实现这一雄心勃勃的目的。

处于堆栈的顶端是dAPIs，这些是API3工具包中最高级别的工具。dAPIs是受管理的API服务，旨在从智能合约的角度，起到类似于Web API的作用。dAPI 具有以下特征：

• dApp 为 API3 DAO 以透明的方式，为其交易提供的服务付费。dApp没有任何承诺，也没有与API供应商纠缠在一起。

• 他们有一个标准化的、用户友好的界面，旨在将技术抽取出来，单独实现。

• 它们智能合约完全存在于链上，并使用链外的第一方预言机基元，就像防护罩下的信标。

• 它们由 API3 DAO 专业管理，因此 dApp 不必担心 API供应商的可用性或寿命， dAPI能够动态适应 API 可用性的变化。

• dApp 由 API3 DAO 提供保险，以防止因故障而造成的损失， API3 DAO 的这种风险保护使 dAPI 具有可量化的安全性。

  dAPI 是 API3 技术堆栈中最容易使用和最自动化的工具， 由于对 API 供应商的不确定性更具弹性，dAPI 具有更多的覆盖范围，因此具有更多的量化安全性。

dApp 应该默认使用 dAPI，并且只有在有充分理由时才深入研究较低层级。

在堆栈的中间是信标。 信标是由 API 提供商本身托管和运营的第一方数据馈送，由 Airnode 提供支持。 信标主要用作构建 dAPI 的模块，但在必要时可以直接由 dApp 使用。 信标直接使用时具有以下特点：

• dApp 与 API 提供者的数据源关联在一起。 如果API供应商停止提供数据，或者dApp想切换到一个新的API供应商，那么dApp必须做出改变。

• dApp仍然受到API3 DAO的风险保护，以避免因故障造成的损失，但信标的覆盖面比dAPI小。信标对API供应商的不确定性的弹性较小，因为dApp直接依赖于API供应商。

• 信标可以单独访问，也可以组合成 "信标集"，从多个来源汇总数据。信标集是静态的--它的数据源是永久固定的。信标不能像dAPI那样被添加到信标集或从信标集中删除。

信标通常被用作dAPI的构建模块，dApp可能在某些情况下，倾向于直接使用信标而不是dAPI，例如：

• dApp需要从特定链上的特定API提供商那里获得数据，但在该链上没有来自该提供商的dAPI。

• dApp和/或API供应商相对于API3 DAO无疑是庞然大物，API3所能提供的风险保护是远远不够的，所以dApp和API供应商直接和对方对接更为合理。

• 由于合同或监管原因，dApp需要直接与API提供商合作，这会与API3管理的dAPI会产生冲突。

信标是较低层级的第一方预言机基元，可以根据需要使用，使API3技术栈更具有可扩展性，无论是向上还是向下。

dApps可以直接使用信标，但默认情况下应该更倾向于使用dAPI，只有在必要时才使用信标。

在堆栈的底部是Airnode协议。这些是底层规则和通信标准，使信标和dAPIs成为可能。直接使用 Airnode 协议为 dApp 提供了对其与 API 交互的最大控制权，但它也需要更多的努力和专业知识。

Airnode协议包括如下示例：

RRP 模拟传统的 Web API 范例，其中客户端向服务器发出请求，然后等待响应返回。 使用 RRP，“客户”就是您的智能合约。 Airnode 为智能合约提供了向 Web API 发送请求并接收响应的管道。

何时直接使用 RRP ，如下所示，当您的智能合约需要通过不固定的请求传递参数时——它们会随着每个请求而变化。

例如，假设你的智能合约需要知道用户所在城市的天气，而每个用户都在不同的城市。 运行一个不断更新的数据源来为世界上每个城市提供天气是没有效率的。 相反，dApps 可以直接使用 RRP，并在智能合约发送请求时将城市作为参数传递， 我们将这种使用模式称为 Web3 API。

PSP，也称为“pub-sub 协议”，是另一种可用于构建信标的 Airnode 协议。 不同之处在于 PSP 是由 API 提供者发起通信。 API 提供者无需等待来自智能合约的请求，而是“知道”何时发送响应并在正确的时间发送它们。

当智能合约使用 RRP 时，就像使用 Google 搜索一样简单。 合约发送一个带有参数（搜索词）的请求，并将立即得到匹配网页的响应。

当智能合约使用 PSP 时，它就像订阅 Google Alerts。 当发现符合某些参数（搜索条件）设置的标准的网页时，合约订阅将在未来的任何时间收到通知。

PSP 相对于 RRP 的优势在于 PSP 可以更高效。 在上面的“RRP 天气”示例中，如果智能合约想要在佛罗里达州奥兰多的温度达到 100°F 时向客户汇款，客户将不得不手动检查温度并要求付款， 如果这能自动发生就更好了。 但是为了使用 RRP 使该过程自动化，智能合约必须每天请求温度，这会因gas消耗而变得昂贵。

或者，智能合约可以使用 PSP 并订阅在奥兰多的温度达到 100°F 时收到通知，这是自动的且效率更高。 PSP 让智能合约将重复检查温度的工作传递给链下 API 提供者，这样更快并且避免支付大量gas。

dApp 可以直接使用 Airnode 协议，但对于具有固定 API 参数的典型数据馈送，应该更喜欢 dAPI 或 信标。

dApp开发者可以使用最高层的dAPIs，以获得最简单、最有弹性、风险最小的链下API访问。或者，如果他们的dAPIs不能满足特殊需求，可以选择与较低层的信标和Airnode协议合作。

智能合约开发者应该谨记：

• 优先使用dAPIs。因为它们是最简单的，安全性也最能量化。

• 如果想要数据反馈，但API3提供的dAPIs不能满足需求，可以直接使用信标。

• 如果想要低级别的访问API参数和响应，就直接使用Airnode协议。

API3技术栈被设计为带有一定的层次结构，可以轻松地服务于最常见的情况，同时可以灵活地向上和向下扩展，以服务于各种不太常见的应用案例。