公司在API的发展历程中处于不同的阶段。有些人刚刚开始看到他们需要一个API策略，而另一些团队则专门定义和实现一个API策略。但不管他们在哪里，我们发现他们都在寻找方法来接受API设计优先的方法。

什么是“设计优先”？

乍一看，“设计优先”似乎意味着人们使用其他方法推迟了设计，或者完全退出了设计阶段。这不是我们说的设计优先。 相反，设计优先意味着人们以人类和计算机都能理解的方式写下他们的 API 设计。其他方法可能会鼓励预先设计，但在这些方法中，设计不能在以后的自动化或开发人员工具中使用。

设计优先意味着团队中的每个人都说同一种语言。这意味着每个工具都可以利用相同的设计。采用这种方法的公司和团队可以缩小设计和开发之间的差距。这种 API 设计风格有很多好处，包括： **产品驱动的API。**在此过程的早期，团队可以包括产品经理和质量检查工程师，来帮助塑造API的功能。这有助于团队构建以产品为重点的 API。 **设计驱动开发。**API 开发人员可以使用 API 设计来驱动他们的开发工作。自动化工具可以指导他们构建什么，并确保他们根据设计构建 API。 **并行工作。**人们可以在 API 本身完成之前开始构建 API 客户端。允许 API 使用者、API 生产者和技术编写者并行工作，而无需相互等待。 **更短的反馈循环。**API团队可以使用自动化工具来获得更快的反馈来验证他们的设计。团队可以在编写时试用设计并查看其文档，而不是等到开发人员交付工作代码。

帮助 DevOps – DevOps 团队可以使用 API 设计在 API 部署到生产中之前对其进行测试。他们可以使用自动化工具根据设计检查实现，而不是手动检查。 适应后期变更——团队可以在整个开发阶段影响 API 设计。使用正确的工具，他们可以使设计成为一个持续和不断发展的过程，而不是仅在开发之前发生的步骤。

代码优先方法的挑战

通常，当我们说“代码优先”时意思是团队从代码中生成机器可读的 API 定义，而不是自己编写。他们将生成的文档用作构建资产而不是设计资产。Code First 并不意味着团队会忽略设计。相反，这意味着他们的设计隐藏Confluence 页面或文本文档中，并且可能会被历史遗忘。

使用Code First的团队会错过整个开发过程中使用API设计的好处，而不仅仅是编写代码。这会导致一些潜在的问题。 用户满意度——如果 API 文档没有发布、不完整或与部署的 API 不一致，API 用户可能会感到沮丧并去使用其他产品。 错误的 API——如果团队没有自动化工具来指导设计，可能会构建和部署错误的东西。 错失机会——如果团队没有发布 API 文档的流程，其他团队将难以发现他们的 API，这可能会导致重复工作和错失机会。 不一致的开发人员体验——如果团队不使用工具来指导他们使用的标准，可能会生成具有与其他团队不同的实践和经验的 API。 但老实说，任何团队都需要努力才能转向设计优先的方法。对于较大的公司，需要专注于指导转型的专职人员。无论公司的规模大小，公司都必须是有意为之的向“设计优先”转变。

Eolinker 如何提供帮助？

无论采用何种方法，Eolinker都可以融入人们的开发工作流程，提供了许多可以提供帮助的工具。

**设计工具。**使用Eolinker来编写 API 文档、使用标准化工具来编写一致的 API，以及使用协作工具来讨论 API 设计。 **快速反馈工具。**使用MockAPI获得快速反馈并在开发人员构建之前试用设计。 **集成工具。**使用同步功能来帮助将 API 设计纳入开发工作流程，或者使用 API 管理工具来帮助自动化 API 部署。 **DevOps 和自动化。**使用Eolinker openAPI，将 Eolinker 集成到 DevOps 流程中，并构建自动化。 **开发人员工具。**使用自动生成代码功能生成客户端SDK，轻松使用软件项目中的API。 我们认为 Eolinker 提供了人们构建出色 API 所需的工具，无论他们使用设计优先还是代码优先。

Eolinker 入门

Eolinker是API设计和API协作的最佳平台，专注于让 API 设计成为整个开发过程中的真实来源。如果对 Eolinker 如何帮助您采用“设计优先”方法感兴趣，请访问Eolinker：www.eolinker.com