今天，有各种各样的工具、技术和平台可以帮助开发人员设计API。尽管资源丰富，但API设计中仍然存在一个很大的问题：如何给API命名。这听起来简单，但命名本身也需要一套可持续、稳定、可靠的设计流程来定义API识别、分类和命名的原则。总之，这件事绝非很多人想象的那么容易。在《API设计模式》中，作者兼Google软件工程师JJGeewax称命名API开发人员需要学习和掌握的众多关键设计因素之一。合理的API命名约定不仅可以提高API的可访问性和用户友好性，还有助于避免API在使用过程中出现的许多令人头疼的问题。Geewax名字之谜提到API的名字之所以如此重要，是因为API的功能往往取决于它与用户交互的能力。用户在访问过程中，常常通过API名称来快速判断要接收、查看或操作的信息类型。此外，这些名称还可以表明技术组合中的哪些API彼此直接相关，或者旨在处理哪些请求类型。在本书的第三章中，Geewax讨论了API命名方法的意义：在传统的编译代码中，我们的函数和变量名称只影响那些有权访问源代码的人。在编译（缩小）和部署之后，这些名称通常会完全消失。在设计和构建API时，名称的选择更为重要，因为它们负责表示和描述所有API用户将看到和交互的内容。Geewax还强调，最好在开发初期就确定好API的命名模式，甚至可以考虑将命名作为开发的第一步。开发人员应对API命名实践设定期望，特定名称的选择最终将影响API组合的管理方式。例如，特定API对应的特定名称会影响开发者在后续版本更新或新需求出现时，可以为新API使用的特定名称。API组合越大，开发者就越难在不影响原有系统的情况下更改命名方案。API名称：好的和坏的Geewax在《API设计模式》中提出的命名实践基本上围绕着同一个中心主题：API名称有好有坏。一个好的API名称不仅要减少冗余，还要尽量减少用户理解的难度。而且不好的名字还可能误导用户，导致他们产生误解，找不到自己最需要的API。在极端情况下，糟糕的名称甚至会导致冗余构建，浪费宝贵的应用程序资源并增加不必要的开发成本。在书中，Geewax以一个存储用户账户偏好的API为例，并提到如果开发者简单地将API命名为APIPreferences，用户将很难理解API在上下文中的作用。在这种情况下，像UserPreferences这样的名称显然更适合确保用户准确理解他们正在处理的内容。另一方面，名称过于具体也不是一件好事。假设开发人员将用户首选项API命名为SingleUserAccountPreferences，用户可能想知道该API是存储许多用户的个人首选项还是仅存储单个用户的首选项。如果恰好是后一种解释，开发团队甚至可以为每个单独的帐户单独构建API。所以，UserPreferences是最好的选择，详细明了。API命名特点在命名API时，开发人员实际上可以灵活地使用它。毕竟命名约定不像程序代码那样有严格的语法和结构要求。但是，灵活并不意味着一切都可以作为名称。如果同一事物也有多种表达方式，我们往往会混用这些表达方式，这最终会导致命名规则复杂且不可预测，同时也会让用户难以区分不同API之间的联系和区别。为此，我们必须控制住灵活表达的“诱惑”，给自己强加一些命名规则，避免破坏API名称良好的可预见性。当然，什么是清晰，什么是简单，如何在两者之间找到平衡，还要看项目的特点。几乎不可能找到一种万能的解决方案来应对各种考验和磨难。作为指南，Geewax结合API设计原则提出了API名称应体现的三个特点：;简单性：名称除了具有表现力外，还应在每个特定部分提供合理的价值；可预测性：这意味着API名称应该易于理解并遵循清晰的命名模式。那么，开发者如何保证API名称满足这三个条件呢？Geewax的回答是确定API命名的四个通用实现原则。第一，美式英语优先。虽然肯定会有例外，但最好使用美国英语作为API名称，这也是编程世界中最受全球认可的语言。如有必要，提供本地化文档始终是个好主意。其次，注意使用正确的语法。虽然简洁的语法很有吸引力，但最好在API名称中坚持使用正确的语法。例如，使用正确的拼写并注重正确使用单数和复数名词。这不仅有助于准确表达API的功能，还可以降低用户混淆的风险。第三，句法同样重要。语法规定了API名称中单词的顺序。在大多数开发场景中，语法应遵循以下三种标准格式之一：camel、snake和kabab。最后，确保包含上下文。理想情况下，API名称应该提供一些关于框架或程序类型的提示。如果API名称在不同的上下文中可能有不同的含义，那么添加上下文以消除误解的可能性是个好主意。
