深入探讨：如何设计优雅而强大的 API 接口？
- 作者
无论我们意识到与否，我们在网络服务和应用程序编程接口（API）的世界中无处不在，但许多 API 的使用却令人头痛。你是否曾经使用某个外部服务的 API 连接时心想：“他们到底在想什么？”我们有过这样的经历，通过 API 连接服务可能会令人困惑。不管是因为设计不佳、文档缺失、频繁变更还是存在 Bug，使用 API 往往都是一种挑战。
但事实并非如此。我们可以创建令人喜爱的、出色的 API，我们也会享受制作它们的过程。那么，设计一个好的 API 的关键是什么呢？这篇文章分享了秘密，指导我们创建一个干净、文档完备、易于使用的 API。
准备好了吗？让我们一起了解如何设计一个让人们喜欢使用的 API。
设计一个良好 API 接口的重要性
API 对于公司来说至关重要。客户不会轻易使用 API——他们投入了时间和金钱来进行集成、编码和学习。然而，过度依赖 API 也会带来挑战。停止使用 API 的成本可能很高，这显示了 API 在运营中的关键作用。
设计良好的公共 API 具有吸引和保留用户的巨大潜力。然而，糟糕的 API 设计很快就会导致问题——比如因 API 故障而导致的大量额外的支持。这可能会将公司最重要的数字资产变成头疼的问题。
API 的这种双重性质凸显了在设计它们时的关注和精确性的重要性。目标是打造出比缺点更多的好处的 API。
当我们构建产品时，通常会考虑到没有太多技术专业知识的普通人。我们创建友好的界面，征求他们想要什么的意见。但 API 开发是不同的——我们正在为熟练的程序员创建接口。他们甚至会注意到微小的问题，可能和我们一样挑剔。
作为 API 设计者，我们的视角与用户的视角略有不同。我们专注于 API 应该做什么或提供什么。与此同时，用户关心的是以最少的努力轻松地获得他们所需的东西。这种不同的观点会引发问题。关键在于调整我们的观点，使之与用户的观点相匹配。这似乎很明显，但很少有 API 采用这种以用户为中心的方法。
良好 API 的特征
良好 API 具有几个特征：
- 学习门槛低 - 用户可以很快的知道这个接口的功能
- 简单易用 - 即使在没有文档的情况用户也知道大概怎么使用
- 足够健壮 - 很难被错误使用
- 可读性和可维护性高 - 接口足够清晰和便于维护
- 容易扩展 - 方便添加合理的新特性
既然我们已经讨论了什么是好的 API，让我们继续了解如何设计一个好的 API 的技巧。
准确的实现需求
设计优质 API 的第一个关键步骤是从用户那里收集需求。对此过程要持怀疑态度。用户经常提出具体的解决方案，而不是专注于他们潜在的需求。
我们的工作是让用户向我们展示核心用例，以发现那些初始看来隐藏的根本需求。在最初的“解决方案”之下可能潜藏着更好的设计思路。
此外，想象非常灵活、可以解决各种挑战的 API 令人兴奋。但我们必须始终专注于用户的实际需求。
开始设计过程时，起草一个高层次的功能规范。在这个早期的实验阶段，速度和灵活性比详细的细节更重要。
广泛分享草稿，既与目标用户又与其他利益相关者分享。倾听反馈意见，因为可能会有宝贵的见解，帮助塑造一个精细的产品。
关键在于不要在早期就做太多假设。需求收集为产品打下了基础——在进行正式的 API 设计之前，花时间确保它正确无误。
只实现一个功能
设计优秀 API 的关键规则之一是，每个 API 应该专注于非常好地解决一个主要问题，而不是试图解决太多不同的问题。
创建一个通用的“瑞士军刀”API，试图涵盖许多用例往往会失败。范围过于分散，没有与特定用户需求紧密联系的明确、独特的目标。试图成为每个人的一切结果往往导致功能浅显。
相反，限制我们构建的每个 API 的范围。确保目的明确而专注。将所有能力直接对齐到满足明确用户需求的目标。任何辅助功能都应该被移除。
例如，一个专注于地址验证的 API 有一个明确的目的。一个专注于信用卡交易的 API 定义了不同但仍然狭窄的功能。
一致性
让我们探讨一些有助于 API 整体清晰和一致性的有效命名实践和标准化响应。
清晰易懂的命名
在设计一个好的 API 时，清晰性始于我们为端点和资源选择的名称。采用并始终应用命名约定使开发人员能够直观地理解 API，就像说一种通用的语言一样。例如，使用 RESTful 约定来命名像“/users”这样的端点以检索用户信息符合行业标准。这帮助开发人员在不需要过多文档的情况下理解端点的目的。
分享内容