API设计停留在过去

二十年前，人们普遍认为动态编程语言效率更高，因为您不必花费时间处理类型签名。那么，使用静态类型语言的唯一原因是为了更好的性能。说实话，在当时，这一观点有一定的道理，许多组织选择离开世界上的爪哇，转向蟒蛇。然而，这在很大程度上是因为广泛使用的特定静态类型语言，以及当时缺乏支持它们的工具。

到目前为止，这种工具已经变得更加广泛。事实上，随着时间的推移，业界已经了解到，静态类型语言实际上支持一系列新的工具，最终，这种工具可以极大地提高开发人员的工作效率和代码库的可维护性。像自动补全和跳转到定义这样的编辑器特性使程序员的工作效率大大提高，而且这些特性大多只在静态类型的语言中才能实现。我们看到了Tyescript的兴起，尽管它没有比JavaScript更好的性能优势，因为它的工作效率更高。此外，当每个人都能够对彼此的代码有某种类型的原因时，更大的代码库变得更容易管理，从而能够更快地添加功能，减少错误。换句话说，维护类型签名的好处现在远远超过了成本。

随着时间的推移，业界已经了解到，静态类型语言实际上可以实现一系列新的工具，最终，这种工具可以极大地提高开发人员的工作效率和代码库的可维护性。

然而，当谈到网络API时，该行业仍然落后了20年。大多数开发人员继续依赖阻力最小的方法：定义RESTful服务，依赖JSON作为数据格式，使用HTTP作为传输协议。有些人认为动态类型的JSON和定义松散的REST标准比替代标准更有效率，或者与其他API标准相关的学习曲线过于陡峭。然而，与20年前的动态语言类似，API开发的现状留下了很大的改进空间。

如今的API开发绝大多数是自由形式的。从根本上说，这意味着声称他们的服务是RESTful的每个公司--以及每个公司内的每个团队--实际上可以有非常不同的API设计标准。例如，在一个团队中，命名约定、分页和版本控制都可能与另一个团队截然不同。通常，团队可能会用不必要的字段重载对象，并使用不一致的数据类型。不幸的是，这导致了许多问题。

很容易理解为什么不同结构的API会损害服务的可理解性。当API以不同的方式设计时，应该如何使用服务并不总是显而易见的，这使得团队无法快速、自信地围绕新服务构建应用程序。

组织确实尝试过标准化服务结构，主要是通过API样式指南的方式。设置风格指南本身就是一件令人头疼的事情，要么需要团队精心制作，要么需要选择一个受欢迎的指南。团队和个人很少能就风格指南达成一致，因此在代码评审中，这个决定经常被忽略和重申。归根结底，即使内部就样式的方法达成了共识，也没有好的方法来强制、监视或嵌入API以确保遵守。

服务设计和维护的不一致方法还有另一个意想不到的影响：破坏更改。在自由格式的API环境中，您不能完全理解对合同进行更改的下游影响。这也是反向的；与仍需要更新的服务器交谈(包括在滚动更新期间)的客户端可以发送服务器不理解的请求。作为一个组织，没有一个很好的方法来解决这个问题。您要么希望该服务持续破坏用户，要么开发某种内部流程来更好地管理合同更改。许多团队避免完全进行更改，而是选择只在需求更改时添加他们的API。无论如何，相当多的时间浪费在内部通信上，API漂移，用户仍然中断。归根结底，团队希望并需要对API演进进行更严格的管理。

许多团队避免完全进行更改，而是选择只在需求更改时添加他们的API。无论如何，相当多的时间浪费在内部通信上，API漂移，用户仍然中断。归根结底，团队希望并需要对API演进进行更严格的管理。

现在是业界从自由形式方法转向所有API都以编程方式使用模式定义的时候了。模式驱动开发解决了上面总结的许多挑战。API更容易理解，而且从第一天起就可以依赖。组织可以在多个团队中设置和执行API标准。服务所有者可以根据需要对其服务进行更改，并建立更多的结构以防止客户端中断。

这已经是一个重大改进，但是模式提高开发人员生产率的机会要大得多。与静态类型语言为工具带来新潜力以提高开发人员生产力的方式类似，模式驱动开发的主要承诺是模式可以自动生成的资产。这是一个大到足以在另一篇文章中探讨的主题，但可以说，依赖模式可以自动化实际与服务交互所需的所有样板代码。

如今，模式驱动的API协议有时被视为只有在性能重要时才使用的协议。类型化语言需要工具来支持它们的采用，同样，需要一个工具生态系统来支持模式驱动的API协议的使用。

我们BUF认为，目前模式驱动开发的最佳选择是协议缓冲区(我们将在未来的文章中探讨这一主题)，我们正在努力构建这样的工具来支持使用Protobuf定义其服务的组织。我们希望，有了这种工具，团队将把目光投向API模式，以获得全面的生产力提升，而不仅仅是性能。