与他人的 API 交谈，而无需再次编写 HTTP 粘合代码

与外部 API 的每次集成都以相同的方式开始：阅读文档，弄清楚身份验证，围绕 HTTP() 编写一个薄薄的包装，添加没有人要求的重试逻辑，直到第三次故障，然后为下一个供应商重复这一过程。Phlo 的连接器框架旨在停止重复这一部分。

一个基类，一个契约

每个连接器都扩展了一个共享的 Connector 基类：来自 creds.ini 部分的凭证解析，基于 HTTP() 的 JSON 请求助手，选择性幂等重试，分页，以及标准化的结果形状 obj(ok, status, data, error)，这样调用代码就不会在供应商特定的响应格式上分支。

$res = (new Shopify)->orders(['status' => 'open'])
if (!$res->ok) return error($res->error, $res->status)
foreach ($res->data AS $order) ...

基于OAuth的提供者共享一个带有自动刷新的TokenStore的OAuthConnector基础类，因此令牌过期的处理只需在共享的基础类中进行一次，而不是每个集成中都处理一次。

今天发布的内容

Shopify和Lightspeed用于零售，Slack、Telegram、Twilio和MessageBird用于消息传递，Resend用于事务邮件，Moneybird、Exact Online和e-Boekhouden.nl用于会计，Microsoft Graph、Google Calendar和Google Sheets用于Google和Microsoft生态系统。每一个都是在相同合同之上的薄型文档类，而不是需要重新学习其自身习惯的定制SDK。

QUERY，用于带有主体的读取

连接器合同的一个较新补充是QUERY HTTP方法（RFC 10008）：一种安全的、幂等的读取，携带请求主体，用于过滤器不适合干净地放入URL的查找。route QUERY search => $this->search的解析方式与其他路由相同，%payload以与解码POST相同的方式解码QUERY主体，而HTTP()接受一个匹配的QUERY:参数，因此连接器或您自己的应用程序可以调用一个恰好期望这种形状的API，而无需手动构建。

实际节省时间的部分

价值不在于任何单一的连接器，而在于添加下一个连接器意味着只需实现一次特定于供应商的请求形状，并免费继承凭证处理、重试和分页。一个本来会是一个小型定制项目的集成变成了一个下午的工作，将一个API的端点映射到一个已经有效的合同上。