2

Zapier/IFTTT 如何为不同的 API 提供者实现触发器和操作？是否有任何通用方法可以做到这一点，或者它们是由个人实施的？

我认为实现是基于 REST/Oauth 的，从高层次来看，这是通用的。但是对于 Zapier/IFTTT，它定义了很多触发条件，过滤器。这些条件，过滤器应该特定于不同的提供者。相应的实现是单独的还是通用的？如果是个人，必须有庞大的劳动力。如果是通用的，该怎么做？

4

3 回答 3

2

PipeThru 开发人员在这里...

每个 API 都有可以重复使用的通用元素，例如 OAuth 身份验证、通用数据格式（JSON、XML 等）。大多数 API 都在争取 RESTful 实现。然而，理论与现实相遇，大多数 API 无处不在。

每个服务都提供自己的端点，并且对于给定的服务，没有公认的端点集是正确的。例如，在 CRM 软件中，不清楚应该如何表示一个人、该人的注释、相应的电话号码、地址以及活动。您提供一个端点还是多个端点？你如何更新每个？您是否提供与记录相关的记录（例如该人的公司）？每个都需要该服务的特定知识以及一些数据规范化。

大多数触发器涉及检查新记录（唯一 id）或更新字段，通常是最后更新时间戳。大多数服务以 ISO 8601 格式显示它们的时间戳，这使得解析时间戳变得容易，但并非所有人。Dropbox 实际上提供了一个 delta API 端点，您可以向该端点提供哈希值，并且 Dropbox 会从该点向您发送所有新的/更改的内容。我喜欢在更多 API 中看到增量和/或活动端点。

归根结底，集成每个单独的服务确实需要大量的努力和测试。

我要指出的是，Zapier 确实为其他公司实现了一个 API 来插入他们的工具。您可以将新的/更新的数据发送到 Zapier 以触发他们的 Zapier 之一，而不是 Zapier 实现您的 API 和 Zapier 轮询您的数据。我喜欢把它想象成网络钩子。这允许 Zapier 支持更多服务，而无需对每一项进行编程。

于 2015-01-12T21:30:53.577 回答
2

Zapier 开发人员在这里 - 简短的回答是，我们实现了每一个！

虽然像 OAuth 这样的标准使得将一些代码从一个 API 重用到另一个 API 变得更加容易，但每个 API 都有独特的端点和独特的要求这一事实是无法回避的。适用于一种 API 的方法不一定适用于另一种。在内部，我们已将尽可能多的流程抽象为可重用的部分，但添加新 API 总是需要一些工作。

于 2015-01-12T21:15:28.760 回答
1

我在 Zapier 上实现了一些 API，所以我想我可以在这里提供至少部分答案。如果不使用 webhook，Zapier 将检查来自服务的 API 响应，以查找名称最短且还包含字符串“id”的字段。对此字段的更改会导致 Zapier 触发任务。这是基于 id 通常是增量或随机的假设。

我不得不通过将 id 值转移到另一个字段并在 id 未能触发或触发过于频繁时将不同的值写入 id 来解决这个问题（例如，除以 10 然后写入 id 可以降低触发灵敏度） . 歧义也是一个问题，例如在包含 post_id 和 mesg_id 等字段的 API 响应中。

简短的回答是系统会做出有根据的猜测，但要让它为特定服务可靠地工作，您应该在代码中非常具体地了解触发事件的构成。

于 2014-12-04T07:30:55.340 回答