软件工程
让你的系统可靠地互联互通
大多数集成项目在失败场景中崩溃。演示可行，正常情况可行，但支付提供商在请求中间超时，或会计API在月末限流时，无人知晓订单是被创建了两次还是一次都未创建。正确处理这些情况才是真正的工作。
此方案解决的问题
两种模式导致大部分集成问题。在Web请求中同步调用第三方API，让他们的糟糕一天变成你的宕机。以及缺乏幂等性，导致重试时创建重复订单、重复发票或重复扣款——手动对账的成本远超正确构建的成本。
您将获得的服务
先设计后构建
资源、动词、状态码、错误形态、分页和版本控制等，以OpenAPI规范提前达成一致。发布后的API变更成本高昂；文档变更则不然。
适配消费者的认证
OAuth 2.0用于第三方代表用户操作，服务器间通信使用签名密钥，移动客户端使用短期令牌与刷新机制。选择认证方式以匹配调用方，而非出于习惯。
幂等性与重试
写操作需接受幂等键，使重试请求无法创建第二条记录。出站调用使用指数退避与熔断器，让故障依赖降级而非级联。
可信的Webhook
签名负载、重放保护，以及带手动重新发送的交付日志。接收端应先验证再入队——切勿在请求中同步处理Webhook。
限流与配额
为每个消费者设置限制，并提供清晰的响应头与429状态码，避免单个客户端降低整体服务质量。这正是让API安全交付给合作伙伴的关键。
保持同步的文档
从规范生成并发布，附带真实请求与响应示例，避免手写文档常见的与实现脱节问题。
我们的工作方式
映射流程
数据如何流动、方向、频率，以及某步骤失败时必须执行的操作。失败问题正是塑造设计的关键。
规范化
在编写代码前，与API消费者共同审核OpenAPI文档。消费者能发现生产者无法察觉的设计问题。
按合约构建
实现加合约测试，让破坏性变更在CI中失败，而非在合作伙伴的集成中。
强化边缘节点
超时设置、重试机制、熔断器、死信队列与结构化日志。
沙盒测试与正式上线
为消费者提供沙盒环境与测试凭证用于开发，随后进行分阶段生产发布。
监控
按集成服务统计错误率、延迟与故障次数，在依赖服务出现故障时立即告警，而非等到故障发生后再处理。
您应当期待什么
- 第三方服务中断仅影响单一功能，而非整个网站
- 重试机制不会产生重复订单、发票或收费
- 合作伙伴可直接通过文档集成，无需询问您的团队
- 合约测试可捕获破坏性变更，而非由合作伙伴发现
构建于
- Node.js
- TypeScript
- Laravel
- PHP
- Python
- FastAPI
- OpenAPI
- GraphQL
- REST
- PostgreSQL
- MySQL
- Redis
- RabbitMQ
- Stripe
- Xero
- QuickBooks
- Shopify
- Twilio
- SendGrid
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
API开发与集成 — your questions
包括那些大多数机构在页面上忽略的成本问题。
单次范围明确的集成（如一个支付提供商或 CRM 同步）通常需 £4,500 至 £9,000。面向外部消费者的完整 API（含认证、限流、沙盒及文档）起价为 £12,000。成本变量几乎总是取决于对方系统的表现。
大多数情况下使用 REST；当客户端确实需要跨相关数据自行组合查询时（通常是移动应用以减少往返次数），则使用 GraphQL。GraphQL 在缓存、限流和查询成本控制方面增加了真正的复杂性，因此需有明确需求而非仅出于偏好。
通常可以，但我们会明确说明权衡。可行方案包括：数据库级集成（若可访问）、定期文件交换，或作为最后手段的网页抓取——抓取可行但对方若修改标记即会失效。我们将抓取定价为持续维护而非一次性项目，因为它本身就是如此。
这在设计之初就已考虑。出站调用通过带重试和熔断器的队列运行，因此提供商故障仅导致延迟操作，而非失败请求或 500 页面。任何无法恢复的情况会进入死信队列并触发警报，确保不会静默丢弃。
会，文档从 OpenAPI 规范自动生成，因此不会过时，并附带可运行的示例和沙盒供测试。手写的 API 文档在两次发布后即过时，这也是我们不采用此方式的原因。
在 URL 路径中进行版本化，并配有书面的弃用政策——增量变更进入当前版本，破坏性变更启用新版本，旧版本在约定的窗口期内保持可用。消费者可据此规划，而非被动发现。