以API为先的业务开发：为什么以及何时

API优先的简单解释

普通开发通常是这样的：你先构建网站或应用程序，当需要移动版本或外部集成时，才在完成的代码上附加一个API。API优先则颠倒了这个顺序。你首先设计合同——任何客户端（网站、移动应用、合作伙伴、内部服务）用来读取数据和执行操作的方法集合——然后再构建界面及其周围的一切。

关键思想是API不再是服务入口，而是成为主要产品。在这个图中，网站只是你的API的一个客户端，与移动应用或合作伙伴仪表板平起平坐。合同在前期达成一致：哪些字段、哪些状态、错误时发生什么。从那里，团队根据该协议工作，而不是根据其他人的代码。

一个逻辑，多种渠道

API优先的主要商业好处是重用。支付、目录、身份验证或价格计算的逻辑只需编写和测试一次。网页、移动应用、聊天机器人、店内收银机和合作伙伴仪表板都调用相同的方法。你不需要三次实现创建订单并追踪三组不同的错误。

对于企业来说，这就是直接的节省。在网站之后推出移动应用不再是一个从零开始的项目：界面是新的，但整个服务器端逻辑已经构建并经过实战检验。新的销售渠道可以更快、更便宜地上线，并且行为在各处保持一致——应用中的价格不会与网站上的价格偏离，因为有一个单一的真实来源。

集成、合作伙伴和生态系统

企业几乎从不生活在真空中：客户关系管理、会计、分析、支付系统、市场。当天产品从第一天起就有一个干净的API时，每个这样的集成都成为与现有合同的连接，而不是对单体的手术。合作伙伴可以嵌入你的服务，而你可以成为其他人产品的一部分。

公共API解锁了一个独立的增长模型。它让合作伙伴在你的产品上构建自己的场景，并让你通过其他人的手来扩展。这正是支付网关和SaaS平台的运作方式：集成商带来客户，因为连接很简单，每个新的集成都在不直接营销支出的情况下扩大了你的覆盖范围。

并行工作和团队效率

达成的合同也是一种并行化工作的方式。一旦团队确定了方法的形状，前端和后端就不再互相等待。移动开发人员针对一个模拟服务器它镜像合同，而服务器端仍在完成中。当各部分相遇时，双方都已准备好，项目从未停滞。

同样的原则在更换供应商或扩展团队时也适用。新人员不必阅读整个代码库——API文档足以理解系统能做什么。合同成为业务、设计和工程之间的共享语言，减少对记得一切的开发者的依赖。

何时值得采用API优先，何时不值得

这种方法并不是免费的，公平地说，它并不总是必要的。如果你计划多个渠道（网站加应用），期待集成和合作伙伴，正在为长期建设，或运行大型并行团队，API优先的做法是值得的。产品的生命周期越长，消费者越多，早期的纪律就越能得到回报。

• 值得应用：市场、金融科技、SaaS、同时拥有移动应用和网页版本的产品、拥有合作伙伴计划的平台。
• 可以简化：单页面着陆、促销网站、快速测试假设的MVP，第二个渠道仍然遥遥无期。

对于一个小型网站，设计一个完整的合同是多余的。不过，即使在这种情况下，保持数据和展示之间的清晰分离也有助于你以后不必重写所有内容。

这种方法的成本

API优先有其自身的代价，值得在开始时达成一致。合同必须在编写任何代码之前经过深思熟虑——这对项目早期的分析师和架构师来说是额外的工作。之后，API必须是版本化的：一旦外部客户依赖于它，你就不能在不破坏他们的集成的情况下悄悄更改响应格式。

添加必须保持最新的文档，以及对安全性的专注：身份验证、速率限制、输入验证。所有这些都是值得的，但它需要成熟的流程。因此，重要的是不要把API优先变成一种教条：设计出产品今天和可预见的未来所需的合同，而不是为了以防万一而设计接口。

我们如何在产品中应用API优先

我们设计数字产品，而不仅仅是网站，因此API优先对我们来说是一种工作标准，而不是口号。一个好的例子是Payora，我们的支付网关。整个集成围绕一小组REST方法构建：创建发票、检查其状态、获取支付详情。随之而来的是一个现成的托管结账和签名 Webhook，它告诉商店支付已经发生。商店不必绘制支付界面或理解区块链——它与一个清晰的合同合作。

另一个例子是Astrina，一个具有公共开发者API的SaaS平台。外部开发者使用密钥调用其方法，配额和状态会在响应中返回。从架构上讲，我们将各个部分分布在子域名上——API单独，支付界面单独，管理面板单独——这样每个部分都可以拥有自己的缓存和安全策略，并独立扩展。您可以在我们的投资组合.

从哪里开始

中看到其他项目的样子。如果您计划多个渠道、集成或合作伙伴计划，优先考虑API几乎肯定会为您节省金钱和麻烦——但这个决定应该在开发开始之前做出，而不是之后。正确的第一步不是立即编写API，而是定义谁将在一两年内使用该系统，并为他们设计合同。

我们在设计阶段正是帮助您做到这一点：我们研究场景，制定合同和版本控制，并判断这种方法在哪里是值得的，在哪里是过度的。通过联系表告诉我们您的任务—— 我们将提出一种架构，您在第二个渠道推出时无需重写。

常见问题