采用 API 设计优先方法

公司在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